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:
Top comments (2)
This is a great framing because it moves AI coding tools from “prompt → output” into a closed engineering loop.
What stands out is the idea that real productivity doesn’t come from better prompts, but from continuously cycling through:
spec → generate → evaluate → refine → repeat
That shift is important because it treats the AI like a co-developer in a feedback system, not a one-shot generator. The biggest gains usually come from tightening the evaluation step—tests, constraints, and clear acceptance criteria—rather than trying to perfect the initial instruction.
In practice, this loop also exposes where systems break: vague specs, missing edge cases, and unclear success definitions. Once those are fixed, the model becomes significantly more reliable.
It’s less about “using AI to code” and more about building a disciplined iteration pipeline around it.
The loop matters more than the model choice. The best results I see come from making the agent expose its assumptions, touch the actual files, run a verification command, and then revise. A one-shot prompt can feel fast, but the engineering loop is what makes the output trustworthy.