Why AI adoption stalls at half the team, and what moves it

The pattern is the same in most engineering organizations: a few enthusiasts, a careful middle that opted out, and an adoption number stuck around half. The causes are specific and fixable, and none of them is the tool.

Ask an engineering leader how AI adoption is going and the honest answer, more often than not, is a number close to half. A few engineers use the tools for everything. A few refuse. The large middle tried them, got mixed results, and quietly went back to working the way they know. The mandate went out, the seats are paid for, and the plateau holds. The reasons are consistent enough to list.

Five reasons the middle opts out

1. There is no review standard, so careful engineers protect the codebase by abstaining. The engineers who care most about quality are the first to stop using AI when they see fast, unreviewed code entering the main branch. The leader who wrote publicly that they feel like they are losing control of their own projects described exactly this moment. Abstaining is the rational move when nobody has said what gets delegated and how output is reviewed.
2. The tools were tried on the hardest code first. A developer opens an assistant on the oldest, least documented part of the system, gets confident nonsense, and concludes the tools do not work here. They were right about that file and wrong about the codebase.
3. The codebase is not readable by the tools. No context files, thin tests, tribal knowledge in people's heads. AI output is only as good as what the tool can see, and in most mature systems it sees very little.
4. Nobody owns it. The mandate names a goal. It does not name a person who configures the tooling to the stack, publishes the delegation list, and shows up in code review to hold the standard. Ownership by everyone is ownership by no one.
5. The fears are legitimate and unanswered. Leaders worry, in public, about hollowing out junior talent. Juniors worry about learning nothing. Seniors worry about becoming full-time reviewers of machine output. A memo does not address any of that. A working practice does.

What moves the number

The fixes map one to one onto the causes, and they are practice changes, not tool changes.

• Publish the delegation list and the review standard. One page: which task types the team delegates to AI by default, which always get a human first, and what an AI-produced pull request must carry to be reviewed. The careful middle comes back the week that page exists, because now using the tools is the disciplined choice rather than the risky one.
• Start where AI wins. Tests, boilerplate, migrations, documentation, well-covered modules. Early wins in the right places create the habit; the hard code comes later.
• Make the codebase AI-ready. Context files that describe the architecture and conventions, tests that make output verifiable, documentation of the parts only two people understand. This is the work that turns "the tools do not work here" into "the tools work here now."
• Measure delivery, not logins. Cycle time, review turnaround, rework rate, per task type. The number that unblocks a skeptical senior engineer is the rework rate staying flat while cycle time drops. We wrote a practical setup for measuring it.
• Give it an owner who works in the code. Standards demonstrated on real tickets, in the team's own pull requests, by a senior engineer the team respects, change behavior in weeks. Standards in a document change little.

The shape of the fix

Every item on that list is something a senior engineer does from inside the team, on real work, with your developers taking part. None of it can be bought, and none of it survives as a document nobody reads. That is what the forward deployed engineer role exists to do: own the practice in the middle, where the decision made above the team and the uneven habits below it never meet on their own. Give the middle an owner and the plateau moves, because the reasons it held were never about the tools.

Frequently asked questions

Why do developers stop using AI coding tools after trying them?

Mixed early results on hard or undocumented code, no review standard that makes AI use the safe choice, and no one showing what disciplined use looks like on the team's own tickets. The careful majority opts out until those three change.

How do I get the rest of my engineering team to adopt AI?

Publish a delegation list and a review standard, start on task types where AI reliably wins, make the codebase readable to the tools with context files and tests, measure delivery rather than usage, and give the practice a senior owner who works in the code.

Is a 50 percent AI adoption rate bad?

It is the normal plateau after a mandate without an owned practice. It is only bad if it stays there. Teams that add a review standard and an owner typically move past it within weeks, and the adoption number stops mattering because delivery metrics take its place.

What does AI-ready code mean?

Code that an AI tool can work in reliably: documented architecture and conventions in context files, tests that make output verifiable, and the tribal knowledge of the system written down where the tool can read it.

Part of: Forward Deployed Engineers at Viaro