Ch.4: Claude Code: Think Before You Code

0:00 So you ask Claude Code for one clean auth refactor, and 20 minutes later it has edited 30 files, the tests are failing, and your actual problem is reviewing a cleanup diff you never wanted. Oh, anyone who's tried a coding agent knows that moment. You go in for a feature and come out babysitting a mess. Honestly, I think the fix is an order of operations: read first, agree on the approach, then let it type. Plan mode is the brake before a big ask turns into a big diff. And the part that surprised me: what helps most isn't a magic prompt.

0:38 It's a sequence change. Right. Plan mode gives Claude Code a read-first step, where its whole job is to understand the repo and agree on what will change before any code moves. And it pulls apart two jobs that keep colliding. First you decide what should happen. Then the agent handles the typing and the testing. They only stay clean when they don't overlap. So here's the precise version, and this part matters, because the current Claude Code docs, Draw the line more carefully than most shorthand posts do.

1:10 In plan mode, Claude can read files, search the codebase, run exploratory shell commands with the usual prompts, and write a plan. What it does not do is edit your source files. So it can look around, but the source files stay untouched until you actually approve execution? Sure. Take a backend engineer asking for a login migration, who approves one read-only command to list the test names. If the agent guesses wrong, all you've got is a single bad plan to toss, not half-written login code sitting in your tree.

1:43 It's a cheap spot to say no, before any of it is real. But a tech lead on my team says it straight: this is a one-line change, why are we holding a planning session for it? And that objection, honestly, is fair. Sure. Tiny edits really are their own animal. But the second it's a production-risk change, you want the approach on the table before a single line moves. Yup. So take a payments team asking for retry-safe request IDs, the little keys that stop a retry from charging a customer twice. The agent patches the API handler, but the constraint that bites is living over in the queue worker.

2:22 A minute of read-only poking is way cheaper than untangling that confident wrong turn later. Yeah, and that 20-minute review afterward is just the invoice for the 1 minute you skipped. Everyone's first move is to blame the model. But an incident like that starts earlier than the first edit. The request let it start before anyone agreed on an approach. So now I just ask for the approach before that first edit ever lands. Now, a strong plan-mode prompt is basically: investigate this, propose a plan, and don't edit anything yet.

2:57 You hand it the outcome you're after, the constraints you already know, and the review bar. For instance: we need token-based login, JWT if the repo uses signed login tokens, keep the old session path alive through the migration, match the existing middleware pattern, and tell me which tests you'd run. Oh, that's the sneaky-important part. You're telling it what earns approval, not what to build. It gets room to discover the design, but not room to invent one out of nowhere. So once the prompt sets that bar, the agent goes exploring.

3:32 It hunts down the current auth entry points, reads the middleware, checks how the test suite is organized, looks for token helpers before it invents brand-new ones. Here's where it gets interesting, though. What actually counts as real exploration, instead of grepping for one familiar filename and calling that a plan? Yeah. The plan has to be grounded in whatever it actually turned up. Let's say the repo already has token_utils.py, auth_middleware.py, and a migration helper sitting right there. If the plan ignores all three and pitches a shiny new auth package, that's your tell it hasn't really looked yet.

4:10 Yes. And exploring also means clocking how this repo already does things: how it wires middleware, how it hides new behavior behind flags, how it runs its migrations. No evidence, no approval. So now you've got a plan grounded in the repo before it edits a thing. And a usable plan tells you what it'll touch, in what order, how it'll verify, and what it still doesn't know. That last part, the unknowns? Those are the whole point. For example, a plan that says I need to confirm how refresh tokens get stored beats one that quietly assumes the answer and edits the database layer anyway.

4:46 One invites review. The other buries the risk inside the code it's about to write. Yeah, well put. So the honest unknown is really a safety feature. It's your handle to say: stop right there, answer that one first, then we keep going. But here's the trap waiting on the other side. Sometimes a plan reads beautifully and still misses reality. Beautiful plan, wrong repo. Exactly. So don't approve vibes. Push on the specifics: why that file? What test breaks if the assumption is wrong? What's it deliberately choosing to leave alone?

5:19 So the plan isn't a permission slip. Yup. It's the thing you interrogate before the expensive part starts. If a plan can't survive two pointed questions in code review, then the implementation would've been a train wreck with better formatting. And otherwise you'd just be reviewing the wreck instead of preventing it. Okay, so, say the plan's solid. You still get to pick how much trust the execution pass earns. Current flows give you a few lanes: stay in the planning loop, approve into auto mode, approve into accept edits, or review each edit by hand.

5:51 Hold on. Define accept edits for me. Sure. The planning loop means no edits land yet. Manual review means every single change waits on you. Accept edits lets file changes go through while you still watch the broader run. And auto hands the agent the widest lane, so save that one for when the workspace is genuinely safe. Huh. Okay, so approval is really about how closely you ride the next pass. It's a supervision dial. So after you approve, plan mode does one more, Quiet thing. It hands off a clean note to the execution pass rather than the whole messy search log. It's like giving a teammate the one-paragraph design decision instead of the entire Slack thread that produced it.

6:35 And nobody, nobody, wants to scroll back through four hundred messages hunting for the single line where the decision actually got made. Right. And there's a setting for exactly this: turn it on, and accepting the plan can even offer to clear the planning context first, so the execution pass starts clean with just the plan, not every dead end you wandered down to get there. Once execution kicks off, that plan turns into an actual contract. The agent should work straight down the steps, touch the files it said it would, and run the checks it promised.

7:08 Okay, but what do I actually do when it drifts mid-run? Yeah. You stop the run while the scope is still visible. Consider a run that promised to touch three auth files, then reaches into billing middleware. Might be correct! But that's a review stop, and it should explain itself before the change grows. And it changes what review even means. You're no longer asking, do I like this random diff. You're asking, did it follow the plan and did the checks pass? And the far end has its own failure mode.

7:41 You'll hear a staff engineer say, I plan everything now, like it's a badge of honor, and then, weirdly, they quietly stop shipping. Yeah, for the genuinely tiny stuff, skip it. Rename a variable, fix a typo, keep moving. My instinct is: one obvious implementation plus one small risk area, skip the plan. Several plausible approaches, a bunch of files, or consequences you'd pore over in a pull request? Plan first. For sure. And that line matters, because planning should feel like leverage, not paperwork. The moment it curdles into ritual, people quit reaching for it right when it counts most.

8:19 So this is the analogy that finally made it click for me. Imagine a strong engineer walking up to your desk and going, I can make this change right now. And your answer should be: great, first walk me through your approach. And said out loud like that, it stops sounding like an AI feature. It's just the review you'd want on any serious change anyway. Right. And the way I've always seen it, good engineering starts by agreeing on limits up front: which files, which tests, what's the rollout risk, what's the way back if it breaks.

8:53 It also protects the agent from you. Too vague a request, and the plan surfaces that before the model fills the gaps with whatever pattern it grabbed first. Now, the recipe that falls out of all this is almost unremarkable, which is exactly why it holds up. Reach for plan mode on design changes, auth or security work, data migrations, concurrency, and shared infrastructure. Huh. And every item on that list is a spot where the blast radius outruns the diff size. Below that line, you just go. Yeah. Ask for that plan, challenge the assumptions, approve how much freedom execution gets, then make it verify what it promised.

9:32 Use it whenever a wrong first edit would mean a real review problem, not just a typo you fix in a second. And the payoff compounds after a few sessions. You start spotting which prompts produce mushy plans, and that feedback quietly sharpens your requests, your repo instructions, the whole way you supervise this kind of work. So the whole rule really boils down to one line: get the approach while the approach is still cheap to change. That's it. Plan mode is the fix for the most expensive agent failure: the wrong approach, shipped with full confidence.

10:06 It hands the approach back while changing your mind still costs almost nothing. Coming up next, the one file that makes every session sharper from the first prompt: clawd dot em dee. Thanks for listening to Learning Podcasts.