Define Claude Code and Coding Assistants

0:00Welcome back to skill two in the Claude Certified Architect Foundations course.

0:06So far, we've explored basically installing Claude Code.

0:10And for those of you that are coming from a background where you've been using chatbots

0:14to program, then you're going to definitely find Claude Code to be a force multiplier.

0:19And there are other agentic coding solutions like Cursor, Copilot, and others.

0:24But now in this skill, we're going to do something interesting.

0:27The one thing I did want to do is go a little bit deeper into the Claude.md and show you that

0:33there are different versions and we'll ask Claude to do that first.

0:36But moving forward, we're going to talk about what happens behind the scenes.

0:40Because we're working in a CLI and you see Claude Code doing stuff and you see the files

0:46get edited and it asks and it plans, but what is it really doing?

0:50Is Claude Code actually editing the files directly?

0:54And the answer is no.

0:56And that's what we're going to talk about in this skill because it's fascinating to

0:59understand how these models actually make changes.

1:03And the keyword here are tools.

1:06So in the first skill, we install Claude Code, use the official documentation,

1:11review the terminal workflows, and set up our original project,

1:15Claudey or not, the simple weather app.

1:17And now we're going to define Claude Code and coding assistants.

1:21So that means that we're going to be using Claude Code as a coding assistant.

1:25So we're leaving installation behind and now really shifting gears into a mental model.

1:31And like I said, a chat assistant can talk about code,

1:34meaning a chat bot, but Claude Code can work directly inside of a project,

1:40inspect files, and like I said, use tools.

1:44It can even run commands, propose changes, edit files with permission.

1:49We're going to get into those permissions a little bit more,

1:51and it will help you verify the results.

1:55So the flow is usually something like this.

1:58You start with a chat assistant, and then you move into a coding assistant.

2:05And we know what happens here.

2:07You go into some kind of a tool or a chat bot.

2:10We could call this Claude, which is Anthropics chat bot.

2:14And you would copy and paste into your IDE or wherever you're writing code.

2:20That could also include Jupyter Notebooks or Google Colab.

2:25But those tools have their own chat assistants.

2:29And some of them are actually coding assistants.

2:32But to understand what's happening behind the scenes for a coding assistant,

2:36we need to understand tool use.

2:38And by the end of this skill, you'll be able to explain

2:41what makes Claude Code different from a normal chat bot.

2:45And you'll also be able to write stronger prompts

2:47that guide you through safe and verifiable work.

2:51That is really important.

2:52So now let's make a connection to system architecture,

2:55because Claude Code is a great example for an AI system with tools.

3:02And throughout this course, we're really going to get into tool use,

3:05because that is really at the heart of AI agents and agentic systems.

3:10But for an AI system to use tools, it needs context.

3:15And that is key.

3:16That's why we started with Claude.md,

3:19and why we're going to go into that a little bit more.

3:22And we also were able to focus contents using the at command.

3:27So at a file or at certain contexts.

3:31And what might be surprising is that the model

3:34does not directly edit the files by itself.

3:37So at that point, you might be asking, well, wait a minute.

3:40So isn't Claude Code actually editing the code?

3:43Because we saw that in the last skill.

3:45And well, that's why we're going to go behind the scenes,

3:48because it looks like that.

3:49What it's really doing is requesting actions through tools.

3:54It's an AI system that has tools,

3:57meaning the chatbot part of Claude will actually talk to

4:02a system that actually manages the tools.

4:05So there's this conversation happening between different parts of the AI system.

4:11So the big picture is that the system is going to run tools in a controlled environment.

4:17And you remain in the loop by approving changes,

4:19reviewing plans and checking the outputs.

4:22And that's the architecture pattern that I want to make clear.

4:26So we have model reasoning, then tool request,

4:30and then tool execution, then tool result.

4:35And then here, the model will consider the next decision.

4:42And then finally, the last step is human review, which is the most important.

4:46These are very powerful tools, but they sometimes get really simple things wrong.

4:52And that's called jagged intelligence.

4:55And there is a classic car wash problem that doesn't work on every model.

4:59But when you ask it, and this is the classic problem

5:02that we use to explain jagged intelligence.

5:05If you ask a chatbot, and you should try this with maybe not Opus 4.8,

5:10but maybe Sonnet and earlier models to see if you can replicate it.

5:14You can say, I need to wash my car.

5:16There's a car wash 50 meters away.

5:19Should I drive or should I walk?

5:21And it would say, well, clearly, you should walk because it's

5:25and it would give you reasons as to why it's closer.

5:27And it would take longer to get in the car, find parking and so on.

5:31But it misses the most common sense part,

5:33which is, well, the whole point of this is to get your car washed.

5:36And that's why the human review is important.

5:40But while it gets that simple common sense problem wrong,

5:44it can do really incredible things like fine tune machine learning models

5:48using many deep neural layers.

5:50But it fails to understand the context that you need to get your car washed.

5:55And so that's just one example that we use to talk about

5:58why human review is so important.

6:00While the car wash problem has generally been solved,

6:04jagged intelligence is still a real thing.

6:06It comes up all the time.

6:08And one more thing I'm going to say about this pattern down here.

6:12This is going to come back later when we get into MCP hooks,

6:16GitHub workflows and the cloud code SDK and also agent style systems

6:21when we start to build agentic systems.

6:23So this is a very important pattern.

6:25So you're probably asking, OK, so what are we going to cover in this skill?

6:28Great question.

6:29So we're going to first talk about coding assistant

6:33or coding assistance in general and build a mental model

6:37because they're different from cloud code

6:40compared to chat only assistance, right?

6:43What's happening behind the scenes?

6:45And then we'll get into the good stuff, tool use and cloud code

6:50because that is abstracted.

6:52You don't really see it grabbing tools and doing stuff, right?

6:56And there are quite a few built in tools.

6:58So we're going to explore the major tool categories.

7:02And these are the tools that cloud code can use.

7:06And then we're going to talk about prompts and how to guide cloud code safely.

7:13Again, jagged intelligence and other reasons are why we need to make sure

7:17that we're doing the best job that we can in prompt engineering

7:22to create the best output for cloud code.

7:26And we're going to continue to talk about project context.

7:30And we'll do that using the cloudy or not app.

7:33And then we're going to get into some pretty cool stuff.

7:36So performance style workflows and also data analysis style workflows.

7:44And then we're going to have our challenge.

7:47And again, you'll see this in every skill because we're looking

7:51and aiming for these small iterative learning curves

7:55because that is the best way to understand the concepts

7:58in the cloud certified architect foundations course.

8:01All right.

8:01So on that first note, we're going to talk about coding assistance in the first video.

8:06And if you thought that there was only one, well, there's three.

8:10And they have three different roles.

8:13See you there.

0:00Before we get into cloud code,

0:01I wanted to make sure that we understood the difference between each one of

0:05these different markdown files,

0:08because context is key when working with cloud code.

0:12So when looking at this first one right here,

0:14we know that the cloud dot empty file is where you give cloud persistent

0:19project instructions. So instead of repeating the same guidance,

0:24every time that you open cloud code,

0:26you simply write those instructions once and let Claude use them as part

0:31of its project context.

0:33So this is project level and we usually

0:38create this like we did in the last skill with this slash init command,

0:42right?

0:43Meaning that this file is going to live inside of the project and should be

0:47committed to source control.

0:50And more importantly is what you share with other engineers.

0:54And like you saw in the last scale,

0:55we use this for instructions that apply to the whole projects,

0:59such as how the app is organized, which commands to run,

1:02how to test work and what conventions Claude should

1:07follow when editing the code.

1:09And now we have Claude dot local dot MD.

1:12And this is the personal level. And by personal level, I mean,

1:16it's not meant to be shared with the team.

1:18So you can use it for your own preferences, local setup notes,

1:22or temporary instructions that help Claude work with your machine

1:27without adding those details to the shared project, because well,

1:31your machine is not going to be the same machine as your team's machine, right?

1:35And you would not share this.

1:38So you might use something like get ignored to make sure that you're not putting

1:42that into the repository for your team or for your project.

1:47And finally, we have till they slash dot Claude slash Claude dot MD.

1:51And this is if you guessed it global level,

1:54and this applies to projects on your machine.

1:58So you can think of the global scope or the global level as applying

2:03to projects all across your machine.

2:06So use this for broad instructions that you want Claude to follow everywhere,

2:11such as general coding preferences,

2:13review style and how you like Claude to explain changes.

2:18So to zoom out, Claude dot MD are the files that help Claude

2:22start with better context, and that's why I'm saying that context is key.

2:26So for this course, we're really just focusing on number one.

2:30We mostly care about project level because that is the shared memory

2:34file for Claude or not app.

2:36That's the project that we're using.

2:38And it helps Claude understand the project structure,

2:41the different testing commands, as we saw in the last skill

2:44and the workflow expectations before we ask it to make changes.

2:49All right. So now that you know what this is,

2:51let's go ahead and try this out in Claude code.

2:54All right. So I have here in Claude code, a simple project prompt.

2:59So look at this project and create two files.

3:01One, the local number one Claude dot local dot MD.

3:06And this is the personal level.

3:08So we're going to create this in the project route.

3:10So it says personal overrides this project only.

3:13And it's not committed.

3:15Include things like my current focus, local workflow preferences

3:19and any environment notes specific to my machine.

3:22And then number two, we're going to do the global sort of preferences.

3:26And that's what it says here that should apply across all my projects.

3:29Not just this one include coding style,

3:32commit message format and how I like Claude to communicate.

3:36Do not create or modified Claude dot MD because we already have it down here.

3:40It already exists.

3:42So before writing each file, show me what you plan to put in it

3:45and wait for my approval.

3:47All right. So what we're doing here and you don't have to do this part.

3:50I'm just doing this so that you know how to do this moving forward.

3:54And I'm just going to demo it.

3:55So for this course, we only need the Claude MD that we generated

3:59in the previous skill.

4:00But I think this is pretty important to know.

4:03So let's go ahead and hit enter.

4:05So it's asking here, let me read the project and existing

4:08Claude configs before I draft anything.

4:10And let's go ahead and press number one for yes.

4:13And we're just going to say number two so that it just keep reading as it needs.

4:17And I believe that's a safe option.

4:19So nothing that's going to be written so we can just let it continue to read.

4:24And now it's creating those two files.

4:26So we have the personal and the global.

4:29So two questions before I write.

4:31There's a current focus in Claude dot local MD learning

4:35Claude code workflows accurately describe what you're working on.

4:39And for right now, we're not going to worry about that.

4:41And number two, is there anything you'd like to add or cut

4:43from the global preferences?

4:44And we're not going to really change anything.

4:47No, I'm going to say no.

4:49Go ahead and create these.

4:52OK, so now it's open the changes in Visual Studio code.

4:56Do you want me to create the local?

4:59I'm going to say yes and yes for that one, too.

5:02So I'm going to ask it a question here.

5:04Where is this is supposed to be at the root directory.

5:07Let's ask it a question.

5:09All right. So again, opened it over here.

5:12Here are the global references.

5:13And you can see that it's in Claude.

5:15And I'm going to close this and see if we can run it here locally.

5:19And I'm going to say yes.

5:21And there we can see the global preferences.

5:23So this is different than this one here.

5:27So this is the file guidance

5:30when working on this project.

5:32And here we have global Claude preferences.

5:35So this is you can see communication style, coding style, commit messages.

5:40And if we look at the local, these are personal overrides.

5:43And now we've covered all three.

5:46And so they're in different locations.

5:47So I just wanted to share that with you.

5:49So let's go ahead and clean this up.

5:51So I'm saying, great.

5:53Now, delete global and local files.

5:58And we can also use shift tab. Right.

6:00So except edits, plan mode and auto mode.

6:04And we're just going to use except edits on.

6:07And we're going to say, great.

6:09Now, delete global and local files.

6:11And what's important here is that I gave you a very vague prompt,

6:16which is a little dangerous. Right.

6:18But as you can see here, because we have the edits on,

6:21you can actually see what is the context.

6:25So I get scared when I write very, very vague prompts like this.

6:28But we're going to write good prompts in the rest of this course.

6:31And that's a little introduction.

6:33So we're going to say, yes, go ahead.

6:36Well, in this case, we got a API error and that's OK.

6:39So what we're going to do is just manually delete these

6:43because we've already covered them.

6:44And I'm going to also go over here and view the hidden files to delete this one.

6:50All right. So I deleted them and I just wanted to confirm that they are gone.

6:53And then I think that's probably it for this video after it's done envisioning.

6:58All right. So there's another API error.

7:00So what I'm going to do is just exit and start again.

7:04OK, so I know that I've confirmed that I've deleted those files.

7:07So we're good to go.

7:08So I will see you in that next video where we compare chatbots

7:12to coding assistants and make a mental model.

7:15See you there.

0:00Welcome back. In this video,

0:01we're going to explore the coding assistant model to build that mental model,

0:07because it's totally different from a chat bot.

0:10And also it abstracts how it's actually changing your code,

0:15meaning how it works through the code base using these tools.

0:19So here you are and you ask a question and let's say that you're asking for a

0:24change. And again,

0:26this is in the context of the cloudy or not app. So our simple weather app.

0:31So what happens next? Once you ask that question,

0:35it goes into cloud code, which has two main parts.

0:40And we know that cloud code is a language model, but the busy,

0:44and we know that cloud code is a language model,

0:47but the biggest mistake that people make with cloud code is treating it like a

0:52normal chat bot or like a lamp or like a language model.

0:56And that's because a chat bot can answer questions.

0:59But a coding assistant is working inside your project,

1:03meaning it's going to inspect files, understand project structure,

1:07even run terminal commands,

1:08edit files and use the feedback from those actions to decide what to do next.

1:15So when you ask it a question,

1:17what you're doing is really providing a goal.

1:20And then Claude here, as you see in this first step,

1:24we'll now talk to another component and that's how it gathers context and then

1:29proposes a plan. And then it decides, maybe I need to use a tool.

1:34And so this is where the tools live in.

1:38The tools are another language model that has access to tooling, right?

1:42So there's multiple steps and multiple models talking to each other.

1:48Cloud code is really handling the context,

1:51the planning, and then it decides, Hmm,

1:55I need to use a tool and then it'll use those tools by talking to another

1:59language model that has access to these tools.

2:02And then it'll see what the tools did,

2:05meaning it'll receive information back so that it can look at the results and

2:10then it might iterate.

2:11And that's why I have here an arrow going up and down between the language

2:15model and between the tools. So let's say that we define this goal here.

2:21Let's say add wind speed to the weather report, right?

2:25And then we give it context, right? And that's still here.

2:28And this is inside of our prompt.

2:29We can at mention maybe data slash Austin dash forecast dot JSON,

2:36right?

2:36Or maybe the source files for the JS files that are the analyzing forecast or

2:42the format of the weather report.

2:44And then cloud knows that in order to verify it can run NPM test and NPM start.

2:51And that's where the tools come in.

2:53So we have a goal and we're specifying the context with these at commands and

2:58that goes from us into cloud code,

3:01but then it starts to iterate here with the tool use.

3:04And that's really the biggest different. So what's really happening here.

3:08So number one, it gathers context.

3:12Number two, it makes a plan and we've seen it do this.

3:16You can actually see how it thinks. And then once it makes a plan,

3:19it might ask you if it can take action.

3:24And then number four, once it takes action,

3:27meaning it starts to use some kind of tools,

3:30then it can observe the results. And then at that point,

3:34it can iterate until it accomplishes the goal.

3:37So the main difference here between a chat bot and a coding assistant is that

3:42the chat bot talks about code and the coding assistant works on the code base

3:47using these tools. So that's model plus environment plus tool,

3:52plus context and permissions,

3:54which we already discussed in the last skill in the beginning of this skill.

3:59And here is probably one of the most powerful parts.

4:03Cloud code is most useful when you give it a clear goal,

4:07the right project context and a verification step.

4:11We're going to learn more about that when we get to prompting.

4:14Now you're probably saying, Hmm, okay, great. So uses tools,

4:18but what is happening when it starts to use tools?

4:22They goes back and forth. And I understand that.

4:24But what is happening when it starts to use tools?

4:28It goes back and forth. And I understand that we're gathering contacts,

4:31making a plan, taking action,

4:33but then what happens in between these two steps? It takes action.

4:36Then it observes the results.

4:38So now we want to peer inside of this part tools.

4:43Let's explore the tool use workflow next. All right.

4:47So we have you here and then now Claude code here,

4:52which is the language model. And then we have Claude.

4:56So I'm going to draw these three lines so we can see what action

5:00touches each one of these. So let's take step number one.

5:04So you're going to ask a question. So let's say that you ask what logic decides

5:09if Austin is cloudy or not.

5:13So that goes from you. So this is this first query,

5:17and that goes from you to Claude code. Then what happens next?

5:22So that's this point. Okay. I'm going to just write number one here,

5:26number two here. So we know what's happening. So number two,

5:29Claude code is going to send the question and tool instructions to Claude.

5:34So from Claude code to Claude, and that's what I was talking about.

5:38So you can consider Claude code is the language model and Claude is actually

5:43doing the tool use. And so here for number three,

5:47it calls a read tool.

5:50So it might read source, analyze forecast dot JS,

5:55because that is a tool call.

5:57And then it sends that to Claude code and then number four,

6:01Claude code reads. Okay. So that is the main distinction.

6:06So now Claude code has this context because it was able to read that.

6:11And then Claude code will return the file back to Claude.

6:15So it returns file content and then

6:20number six. So let me write, this is three, this is four,

6:24this is five. And then you get this answer finally here,

6:29which would be number six, which is the return answer.

6:33So the takeaway here is that you are talking to Claude code,

6:37but Claude code talks to Claude and Claude is really using

6:42the tools.

6:43So it does the reasoning and the tools and then sends that back to Claude code.

6:47So they're sharing this responsibility.

6:50So when we take this back to the Claudia or not app, you,

6:53the user would ask about forecast logic, then right here.

6:58And that means that Claude is going to actually read the source file and

7:03then the data file if needed,

7:05and then explains the relationship and it might suggest the change.

7:10And then you decide whether to prove it,

7:12but there is this back and forth here that's happening until it reaches the

7:17goal. And that goal comes from your original query.

7:22So tools are really just capabilities. It's not magic, right?

7:26Now you know that Claude code has access to tool categories that let it work

7:31within a code base, depending on the version, configurations, permissions,

7:35and environment tools can include many different things.

7:39And that's what we're going to explore in the next video.

0:00At this point, you might be asking,

0:01why are we going into tools so much?

0:04It is interesting to understand

0:06that we are speaking to multiple agents,

0:09not just to Cloud Code,

0:11but Cloud Code then talks to Cloud,

0:13who has access to different tools.

0:15And the reason is not just for Cloud Code,

0:17but when we get into the API section

0:20and start to build agentic workflows,

0:22that is precisely where we get into tool calls

0:25into much more detail.

0:27So this is really relevant for Cloud Code,

0:29but also much more relevant for the rest of the course

0:33when we're thinking about system architecture.

0:37All right, so now let's make a list of tools

0:40and their purpose.

0:42So the first one that we explored,

0:44well, we already know what this does.

0:45This basically reads a file.

0:48So you would talk to Cloud Code,

0:49Cloud Code would talk to Cloud,

0:51and then Cloud would use this tool to read a file.

0:55But there's another tool that's for editing and writing.

1:00So you might be surprised to know,

1:01wow, these are actually separate tools.

1:05So this is to modify or even create files.

1:10And we also have a bash tool.

1:12So this is for running shell commands.

1:16And then we also have glob and grep.

1:20So if you already know what grep is,

1:22well, let's talk about both.

1:24So glob finds files.

1:27So I'm gonna say find by pattern.

1:31And grep will search file contents.

1:36And there's also notebook tools.

1:39And this is for both reading and editing.

1:45And again, this is for, you know, like notebooks,

1:48like Google Colab or Jupyter Notebook more specifically.

1:53But there are many other tools like to do right.

1:56And that is gonna track multi-step work

1:59and web fetch and web search

2:01so that you can bring in web content.

2:03And then finally, we have an agent tool.

2:06So this will launch a sub-agent for a focus task.

2:10So let's say launch sub-agent.

2:13So why am I showing you all of this?

2:15Well, the takeaway is that tools shape

2:17what kind of work Cloud Code can do.

2:21And when we get into the API later,

2:24this is where you really get into these

2:26because you're going to choose tools

2:28that are specific for an application for production.

2:33So this is the system architecture part.

2:36And well, we really need to know how this works

2:38with Cloud Code well before we get

2:40into architecting our own solution.

2:42Let's say that we give Cloud Code a task,

2:44add wind speed to the report.

2:46So what relevant tools do you think will be used?

2:50Well, first of all, it would read.

2:52So it needs to read the data

2:54but it's also gonna read analysis logic

2:57and then it's going to edit.

2:59So it might edit the report formatter

3:02or even write or run tests

3:06and it might even run shell commands.

3:09And it might even need to search file contents

3:12or find patterns.

3:13And so it's already using a bunch of tools, right?

3:16So a capable Cloud Code workflow

3:19is not just asking for an output,

3:21it's guiding tool use toward a verifiable result.

3:26And so that brings us to prompting.

3:28In my other courses where I teach prompt engineering,

3:31there's always some kind of approach

3:34like context, role, expectation,

3:38ask to, and the different shots.

3:41For example, no examples, it would be zero shot.

3:43One shot would be one example

3:45and few shot would be two more examples.

3:48But for Cloud Code, we're gonna start with four phases

3:52that are really prompt engineering focusing on Cloud Code.

3:56So instead of asking Cloud Code

3:57to immediately modify the project,

4:00you can ask it to inspect first,

4:03then ask for a plan,

4:04then approve the edit

4:06and finally verify with project commands.

4:09So we will start here, number one with inspect.

4:13And that's where shift tab comes into play

4:16because you can choose the right mode.

4:19And here is where Cloud Code would plan.

4:23Then number three, we would have the editing phase

4:27and number four, verification, verify.

4:30All right, so let's go ahead and try this out.

4:32So I'm going to use inspect first.

4:34So I'm literally gonna say inspect

4:37and then I'm going to focus the context

4:41by saying at data slash Austin forecast dot JSON.

4:46Let's also choose a source file,

4:49analyze the forecast or source analyze forecast dot JS.

4:54And let's add another source file here for the format.

4:58And then I'm gonna say don't edit just yet.

5:03First, explain how the current weather is created.

5:08So, so far we've done inspect

5:10and now we're gonna do plan.

5:12So I'm gonna say then propose,

5:15let's say I'm gonna use the word plan

5:18to add wind speed to the app or to report I can say.

5:23And then most importantly, it's going to,

5:26before it edits, you need to approve it.

5:28So I'm gonna say after I approve the plan,

5:32update the code.

5:34This is where we're asking it to do the edit part.

5:37And then we're gonna ask it for verification.

5:40So update the code and test

5:42or let's say tests run NPM.

5:45And we don't really need to add this

5:46because it knows from the cloud dot markdown file,

5:49but I'm gonna be very clear anyway.

5:52And then I'm gonna ask for a summary.

5:54Summarize the results.

5:56So you could try this without NPM run or run NPM test.

6:02It would know that it has to do that.

6:03So if you wanna take that out

6:05and compare my output to yours,

6:07we're both working in different ways to learn more.

6:10So I think that's a cool experiment.

6:12Okay, so you can also use shift tab.

6:14So accept edits on or plan mode on, auto mode on.

6:21So let's do accept edits on.

6:23Okay, now let's run this.

6:26All right, so here we go.

6:27Now I'm gonna make this a little bit bigger here like that.

6:31All right, so how the current report is created.

6:34The data flows through the three pure stages.

6:37We already know this, so that's good.

6:38All right, observation.

6:40And you can also make it more concise.

6:43Something that is really powerful to do

6:44is to say answer under 250 characters.

6:48It's a good way to keep your token spend a lot lower

6:52because it's gonna spend a lot of tokens

6:54and then Anthropic makes a lot of money.

6:56So if you've also been reading the news,

6:58these token costs can get out of hand.

7:00And so not only are you paying for the token costs

7:04for the prompt, but for the reasoning that you don't see

7:06and then the output.

7:07So it's a lot higher than you think.

7:10When we get into the API, we're gonna manage token costs,

7:13which includes reasoning tokens.

7:15And you'll learn a lot about that then.

7:17But for right now, you could also just say,

7:20make sure to keep this under 250 characters

7:24or 500 characters, something like that,

7:26because this is a little bit verbose.

7:28So I didn't do that,

7:29but you could also add that into the mix.

7:32And so here's the plan.

7:34Check the existing text configuration, which is untested,

7:38and then add one mile per hour assertion

7:41to analyze forecast tests.

7:43So it verifies a pass-through and then you add wind

7:46and then you run NPM tests.

7:48Okay, so this is great.

7:49So wind speed is already wired up end to end.

7:52So all we have to do is test it.

7:54Cool.

7:55All right, so what else?

7:56So it's giving us some more observations,

7:59but now let's look on the plan.

8:01It's gonna check the existing tests to confirm

8:04because it's untested and then add wind speed assertion

8:07to the test.

8:09And then it's gonna add wind,

8:11which is a line assertion to another test.

8:13And then it's gonna run the tests

8:15and make sure that it passes all the tests.

8:17Okay, that's what I like to see.

8:19So here's the plan and you can see it again.

8:22I like this.

8:23Sounds good.

8:25And I'm gonna just say approved

8:27because that's the language that I used before.

8:29In this case, for some reason it's moonwalking,

8:32but now it's gonna run the test.

8:35And I'm gonna say, don't ask again for the tests

8:38because I'm okay with running several tests

8:40and it's continuing to moonwalk

8:42because Cloud Code is also a good dancer.

8:45And then here we go.

8:46All tests pass.

8:47All right.

8:48So it turns out the wind speed

8:49was already fully implemented and tested.

8:51You're welcome.

8:52I did that.

8:53So we're just testing things that I know are gonna work

8:55because we don't wanna get stuck in the weeds

8:58with having to fix tests,

8:59but we do want to know how to prompt.

9:01So this is Cloud Code prompt engineering.

9:05And one of the good things that we did

9:06that I really like is that we made sure

9:09that our prompt included good context, right?

9:12Because a good Cloud Code prompt

9:14should make it hard for Cloud to guess.

9:18You want to remove the degrees of freedom

9:21because if you don't, it's going to,

9:24I guess the technical word here is hallucination, right?

9:27We wanna mitigate hallucination

9:29by reducing the degrees of freedom.

9:31So you wanna make sure that your context

9:33is very focused and context management is key.

9:38So you wanna always point it to that evidence.

9:40And we did that.

9:42But let's say we wanna take it a next step further, right?

9:46So let's say review,

9:47and you really want to focus on what's really important.

9:51So let's say we can focus on the package.json

9:56and the index source slash index.

9:59And let's do that source, analyze forecast.

10:04And finally here, we're going to also in the source format,

10:09weather report.js.

10:11And then I want to explain,

10:13I'm gonna ask it in a new line,

10:15explain the app flow, which we already know

10:18from data loading the final terminal output.

10:23And now you see this habit that I want you to get into.

10:27What we're doing is choosing the files

10:30that match the task, right?

10:32And what does that mean?

10:33Well, we wanna point Cloud Code to the evidence.

10:37And so in this case,

10:38we are saying that we wanna know

10:39how the app will flow from the data

10:42all the way to the output in the terminal.

10:46And how do we do that?

10:47Well, we point it to package.json, the index,

10:50and we already know that this is the flow.

10:53So now we can just hit enter and it's newspapering

10:57because it's very smart.

10:59And you can also ask Cloud to create a to-do list

11:01when working on complex tasks.

11:03That's something that I do.

11:05All right, so here we go.

11:06It's pretty verbose, formatting, output, cool.

11:10So the key design constraint is that analyze forecast

11:14and format weather report are pure functions.

11:17No file reads, no logging, no mutations.

11:20All in out is isolated to index.js,

11:23which makes the two core functions straightforward

11:26to unit test with inline fixtures.

11:29Okay, perfect.

11:30All right, so I think we're done with this video.

11:32And next up, we're gonna do some workflow examples

11:35and we'll check out performance style workflows

11:39and data analysis style workflows.

11:41See you there.

0:00Now we're going to add goals and we're going to do that within workflow examples.

0:05And so we'll start here with performance style workflow because performance work

0:10is a useful pattern, even when the project is small, like Claudia or not.

0:15And we, we know that the point is not that Claudia or not app has a serious

0:19performance problem. It's tiny.

0:21The point is that cloud code should not optimize blindly.

0:24That's what we're going to study here. Good performance work is measured.

0:28First you run a baseline and then you find the slowest and most repetitive

0:36path.

0:37And then you make one focused change because you want to think like a

0:42scientist, you change one thing,

0:45and then you make one change and then you run the same check again.

0:50And the value here is the scientific method,

0:53because now you're going to compare before and after

0:57that one focus change. And we start with a goal.

1:02That's what I said we were going to do. And what does that goal make the,

1:07and I'm just going to say weather app faster.

1:10We're about to push this to production.

1:12So we want to make sure that Claudia or not is rocking. And how do we do that?

1:16Well, this is step one. So step two, and this is like a review.

1:22We send it off to cloud code because we created a prompt.

1:26We already know how to create that prompt and target and focus the context.

1:31And what happens inside of here, two things. So number one,

1:35we have an LLM and then we have tools and they're going to work together.

1:41These are different models. So one is cloud code. The other one is cloud.

1:45And remember they're working towards this goal. So what's going to happen?

1:49It's going to run benchmarks.

1:52It's going to find the slowest case and it's going to create a small

1:58reproduction.

1:59Then it's going to profile the code and it's going to improve the

2:03implementation run benchmarks again.

2:08And we're going to compare before and after.

2:11So this is exactly what we're talking about.

2:13Now you can see that it's going to do that,

2:16but now it has a goal in mind and cloud code works best when it has a goal.

2:21So we're going to measure first and verify after.

2:24And what's happening here in this section is really forecast parsing.

2:29It's using these tools to enable everything that we have right here.

2:35And that's again, in order to serve this goal. Okay.

2:38So let's try this out in cloud code. So I'm stating a goal.

2:41If you see a small improvement, that's the same small, safe improvement.

2:47Let's be careful here.

2:49I want you to propose it first. Don't change anything till I approve.

2:55Okay. So this is not enough. So what do we do?

2:58So we're going to give it a better goal.

3:01So I wanted to see if you thought that there was a problem here, right?

3:05So I made it vague on purpose. And if you were like, wait a minute,

3:09that's not really a great goal. So now we can do that.

3:12So I just wanted to show you the difference and kind of give you a little bit of

3:15goosebumps. If, if you felt like that was not a great prompt and kudos to you.

3:19So now let's make it better.

3:21So treat this as a performance style review and we're going to be very clear.

3:28So of cloudy or not app and what is the next step?

3:33Pause the video and think about it for just a second.

3:39If you said focus context, you are on the right track. So let's do that.

3:43Inspect at source,

3:46analyze forecast.js and data Austin forecast.json.

3:54And I'm going to say, don't edit just yet.

3:58And we also want to say, explain whether,

4:02and I hope it doesn't think I'm saying whether like W E A I'm sure it'll get it.

4:07So explain whether there is, but you see where I stopped. I was like, Hmm,

4:11maybe I should use another word. And also I misspelled it.

4:15Maybe that's why I was concerned. I don't know,

4:18but I like to be careful with these prompts.

4:20So explain whether there is any member what we talked about,

4:23repeated or unnecessary work in the current logic.

4:30If you see a small, safe improvement, propose it first.

4:33Don't change anything until I approve.

4:35Now what I'm going to do here is add one more line.

4:39Please be concise and stay under 400 chars limit.

4:47All right, let's see what happens. Now, this is what I'm talking about.

4:51That one little magical line is probably my most used little trick and prompt

4:56engineering here. It says,

4:59analyze forecast maps over daily three times map for high temperature and map

5:04for low and reduce for rainiest day plan a fourth reduced for average cloud

5:09cover. So the proposal is collapse all four into a single reduce pass and you

5:14compute all of these together. Safe change, pure function,

5:18same outputs approve question mark. Yes, approved.

5:23I like that. And I really do like how small this is.

5:26It's easier for me to read. Sometimes it might be too little.

5:29I mean the character limit might be too restrictive if you're doing something

5:33complex, but for this I thought this would be a good number and it turned out to

5:36be pretty good. So approved.

5:39Now it's getting into Star Trek and it started to beam. It's beaming.

5:43It's inference. Okay, so those are the changes. So you can see,

5:47and this is really cool because now you can see what it was and now what it is

5:51and all tests passed.

5:54And if you wanted to get into the big picture,

5:56what metrics are you using to evaluate performance?

6:01You could do that.

6:03These are things that now that you've defined all of the context,

6:06you can definitely do. Now for the next one,

6:09we're not going to do it in cloud code because we're not working with a

6:12notebook. We will be working with a notebook very soon.

6:17So I did want to at least talk about this because when you're working through

6:21most of the tests,

6:22it really helps to use cloud code to its fullest capabilities.

6:26So let's say that we have a CSV here, right?

6:31It's going to be rows and columns, but it's not going to look like this.

6:35The CSV is just comma separated text. Let's say that this is what we had.

6:40And I'm just drawing it like that to give the illusion that this is a

6:43spreadsheet type of information, but CSV is different kind of text.

6:48So in case you didn't know that now, you know, all right,

6:50so now what happens? So same thing, we send this to cloud code,

6:55which will first understand the data and then it's going to write

7:00and run code. So again,

7:02this is the tool use being leveraged for our notebook analysis.

7:07So I'm going to say notebook analysis. And so what it's going to do in this case,

7:12it's going to take the data and it's going to take the data and it's going to

7:17in this case, it's going to inspect the schema.

7:21And at this point, let me say one, here's two,

7:24it's going to write and run notebook cells.

7:29All right. So pretty familiar. If you're familiar with notebooks,

7:32then you'll see how this works. If not,

7:35you're going to definitely be familiar with Google Colab and a few skills from

7:39now. And then here it would explore patterns again,

7:43using tools. And then here might create a chart.

7:48And number five, summarize insights. All right.

7:52This is classic data analysis workflow.

7:55You use code execution as a feedback loop.

8:00And then this goes back here. Okay.

8:02And this is really the same thing for our cloudy or not app,

8:09but now with a different workflow.

8:11But I didn't want to say that you could also apply UI browser workflows.

8:15You can also use GitHub integrations.

8:18So you can actually use at mentions in a PR or open a pull request,

8:23right? So you would have cloud code, read context,

8:26review changes and maybe respond to feedback and post a report.

8:30These are all things that you can do for peer reviews and inside of GitHub.

8:35It's a very popular way to use cloud code. All right.

8:39So I think that's it for this video. And next up we have the challenge.