I started making AI agents write a plan before they touch the code

by

One small change has made my AI coding sessions much easier to control.

Before asking the agent to implement a non-trivial feature, I now ask it to write a short implementation plan first.

Not a huge specification.

Just:

  • What files it expects to change

  • What existing code it plans to reuse

  • What assumptions it's making

  • What could break

  • How it plans to verify the change

Then I review the plan before giving it permission to implement anything.

I started doing this because I noticed a recurring pattern with AI coding:

The agent could produce a perfectly reasonable solution very quickly, but it would sometimes make a decision I would never have made if I'd thought about the architecture first.

The code wasn't necessarily bad.

The problem was that I was reviewing the decision after implementation instead of before it.

The interesting part is that the planning step is cheap.

Sometimes I look at the plan and say:

"Yes, do it."

Other times I catch something like:

"Why are we adding a new abstraction when one already exists?"

or:

"Why are we changing this file when the actual source of the problem is somewhere else?"

That has made me think that good vibe coding isn't necessarily about giving the agent better prompts.

It may be about giving the human a better checkpoint.

I've been experimenting with this workflow while building, and I'm curious how other people handle it:

Do you review an agent's plan before implementation, or do you prefer to let it work first and review the diff afterward?

What has worked better for you?

8 views

Add a comment

Replies

Best

The planfirst checkpoint makes a lot of sense. Reviewing the decision before there's a big diff is much cheaper than spotting the architectural mistake afterward.

 Exactly. That's the part I've found most useful.

Once the agent has already changed 8–10 files, it becomes much harder to question the original decision because you're now reviewing a large implementation rather than the idea behind it.

The plan creates a cheap checkpoint.

I've also started treating the assumptions section as especially important. If the agent says:

"I'm assuming X already exists"

that's something I can verify before letting it touch the code.

It turns the workflow from:

Prompt → Code → Review

into:

Prompt → Plan → Challenge assumptions → Code → Verify

For me, that small change has made AI-assisted development feel much less like "letting the agent run" and more like actually collaborating with it.