I notice the senior engineers I work with often trust AI output less than the juniors do. They read what the agent produced, recognise that it looks plausible, and slow down. The juniors paste it in. The conventional read is the generational one: older devs are slower to warm to new tools. The data points at something more specific.
The clearest measurement comes from METR's 2025 study. They put 16 experienced developers on tasks in their own codebases, with and without AI assistance. The contributors finished 19% slower with AI. After the study they reported feeling 20% faster. That is a 39 percentage point gap between what was measured and what was felt, in people who do this work full-time, on code they wrote themselves. The slowdown is real. The felt experience lags behind it.
The pattern shows up at scale too. JetBrains' 2025 Developer Ecosystem survey of 24,500 software developers found that those with ten or more years of experience report low trust in AI output 61% of the time. Those with zero to two years of experience report low trust 48% of the time. Stack Overflow's 2025 Developer Survey, separately, with 49,000 respondents, found that 46% of developers actively distrust AI output accuracy. Of the experienced developers in the sample, only 2.6% reported "highly trusting" AI outputs and 20% reported "highly distrusting" them: the lowest trust and highest distrust of any experience bracket.
Engineers with more years of practice trust the tool less.
The piece I wrote last week argued that engineering work has decomposed into producing output and validating it, and that validation is the harder of the two. The senior-trust gap is the same observation from a different angle. Seniors trust less because they have validated more, and validation has shown them more. They have seen the plausible-but-wrong code enough times to recognise the pattern in AI output specifically. Juniors have not yet seen enough wrong-looking code in general to develop the calibration.
A small concrete example. Three weeks ago I was reviewing a retrieval function the agent had written for the ese-bot codebase. Plausible. Type-checked. Wrong about which boundary the retrieval was supposed to respect. It took me fifteen minutes to find the error. The generation had taken seconds. The trust calibration in that moment was not about familiarity with AI. It was about familiarity with the failure modes of code that looks right but is not.
The conventional take in industry coverage is that AI replaces junior work, so juniors are at risk and seniors are fine. The data flips this. Seniors are the ones currently absorbing the cost, because they do the validation: recognising what looks plausible but isn't, slowing down on each piece. Juniors paste it in. The code base will be shaped by whatever validation did not happen.
This matters for how teams invest in their AI practice. If aggregate productivity numbers look positive but the senior productivity number is negative, the aggregate is hiding a population split. The investment that pays off is not training juniors to prompt better. It is making the validation work that seniors are already doing legible enough to scale.
The next piece will be about another split that aggregate numbers hide. The data I cited above is software-developer survey data: JetBrains, Stack Overflow, METR's open-source contributors. Equivalent surveys do not exist for hardware, embedded, or control. What does exist in those domains is validation-failure research that did not measure trust. The next piece looks at that asymmetry.
If you have noticed your own trust in AI output going down rather than up, where in your work did that shift happen?