Why two developers fly with agents and the other ten do not

Six weeks into almost every coding agent rollout, the same distribution appears. Two developers are visibly faster: they delegate whole tickets, run agents while they review, and their pull requests arrive with tests already written. A few others use the tools as expensive autocomplete. The rest tried twice, got mediocre results, and went back to typing everything themselves. This is the AI coding adoption gap, and it is the main reason a rollout that looked successful in month one looks like wasted budget in month six.

The comfortable explanation is talent: some people are AI-native and the rest are not. We have watched enough teams up close to say that explanation is wrong, and that believing it guarantees the gap never closes.

The adoption gap is not a talent gap

Sit next to your two fast developers for an afternoon and what you see is not brilliance. It is procedure. They write the task down before starting, with a definition of done. They know which files and constraints the agent needs and hand them over up front. They treat the first output as a draft, interrupt early when the direction is off, and make tests the referee of whether the work is finished. They also know which tasks not to delegate at all.

None of that is innate. All of it is learnable in days. Almost none of it is written down anywhere, and that last fact is the entire problem.

Why the knowledge stays stuck in two heads

Classic engineering practice spreads through artifacts. A style debate ends in a linter rule. A production incident ends in a runbook. A recurring review argument ends in a checklist. The repository accumulates the team’s judgment, and new people inherit it on day one.

Agent workflow has no such artifact by default. Prompt history is personal. Sessions happen in a terminal nobody else watches. When one of the ten gets a bad result, the failure is private too, so nobody debugs their workflow the way a colleague would debug their code. The two who fly usually cannot even articulate their advantage: ask them why they are fast and you get a shrug, because a procedure that has become habit feels like nothing at all.

That is why the gap is an organizational bug rather than a skills shortage. Organizational bugs do not fix themselves through enthusiasm, license renewals or another vendor demo.

The fixes put the workflow in the repository

Everything that works against the gap is a form of extraction: getting working procedure out of two heads and into places where the agent, and therefore everyone, can use it.

Shared agent skills come first, because the mechanism is direct: a skill turns one developer’s workflow into the team’s by writing the procedure into a versioned file the agent loads when the matching task shows up. The migration routine, the review checklist, the test conventions your best user silently applies: once these are skills, the skeptic inherits them on their first attempt instead of failing without them.

Conventions come second. A team that has shared standards for how agent tasks get framed, what context gets attached and what done means removes most of the variance that gets blamed on the model. Free-form prompting produces free-form quality, and the slow ten are usually free-forming.

Champions come third, because artifacts alone do not change habits. One credible engineer per squad who pairs, runs office hours and reviews workflows does more than any mandate. We have written up how the champion model keeps adoption alive after the initial push fades.

Workshops come last and must be role-specific, on your own codebase. Generic prompt training does not transfer. Watching a colleague delegate a real ticket from your own backlog does.

Watch the median, not the heroes

While you fix the gap, measure it honestly. Averages hide it: two power users can carry the aggregate numbers while ten people barely touch the tools. Track the distribution instead: how many engineers delegated at least one task end to end this week, how the median compares to the top pair, and what actually changed in your delivery against the baseline you took before rollout. The goal is not to make the top two faster. It is to make the median look like them.

The gap is also good news in disguise. Your ceiling is not a vendor promise, it is proven internally, by your own people on your own codebase. Closing the distance between the two and the ten is the core of our agentic engineering work with client teams: baseline the current state, run a pilot squad, extract what works into skills and conventions, then measure monthly. The two developers already proved it works. The job is making it ordinary.