My 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.

And 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

code 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. Then 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. Now, 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. But 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

actually 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. The

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. And 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. You 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. So 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

start 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. And 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. Claude 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. If 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. It 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

let'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. If 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. Is

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. And 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. And 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. And 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. So hopefully I've

convinced 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. The 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. I 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. Doing 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. Understand 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. It 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. It 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. In 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. And

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. So 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. So 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. Kind 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

made 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. Here 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. It 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. This 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. I 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. The 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

think. 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.

going 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. You

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. In 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. And

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.

Wouldn'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. The 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. And 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. And 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. If 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.

Thanks for following along folks. I've

been really enjoying making these AI

coding videos. I'll see you in the next

one.