The AI coding gap to staff for is validation, not more seats

A column published by devops.com argues that engineering resistance to AI coding tools comes from a change in what the job is, not from fear of losing it ^[1]. That reframing has budget consequences, because the two figures the piece leans on describe a work queue rather than a licensing problem: 84 percent of developers using or planning to use AI coding tools in 2025, and 33 percent who trust the code those tools produce ^[3][4].

The distance between those two numbers is 51 points ^[1]. Put the other way, roughly two thirds of developers did not report trusting the output they are increasingly shipping alongside ^[2]. The piece characterises the trend as adoption rising while trust falls, and treats that divergence, not job anxiety, as the signal worth reading ^[5]. If you accept the numbers, the marginal constraint in an AI-assisted team is not how many people can generate code. It is how much code can be read, tested, corrected and owned per week.

That is a different staffing plan. The column lists what the developer is now asked to do: define tasks clearly, supervise execution, validate output, accept accountability for code they did not personally write, and work at a higher level of abstraction ^[6]. Each of those is labour with a throughput ceiling, and the piece notes the well-known dynamic behind the friction, that reviewing, explaining and refining someone else's work can feel like more effort than writing the solution yourself ^[7]. Buying more seats increases the input to that ceiling without raising it.

The identity argument also predicts which training spend will fail. The piece distinguishes AI adoption from learning another language, arguing that moving from Java to Python preserves the same underlying craft while AI changes what the workflow and the job actually are ^[8]. Engineers who happily pick up new technology can still resist a move from maker to orchestrator, on that reading ^[1]. So a course catalogue is the wrong instrument. What changes is who signs off, who is on the incident, and what the performance review measures.

The column's advice to management is to stop framing AI as only an efficiency initiative, on the grounds that "AI will save you time" does not address motivation, ownership, accountability or identity ^[9]. It nominates architecture, judgment, validation and outcome ownership as the skills that gain value ^[10], and claims the strongest engineers of this period will be those comfortable managing both people and autonomous agents ^[11]. It goes further, arguing that the top one to two percent of engineers are separated less by technical range than by willingness to let go of hands-on coding and be measured on outcomes ^[12]. That last point is the author's assertion, not a finding, and it is the sort of claim that gets used to justify promoting the wrong people.

Two caveats on the evidence. The piece cites a 2024 peer-reviewed study for the identity claim ^[2], and as supplied it names neither that study nor the 2025 survey behind the adoption and trust numbers ^[13].

Worth watching: whether the trust figure moves in the next survey cycle or stays flat while adoption climbs, and whether teams start reporting review capacity, revert rates and time-to-sign-off as first-class metrics rather than counting generated lines or accepted suggestions.