There is a simple test for whether an eng team's AI adoption is real or just a few people enjoying a new tool.
If you cannot say what changed and roll it back cleanly, it is still a pilot.
That sounds strict. I think it needs to be.
Most teams spend their energy asking whether Claude Code or Copilot is "good enough." Fewer ask what happens when an AI-assisted change turns out to be wrong on a Tuesday afternoon. That second question is the one that tells you what you actually have.
Can the team see what the tool changed?
Can a reviewer explain why they approved it?
Can someone undo it without a forensic investigation?
If the answer is no, a few people are moving fast with AI. The team is not.
Adoption metrics hide the real question
Seat counts and weekly-active-user dashboards are easy to report and easy to be wrong about. They tell you who opened the tool. They do not tell you whether the rest of the team trusts what it produces, or whether anyone would catch a bad AI-assisted change before it shipped.
A team can have high tool usage and still have no real adoption, because usage and workflow are not the same thing. One engineer running Claude Code all day is a power user. It is not a system the team can rely on.
What "still a pilot" looks like on an eng team
The pattern is rarely "the model wrote bad code." It is usually one of these:
The diff is too large to actually review. A reviewer approves it because reading every line would take longer than redoing the work.
Nobody can say why a change was approved. "It looked fine" is not a review standard, whether a human or an AI wrote the code.
AI-assisted changes do not go through the same path as everything else. They land through a side door: a fast-tracked PR, a direct push, a "just this once."
There is no shared expectation for what a good AI-assisted PR looks like, so quality depends entirely on which engineer is driving.
Reverting means reconstructing intent from a diff instead of reading a clear commit message and rolling back a normal change.
These are workflow problems, not model problems. They are also why AI coding tools can look transformative in week one on one engineer's laptop and barely move the team's output three months later.
What rollback actually requires
Rollback does not need new tooling. It needs a few things the team already knows how to do, applied consistently:
- AI-assisted changes go through the same review and merge path as any other change
- the diff is scoped small enough that a reviewer can actually read it
- commit messages and PR descriptions say what changed and why, not just that a tool was used
- a reviewer can explain, in a sentence, why they approved it
- reverting is a normal git operation, not a special case
If you have that, the team can move fast with AI and still trust what ships. If you do not have that, one bad AI-assisted change becomes a trust event, and the team quietly reverts to doing things the slow way, tool subscriptions included.
Where to look first
You do not need a company-wide audit to run this test. Pick five recent PRs where AI clearly did meaningful work. For each one, ask whether the team could answer the three questions above.
If most of them pass, the team has a real workflow, even if it is informal. If most of them do not, that gap, not the choice of tool, is the actual adoption problem.
The practical standard
A coding agent is not "adopted" because a few engineers are fast with it.
It is adopted when the whole team can ship AI-assisted work through the same review path, explain what changed, and undo it cleanly when it is wrong.
That standard is less exciting than a demo of one engineer shipping a feature in an afternoon. It is the one that determines whether AI adoption holds up once the novelty wears off.
If you want help mapping where your team actually stands and building a workflow the whole roster can run, book a call.