I was an AI skeptic. Then I tried plan mode

Matt PocockPublished Jan 16, 202612:20Added Sep 6, 2026

Plan Mode is the most important feature for AI coding. Learn why I use it for every single code change, how it works, and the specific rules I use to make plans actually readable. 0:00 Intro

Watch on YouTube →
Contributed by Heather

Transcript

Transcript format
Chapters8

Intro

00:00My interest in AI coding started when I tried plan mode. Before I tried plan mode, I was a total AI skeptic. I thought there's no way that AI can write decent code. Certainly not at the speed that I can. There's no way that AI can understand my codebase as well as I can.

00:14And there's no way that AI can mimic the instincts that I've built up over a long career doing this stuff. And then Claude Code released plan mode and I tried it and I've never gone back. Every piece of

The Plan Loop

00:24code I write now goes through this loop where I first plan it in plan mode with an AI. I then get the AI to execute the plan. Basically, write the code that was in the plan. We then test it together either by running unit tests or by type checking or by manual QA.

00:36Then we commit the code and the process starts again and we start planning the new thing. I believe this process is completely indispensable to getting decent outputs from an AI. And if you drop this plan step altogether, then you are really hampering yourself in terms of what you can do.

00:51Now, for folks who want to skip to the end and get the good stuff immediately, I've added a link below that shares my rules for creating really great plans in my claw.md file. We're going to be going through some of these and why I have them in here.

01:02But if you want to get them right now and start using them, then follow the link below. And if you don't want to miss out on any more of this stuff, then sign up to my newsletter there, too. But let's

What Is Plan Mode?

01:10actually get talking about what plan mode is. First of all, when you run claw code or any kind of AI coding assistant on your computer, it can do four main things. It can write to the file system. It can read from the file system or it can read websites and documentation and go and ping URLs or it can run bash scripts on your local machine or if you're on Windows, you know, PowerShell or anything like that or it can use MCP servers that are either running locally or are remote and call tools on them to do things and find out information.

01:37The way the plan mode works is you essentially disable the write functionality. In plan mode, the AI agent isn't allowed to write files. And the agent has a different system prompt telling it to do different things to actually create a plan before making any changes.

01:53And if it tries to make changes, then it should actually encounter an error. So, it's being stopped from making changes. So, because the agent can't do any writes to the file system, it then goes into a mode where it explores your codebase, looks for all the information it might need, and puts that into a detailed plan that it will then go to execute on afterwards.

02:11You can get into plan mode really easily by just taking Claude code and just shift tabbing until you reach plan mode. Claude Code was the first place that I saw plan mode. I don't know about 9 months ago, let's say. But now other places like Cursor and VS Code also have plan mode.

02:25So I told you what it is, but I haven't really told you why this plan step here is so crucial. What happens if you don't plan and instead go straight into executing? Well, let's

Planning helps the agent

02:36start off with the agent first. I want you to imagine for a second that you had a colleague who every time they made a commit forgot everything they'd ever learned about the repo. How would you make that colleague productive? Well, probably what you tell them is to explore the repo first before they went and made any changes.

02:52And that's what plan mode does here. It loads up the LLM's context with all the relevant info. It helps the LLM look at your code base to see code patterns that you're using. And not only that, it will often use a really cheap, fast model to do this.

03:06Claude Code often uses 4.5 Haiku which is really cheap and really really quick and launches it in a sub agent. So Haiku can go and ping out loads and loads of requests for different files and then it sends back a summary to the parent more expensive agent.

03:19If you had no idea what I just said, I will explore that in a future video. But all of this to say that planning helps the agent. Now if you don't do this then the context won't be loaded with relevant information. The LLM might make a stupid mistake because it just doesn't have all the information.

03:34It might use patterns or contexts that aren't actually used in your codebase. And so lots of the failure modes that you might be seeing while using these tools might be down to the fact that you're not planning. But

Planning helps you

03:44let's talk about the other side of the coin that planning actually helps the developer. There's a great maxim from the pragmatic programmer that says no one ever knows what they want. When you start planning out a new feature or a new idea, you probably don't fully know exactly what you want.

03:58If you're planning a refactor, you might not fully understand the ramifications of your change. When you've got a UI thing to tweak, you might have three different options that you're considering in your head. The way around this for most developers is rubber ducking.

04:09Is literally talking it out with someone else or a rubber duck in front of you until you figured out the best solution by talking through it, considering all the options. And so, an actual planning process helps the developer by making sure they have a strong idea of what they want.

04:24And this process is iterative. In other words, you loop back and forth with the AI until you have a plan that you feel that you can depend on. And that process of the AI suggesting something and you saying, "Uh, no, not quite." By the end of that, both you and the AI are going to have a clearer idea of what actually needs to be done.

04:41And then the doing of it is really simple and you can mostly let the AI go on autopilot. Now, if you don't do this, then the AI is not going to know what quite what you want. You in this situation are like a demanding client demanding something gets fixed, but the AI doesn't quite know how to implement it or the AI isn't sure how to please you.

05:00And if you don't talk out the requirements, you're not going to fully know what they are. Hashing out the requirements before you get to code is something we've been doing for 50 years as developers. And there's no reason why we should stop now.

05:10So hopefully I've

Demo

05:12convinced you that plan mode is really useful. Let's actually walk through a recent trace of mine so we can see it working. I've been working on my course video manager, which you've probably seen a few times if you've been looking at this channel.

05:21The first thing I did was I entered plan mode and I described a bug that was happening essentially in my database. I've just moved from repos into repo versions, but not all of the code had been migrated yet. So, something weird was happening when I added a repo.

05:36I didn't type this out. I just dictated this in. And by the way, if you're not using a dictation tool like Whisper Flow or Super Whisper, you absolutely have to, but that's probably a topic for another video. So, what it did is it then ran an explore sub agent to explore the codebase, understand the current schema, and how repos are created.

05:52Doing this, it burnt around 40,000 tokens. But bear in mind it wasn't using opus 4.5 for this. It was using haik coup 4.5. And then it said now I can see the issue clearly. The api.reos.ad.ts create sections without a version. Let me explore how versions are created elsewhere.

06:06Understand that create sections method signature. So the explore sub agent just gave it a little hint as to what was going wrong and then it went and looked itself by searching in the repo with search create repo version. Let me check the exact schema definition and then once it had a full understanding it said let me write the plan.

06:23It saves these plans on the file system so that you can actually read them yourselves. And in fact, you can see in this directory I have dozens and dozens of plans from all of my plan mode usage. One thing it then did is it asked me some questions.

06:34It asked, should new repos default to v 1.0 is the initial version name and I said yes. So in other words, it was iterating with me towards the solution. This was a question that I hadn't answered in my initial like twoline prompt and it figured out it needed that information and it asked me the information.

06:51In other words, I was behaving like a crappy client, not providing all the information up front. And so I had a question from the developer and I answered it. So I then approved the plan and moved out of plan mode into um actual pushing mode.

07:02And from there, it was then able to actually make the changes. Funnily enough, it turned out that there was something that neither of us had considered, which was the sections still had a repo ID on them from the previous iteration. I said, surely they can just have a repo version ID and then resolve any dependencies through that.

07:20So for this I actually kicked off plan mode again. It went and did some more exploration here and then it found that it was a completely different task. So it updated the plan file with this refactor. Further down it then answered or I answered some more questions and it then went and did it and executed the code changes.

07:35So that's what the plan mode execution loop actually looks like. And this scales from small changes as we saw there to actually large scale architectural changes. One really cool thing I've seen people doing is taking their plans and putting them in GitHub issues so other people can comment on them.

07:50Kind of like a request for comment RFC proposal where you just put it up, people ping their like ideas up there and then you reach a shared solution together. It's even great to put them on GitHub PR so that someone reviewing your code can understand what the plan was when you

Tips for improving plans

08:05made the code. But there's probably one question that's coming to your head immediately. Isn't this just like a huge amount of reading? Like I don't want my job to become just reading product requirement documents all day. Well, let me show you the single line of text that I added to my claw.md file that has made my plan so much easier to read.

08:20Here it is right here. Make the plan extremely concise. Sacrifice grammar for the sake of concision. Now, I've talked about this before, but this is an absolutely key part to my workflow. This takes plans that are like 2,000 words long and puts them in 400 words.

08:35It gives you a really detailed highlevel overview of the changes and actually means you can skip through loads of the plan really really fast and just scan it to see if anything looks wrong. And finally, I say at the end of each plan, give me a list of unresolved questions to answer if any.

08:51This gives the agent an extra little nudge just to ask me anything that it's confused about or not sure about. And it puts it in more of an exploratory sort of slightly worried paranoid mode, which is where I want it. I strongly recommend you take these literally three lines of text here, take them, put them in your claw.md and you will notice a massive difference in plan mode.

09:11I could make this setup longer, right? I could really go into detail here, but I don't want to overforce the LLM and this this core.md will be put into every single session I use. So, I find that the concision here is actually really essential for steering the LLM better.

09:27The fewer instructions you use inside your claw.md, the more instruction budget the LLM has to do other things. But instruction budget is probably the topic for another video, I

I can do it faster myself

09:36think. Now, there's one final thing to cover here, which I can hear you typing out in the comments immediately. I got loads of these comments on my Clawude Code video as well, which covered some similar ground. And what you're probably typing is, I can do this faster myself.

09:49going through the whole plan mode then just to get the AI ready to do the work. I can just go into the codebase myself, change the files and actually just do it. And guess what? In some cases, you are absolutely right. When you know the codebase inside out when you know exactly the change that needs to be made, you go into the codebase with a massive advantage over the LLM, which is you have all the context already.

10:10You don't need to send off an explore sub agent or burn tokens to actually understand the codebase. You know it already. And in those cases, you should absolutely go through and make the change yourself. But here's the thing you should think about, which is those cases are going to be relatively limited.

10:24In a large organization, you only have so many repos that you understand deeply. Plan mode allows you to contribute effectively to repos you don't know that well because you and the LLM walk in with the same amount of context. And plan mode allows you to work your way through the repo, figure out exactly what change needs to be made, even if it's in a language that you're not quite that familiar with.

10:43And here's the other thing. In this situation where you can do it faster than the LLM, it's probably quite a simple change. If it's a big architectural tweak, then you probably still want to go through the rubber duck process. You can do that with a colleague, of course, but then you're taking up your colleagueu's time.

10:59Wouldn't it be better to rubber duck with an AI that can scan the codebase, understand what's going on, create a plan document, send that plan document to your buddy and say, "I've got this plan. What do you think?" or you might find with the AI that actually the requirements are more solid than you thought and you can just get the AI to bash it out.

11:14The final point here is that these tools are only going to get faster. It's an open question as to whether the tools are going to get smarter. I think they're going to get a bit smarter but not a lot smarter. But what's guaranteed is that they will get faster.

11:26And so if your only advantage over AI is your speed, then that advantage will get eroded more and more and more. And so for me, I'm using plan mode every single time because I want to develop familiarity with these tools. I want to understand how they work and what their weaknesses are because there are weird weaknesses baked into the cake that are not going to be removed however long this goes on for.

11:47And the more feel I can get for AI, I know the more secure my career is going forward. So that's plan mode. This loop where you plan before you execute and test that loads up the LLM with context and makes your requirements clearer to yourself.

11:59If I had one tip to give to anyone that's doing AI coding, it is to use plan mode. It is a phenomenal tool for working with AI and I honestly could not live without it. And if you want to get the most out of plan mode, then you got to follow the link below to get my agents.mmd file.

12:15Thanks for following along folks. I've been really enjoying making these AI coding videos. I'll see you in the next one.