쉐도잉 연습: I was an AI skeptic. Then I tried plan mode - 영상으로 영어 말하기 배우기

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.

It's certainly not at the speed that I can.

There's no way that AI can understand my code base 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 that 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 code base, 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 clawed code and just shift-tabbing until you reach plan mode.

Clawcode was the first place that I saw plan mode, I don't know, about nine months ago, let's say.

But now other places like Cursor and VS Code also have plan mode.

So I've 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'd tell them is to explore the repo first before they went and made any changes.

And that's what PlanMode does here.

It loads up the LLM's context with all the relevant info.

It helps the LLM look at your codebase 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 context 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.

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've figured

out the best solution by talking through it considering all the options.

And so an actual planning process helps the 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, 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 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 and explore subagent to explore the codebase, understand the current schema and how repos are created.

Doing this, it burned around 40,000 tokens.

But bear in mind, it wasn't using Opus 4.5 for this, it was using Haiku 4.5.

And then it said, now I can see the issue clearly.

The API.repos.add.ts creates sections without a version.

Let me explore how versions are created elsewhere.

Understand that create sections method signature.

So the explore subagent 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 v1.0 as the initial version name and I said yes.

So in other words it was iterating with me towards the solution.

100

This was a question that I hadn't answered in my initial like two line prompt

101

and it figured out it needed that information and it asked me the information.

102

In other words I was behaving like a crappy client not providing all the information up front

103

and so I had a question from the developer and I answered it.

104

So I then approved the plan and moved out of plan mode into actual pushing mode.

105

And from there it was then able to actually make the changes.

106

Funnily enough it turned out that there was something

107

that neither of us had considered which was the sections still had a repo ID on them from the previous iteration.

108

I said surely they can just have a repo version ID and then resolve any dependencies through that.

109

So for this I actually kicked off plan mode again.

110

It went and did some more exploration here and then it found

111

that it was a completely different tasks so it updated the plan file with this refactor.

112

Further down it then answered or I answered some more questions

113

and it then went and did it and executed the code changes.

114

So that's what the plan mode execution loop actually looks like.

115

And this scales from small changes as we saw there to actually large scale architectural changes.

116

One really cool thing I've seen people doing is taking their plans

117

and putting them in GitHub issues so other people can comment on them.

118

Kind of like a request for comment RFC proposal where you just put it up, people ping their ideas up there and then you reach a shared solution together.

119

It's even great to put them on GitHub PRs so

120

that someone reviewing your code can understand what the plan was when you made the code.

121

But there's probably one question that's coming to your head immediately.

122

Isn't this just like a huge amount of reading?

123

Like I don't want my job to become just reading product requirement documents all day.

124

Well, let me show you the single line of text

125

that I added to my claw.md file that has made my plan so much easier to read.

126

Here it is right here.

127

Make the plan extremely concise, sacrifice grammar for the sake of concision.

128

Now I've talked about this before but this is an absolutely key part to my workflow.

129

This takes plans that are like 2000 words long and puts them in 400 words.

130

It gives you a really detailed high level overview of the changes

131

and actually means you can skip through loads of the plan really really fast

132

and just scan it to see if anything looks wrong.

133

And finally I I say at the end of each plan, give me a list of unresolved questions to answer, if any.

134

This gives the agent an extra little nudge just to ask me anything that it's confused about or not sure about.

135

And it puts it in more of an exploratory, sort of slightly worried, paranoid mode, which is where I want it.

136

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.

137

I could make this set up longer, right?

138

I could really go into detail here, but I don't want to overforce the LLM and this claw.md will be put into every single session I use.

139

So I find that the concision here is actually really essential for steering the LLM better.

140

The fewer instructions you use inside your claw.md, the more instruction budget the LLM has to do other things.

141

But instruction budget is probably the topic for another video, I think.

142

Now there's one One final thing to cover here, which I can hear you typing out in the comments immediately.

143

I got loads of these comments on my Claude Code video as well, which covered some similar ground.

144

And what you're probably typing is, I can do this faster myself.

145

Going through the whole plan mode rigmarole, 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.

146

And guess what?

147

In some cases, you are absolutely right.

148

When you know the codebase inside out, when you know exactly the change that needs to made, you go into the codebase with a massive advantage over the LLM, which is you have all the context already.

149

You don't need to send off an explore subagent to burn tokens to actually understand the codebase, you know it already.

150

And in those cases you should absolutely go through and make the change yourself.

151

But here's the thing you should think about, which is those cases are going to be relatively limited.

152

In a large organisation you only have so many repos that you understand deeply.

153

PlanMode allows you to contribute effectively to repos you don't know that well.

154

Because you and the LLM walk in with the same amount of context.

155

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.

156

And here's the other thing.

157

In this situation, where you can do it faster than the LLM, it's probably quite a simple change.

158

If it's a big architectural tweak, then you probably still want to go through the rubber duck process.

159

You can do that with a colleague, of course, but then you're taking up your colleague's time.

160

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?

161

Or you might find with the AI

162

that actually the requirements are more solid than you thought and you can just get the AI to bash it out.

163

The final point here is that these tools are only going to get faster.

164

It's an open question as to whether the tools are going to get smarter.

165

I think they're going to get a bit smarter but not a lot smarter.

166

But what's guaranteed is that they will get faster.

167

And so if your only advantage over AI is your speed, then that advantage will get eroded more and more and more.

168

And so for me, I'm using plan mode every single time because I want to develop familiarity with these tools.

169

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.

170

And the more feel I can get for AI, I know the more secure my career is going forward.

171

So that's plan mode, this loop where you plan before you execute

172

and test that loads up the LLM with context and makes your requirements clearer to yourself.

173

If I had one tip to give to anyone that's doing AI coding, it is to use plan mode.

174

It is a phenomenal tool for working with AI and I honestly could not live without it.

175

And if you want to get the most out of plan mode, then you've got to follow the link below to get my agents.md file.

176

Thanks for following along, folks.

177

I've been really enjoying making these AI coding videos.

178

I'll see you in the next one.

쉐도잉이란? 영어 실력을 빠르게 키우는 과학적 방법

쉐도잉(Shadowing)은 원래 전문 통역사 훈련을 위해 개발된 언어 학습 기법으로, 다언어 학자인 Dr. Alexander Arguelles에 의해 대중화된 방법입니다. 핵심 원리는 간단하지만 매우 강력합니다: 원어민의 영어를 들으면서 1~2초의 짧은 지연으로 즉시 소리 내어 따라 말하는 것——마치 '그림자(shadow)'처럼 화자를 따라가는 것입니다. 문법 공부나 수동적인 청취와 달리, 쉐도잉은 뇌와 입 근육이 동시에 실시간으로 영어를 처리하고 재현하도록 훈련합니다. 연구에 따르면 이 방법은 발음 정확도, 억양, 리듬, 연음, 청취력, 말하기 유창성을 크게 향상시킵니다. IELTS 스피킹 준비와 자연스러운 영어 소통을 원하는 분들에게 특히 효과적입니다.

쉐도잉 연습: I was an AI skeptic. Then I tried plan mode - 영상으로 영어 말하기 배우기

맥락 및 배경

일상적인 의사소통을 위한 5가지 주요 구문

단계별 쉐도잉 가이드

쉐도잉이란? 영어 실력을 빠르게 키우는 과학적 방법