A practical model for AI-assisted engineering without giving up control.
AI makes execution cheap, but cheap execution without structure produces a mess. Controlled Acceleration front-loads the thinking, gives AI clear boundaries, and keeps humans responsible for deciding whether the result is right.
Humans own intent. AI handles execution. Constraints keep everything aligned.
Who this is for
Controlled Acceleration is for engineers and technical teams using AI on real software, where correctness, maintainability, and trust matter as much as speed.
It’s particularly useful when AI can do a lot of the implementation work, but the consequences of getting that work wrong are significant.
The five phases
Plan Agree on intent before any code. What are we doing? Why? What does success look like? AI can help you think through this, but the decisions are yours.
Specify Turn the plan into something concrete. A PRD. A mapping document. Input and output shapes. Examples. Acceptance criteria. Specification defines what “right” looks like. The more explicit you are, the less the AI has to guess.
Constrain Set boundaries that keep AI on track. Types. Schemas. Clear scope. Rules files. Constraints define what’s allowed while getting there. They’re guardrails that reduce drift.
Execute Let the AI work. With intent, specification, and constraints in place, it handles the systematic parts: scaffolding, transformations, repetitive logic. This is where much of the speed comes from.
Verify Check that the output matches intent. Tests are one of the primary tools. Not coverage for coverage’s sake, but evidence that the code does what you specified.
How the phases connect
Each phase feeds the next.
Planning without specification leaves too much ambiguous. The AI fills the gaps with guesses.
Specification without constraints lets the AI drift into patterns you didn’t want.
Execution without verification means trusting output you haven’t checked.
Verification without planning means not knowing what “correct” looks like.
The model is a loop. Plan, specify, constrain, execute, verify. Learn something, refine the plan, and go again.
Where humans stay in the loop
Controlled Acceleration isn’t about maximising how much work AI performs. It’s about putting human judgement and machine execution where each is strongest.
| Phase | Responsibility |
|---|---|
| Plan | Human-led |
| Specify | Human-led |
| Constrain | Shared |
| Execute | AI-led |
| Verify | Human-led |
Plan and Specify remain human-led because they depend on context, intent and judgement. Constrain is shared: humans decide the boundaries and tooling enforces them. AI takes the lead during systematic execution, while verification returns responsibility to the human to decide whether the result actually satisfies the intent.
The model in practice
The five phases describe the work, but they aren’t five mandatory sequential steps.
When I first developed Controlled Acceleration, I treated Plan, Specify, and Constrain as distinct phases. After using the model repeatedly, those boundaries became less important.
In practice, they often collapse into one activity: think deeply before execution begins.
Think deeply → Execute → Verify
That doesn’t replace the five-phase model. The phases are still useful because they describe the responsibilities that need to exist and give you a way to diagnose what went wrong.
If execution drifts, was the intent unclear? Was the specification incomplete? Were the constraints weak? If the result looks convincing but is wrong, what did verification fail to catch?
The model describes the work that needs to happen, not ceremony that needs to be followed.
How to use this model
When starting a task, ask whether the intent is clear, whether “right” has been defined, and what boundaries are already encoded in the system. Then execute. Then verify.
When something goes wrong, use the phases diagnostically. Bloated code can point to weak planning. Drift often points to weak constraints. Bugs escaping into production can expose gaps in verification.
When reviewing AI output, don’t just ask whether the code looks reasonable. Ask whether it satisfies the original intent and whether you have enough evidence to trust it.
When mentoring, the model gives you more useful language than “AI got it wrong.” Was the specification vague? Did we leave an important decision implicit? Was there nothing constraining the implementation?
Why this works
AI doesn’t have to be perfectly reliable for AI-assisted engineering to be reliable.
Controlled Acceleration reduces the places where AI is allowed to guess. Intent is made explicit, boundaries are encoded in the system, and output is checked against something humans defined before execution began.
The aim isn’t to remove uncertainty completely. It’s to make uncertainty visible, bounded, and verifiable.
Front-loading the thinking can make execution dramatically faster because fewer decisions are being invented halfway through implementation. Verification becomes easier too, because you already defined what success looks like.
A little structure upfront. A lot more reliability downstream.
Explore Controlled Acceleration
The model is the starting point. The writing below explores what happens when you apply it to real engineering work.
Start here
The Model in Practice
How the five-phase model changed once I stopped consciously following five sequential steps and started using it as a way to think.
The 90/10 Problem
Why AI can do most of the implementation while the final few decisions still determine whether the work is actually correct.
Planning and constraints
Planning Is the Highest-Leverage Work
Why faster execution makes thinking before execution more valuable, not less.
Skills as a Type System for AI
How structured interfaces, examples, and constraints can make AI behaviour more predictable.
Execution and verification
AI as a Teammate, Not a Tool
How the working relationship changes when AI can perform substantial pieces of engineering work rather than simply assist with individual tasks.
Tests as Verification, Not Ceremony
Using tests to prove that implementation matches intent rather than treating coverage as the goal.