A team rolls out AI coding tools and the dashboard looks like a clean win. Task throughput per developer climbs. Epics completed jump by two-thirds. Pull request merge rate ticks upward. Every number that goes into the board deck is moving in the right direction.
Now look at what is happening behind that dashboard. Median time a pull request sits waiting for review rises more than four times over. Pull requests that merge with no review at all rise by nearly a third. The ratio of incidents to pull requests more than triples. This is not a projection. It is telemetry from 22,000 developers across more than 4,000 teams, measured before and after AI adoption inside the same organizations, published by Faros AI in its 2026 engineering report.
The work did not disappear. It moved somewhere the dashboard does not look.
I spent 25 years running large-scale operations at Apple, Intuit, eBay, and Travelers before founding CXAmplify. I watched this pattern play out long before AI entered the picture. A system looks efficient on the surface while the judgment underneath it quietly erodes. What is different now is the timeline. A gap that used to take years to show up in a workforce shows up in a review queue in months. That gap between what the dashboard reports and what is actually happening to the people running the system is why I wrote AMPLIFIED. Scaling AI without scaling the judgment and trust of the people operating it does not produce a faster organization. It produces a brittle one that has not been tested yet.
Two data sets, one broken quality gate
Sonar’s 2026 State of Code Developer Survey asked more than 1,100 professional developers a direct question: do they trust the code AI generates. Among them, 96 percent said no, not fully. Only 48 percent said they always verify AI-assisted code before committing it, and 38 percent said reviewing AI-generated code takes more effort than reviewing a colleague’s. AI already accounts for 42 percent of committed code, a share Sonar expects to reach 65 percent by 2027.
Put those self-reported numbers next to the instrumented ones from Faros and the picture sharpens. Almost nobody trusts the output. Barely half of them check it. The review queue is backing up exactly the way that combination predicts.
This is the pattern I call the Efficiency Trap. Optimization for speed and volume produces gains that are real and visible. The judgment, trust, and accountability that used to sit inside every reviewed line of code do not disappear when the visible metrics improve. They get displaced onto whoever still has to catch what the system missed, and that displacement does not show up anywhere leadership is looking until it becomes an incident.
AI took the Task. Nobody redesigned who owns the Work.
There is a distinction I built AMPLIFIED around: a Task is not the same as Work. A Task follows a pattern the system can learn. Generate a function. Draft a test. Produce boilerplate. AI is legitimately fast at this. Developers in the Sonar survey rate it highest on documentation, code explanation, and test generation, the parts of the job closest to pattern completion.
Work is different. It is the judgment call on whether code that passes every test still does the right thing in a system it does not fully understand. That call requires context the model does not have, and it was never the model’s to own. It is the engineer’s.
When a team adopts AI coding tools without redesigning who is accountable for that judgment call, the accountability does not vanish. It defaults to whoever happens to be reviewing the pull request that day, under whatever time pressure exists, with whatever context they managed to hold onto. Nobody decided that. It just happened, and I have never seen an organization get consistent outcomes from a decision nobody made on purpose.
Someone will point out that throughput is up a third and epics completed rose by two thirds, and ask what the complaint actually is. The gain is real. The complaint is that it is measured against the wrong denominator. Review time, in the same telemetry, grew more than four times over the same period. If a team’s planning captured the first number and not the second, the organization is absorbing the difference somewhere it is not tracking: senior engineers’ evenings, merges nobody looked at, or the incident count. Something is paying for the gap.
The people closest to the system trust it least, and that is a signal, not a complaint
Trust in AI-generated code is not holding steady while adoption grows. It is moving the opposite direction. Stack Overflow’s most recent developer survey found trust dropped from 40 percent in 2024 to 29 percent in 2025, even as adoption reached 84 percent. Among developers with the most experience, the ones closest to production systems, trust is the lowest of any segment measured.
I have made a version of this mistake before, and watched leaders make it and call it strategy. Automate aggressively, celebrate the efficiency gain, declare the rollout a success, and move on to the next initiative. The people who used to carry the institutional judgment about what a system should never do quietly stop being asked to exercise it. Some keep doing the unpaid verification work anyway, at a cost nobody is tracking. Some stop, not because they stopped caring, but because a queue that has grown four times over cannot absorb the same level of scrutiny at the same pace, and something has to give first.
That is disengagement, and it rarely announces itself. It shows up as a senior engineer who used to flag the subtle problem and now approves the pull request because the queue will not wait. By the time that shows up in a retention number or an incident report, the organization has already lost the thing it needed most: that engineer’s judgment, exercised in real time, not reconstructed after a failure.
Accountability is a workflow decision, not a discipline problem
The instinct, when a review queue backs up, is to tell developers to be more careful. That treats a structural imbalance as a character problem, and I have watched that exact mistake burn through goodwill in operations far larger than a codebase. Volume outpaced capacity. Telling people to try harder does not change the ratio. It adds guilt on top of overload.
The fix has to be built into the workflow, not appended to it as a reminder. Three moves I use with clients building this into their engineering operating model:
Name which categories of change can ship on automated checks alone, and which categories, changes touching authentication, billing logic, or production data, require a named human sign-off regardless of how full the queue is. Do not let queue pressure quietly turn Work into a Task. That reclassification is what I call Boundary Drift, and it happens by default, not by decision, unless someone designs against it.
Budget review time as real capacity in sprint planning, not whatever time is left over. If it is growing four times faster than throughput and nobody adjusted the plan, that plan was built on a number that stopped being true months ago.
Track the gap between throughput and review load as its own indicator, watched in the same weekly meeting as velocity, not just the incident count that shows up after something breaks. The incident count is a lagging measure. The gap is a leading one.
Scaling AI is not about speed. It is about whether the people closest to the work still trust it enough to look closely.
The real measure of whether an AI rollout is working is not how many pull requests merge in a sprint. It is whether the engineers closest to the system still believe their judgment matters enough to slow something down when it needs slowing down, and whether the organization has built a place for that to happen without punishing the person who does it.
Adoption and trust cannot keep moving in opposite directions indefinitely. A tool that 84 percent of developers use while trust in it falls to 29 percent is not a stable state. It is a countdown. The pilot phase looks fine because the people running it chose to be there and are paying close attention. The real test comes 18 months later, when the same tools are being used by engineers who never chose them, inside a review queue that has already grown four times over, run by an operating model nobody redesigned to match the new numbers.
Ask your engineering leadership one question: when a pull request merges without review because the queue could not absorb it that day, who made that call. If the honest answer is that nobody decided, that it just happened, the operating model was never designed. It inherited its shape from whichever tool moved fastest, and it will keep inheriting decisions that way until someone builds one on purpose.
