Define Claude Code and Coding Assistants

0:00Welcome back to skill two in the Claude Certified Architect Foundations course. So far, we've explored basically installing Claude Code. And for those of you that are coming from a background where you've been using chatbots to program, then you're going to definitely find Claude Code to be a force multiplier. And there are other agentic coding solutions like Cursor, Copilot, and others. But now in this skill, we're going to do something interesting. The one thing I did want to do is go a little bit deeper into the Claude.md and show you that there 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. Because we're working in a CLI and you see Claude Code doing stuff and you see the files get edited and it asks and it plans, but what is it really doing? Is Claude Code actually editing the files directly? And the answer is no. And that's what we're going to talk about in this skill because it's fascinating to understand how these models actually make changes. And the keyword here are tools.

1:06So in the first skill, we install Claude Code, use the official documentation, review the terminal workflows, and set up our original project, Claudey or not, the simple weather app. And now we're going to define Claude Code and coding assistants. So that means that we're going to be using Claude Code as a coding assistant. So we're leaving installation behind and now really shifting gears into a mental model. And like I said, a chat assistant can talk about code, meaning a chat bot, but Claude Code can work directly inside of a project, inspect files, and like I said, use tools.

1:44It can even run commands, propose changes, edit files with permission. We're going to get into those permissions a little bit more, and it will help you verify the results. So the flow is usually something like this. You start with a chat assistant, and then you move into a coding assistant. And we know what happens here. You go into some kind of a tool or a chat bot. We 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. That could also include Jupyter Notebooks or Google Colab. But those tools have their own chat assistants. And some of them are actually coding assistants. But to understand what's happening behind the scenes for a coding assistant, we need to understand tool use. And by the end of this skill, you'll be able to explain what makes Claude Code different from a normal chat bot.

2:45And you'll also be able to write stronger prompts that guide you through safe and verifiable work. That is really important. So now let's make a connection to system architecture, because Claude Code is a great example for an AI system with tools. And throughout this course, we're really going to get into tool use, because that is really at the heart of AI agents and agentic systems. But for an AI system to use tools, it needs context.

3:15And that is key. That's why we started with Claude.md, and why we're going to go into that a little bit more. And we also were able to focus contents using the at command. So at a file or at certain contexts. And what might be surprising is that the model does not directly edit the files by itself. So at that point, you might be asking, well, wait a minute. So isn't Claude Code actually editing the code? Because we saw that in the last skill.

3:45And well, that's why we're going to go behind the scenes, because it looks like that. What it's really doing is requesting actions through tools. It's an AI system that has tools, meaning the chatbot part of Claude will actually talk to a system that actually manages the tools. So there's this conversation happening between different parts of the AI system. So 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, reviewing plans and checking the outputs. And that's the architecture pattern that I want to make clear. So we have model reasoning, then tool request, and then tool execution, then tool result. And then here, the model will consider the next decision. And then finally, the last step is human review, which is the most important. These are very powerful tools, but they sometimes get really simple things wrong.

4:52And that's called jagged intelligence. And there is a classic car wash problem that doesn't work on every model. But when you ask it, and this is the classic problem that we use to explain jagged intelligence. If you ask a chatbot, and you should try this with maybe not Opus 4.8, but maybe Sonnet and earlier models to see if you can replicate it. You can say, I need to wash my car. There's a car wash 50 meters away. Should I drive or should I walk? And it would say, well, clearly, you should walk because it's and 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. But it misses the most common sense part, which is, well, the whole point of this is to get your car washed. And that's why the human review is important. But while it gets that simple common sense problem wrong, it can do really incredible things like fine tune machine learning models using many deep neural layers. But it fails to understand the context that you need to get your car washed. And so that's just one example that we use to talk about why human review is so important.

6:00While the car wash problem has generally been solved, jagged intelligence is still a real thing. It comes up all the time. And one more thing I'm going to say about this pattern down here. This is going to come back later when we get into MCP hooks, GitHub workflows and the cloud code SDK and also agent style systems when we start to build agentic systems. So this is a very important pattern. So you're probably asking, OK, so what are we going to cover in this skill? Great question. So we're going to first talk about coding assistant or coding assistance in general and build a mental model because they're different from cloud code compared to chat only assistance, right?

6:43What's happening behind the scenes? And then we'll get into the good stuff, tool use and cloud code because that is abstracted. You don't really see it grabbing tools and doing stuff, right? And there are quite a few built in tools. So we're going to explore the major tool categories. And these are the tools that cloud code can use. And 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 that we're doing the best job that we can in prompt engineering to create the best output for cloud code. And we're going to continue to talk about project context. And we'll do that using the cloudy or not app. And then we're going to get into some pretty cool stuff. So performance style workflows and also data analysis style workflows.

7:44And then we're going to have our challenge. And again, you'll see this in every skill because we're looking and aiming for these small iterative learning curves because that is the best way to understand the concepts in the cloud certified architect foundations course. All right. So on that first note, we're going to talk about coding assistance in the first video. And if you thought that there was only one, well, there's three. And they have three different roles. See you there.

0:00Before we get into cloud code, I wanted to make sure that we understood the difference between each one of these different markdown files, because context is key when working with cloud code. So when looking at this first one right here, we know that the cloud dot empty file is where you give cloud persistent project instructions. So instead of repeating the same guidance, every time that you open cloud code, you simply write those instructions once and let Claude use them as part of its project context.

0:33So this is project level and we usually create this like we did in the last skill with this slash init command, right? Meaning that this file is going to live inside of the project and should be committed to source control. And more importantly is what you share with other engineers. And like you saw in the last scale, we use this for instructions that apply to the whole projects, such as how the app is organized, which commands to run, how to test work and what conventions Claude should follow when editing the code.

1:09And now we have Claude dot local dot MD. And this is the personal level. And by personal level, I mean, it's not meant to be shared with the team. So you can use it for your own preferences, local setup notes, or temporary instructions that help Claude work with your machine without adding those details to the shared project, because well, your machine is not going to be the same machine as your team's machine, right? And you would not share this. So you might use something like get ignored to make sure that you're not putting that into the repository for your team or for your project.

1:47And finally, we have till they slash dot Claude slash Claude dot MD. And this is if you guessed it global level, and this applies to projects on your machine. So you can think of the global scope or the global level as applying to projects all across your machine. So use this for broad instructions that you want Claude to follow everywhere, such as general coding preferences, review style and how you like Claude to explain changes.

2:18So to zoom out, Claude dot MD are the files that help Claude start with better context, and that's why I'm saying that context is key. So for this course, we're really just focusing on number one. We mostly care about project level because that is the shared memory file for Claude or not app. That's the project that we're using. And it helps Claude understand the project structure, the different testing commands, as we saw in the last skill and the workflow expectations before we ask it to make changes.

2:49All right. So now that you know what this is, let's go ahead and try this out in Claude code. All right. So I have here in Claude code, a simple project prompt. So look at this project and create two files. One, the local number one Claude dot local dot MD. And this is the personal level. So we're going to create this in the project route. So it says personal overrides this project only. And it's not committed. Include things like my current focus, local workflow preferences and any environment notes specific to my machine.

3:22And then number two, we're going to do the global sort of preferences. And that's what it says here that should apply across all my projects. Not just this one include coding style, commit message format and how I like Claude to communicate. Do not create or modified Claude dot MD because we already have it down here. It already exists. So before writing each file, show me what you plan to put in it and wait for my approval. All right. So what we're doing here and you don't have to do this part. I'm just doing this so that you know how to do this moving forward.

3:54And I'm just going to demo it. So for this course, we only need the Claude MD that we generated in the previous skill. But I think this is pretty important to know. So let's go ahead and hit enter. So it's asking here, let me read the project and existing Claude configs before I draft anything. And let's go ahead and press number one for yes. And we're just going to say number two so that it just keep reading as it needs. And I believe that's a safe option. So 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. So we have the personal and the global. So two questions before I write. There's a current focus in Claude dot local MD learning Claude code workflows accurately describe what you're working on. And for right now, we're not going to worry about that. And number two, is there anything you'd like to add or cut from the global preferences? And we're not going to really change anything. No, I'm going to say no. Go ahead and create these. OK, so now it's open the changes in Visual Studio code.

4:56Do you want me to create the local? I'm going to say yes and yes for that one, too. So I'm going to ask it a question here. Where is this is supposed to be at the root directory. Let's ask it a question. All right. So again, opened it over here. Here are the global references. And you can see that it's in Claude. And I'm going to close this and see if we can run it here locally. And I'm going to say yes. And there we can see the global preferences. So this is different than this one here.

5:27So this is the file guidance when working on this project. And here we have global Claude preferences. So this is you can see communication style, coding style, commit messages. And if we look at the local, these are personal overrides. And now we've covered all three. And so they're in different locations. So I just wanted to share that with you. So let's go ahead and clean this up. So I'm saying, great. Now, delete global and local files.

5:58And we can also use shift tab. Right. So except edits, plan mode and auto mode. And we're just going to use except edits on. And we're going to say, great. Now, delete global and local files. And what's important here is that I gave you a very vague prompt, which is a little dangerous. Right. But as you can see here, because we have the edits on, you can actually see what is the context. So I get scared when I write very, very vague prompts like this. But we're going to write good prompts in the rest of this course.

6:31And that's a little introduction. So we're going to say, yes, go ahead. Well, in this case, we got a API error and that's OK. So what we're going to do is just manually delete these because we've already covered them. And I'm going to also go over here and view the hidden files to delete this one. All right. So I deleted them and I just wanted to confirm that they are gone. And then I think that's probably it for this video after it's done envisioning. All right. So there's another API error. So 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. So we're good to go. So I will see you in that next video where we compare chatbots to coding assistants and make a mental model. See you there.

0:00Welcome back. In this video, we're going to explore the coding assistant model to build that mental model, because it's totally different from a chat bot. And also it abstracts how it's actually changing your code, meaning how it works through the code base using these tools. So here you are and you ask a question and let's say that you're asking for a change. And again, this 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, it goes into cloud code, which has two main parts. And we know that cloud code is a language model, but the busy, and we know that cloud code is a language model, but the biggest mistake that people make with cloud code is treating it like a normal chat bot or like a lamp or like a language model. And that's because a chat bot can answer questions. But a coding assistant is working inside your project, meaning it's going to inspect files, understand project structure, even run terminal commands, edit files and use the feedback from those actions to decide what to do next.

1:15So when you ask it a question, what you're doing is really providing a goal. And then Claude here, as you see in this first step, we'll now talk to another component and that's how it gathers context and then proposes a plan. And then it decides, maybe I need to use a tool. And so this is where the tools live in. The tools are another language model that has access to tooling, right? So there's multiple steps and multiple models talking to each other.

1:48Cloud code is really handling the context, the planning, and then it decides, Hmm, I need to use a tool and then it'll use those tools by talking to another language model that has access to these tools. And then it'll see what the tools did, meaning it'll receive information back so that it can look at the results and then it might iterate. And that's why I have here an arrow going up and down between the language model 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? And then we give it context, right? And that's still here. And this is inside of our prompt. We can at mention maybe data slash Austin dash forecast dot JSON, right? Or maybe the source files for the JS files that are the analyzing forecast or the format of the weather report. And 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. So we have a goal and we're specifying the context with these at commands and that goes from us into cloud code, but then it starts to iterate here with the tool use. And that's really the biggest different. So what's really happening here. So number one, it gathers context. Number two, it makes a plan and we've seen it do this. You can actually see how it thinks. And then once it makes a plan, it might ask you if it can take action.

3:24And then number four, once it takes action, meaning it starts to use some kind of tools, then it can observe the results. And then at that point, it can iterate until it accomplishes the goal. So the main difference here between a chat bot and a coding assistant is that the chat bot talks about code and the coding assistant works on the code base using these tools. So that's model plus environment plus tool, plus context and permissions, which we already discussed in the last skill in the beginning of this skill.

3:59And here is probably one of the most powerful parts. Cloud code is most useful when you give it a clear goal, the right project context and a verification step. We're going to learn more about that when we get to prompting. Now you're probably saying, Hmm, okay, great. So uses tools, but what is happening when it starts to use tools? They goes back and forth. And I understand that. But what is happening when it starts to use tools? It goes back and forth. And I understand that we're gathering contacts, making a plan, taking action, but then what happens in between these two steps? It takes action.

4:36Then it observes the results. So now we want to peer inside of this part tools. Let's explore the tool use workflow next. All right. So we have you here and then now Claude code here, which is the language model. And then we have Claude. So I'm going to draw these three lines so we can see what action touches each one of these. So let's take step number one. So you're going to ask a question. So let's say that you ask what logic decides if Austin is cloudy or not.

5:13So that goes from you. So this is this first query, and that goes from you to Claude code. Then what happens next? So that's this point. Okay. I'm going to just write number one here, number two here. So we know what's happening. So number two, Claude code is going to send the question and tool instructions to Claude. So from Claude code to Claude, and that's what I was talking about. So you can consider Claude code is the language model and Claude is actually doing the tool use. And so here for number three, it calls a read tool.

5:50So it might read source, analyze forecast dot JS, because that is a tool call. And then it sends that to Claude code and then number four, Claude code reads. Okay. So that is the main distinction. So now Claude code has this context because it was able to read that. And then Claude code will return the file back to Claude. So it returns file content and then number six. So let me write, this is three, this is four, this is five. And then you get this answer finally here, which would be number six, which is the return answer.

6:33So the takeaway here is that you are talking to Claude code, but Claude code talks to Claude and Claude is really using the tools. So it does the reasoning and the tools and then sends that back to Claude code. So they're sharing this responsibility. So when we take this back to the Claudia or not app, you, the user would ask about forecast logic, then right here. And that means that Claude is going to actually read the source file and then the data file if needed, and then explains the relationship and it might suggest the change.

7:10And then you decide whether to prove it, but there is this back and forth here that's happening until it reaches the goal. And that goal comes from your original query. So tools are really just capabilities. It's not magic, right? Now you know that Claude code has access to tool categories that let it work within a code base, depending on the version, configurations, permissions, and environment tools can include many different things. And that's what we're going to explore in the next video.

0:00At this point, you might be asking, why are we going into tools so much? It is interesting to understand that we are speaking to multiple agents, not just to Cloud Code, but Cloud Code then talks to Cloud, who has access to different tools. And the reason is not just for Cloud Code, but when we get into the API section and start to build agentic workflows, that is precisely where we get into tool calls into much more detail. So this is really relevant for Cloud Code, but also much more relevant for the rest of the course when we're thinking about system architecture.

0:37All right, so now let's make a list of tools and their purpose. So the first one that we explored, well, we already know what this does. This basically reads a file. So you would talk to Cloud Code, Cloud Code would talk to Cloud, and then Cloud would use this tool to read a file. But there's another tool that's for editing and writing. So you might be surprised to know, wow, these are actually separate tools. So this is to modify or even create files.

1:10And we also have a bash tool. So this is for running shell commands. And then we also have glob and grep. So if you already know what grep is, well, let's talk about both. So glob finds files. So I'm gonna say find by pattern. And grep will search file contents. And there's also notebook tools. And this is for both reading and editing.

1:45And again, this is for, you know, like notebooks, like Google Colab or Jupyter Notebook more specifically. But there are many other tools like to do right. And that is gonna track multi-step work and web fetch and web search so that you can bring in web content. And then finally, we have an agent tool. So this will launch a sub-agent for a focus task. So let's say launch sub-agent. So why am I showing you all of this?

2:15Well, the takeaway is that tools shape what kind of work Cloud Code can do. And when we get into the API later, this is where you really get into these because you're going to choose tools that are specific for an application for production. So this is the system architecture part. And well, we really need to know how this works with Cloud Code well before we get into architecting our own solution. Let's say that we give Cloud Code a task, add wind speed to the report.

2:46So what relevant tools do you think will be used? Well, first of all, it would read. So it needs to read the data but it's also gonna read analysis logic and then it's going to edit. So it might edit the report formatter or even write or run tests and it might even run shell commands. And it might even need to search file contents or find patterns. And so it's already using a bunch of tools, right? So a capable Cloud Code workflow is not just asking for an output, it's guiding tool use toward a verifiable result.

3:26And so that brings us to prompting. In my other courses where I teach prompt engineering, there's always some kind of approach like context, role, expectation, ask to, and the different shots. For example, no examples, it would be zero shot. One shot would be one example and few shot would be two more examples. But for Cloud Code, we're gonna start with four phases that are really prompt engineering focusing on Cloud Code. So instead of asking Cloud Code to immediately modify the project, you can ask it to inspect first, then ask for a plan, then approve the edit and finally verify with project commands.

4:09So we will start here, number one with inspect. And that's where shift tab comes into play because you can choose the right mode. And here is where Cloud Code would plan. Then number three, we would have the editing phase and number four, verification, verify. All right, so let's go ahead and try this out. So I'm going to use inspect first. So I'm literally gonna say inspect and then I'm going to focus the context by saying at data slash Austin forecast dot JSON.

4:46Let's also choose a source file, analyze the forecast or source analyze forecast dot JS. And let's add another source file here for the format. And then I'm gonna say don't edit just yet. First, explain how the current weather is created. So, so far we've done inspect and now we're gonna do plan. So I'm gonna say then propose, let's say I'm gonna use the word plan to add wind speed to the app or to report I can say.

5:23And then most importantly, it's going to, before it edits, you need to approve it. So I'm gonna say after I approve the plan, update the code. This is where we're asking it to do the edit part. And then we're gonna ask it for verification. So update the code and test or let's say tests run NPM. And we don't really need to add this because it knows from the cloud dot markdown file, but I'm gonna be very clear anyway. And then I'm gonna ask for a summary.

5:54Summarize the results. So you could try this without NPM run or run NPM test. It would know that it has to do that. So if you wanna take that out and compare my output to yours, we're both working in different ways to learn more. So I think that's a cool experiment. Okay, so you can also use shift tab. So accept edits on or plan mode on, auto mode on. So let's do accept edits on. Okay, now let's run this.

6:26All right, so here we go. Now I'm gonna make this a little bit bigger here like that. All right, so how the current report is created. The data flows through the three pure stages. We already know this, so that's good. All right, observation. And you can also make it more concise. Something that is really powerful to do is to say answer under 250 characters. It's a good way to keep your token spend a lot lower because it's gonna spend a lot of tokens and then Anthropic makes a lot of money. So if you've also been reading the news, these token costs can get out of hand.

7:00And so not only are you paying for the token costs for the prompt, but for the reasoning that you don't see and then the output. So it's a lot higher than you think. When we get into the API, we're gonna manage token costs, which includes reasoning tokens. And you'll learn a lot about that then. But for right now, you could also just say, make sure to keep this under 250 characters or 500 characters, something like that, because this is a little bit verbose. So I didn't do that, but you could also add that into the mix.

7:32And so here's the plan. Check the existing text configuration, which is untested, and then add one mile per hour assertion to analyze forecast tests. So it verifies a pass-through and then you add wind and then you run NPM tests. Okay, so this is great. So wind speed is already wired up end to end. So all we have to do is test it. Cool. All right, so what else? So it's giving us some more observations, but now let's look on the plan. It's gonna check the existing tests to confirm because it's untested and then add wind speed assertion to the test.

8:09And then it's gonna add wind, which is a line assertion to another test. And then it's gonna run the tests and make sure that it passes all the tests. Okay, that's what I like to see. So here's the plan and you can see it again. I like this. Sounds good. And I'm gonna just say approved because that's the language that I used before. In this case, for some reason it's moonwalking, but now it's gonna run the test. And I'm gonna say, don't ask again for the tests because I'm okay with running several tests and it's continuing to moonwalk because Cloud Code is also a good dancer.

8:45And then here we go. All tests pass. All right. So it turns out the wind speed was already fully implemented and tested. You're welcome. I did that. So we're just testing things that I know are gonna work because we don't wanna get stuck in the weeds with having to fix tests, but we do want to know how to prompt. So this is Cloud Code prompt engineering. And one of the good things that we did that I really like is that we made sure that our prompt included good context, right? Because a good Cloud Code prompt should make it hard for Cloud to guess.

9:18You want to remove the degrees of freedom because if you don't, it's going to, I guess the technical word here is hallucination, right? We wanna mitigate hallucination by reducing the degrees of freedom. So you wanna make sure that your context is very focused and context management is key. So you wanna always point it to that evidence. And we did that. But let's say we wanna take it a next step further, right? So let's say review, and you really want to focus on what's really important.

9:51So let's say we can focus on the package.json and the index source slash index. And let's do that source, analyze forecast. And finally here, we're going to also in the source format, weather report.js. And then I want to explain, I'm gonna ask it in a new line, explain the app flow, which we already know from data loading the final terminal output.

10:23And now you see this habit that I want you to get into. What we're doing is choosing the files that match the task, right? And what does that mean? Well, we wanna point Cloud Code to the evidence. And so in this case, we are saying that we wanna know how the app will flow from the data all the way to the output in the terminal. And how do we do that? Well, we point it to package.json, the index, and we already know that this is the flow. So now we can just hit enter and it's newspapering because it's very smart.

10:59And you can also ask Cloud to create a to-do list when working on complex tasks. That's something that I do. All right, so here we go. It's pretty verbose, formatting, output, cool. So the key design constraint is that analyze forecast and format weather report are pure functions. No file reads, no logging, no mutations. All in out is isolated to index.js, which makes the two core functions straightforward to unit test with inline fixtures. Okay, perfect.

11:30All right, so I think we're done with this video. And next up, we're gonna do some workflow examples and we'll check out performance style workflows and data analysis style workflows. See you there.

0:00Now we're going to add goals and we're going to do that within workflow examples. And so we'll start here with performance style workflow because performance work is a useful pattern, even when the project is small, like Claudia or not. And we, we know that the point is not that Claudia or not app has a serious performance problem. It's tiny. The point is that cloud code should not optimize blindly. That's what we're going to study here. Good performance work is measured. First you run a baseline and then you find the slowest and most repetitive path.

0:37And then you make one focused change because you want to think like a scientist, you change one thing, and then you make one change and then you run the same check again. And the value here is the scientific method, because now you're going to compare before and after that one focus change. And we start with a goal. That's what I said we were going to do. And what does that goal make the, and I'm just going to say weather app faster.

1:10We're about to push this to production. So we want to make sure that Claudia or not is rocking. And how do we do that? Well, this is step one. So step two, and this is like a review. We send it off to cloud code because we created a prompt. We already know how to create that prompt and target and focus the context. And what happens inside of here, two things. So number one, we 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. And remember they're working towards this goal. So what's going to happen? It's going to run benchmarks. It's going to find the slowest case and it's going to create a small reproduction. Then it's going to profile the code and it's going to improve the implementation run benchmarks again. And we're going to compare before and after.

2:11So this is exactly what we're talking about. Now you can see that it's going to do that, but now it has a goal in mind and cloud code works best when it has a goal. So we're going to measure first and verify after. And what's happening here in this section is really forecast parsing. It's using these tools to enable everything that we have right here. And that's again, in order to serve this goal. Okay. So 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. Let's be careful here. I want you to propose it first. Don't change anything till I approve. Okay. So this is not enough. So what do we do? So we're going to give it a better goal. So I wanted to see if you thought that there was a problem here, right? So I made it vague on purpose. And if you were like, wait a minute, that'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 goosebumps. If, if you felt like that was not a great prompt and kudos to you. So now let's make it better. So treat this as a performance style review and we're going to be very clear. So of cloudy or not app and what is the next step? Pause the video and think about it for just a second. If you said focus context, you are on the right track. So let's do that.

3:43Inspect at source, analyze forecast.js and data Austin forecast.json. And I'm going to say, don't edit just yet. And we also want to say, explain whether, and I hope it doesn't think I'm saying whether like W E A I'm sure it'll get it. So explain whether there is, but you see where I stopped. I was like, Hmm, maybe I should use another word. And also I misspelled it.

4:15Maybe that's why I was concerned. I don't know, but I like to be careful with these prompts. So explain whether there is any member what we talked about, repeated or unnecessary work in the current logic. If you see a small, safe improvement, propose it first. Don't change anything until I approve. Now what I'm going to do here is add one more line. Please be concise and stay under 400 chars limit.

4:47All right, let's see what happens. Now, this is what I'm talking about. That one little magical line is probably my most used little trick and prompt engineering here. It says, analyze forecast maps over daily three times map for high temperature and map for low and reduce for rainiest day plan a fourth reduced for average cloud cover. So the proposal is collapse all four into a single reduce pass and you compute all of these together. Safe change, pure function, same outputs approve question mark. Yes, approved.

5:23I like that. And I really do like how small this is. It's easier for me to read. Sometimes it might be too little. I mean the character limit might be too restrictive if you're doing something complex, but for this I thought this would be a good number and it turned out to be pretty good. So approved. Now it's getting into Star Trek and it started to beam. It's beaming. It's inference. Okay, so those are the changes. So you can see, and this is really cool because now you can see what it was and now what it is and all tests passed.

5:54And if you wanted to get into the big picture, what metrics are you using to evaluate performance? You could do that. These are things that now that you've defined all of the context, you can definitely do. Now for the next one, we're not going to do it in cloud code because we're not working with a notebook. We will be working with a notebook very soon. So I did want to at least talk about this because when you're working through most of the tests, it really helps to use cloud code to its fullest capabilities.

6:26So let's say that we have a CSV here, right? It's going to be rows and columns, but it's not going to look like this. The CSV is just comma separated text. Let's say that this is what we had. And I'm just drawing it like that to give the illusion that this is a spreadsheet type of information, but CSV is different kind of text. So in case you didn't know that now, you know, all right, so now what happens? So same thing, we send this to cloud code, which will first understand the data and then it's going to write and run code. So again, this 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, it's going to take the data and it's going to take the data and it's going to in this case, it's going to inspect the schema. And at this point, let me say one, here's two, it's going to write and run notebook cells. All right. So pretty familiar. If you're familiar with notebooks, then you'll see how this works. If not, you're going to definitely be familiar with Google Colab and a few skills from now. And then here it would explore patterns again, using tools. And then here might create a chart.

7:48And number five, summarize insights. All right. This is classic data analysis workflow. You use code execution as a feedback loop. And then this goes back here. Okay. And this is really the same thing for our cloudy or not app, but now with a different workflow. But I didn't want to say that you could also apply UI browser workflows. You can also use GitHub integrations.

8:18So you can actually use at mentions in a PR or open a pull request, right? So you would have cloud code, read context, review changes and maybe respond to feedback and post a report. These are all things that you can do for peer reviews and inside of GitHub. It's a very popular way to use cloud code. All right. So I think that's it for this video. And next up we have the challenge.