I’ve spent six issues describing a five-phase model for AI-assisted engineering. Plan, Specify, Constrain, Execute, Verify. Clean, sequential, satisfying on a diagram.
Here’s the honest update: I don’t use it that way.
Not because the model is wrong. Because it did its job.
What actually happens
In practice, Plan, Specify, and Constrain aren’t three separate steps. They’re one fluid conversation.
Most of the time, I’m in Claude Code’s plan mode. I describe the problem. The AI asks questions. I refine. We go back and forth until the shape of the work is clear. By the time I say “go”, the plan, the specification, and the constraints are all embedded in the conversation. There’s no separate document for each phase. There’s just clarity.
One move I keep coming back to: asking the AI “What assumptions are you making, and what have I not thought of?” It sounds simple, but it changes the dynamic. Instead of me trying to anticipate every gap, the AI surfaces its own blind spots. It’ll tell you it’s assuming a particular data shape, or that it hasn’t accounted for an edge case you haven’t mentioned. That’s the constraint phase happening inside the conversation, you’re stress-testing the plan before a line of code gets written.
For bigger features, I’ll still write things down in a markdown file. A PRD, a mapping document, something the AI can reference across sessions. But for the daily rhythm, the phases are woven together. I’m planning and specifying and constraining simultaneously, because that’s what thinking about a problem actually looks like.
Then the AI executes. I’m mostly stepped out of this now. The systematic work, the code generation, the repetitive transformations, that’s the AI’s job. Mine is to have thought clearly enough beforehand that the output is worth keeping.
Then I verify. Tests, review, does this actually do what I intended? That phase hasn’t collapsed. If anything, it’s gotten more important.
Three movements, not five. Think deeply. Let AI execute. Verify.
Why the five phases still matter
The model isn’t wrong. It’s a teaching framework.
When something goes wrong, I still reach for it. If the output drifted, I ask: was the specification vague? If the AI added things I didn’t want, I ask: were the constraints missing? If the whole approach was off, I ask: did I actually plan, or did I just start?
Start with the why. Which phase was weak?
The five phases are a diagnostic tool, even when they’re not a sequential process. They give you a vocabulary for understanding where work went sideways. That’s genuinely useful when you’re reviewing output you didn’t write yourself.
Think of it like learning to drive. You’re taught mirror-signal-manoeuvre as three distinct steps. After a year, they’re one fluid movement. You don’t consciously think “now I’m checking the mirror.” You just do it. Nobody says the driving instructor was wrong. The framework did its job. It gave you the structure to internalise.
The framework becomes instinct
This is what I think calm engineering looks like in practice. Not a rigid process you follow step by step. A way of thinking that happens to produce structured, reliable output.
You don’t consciously decide “I’m specifying now.” You just naturally push for clarity because you’ve learned that vagueness compounds. You don’t write a formal constraints document for every task. You just know that without boundaries, the AI will drift. Structure reduces ambiguity, and you’ve felt that enough times that it’s automatic.
The phases collapsing isn’t a failure of the model. It’s the success condition. If you still need to consciously walk through five phases, you haven’t internalised them yet. Once you have, the framework dissolves into how you think.
That’s the goal. Not a checklist you follow. A lens you see through.
What’s next
Now that the model is established and, honestly, starting to disappear into the background of how I work, the interesting questions are different.
If AI handles execution reliably, what’s left for the engineer? If the systematic work is automated, where does human judgement actually matter?
The answer, I think, lives in the gap between AI’s 90% and your shipped code. That last stretch, where the scaffolding is solid but the edge cases, the integration points, the production realities are still yours. I wrote about this recently in The 90/10 Problem; why AI can’t finish what it starts, and why that last 10% is where engineering actually lives.
This post reflects on the Controlled Acceleration Model after six weeks of writing about it and months of using it.