The AI Adoption Bottleneck Keeps Moving
Boris Cherny’s framework shows how access, attention, review, trust, and governance become the constraint in turn, and what unlocks the next phase.
In a recent X post, Boris Cherny, who created Claude Code, describes a pattern he hears every day: one engineer learns to use Claude and ships far more than before, while the rest of the company barely moves.
Across organizations, AI adoption tends to unfold in recurring phases. Each one adds a capability that lets a person coordinate more work, manage more agents, and move faster. But as that capacity grows, a new part of the system starts to queue: access gives way to attention, attention to review, review to trust, and trust to portfolio governance.
The path is not universal. Different teams move at different speeds, and different workflows inside the same company can sit at different points. A dependency update might run safely in the background while a payment change still needs close supervision. The practical question is not, “What level are we?” It is, “Where does this work wait?”
First, the organization opens a lane
In the beginning, the problem is rarely the model.
Capable AI may be blocked entirely. Employees may have access only to an older or lighter model through a slow internal gateway. There may be no approved way to connect an agent to company context, run it against a real repository, or host the work it produces. Useful experiments stay on individual laptops.
The bottleneck is institutional permission. Security, procurement, identity, data policy, and deployment have not yet been turned into one path a team can actually use. Engineering cannot produce evidence without access, while the organization cannot approve an open-ended capability without evidence.
The first useful move is deliberately narrow:
Create one governed path. Give named users access to one real workflow through a scoped pilot, not a company-wide entitlement.
Make the boundary reviewable. Claude Enterprise controls such as SSO, SCIM, role-based access, retention policy, audit logs, and the Compliance API give security teams something concrete to approve.
Let the output go somewhere useful. Keep execution, hosting, identity, and budget inside the organization’s existing rules so agent-created work can enter the delivery system.
This phase ends when one person can use a capable agent on real work without creating a policy exception every time.
Then one engineer learns to delegate
Now the familiar pair-programming experience begins. An engineer describes a task, watches the agent edit, inspects nearly every response, and reviews almost every line before merge.
The work can feel dramatically faster, but it is still synchronous. When the agent works, the engineer watches.
Attention is the bottleneck. The agent has not earned enough trust to continue while the engineer moves on to something else. That distrust is often reasonable: the agent may not have the real build, a meaningful end-to-end test, or a clear acceptance condition. It returns code, but not enough evidence.
Two changes loosen that dependency:
Move from chat into the real repository. Claude Code in the terminal, desktop app, or IDE lets the agent work where the build and project instructions already live. Plan mode creates a no-source-edit checkpoint before implementation, while the person still keeps merge authority.
Make verification part of the task. Builds, types, linting, focused tests, and an end-to-end check should run before handoff. Auto mode can remove routine permission prompts inside explicit ask and deny rules.
The shift is subtle but important. The engineer stops approving every action and starts approving intent and evidence. Once one bounded task can run and verify itself, the engineer can start another.
Soon, work starts to overlap
The engineer is no longer operating a single pair. Several independent tasks can move at once: one agent investigates a flaky test, another updates a dependency, another fixes a bug, and another reviews a pull request.
The gain does not come from typing faster. It comes from overlap. Maintenance work no longer has to wait behind feature work simply because one person cannot hold both tasks at once.
But parallel output creates a new problem. If every stream finishes at the same time, the engineer inherits a queue of diffs, questions, and integration decisions. Writing became cheaper; review did not.
Human review throughput is now the bottleneck.
Anthropic describes this same shift in its Code Review announcement. The Team and Enterprise research preview uses multiple agents to inspect a pull request, investigate suspected bugs, and rank findings, but it does not approve the change. The final decision remains human. Automated review absorbs mechanical investigation; it does not turn a large diff into an automatic merge.
Parallel agents also need more context than a supervised pair. They can make locally sensible changes that violate another team’s convention, duplicate an existing service, or miss the discussion that explains an awkward design. If a human must paste that context into every prompt, concurrency merely moves the bottleneck back to orchestration.
The tools that matter here are different:
Agent view and worktrees make several sessions visible while keeping their edits isolated. Agent view is currently a research preview.
Claude Code Review and Claude Security filter mechanical and security findings before human review while people retain approval.
Scoped MCP servers and connectors let agents retrieve context through restricted OAuth scopes and managed allow or deny rules instead of receiving indiscriminate company access.
Telemetry shows which loops fail, where review waits, and which tasks consume spend without shipping. These are operating signals, not billing records.
Parallel sessions become genuinely useful when they stop behaving like separate conversations. Each needs to gather its own bounded context, run its own checks, and escalate only the decisions that require a person.
Then trusted loops start themselves
So far, a person has started most of the work. The next change is that schedules, repository events, monitoring alerts, and other agents begin to trigger it.
A nightly routine investigates flaky tests. A pull-request event starts a review. An alert opens a session with the failing context already attached. A parent agent delegates research, implementation, and verification, then returns one result. Maintenance and cleanup stop waiting for somebody to find an empty afternoon.
This is where the task becomes a loop: a trigger, the context needed to act, a set of permitted actions, evidence that checks the result, and conditions that stop or escalate the work.
Trust in the loop is now the bottleneck. Team decision throughput and token efficiency matter too, but both become manageable only when the loop has known failure modes and a reliable way to ask for help. A successful demo is not enough. The organization needs repeated evidence that the workflow behaves correctly within a clearly defined boundary.
The questions change accordingly. The operator stops asking whether every line was read and asks instead what evidence the loop produced, which context was missing, why it stopped, and which decision still requires a person.
Anthropic’s account of running an AI-native engineering organization makes this division concrete. Claude can handle style, linting, tests, and bug-finding. People remain involved where legal risk, security boundaries, product judgment, or deep domain expertise matter.
Several capabilities make that selective involvement possible:
Subagents and dynamic workflows divide research, implementation, and verification into workers with explicit inputs, tools, outputs, and acceptance tests. The parallel-agent documentation distinguishes the coordination styles.
Skills and
CLAUDE.mdcarry reusable instructions and repository knowledge; hooks and managed permission rules enforce hard stops.Routines, Channels, and goals cover different parts of initiation and completion. Routines start scheduled or event-triggered work, Channels feed events into an open session, and
/goalevaluates transcript evidence against a completion condition. Routines and Channels are research previews, so the durable design is the mechanism, not the current product label.Sandboxing limits filesystem and network reach when a loop runs without somebody watching it.
Autonomy here does not mean removing humans. It means using them selectively. The loops that earn trust across repeated runs can become named automations. The others remain supervised.
Finally, people steer by intent
At the far end of the journey, people no longer assign and inspect every task. They set objectives, constraints, budgets, and measures of success. Agents initiate much of the work, while humans monitor exceptions and make decisions that exceed the system’s authority or confidence.
The wrong mental model is one giant autonomous organization. A safer one is a portfolio of bounded automation lanes. A migration lane, a fuzzing lane, a feedback-remediation lane, and a feature-building lane require different tools, evaluators, budgets, and approval boundaries.
Large code migrations show why this shape can work. They have finite scope, repeated transformations, and machine-checkable acceptance criteria. Anthropic’s migration write-up describes a generated Zig-to-Rust port of Bun that passed the existing test suite before merge and still produced post-merge regressions. A green evaluator is necessary evidence, not proof that an autonomous workflow is risk-free.
Portfolio governance is now the bottleneck. The organization must decide which work is worth automating, which evaluator is credible, how much each workflow may spend, and which exceptions must remain permanently human. One blanket policy will make low-risk work too slow and high-risk work too permissive.
The control layer becomes more important than any single coding interface:
The Claude Agent SDK turns trusted loops into named services with explicit tools, permissions, and sessions.
A workflow registry records purpose, owner, trigger, data boundary, version, and emergency stop so an operator can answer what is running and why.
Outcome contracts match the evaluator to the work: tests and behavior for migrations, reproducible crashes for fuzzing, acceptance criteria for features, and measured resolution for feedback remediation.
Budget and model routing place ceilings on estimated cost and usage and reserve stronger models for work whose ambiguity warrants them.
Exception routing sends compact evidence to the right person when a loop exceeds its authority or cannot continue safely, with rollback and an emergency stop path.
This is not autonomy without governance. It is governance operating at the same speed and granularity as the automations.
The first diagram shows how the bottleneck moves. This one shows what accumulates underneath it: each phase carries earlier controls forward, adds a few new capabilities, and expands the amount of work and the number of agents one person can coordinate. The counts are illustrative scale cues from Cherny’s framework, not maturity targets.
The takeaway
AI adoption is a story of moving bottlenecks: from institutional permission, to engineer attention, to human review throughput, to trust in the loop, and finally to portfolio governance.
New capabilities matter because they remove the constraint in front of the organization. Guardrails matter because they make the next degree of autonomy acceptable. Tokens alone do neither.
Do not diagnose progress through licenses, token burn, or the number of agent sessions somebody can keep open. Find where work waits. Add the smallest capability and boundary that can remove that constraint. Then watch where the queue moves next.
The goal is not maximum autonomy everywhere. It is an organization that can choose the right operating boundary for each workflow, explain that choice, and move it only when the loop has earned more trust.
Based on Boris Cherny’s X post and Steps of AI Adoption.