The standard framing of AI coding tools is that they remove friction. Describe what you want, the AI helps you build it, work that used to take days takes hours. That's true and it's a real improvement.
The underappreciated part: when execution gets faster, direction gets more important. What determines whether fast execution produces good outcomes is whether it's pointed at the right target. That's a planning question.
Slow execution used to filter out bad decisions
When a feature took two weeks to implement, the team had two weeks to reconsider it. Someone might notice mid-build that the approach was wrong. A stakeholder might ask whether this was actually the most important thing. The friction of slow execution was also, accidentally, friction against bad decisions.
AI compresses that window. A feature that would have taken two weeks now takes two days. Three-quarters less time for anyone to notice the direction is wrong, less time for doubts to surface, less time for the team to recalibrate before the decision is baked into production code.
This isn't an argument against moving fast. It's an argument that moving fast requires being more deliberate about direction upfront, since the build cycle no longer creates the same correction opportunities.
When speed is actively worse
There are situations where AI-assisted speed makes things worse. Specifically: when the team is building the wrong thing efficiently.
A feature that doesn't belong in the product gets built and shipped before anyone has properly evaluated whether it should exist. A technical approach with serious downsides gets implemented faster than the downsides surface. A scope that should have been challenged in planning gets executed before anyone asks the question.
In each case, speed is the problem. Not because speed is bad — because speed in the wrong direction covers more ground before you realise you need to turn around.
"Moving fast in the wrong direction." AI tools don't change that — they amplify it. The most common version of it is AI coding tools making scope creep worse, not better.
What planning does in an AI workflow
It front-loads the thinking that used to happen implicitly during slower execution.
Defining what you're working on — and what you're explicitly not — before a build session does two things. It gives you a reference point when the AI suggests natural extensions during implementation; "should I add X while I'm in here?" is easier to answer if you wrote down at the start that X is out of scope. And it ensures the session is aimed at something deliberate, not just the first thing that seemed buildable.
Not a lengthy document. A clear scope for the current work. That's the difference between productive speed and vibe coding that quietly slows you down.
The direction layer
AI tools are execution tools. They're excellent at building things once you know what to build. They aren't designed to tell you whether the thing you're building is the right thing to build — that's a different kind of problem.
The direction layer — what to build, in what order, toward what goal — requires human judgment. Understanding users, weighing tradeoffs, picturing a future version of the product and working backward. AI doesn't reliably do any of that yet.
The temptation is to let execution momentum substitute for direction. When you can build something quickly, not building it feels like a loss. But "this could be built quickly" isn't the same as "this should be built." Speed isn't a planning argument.
Maintaining a planning layer — releases with defined scope, a backlog for unscoped ideas, regular priority decisions — is how teams turn AI-assisted speed into useful outcomes instead of impressive activity.
How teams get this right
The teams that use AI tools well separate planning from execution. They spend time before a build session defining what success looks like and what's in or out of scope. Then they use AI to execute that scope as efficiently as possible.
They also stay disciplined about scope expansion during execution. When AI tools suggest adjacent features, those ideas get captured and reviewed in the next planning session, not in the middle of a build. (For the other end of this loop — letting agents read and update your plan directly — see how to use AI assistants to manage project work with MCP.)
The combination is powerful: AI execution speed applied to deliberately chosen work. That's a real competitive advantage. Undirected speed is just expensive.
That is the role a planning layer should play in an AI workflow: releases, areas, and tasks that make clear what's getting built and when. With MCP, Claude Code, Codex, Cursor, or another agent can read and update that plan directly. The planning still has to be yours, but a clear release scope gives the AI something to point at.