The most useful thing I heard about AI in engineering teams in 2026 came from someone who was a skeptic in 2025 and changed her mind on evidence.
Charity Majors, cofounder of Honeycomb, on The Pragmatic Engineer podcast, August 12, 2026: there are two camps in every company, the enthusiasts who see real wins and the people on call who see systems getting worse, and neither is making it up. The split, she says, often comes down to who is on call and who is not. Intercom published that its reliability and code quality fell for eighteen months before starting to recover. Her ask is that whoever reports a win also reports what it cost.
I ran into both camps inside one client team. Two developers were merging agent code at a pace nobody had seen. The platform engineer was absorbing the incidents and had stopped believing the wins were real. Both were right, and they had no shared number.
We put three on one page: what shipped, what came back, and time in review. The enthusiasts kept the speed. The on call engineer got the checks moved in front of the merge. The argument ended when the numbers were shared.
Simon Willison, creator of Datasette, put the bar on X: production code written by an agent should be held to a higher standard than code written by a person.
Questions and answers
What are the two camps about AI in engineering teams?
The enthusiasts, who see real wins such as rewrites done in days and toil automated away, and the people on call, who see incidents rising, mental models melting and systems getting worse as more generated code is merged. Charity Majors, cofounder of Honeycomb, said on The Pragmatic Engineer podcast in August 2026 that neither side is making it up.
Why does the split follow the on call rotation?
Because the people the buck stops with see the cost first. Majors describes the split as often coming down to who is on call and who is not: the on call group sees the slop and the incidents, while the enthusiasts see the wins and do not connect them to the cost. Each side ends up believing the other is exaggerating.
Is there evidence that reliability actually falls?
Majors cites Intercom, which published that for eighteen months its reliability and code quality went down after adopting AI heavily, and had only just started to recover. She praises them for publishing the cost alongside the wins.
What does Majors ask engineering leaders to do?
Tell the whole story. Report the win and what it cost, in the same place. Her view is that the two camps stop talking past each other when the cost of a win is stated out loud rather than whispered.
What is the trust account?
Majors's frame for shipping code nobody read. If you debit trust when code is created, because an agent wrote it and no human read it, that trust has to be built back somewhere else: tests, evaluations and conformance checks that prove the new code behaves within the bounds of the old. She says the question is no longer whether teams will ship code they did not read, but what it would take.
What closed the gap in a real team?
In one client team, one page with three numbers that both camps read: what shipped, what came back, and time in review. The enthusiasts kept their speed, the on call engineer got automated checks moved in front of the merge, and the argument ended when the numbers were shared.
Sources
- The Pragmatic Engineer podcast, Stop being skeptical about AI for development, with Charity Majors, August 12, 2026. https://www.youtube.com/watch?v=HC8T1OlgYi0
- Simon Willison on X, September 11, 2026. https://x.com/simonw/status/2098468950871032095
