You give an AI coding agent a one-line prompt. Ten seconds later you have a hundred lines of code. It feels incredible. It feels like the future.
Then you read it. It's not what you meant. So you correct it. Then you correct the correction. Three rounds of "no, not like that" later, you've spent twenty minutes walking the model back to the thing you could have described in the first place.
That fast first draft wasn't progress. It was rework in disguise.
How Anthropic's engineers actually work
The people building the models don't work the way most of us use them. Anthropic's own engineering workflow is four steps: explore, plan, implement, verify. And they're explicit about which one carries the weight. Planning is, in their words, the most important step of the four.
Implement is third on that list. Writing code is not step one. For most of us, it's the only step.
The problem was never typing
When you prompt a coding agent, you're not searching a database. You're onboarding a new engineer who has never seen your codebase. A vague prompt gives that engineer a problem and nothing else: no patterns, no examples of what good looks like, no spec for what "done" means. Then we're surprised when they build the wrong thing quickly.
The bottleneck was never how fast the code got typed. It was how well the work was specified before anyone started.
Plan, spec, build, verify
The fix is to put a real artifact in front of the code. Not a sharper prompt. A spec.
Plan. Let the agent explore the codebase, read the relevant files, and understand the patterns already in use before it proposes anything.
Spec. Turn that into a written plan you can actually review: what files get touched, what the approach is, what the output should look like.
Build. Now the model writes code against a spec instead of against a guess. This is where everyone starts. It should be step three.
Verify. Check the result against the spec, not against your vibe of what you wanted.
The plan is the leverage. Everything downstream gets cheaper when the front of the loop is done right, because you stop paying the tax of catching mistakes after the code exists.
The honest part
Spec-first feels slower. You are spending minutes writing a plan while the just-start-typing version already has a hundred lines on screen. That trade is exactly the point. The typing was never the expensive part. Deciding what to build, and catching a wrong turn before it becomes a hundred lines you now have to unwind, is where the real time goes.
Do the boring part first, and the fast part stays fast.
I broke the whole loop down in a short video: