AI adoption stages describe how far a team has gone in working with coding agents, measured by how many agents run at once and what the person's role becomes. A common model has five: gated (no agents), assisted (one agent, supervised), parallel (roughly ten, orchestrated), supervised autonomy (roughly a hundred), and AI-native (a thousand or more, steering by intent). What separates them is trust, not the model.
What are the five stages of AI adoption?
This ladder was published in July 2026 by Boris Cherny, the creator of Claude Code, as an opinionated framework rather than a study. The agent counts are illustrative orders of magnitude, not measurements, and it is worth reading them as a shape rather than a target.
| Stage | Your role | Agents | The bottleneck |
|---|---|---|---|
| 0. Gated | none yet | 0 | Legacy security and approval processes |
| 1. Assisted | you and an agent, a pair | ~1 | Your attention |
| 2. Parallel | orchestrator | ~10 | Reviewing output |
| 3. Supervised autonomy | manager of managers | ~100 | Trust in the loop |
| 4. AI-native | steering by intent | ~1,000+ | Knowing what to automate |
At stage 1 you run one session at a time and review almost every change before it merges. The work is synchronous: you sit and watch rather than moving on to something else. The unlock is that a change which used to fill an afternoon gets finished between meetings.
At stage 2 one engineer keeps five to ten agents going at once, each in its own worktree or checkout. The agent runs its own tests, build, lint, and security scan before you see anything, so you review final diffs instead of keystrokes, and the maintenance backlog starts shrinking.
At stage 3 the agent writes nearly all of the code and starts work you would otherwise have kicked off by hand. The review question changes from "did you read the code?" to "what context was the model missing, and how do we fix that for next time?"
At stage 4 most agents are started by other agents. You steer by intent and monitor by exception, and a migration that would have taken a quarter becomes a workflow you kick off and check on.
Why is the bottleneck never the model?
This is the most useful column in the table, and the one that holds up regardless of which tools you use. Read it top to bottom and the constraint moves through four different kinds of problem. It starts organizational (stage 0 is a permissions problem), becomes personal (your attention, then your review capacity), turns social (trust across a team, and how fast that team can make decisions), and ends up strategic (knowing which work is worth automating at all).
None of those are solved by a better model. That is why two teams on identical tools sit at completely different stages, and why a model upgrade does not automatically move anyone up. If you want to climb, work on the constraint you actually have.
Nor is it solved by spending more. Tokens alone do not move a team up a step: each step is left by finding the next set of bottlenecks, breaking them down, and building the next set of guardrails to match. The same goes for features. No single feature promotes anyone, because a feature without its guardrail does not raise the ceiling, it raises the blast radius. Parallel agents without isolation collide with each other; automatic permissions without sandboxing widen what an unattended mistake can reach. Adoption is work, not a purchase.
How do you go from one agent to many?
The gate is a self-verification loop you trust: tests, build, lint, and end-to-end testing against a real development environment, all run by the agent before a human looks at the work. Add automated code review and remove the permission prompts that block a session while you are looking elsewhere.
The reason people stay at one agent is rarely technical. It is that without self-verification they do not trust the output, so they feel they have to read everything, so they never look away. Trust is what buys the right to look away, and automated checks are how that trust gets manufactured. This is the same conclusion practitioners reach from the opposite direction in scaling AI development: feedback loops set the ceiling on how well an agent can code, and when output is bad, the fix is usually better feedback loops rather than a better prompt. Verification is the lever.
Everything downstream depends on it. An agent that can tell whether its own work is correct will fix its own mistakes; one that cannot is guessing, and a guessing agent has to be supervised.
What breaks when you run ten agents at once?
Review. You hand-write far less code and instead check six streams of it, which takes more of your time than the coding did. Steering also gets harder, because prompting and correcting several sessions at once is its own skill.
Two things keep this survivable. First, isolation: one worktree or checkout per agent so parallel work cannot collide. Second, holding the same quality bar for agent-written and human-written code. The bar does not drop because the author changed. This is where clean code for AI agents pays for itself, since a codebase that is easy to navigate and verify is what makes ten parallel reviews possible at all.
What does supervised autonomy actually require?
Context and trust. To get past orchestration, the agent needs a way to pull in what it is missing: the code, the wikis, the discussions. It needs enough agency, and enough code-review throughput, to work across code owned by other teams. And the work has to be broken into loops and routines so that agents can start other agents.
The trap is named plainly in the source, and it is worth repeating: scaling agent count before the loop has earned widespread trust. Agent count is the visible number, so it is the tempting one to grow, but it is a lagging indicator of trust rather than a lever on it. A useful discipline at this stage is to ask, of any agent work, whether it is something an engineer would have done anyway. Tokens spent are only waste when the answer is no.
What blocks adoption before it starts?
Stage 0 is worth naming because the constraint is entirely non-technical. It looks like this: only older or lighter models are approved, latency piles up through gateways and custom auth, tool access is ungoverned or blanket-denied, and internal access is process-heavy. The quietly fatal one is having no approval path for hosting what the agent creates, so outputs never leave a laptop. Work that cannot be deployed cannot demonstrate value, so the pilot never produces the evidence that would unblock it.
The causes tend to be legacy approval processes, a focus on containing cost per token instead of outcomes, and no genuine technical voice in the decision. The middle one is the interesting failure: cost per token is easy to measure and cap, outcomes are hard to measure, so the measurable proxy wins by default. A cheaper model that takes three attempts is not cheaper. Getting out is a negotiation rather than a build, and it usually means satisfying the existing security process rather than seeking an exception from it.
How do you measure the return, once a team is bought in?
Watch usage, but do not mistake it for a result. A usage dashboard measures activity: sessions started, tokens spent, agents run. None of that tells you whether the work was worth doing, and a team can climb the usage chart while producing nothing anyone needed.
The sharper question is counterfactual. For a given piece of work an agent did, ask whether you would have spent engineering effort on it anyway. If the answer is yes, estimate what it would have cost in manual engineering hours, and that estimate is your return. If the answer is no, the tokens bought activity rather than value. The virtue of this measure is that it is priced in something a business already understands, namely engineering hours it would otherwise have paid for.
Two honest limits. First, it is a self-report, asked after the work exists, when it is easy to say yes about anything that turned out useful. Treat it as a discipline for killing work rather than a way to justify work already done. Second, it only prices work that was already on someone's list. The larger payoff of the upper stages is that maintenance and fixing run in the background, which frees teams to build things that were never in range before, and a counterfactual measure cannot see that value at all: there is no manual-hours estimate for work nobody would have attempted.
What guardrails does each stage need?
Strip away specific products and three categories remain, each scaling with the unit of use:
- Isolation, so agents cannot collide or reach past their blast radius. A worktree each at stage 2, sandboxing at stage 3.
- Spend and model controls at the right grain: organization-wide at stage 0, per-seat at stage 1, per-automation at stage 4.
- Observability into the stack you already have, not a parallel one. Telemetry export into your existing monitoring at stage 1, team usage analytics at stage 2, token monitoring at stage 3.
There is an honest tension here. The same controls (single sign-on, budget caps, identity management) appear as blockers at stage 0 and as enablers at stage 1. The difference is only whether a control is designed to let work through safely or to slow it down.
If you are earlier than all of this and still working out what an agent is, start with what is an AI agent. For the wider picture, see the Learn AI section.
FAQ
What are the stages of AI adoption?
Five: gated (0 agents, blocked by process), assisted (1 agent, supervised pairing), parallel (10 agents, one orchestrator), supervised autonomy (100 agents, agents starting agents), and AI-native (1,000+, steering by intent and monitoring by exception).
How many AI agents can one engineer run in parallel?
Roughly five to ten, once each agent has its own worktree and runs its own tests, build, lint, and security scan before a human sees the work. Without that self-verification, the practical limit is one, because you end up reading everything.
What is the biggest bottleneck in AI adoption?
It changes by stage and it is never the model. It starts as organizational approval, becomes your attention, then your review capacity, then trust across the team, and finally knowing what is worth automating.
How do you measure the ROI of AI coding agents?
Not by usage, which measures activity rather than return. Ask instead whether you would have spent engineering effort on the work anyway, and if so, what it would have cost in manual engineering hours. That figure is the return. Work you would never have done is activity, not value.
Is a higher adoption stage always better?
No. The framework itself warns that the trap is scaling agent count before the loop has earned trust. Agent count is a lagging indicator of trust, so climbing faster than your verification and review capacity grows makes output worse, not better.