ArticlesFoundations

The two ladders of AI adoption

One grades the risk of the work. The other grades how many agents you run. They are not the same climb.

Stuart LeoAugust 3, 20265 min read

Two people argue about AI adoption and talk straight past each other constantly. I've been both of them.

One says we're quite advanced — agents run unattended overnight on real production code. The other says you're barely started, you're running one agent and reading every line it writes.

Both are right. They're describing different ladders, and neither of them said which one.

Two people, two different climbs

The confusion is structural rather than careless. There genuinely are two independent things that get better as a team matures with agents, and both get called "adoption".

Ladder one is the risk of the work. Are agents doing trivial chores, or real features, or work that ships without a human reading every line? This is the one C² already publishes as crawl, walk, run, and it's about what you trust an agent with.

Ladder two is agent count and what it makes you. One agent you sit beside, or several running in isolation, or more output than you can personally read. This is about how many and what your job becomes.

They're not stages of one progression. They're axes. And the arguments happen because everybody assumes their axis is the axis.

Ladder one: the risk of the work

The first ladder has 3 rungs and it's the better-known of the two.

Crawl is work where mistakes are cheap and instantly visible — adding tests to code that lacks them, small well-defined bugs, mechanical refactors the tests guard, dependency bumps. It feels unambitious. That's the point: it builds the test coverage and the judgement everything above it stands on.

Walk is real features, behind review. The agent builds, a human or a bench agent checks before it lands. Most teams should live here most of the time — ambitious enough to matter, safe enough to catch the misses.

Run is autonomous, well-fenced work. Unattended sessions on scoped tasks behind isolation and a test gate. The same run that would wreck a team on day one is safe on day 90, entirely because of what got built in between.

The failure this ladder explains is starting at run — pointing agents at the highest-stakes work first, watching it go wrong in ways nobody catches, and concluding that agents don't work.

Ladder two: agent count, and what it makes you

The second ladder has 4 rungs, and the useful thing about it isn't the numbers. It's the way your bottleneck changes.

RungWhat you becomeWhat constrains you
Assisted (~1)A pairYour attention. No self-verification yet, so you read everything and never look away. Work is synchronous — you sit and watch.
Parallel (~10)An orchestratorReview throughput. You hand-write less and check several streams instead, each agent verifying itself before you see it.
Supervised (~100)A manager of managersTrust in the loop. "Did you read the code?" stops being the right question.
Intent-steered (1,000+)A monitor by exceptionKnowing what to automate, and matching guardrails to each kind of work.

The transitions matter more than the rungs, and both are things worth naming plainly.

Assisted to parallel needs a self-verification loop you trust. Tests, build, lint, an end-to-end check against a real environment. Without it, going wide just multiplies output you have to read by hand — your attention was the bottleneck, and you made it worse.

Parallel to supervised needs a way for the agent to pull in context — code, decisions, prior discussion. That's the contextbase, and it's the gating capability for autonomy. You cannot supervise what you can't equip.

The stated trap at the third rung is worth quoting to yourself before every scale-up: scaling agent count before the loop has earned trust.

Why they're orthogonal

Here's the case that makes it concrete, and it's mine.

For a long stretch I was running one agent, unattended, overnight, on production code, behind a test gate and worktree isolation. On ladder one that's run — the highest rung, genuinely autonomous work. On ladder two it's assisted — a single agent, and a pilot reading every diff over coffee the next morning.

Neither ladder explains that team on its own. Ladder one says "advanced". Ladder two says "beginner". Both are true, and the pair is the accurate description.

Plotting it makes the point immediately:

              assisted    parallel    supervised   intent-steered
    run          ●        ┌────────────────────┐
    walk                  │  the graph is      │
    crawl                 │  earned in here    │
                          └────────────────────┘
    ● = one agent, overnight, well-fenced, every diff read

This is why single-number maturity scores mislead. The delivery-research community landed on the same conclusion years ago — DORA measures several independent things precisely because one composite level hides more than it reveals. Compressing two real axes into one rung means the advice you get back is aimed at a team that doesn't exist.

Stuart Leo

Most adoption arguments are two people standing on different ladders, each certain the other is on the wrong rung.

Which rung earns the graph

The two-axis view answers a question I get asked a lot, and answers it in a way a single ladder can't: when should I start running agents in a fan-out?

Topology is a parallel-to-supervised capability. It sits in that band on ladder two, and it has a prerequisite that isn't optional: a self-verification loop you already trust. If your agents don't reliably prove their own work before you look, running 6 at once produces 6 streams of unverified output and a reviewing problem you can't staff.

So the honest answer to should I build a graph is usually not yet, and here's what to build instead — the loop. Which is a much less exciting answer than the current enthusiasm suggests, and it's the one that actually holds.

The reverse mistake is real too. A team stuck at crawl on ladder one, adding agents rather than raising the stakes of the work, ends up with 5 agents writing tests nobody needed. Moving up ladder one is nearly always the higher-value move, because it's what builds the verification that ladder two depends on.

Ask which axis first

The honest cost of the two-axis view is that it's harder to report. One number makes a nice slide. Two axes require a sentence, and the sentence is usually "advanced on one, early on the other."

That sentence is worth the awkwardness, because it's the one that tells you what to do next. Advanced on risk and early on count means build the verification loop. Advanced on count and early on risk means you're spreading trivial work thin.

Ask which axis you're describing before you claim a level. Most disagreements about adoption dissolve the moment somebody does.

Start here: see crawl, walk, run, why most agent pilots never reach production, or read the method.

FAQ

How do you measure AI adoption maturity on a development team?
On two axes, not one. The first is the risk of the work you trust agents with — small fixes, then features behind review, then autonomous well-fenced runs. The second is how many agents you run at once and what that makes you — a pair, an orchestrator, a manager of managers. They move independently, and a team can be advanced on one while beginner on the other.
Should I run more AI agents or give them harder work first?
Harder work first, almost always. Increasing the risk of the work builds the tests, context and judgement that make everything else safe. Increasing agent count before you have a verification loop you trust just multiplies output you cannot review — which is the most common way an agent rollout stalls.
What does it take to move from one agent to several?
A self-verification loop you actually trust — tests, build, lint, and an end-to-end check against a real environment — so each agent proves its own work before you look. Without that, going wide means reading several streams of unverified output by hand, and your attention becomes the bottleneck faster than the agents add value.