"One person is 10x'ing their output with Claude, but the rest of the org hasn't caught up." That's how Boris Cherny, the creator of Claude Code at Anthropic, described the pattern on X on July 17, 2026. It matches what we see on almost every engagement. AI adoption in a team almost always starts the same way: one engineer gets several times faster within a couple of weeks, while five people next to them never get it off the ground. The gap isn't about talent, and it isn't about which model you picked.
We ship AI agents and automation every week, so we read Cherny's thread less as a metaphor and more as a description of our own work. The gap has real mechanics, it's measurable, and you close it with the order of adoption, not with a subscription to a smarter model. Below are Cherny's four steps, the numbers from DORA 2025 and METR, and what we see ourselves when one enthusiast fails to scale to the team.
The gap everyone sees: one person 10x's, the team stalls
The adoption gap is the moment individual productivity from AI jumps while team-level delivery stays flat. It shows up almost everywhere, and it's easy to measure.
It starts with a reassuring number: 84–91% of developers have tried AI tools (Digital Applied). But only about 51% use them daily. Real integration into work lives in exactly that gap between "touched it once" and "this is how I work now." And the gap is expensive: daily users ship 60% more pull requests (a median of 2.3 vs 1.4 PRs per week) and save around 4.1 hours a week (Digital Applied).
Cherny himself is the top edge of that distribution: he ships 10–30 pull requests a day by running several parallel Claude instances (Lenny's Newsletter). And it isn't a one-off anomaly. Inside Anthropic, engineer productivity grew roughly 8x in a year, and Claude Code now accounts for about 4% of all public commits on GitHub — the top of the distribution really is high, when a team carries adoption all the way through. Behind Cherny's result isn't senior-engineer magic but a workflow he built and tuned. That's why the team "can't catch up": they see the result, not the workflow that produced it.
Why an individual 10x doesn't scale on its own: AI is an amplifier, not an equalizer
An individual win doesn't transfer to the team by itself, because AI amplifies what's already there instead of leveling everyone up to the best person.
That's the headline finding of Google's DORA 2025 report, built on a survey of roughly 5,000 professionals. It calls AI an "amplifier and a mirror": in cohesive teams it speeds up flow, in fragmented ones it exposes dysfunction. 90% of developers already use AI (+14 points year over year), over 80% report a productivity boost, yet team delivery metrics stay flat (DORA / Google).
Up close the numbers look paradoxical. High-adoption teams merge 98% more pull requests and, at the same time, spend 91% more time on review, while end-to-end DORA metrics barely move (Philipp Dubach). Six independent studies converge on roughly one ceiling: about 10% of system-level gain at 90%+ adoption. More code doesn't mean faster delivery.
The most sobering data point is the METR experiment (July 2025). Sixteen experienced developers, working on a codebase they knew well, were 19% slower with AI. Beforehand they expected a 24% speedup, and afterward they still believed they'd been 20% faster. The gap between perception and reality is nearly 40 points (METR). "It feels like I got faster" is not a metric.
To be fair, METR reran the measurement on newer models in February 2026, and the slowdown shrank to roughly zero. The lesson for a team lead isn't "AI is useless" but "you can't take the effect on faith, you have to measure it." All the more so because trust in AI-written code is low on its own: in that same DORA data, only about a quarter of developers trust it a lot, while roughly a third barely trust it at all.
We unpacked this mechanic in more detail in our piece on the two speeds of AI: model capabilities grow by the quarter, while an organization's ability to rebuild its processes grows by the year.
Boris Cherny's four steps of AI adoption in a team
Cherny frames AI adoption in a team as four sequential steps: experiment → adopt intentionally → measure the return → optimize for cost. Here the order matters more than the speed.
- Experiment. People try the tools on real but non-critical tasks. The goal isn't a top-down "everyone must use AI" mandate, but that everyone at least tries it.
- Adopt intentionally. Shared practices appear: where and how you apply it, which tasks you hand to the agent, what goes into shared context (a
CLAUDE.mdfile, shared prompts). This is the shift from "I found a trick" to "the team has a way." - Measure the return. This is where most teams break. Cherny puts it plainly: usage is worth watching on a dashboard, but it "measures activity, not return" (dnyuz writeup). The right metric is engineering-hours saved: what would this task have cost by hand? That's your ROI, not the number of tokens burned.
- Optimize for cost. Only now does it make sense to count token cost and make the pipeline cheaper.
The main mistake is starting at step four. As Swarmia expands on the idea: "if you go straight to cost optimization, skipping the earlier stages, you'll never succeed with these tools." Until the team has been through experiment and adoption, there's simply nothing to optimize.
By Cherny's logic, the big win doesn't come from AI writing a bit more code. It comes when routine fixing and maintenance move into the background and people are freed up for new work. We wrote about why this doesn't replace engineers but changes what you pay them for.
Turning one enthusiast into a team: treat adoption as a product
You don't close the gap with a "please use AI" memo. You close it when adoption gets an owner, training, and metrics — as its own product.
The best documented case is Plaid. They literally called adoption "our own product": a dedicated team tracked usage and retention by cohort, ran a dashboard, and reached out directly to people who had churned to find out why. Add an internal AI Day with hands-on workshops (80%+ engineer participation, 90%+ CSAT) and short 1–3 minute videos of real workflows instead of generic vendor training. By May 2025, 75%+ of their engineers were using AI regularly (Plaid).
What else works, by the data:
- Internal champions. A champions program lifts adoption by up to 40%. You pick not the loudest people but the technically strong and respected ones; what matters isn't the champion-to-employee ratio, but that every team can reach a champion without filing a ticket (Faros AI).
- Prompting training. Teams without structured training see 60% lower productivity gains (DX). Fluency with the tool doesn't arrive on its own.
- Patience with scale. PwC Netherlands went from 300 enthusiasts to all 6,000 employees in roughly a year; Citi built a network of 4,000+ "accelerators" (Lead with AI). That's months, not a sprint.
The common denominator: you pull the knowledge out of one person's head and turn it into a shared asset — prompts, checklists, short demos. Skip that, and the workflow leaves when its author does.
The practical minimum a team lead can start with fits in one sprint: name a single owner for the rollout, move that one enthusiast's working prompts into a shared repo, set up a short weekly review of "what worked, what didn't," and agree on one shared context file per project. It's cheap and needs no new-license budget, but these are exactly the things that turn a personal trick into a team practice. Champions and training come next — without that base scaffolding, they run empty.
Common mistakes — and what we see on projects
Almost every failed AI adoption in a team is a management problem, not a technical one. Per DX, companies that treat adoption as a process rather than a license handout get three times the results.
What breaks adoption most often:
- Measuring the wrong thing. Counting licenses and tokens instead of engineering-hours saved. The "activity" dashboard turns green while the return stays at zero.
- Speed without review. Across a sample of 22,000 developers, epics closed per person rose 66%, but bugs rose 54% and the odds of a production incident tripled (Faros AI). More code without review capacity is debt, not productivity.
- A top-down mandate without enablement. Per MIT, only 5% of enterprise AI initiatives reach production; adoption is a people problem, not a technology one. And the perception gap is huge: 45% of employees think adoption succeeded, versus 75% of the C-suite.
- Invisible workflows. One person keeps everything in their head, and the team can't reproduce it.
On our own projects we start exactly here: we agree on what counts as return, who owns the rollout, and which tasks go to the agent first. These are the same conclusions we reached after 100+ AI consultations: it's almost never about the model.
If you'd like to scope AI adoption for your own team and processes, take a look at our AI implementation services or just get in touch.