AI accelerates execution, not thinking.
If you skip planning and go straight to “build this”, the AI will invent a plan for you. It won’t be your plan. It won’t reflect your constraints, your domain knowledge, or what you actually need. It’ll be a guess. And guesses compound.
This is the pattern I see when engineers struggle with AI-assisted work. Not bad prompts. Not wrong tools. Just missing plans.
What skipping planning looks like
When someone jumps straight to execution without first agreeing on intent, the symptoms are predictable.
Bloated code. The AI writes far more than necessary because it doesn’t know what’s in scope and what isn’t.
Defensive code. Without clear boundaries, the AI hedges. It checks everything, handles cases that can’t happen, wraps every line in safety logic.
Scope creep. “I fixed the issue, but I also updated this, refactored that, and fixed a side bug I noticed.” Like a junior engineer without focus, the AI touches things it shouldn’t. You end up with huge PRs where you can’t tell what actually changed.
Sometimes the AI writes so much code that you can’t even tell if it solved the original problem. That’s the real cost of skipping planning. You lose visibility.
Planning is the tech lead’s job
This is one of those responsibilities that doesn’t go away when you work with AI. It becomes more important.
The AI doesn’t know your domain. It doesn’t know what matters to the client. It doesn’t know which parts of the codebase are fragile and which are safe to change. You do. Your job is to shape the work before handing it over.
What that looks like depends on the project.
For features: A PRD works well. Describe the problem, the outcome, the constraints, and what’s explicitly out of scope. You can also break the PRD into actionable tasks so the agent can iterate through a larger piece of work step by step.
For migrations: A mapping doc. “We’re migrating 25 instances of X to Y. This is what the old format looks like. This is what the new format should look like. Here are some examples.” That artifact becomes the source of truth for the entire migration.
For refactors: A clear statement of intent. What’s changing, what’s staying the same, what the end state should look like.
The specific format matters less than the clarity. The point is to agree on intent before execution starts.
You don’t have to be precious about it
One thing I’ve learned: you don’t need to get the plan perfect on the first pass.
Tokens aren’t as constrained as they used to be. You can try a minimum viable planning artifact, see if it hits, and iterate. If the AI drifts or the output doesn’t match what you wanted, you revert and add more structure. Refine the plan until the AI can execute it reliably.
This is still faster than skipping planning entirely. A few rounds of iteration on a plan is much cheaper than untangling a mess of code that went in the wrong direction.
Plan readiness checklist
Before handing work to AI, ask:
- Is the goal clear? Can you explain what “done” looks like in one sentence?
- Are inputs and outputs defined? Do you know what shape the data starts in and what shape it should end in?
- Is scope bounded? Is it clear what’s included and what’s explicitly not?
- Do you have an example? Can you show what correct looks like for at least one case?
If you can’t answer these, you’re not ready to execute. Keep planning.
Where this clicked for me
The migration project I mentioned in earlier posts. We estimated over 200 hours for the content and meta work. The actual time was around 80.
That gap wasn’t because of a better model or a clever prompt. It was because we planned first. We built mapping docs. We broke the work into clear phases. We agreed on what the transformations should look like before any code was written.
By the time the agent started executing, it knew exactly what to do. There was no guessing, no drift, no scope creep.
I’ve used planning religiously since then. So have other engineering leaders I talk to. The pattern is the same: “help me plan this”, “help me write a PRD”, “help me write a migration plan”. Before touching code.
And the AI is actually good at this part. It asks clarifying questions. It surfaces edge cases. It takes into account whatever code is already there. Used well, it’s a thinking partner for the planning phase, not just an executor for the building phase.
The real leverage
AI makes execution cheap. That’s the whole point. But cheap execution without clear intent just produces more mess, faster.
Planning is where you decide what matters. It’s where you set boundaries, define success, and rule out the work that shouldn’t happen. It’s the highest-leverage activity in AI-assisted engineering precisely because everything downstream depends on it.
If a human can’t explain the plan, AI will invent one. Make sure it’s yours.
This post explores the Plan and Specify phases of the Controlled Acceleration Model.