How I use Claude Code for real engineering

What's up, friends? We're going to do a little bit of a different kind of video. I've been working a lot with Claude Code recently. I've been getting a lot of questions on how I use it. And so I just sat down to do a little bit of work, and I realized this is actually a really good opportunity to show a complicated multi-phase plan with Claude Code. The only thing I've done so far is I've written this... prompt here. I'm doing a bit of work to add a CLI command to an internal CLI that I have to do with my AI Hero courses. But what I'm doing is less important than how I'm doing it. All you really need to know is this is a pretty large feature that will go probably beyond a single context window. I have here an initial prompt that I've put in. I haven't really put too much thought into this. The way I produced this was I just talked into my microphone and used a dictation tool to dictate it in. And I've also activated plan mode here by tabbing or shift tabbing through until I hit plan mode in the bottom left. Whenever I embark out on a big piece of work, I'm always thinking about creating a plan first. Let's get this running and I can actually talk through while it's going. So this plan is basically... It's sort of forcing ClaudeCode to explore the codebase first. We can see it's kicked off an explore subagent task to explore the current CLI structure in the codebase. It's also doing some searching here, just searching different files, searching different patterns. And what I'm waiting for it to do is to figure out anything that's unclear from my specification and give me back some sort of plan. Again, we can see it's doing a lot of stuff here. It's reading different files. It's doing some other stuff. Let me check the structure for explainer solution folders. And now this is really cool. come back with some clarifying questions. What is the part of the project repo where you want to get commit diffs from? I'm going to make it a CLI option. I just pressed return to choose that one. It's asking whether I wanted to use a positional argument or a required option. I'm going to choose a required option. And it's now asking me a really specific question about my implementation, like should it match exercise numbers strictly or flexibly? I'll choose flexible. And again, it's asking a clarifying question here. What does the O1 represent? It represents the sequence of the diff. This is basically a multi-step form, and then I end up with the submit. I'm ready to submit. my answers, let's go. Alright, it has now come back with a plan. Now this plan might look a little bit different from the plans that you tend to get from Claude code. The first thing is it's extremely concise here. We have a fair few sections but the stuff inside those sections is pretty easy to read. This is because I have this configured like that in my rules which we'll look at in a moment. We have a new file, getdiffs.ts and an updated file, that seems fine, and it's created some implementation steps here too. The crucial thing though, and I have this set up in my rules too, is it's given me some unresolved questions. And I get to choose whether I want to auto accept the edits, manually approve the edits, or keep planning. I'm going to escape out of this for now just so I can show you what's in my rules file. You can call this command memory and you can basically be taken to your user memory or project memory. This is what my user memory looks like. It's really not very long, only about 43 lines. I've given it just some very light hints about what I want. The crucial thing though is to say in all interactions and commit messages be extremely concise and sacrifice grammar for the sake of concision. That's why that plan is so concise and easy to read is because of this top line rule. And it's 100% my favourite thing I've added to rules and I'm never taking it out. There's some stuff in here that's specific to my workflow, like PR comments, like change sets as well, which I use in quite a few repos. I've already said that your primary method for interacting with GitHub should be the GitHub CLI. When creating branches, prefix them with map to indicate they came from me. Very, very light stuff. But here's the one we're seeing here, which is at the end of each plan, give me a list of unresolved questions to answer, if any. And again, make the questions extremely concise, sacrifice grammar for the sake of concision. This is why, then, we're getting this list of unresolved questions right at the point where we can see them. So I'm now going to dictate my answers to these questions into this box. I'll just do the first question just so you get the idea. Yep, you can overwrite existing diff files. That's absolutely fine. And thanks to my dictation tool, this ends up there. OK, I've now got my full answers to those questions. Let's submit it. And it's going to continue creating another plan. Notice how we haven't written any code yet. This is all just planning before we dive into code. OK, it's now given me a plan without any unresolved questions. But my spidey senses are tingly. here, and I've got a feeling this is a pretty large piece of work. And if this piece of work is too large, it's going to overrun the context window of the LLM. It's going to be much better going forward if I break this into a multi-phase plan that I can split over multiple context windows. So I'm actually going to say no, keep planning, and then make the plan multi-phase. Make the plan multi-phase is... really, really nice because it's going to tell Claude to break this down into a set of implementation steps. And now we have our multi-phase plan. Beautiful. Now, at this point, I'm starting to get a little bit nervous about my context window. That's a paranoia that I have. And I'm just going to go and exit out of there and just check my context and see how it's doing. We can see that so far we have 83.7 free space. That's feeling pretty good. We've only used about 33k tokens. Lovely. So I think having had all the exploration and now having this plan in memory, we can then start executing the plan. So I'm going to swap to auto accept edits and I'm going to say execute phase one. Let's go. Okay, we've had our first little paper cut, which is it still thinks it's in plan mode. I just say crack on please with phase one. Lovely stuff. While it's doing its thing, we should talk about this little status line down the bottom. I have this customized so it shows which repo I'm in relative to my repos folder. It also shows which branch I'm on and how many staged, unstaged and new files I have inside the current repo. It's already asking me to build the project. That's a good sign. And I'm going to say yes and don't ask again for PNPM build commands. I'm not going to review it as it's going. I'm just going to review it when it gets to the end. do now is open it up in VS Code to have a look at the files and just see if there's anything I need to tweak. I'm actually going to exit out of Claude here by pressing Ctrl C twice. I'm just going to run code dot. And now I do want to get Claude back into this terminal, so I'm just going to say Claude continue. And Claude will now pick up our conversation where we left off. It's a really nice little flow if you just want to exit out of Claude, run a CLI command, and then go back. So now I can just use the standard git diff viewer that we're all used to just to see what's going on here. I can see that it's added git diffs.js, that's nice, and it's added this to internal. There is a typescript error there but shocker it was actually there before and I'm not entirely sure how to fix it and I can't be arsed. You can also see it's left in here a todo for phase 2 which is really nice. It means that when we go to phase 2 we actually have a hint in the code where it's going to execute it. So this all looks good. What I like to do is either commit these changes or just stage them so it's really clear between phases. what's been added. If we go back to Claude, let's have a quick check on context. Yeah, phase one only used like 3k tokens, so we can absolutely crack on with phase two. And I'm going to leave it accept edits on. Now that we've done the planning, we can be pretty aggressive with accept edits on because we understand the implementation a bit and we kind of get what's going on. Phase two is complete and I'm reviewing it and it looks... Pretty nice. A quick check on context. We are in a very healthy place. Let's do phase three, please. Something I really wish that Claude Code would add is to just add the amount of tokens that I've used so that I can put it in my status line. That would mean I wouldn't need to keep running context. I would just have it right there, which is something that cursor does really, really well, actually. So phase three is complete. And what I accidentally did was went into the file and press save and an auto formatter ran and it did a little. A couple of changes. When that accidentally happens, the claw code doesn't know anything about it, so I do like to tell it. And being very direct with it as well, pull the files into your context. And note how it followed my instructions really well. It didn't do anything, it just literally read a file again. So our context is in a pretty healthy place, and I'm pretty sure we're going to be able to get to the end of this feature without actually needing to reset the context window. But I want to show you what it's like when you do reset the context window. The cool thing about having a multi-phase plan is that we can preserve it between different context windows. And the LLM should have all the information it needs to carry it on. But the question is, where do we actually store it? Do we put it in a local file or do we do something else with it? What I like to do is actually keep these as GitHub issues. And I've said to it, make a GitHub issue containing the current plan, including all of the items that you've checked off the plan list. This is calling GH issue create with this plan in the description of the issue. Everything's been checked off for all of these phases, except for phase four and five. I'm happy with this, so I'll accept this. And now that I have this asset outside of my context window, I can feel happy clearing it. And this means if I run context now, we now have virtually nothing in the context window, no messages whatsoever, we're down to 16K tokens, just from our memory files, the system tools, and the system prompt. So I'm now going to ask it... Get the GitHub issue 24 and enact phase 4 of that plan. Now I'm deciding in my head, do I want to go for accept edits on or do I want to go for plan mode? Because plan mode basically forces it to do a little bit of exploration. And the exploration might be necessary because we've completely cleared out the context. I think though I'm going to go for accept edits on and basically just get it to take the information from the plan and get going. You can see it's asking to view an issue and I'm happy to say don't ask again. Issues are fine. view. OK, it hasn't done so much planning or like code base exploration here, but it has read the correct file and it's now implementing the correct stuff, I think. Yeah, that's actually looking really nice. Let's now do phase five. And of course, because it's already fetched the GitHub issue, it doesn't need to fetch it again. It's still just in the context window. So this process then of splitting work into phases is really, really important. You don't have to put each phase into a separate context window. You can do as many phases as you like, checking the context window as you go. And I really like keeping these assets in the cloud because then actually people can comment on them, add stuff overnight, add stuff async. And I find this flow is a really nice combination of letting the AI go and do its work on accept mode. and having a lot of upfront thinking, doing lots of thought via planning. And this is currently how I'm doing all of my coding, not only for AI Hero stuff, but also for Everlight. And I think my top tips are make sure that in your memory file you have a tip to be extremely concise, get it to produce unresolved questions at the end of each plan, and get it to use the GitHub CLI to create issues so you can share context across multiple context windows. This ended up being a pretty chunky video, and I will see you in the next one.

In this video, I walk through my complete workflow for tackling large coding projects using Claude Code's plan mode. I demonstrate how to start with a rough dictated prompt, use plan mode to explore the codebase and generate clarifying questions, and break complex work into multi-phase plans that can span multiple context windows. I show my custom rules configuration that keeps plans concise and adds unresolved questions, how to monitor context usage throughout implementation, and my strategy of storing plans as GitHub issues to preserve them across context resets. This approach combines upfront planning with aggressive auto-accept during implementation phases, allowing AI to handle substantial features while maintaining control and code quality. I share practical tips including my favorite concision rule, the benefits of multi-phase planning, and how to effectively manage context windows for large projects.

Join my newsletter on AI Hero:

https://www.aihero.dev/s/y-newsletter

Become an AI Hero with my AI SDK v5 Crash Course:

https://www.aihero.dev/workshops/ai-sdk-v5-crash-course

Follow Matt on Twitter

https://twitter.com/mattpocockuk

Join the Discord:

https://aihero.dev/discord