Satya Nadella admitted something uncomfortable on a podcast in June: he’s a token-maxer too. Reaching for the most powerful model available, for tasks that didn’t need it, because it’s addictive. His actual argument was about cost: “the marginal cost of productivity improvement has to match the marginal cost of the token.” Don’t use frontier models for non-frontier problems, he said. That’s a statement about which model to use. The smarter question, and the one that has nothing to do with which model you’re running, is who has cognitive coverage over what it produces.
If raw output is the wrong thing to maximise, what should you be maximising instead?
The volume trap
I’ve observed engineering teams treat AI-generated code the way Nadella describes token-maxing: reflexively, because more output feels like more progress. Ship more, faster, with more of it agent-written. Every dashboard shows the number climbing. Pull requests up. Features shipped up. Lines of code, if anyone still tracks that, up.
None of those numbers tell you whether anyone understands what got built.
That gap used to be small enough to ignore. When a single engineer wrote a few hundred lines a day, the person who wrote the code and the person who understood it were the same person. Understanding was a side effect of authorship. You couldn’t write it without knowing what it did.
Agents broke that link. An engineer can now direct a dozen agents through a sprint’s worth of work in an afternoon, approving output faster than they could ever have typed it. The code gets written. The understanding doesn’t automatically follow, because nobody had to hold it in their head to produce it.
What code review used to test
Code review has always been a proxy question. On the surface it asks: is this good code? Underneath, it was really asking something narrower: did you write this, and do you understand it? For most of software history those two questions had the same answer, so nobody bothered separating them.
They don’t anymore. A reviewer can approve a pull request they only skimmed, written by an agent, reviewed by another agent’s summary, and ship something nobody on the team could explain if a customer called about it tomorrow. The review happened. Understanding didn’t emerge.
I described a version of this in an earlier post on the code review backlog Meta traced its own outage to: the failure wasn’t that AI wrote bad code. It was that nobody was positioned to catch the ways it was subtly wrong, because the human step in the loop had become procedural rather than cognitive.
Cognitive coverage, not code coverage
Engineering teams already have a concept for what fraction of the code gets exercised by tests: code coverage. Nobody ships a system with a code coverage number they can’t explain. But almost nobody tracks the equivalent question for human understanding: what fraction of what shipped this month could someone on the team explain, unprompted, if it broke at 2am?
Let’s call that cognitive coverage. Not how much got built. How much of what got built lives in someone’s head.
This is the actual skill shift, and it isn’t about learning to prompt better. Prompting produces more output, which is exactly the wrong direction. The skill is the same one code review always tested, applied deliberately instead of incidentally: reading agent-generated work closely enough to own it, not just approve it.
Three things build that muscle:
- Ask what breaks it, not whether it works. An agent’s output usually works on the happy path, because that’s what it was optimising for. The question that builds understanding is what input makes it fail, and whether you can answer that without running the code.
- Explain it before you ship it, not after it breaks. If you can’t describe what a piece of agent-written work does in plain language before it goes live, you don’t have cognitive coverage on it yet, regardless of how many tests pass.
- Rotate who owns what, deliberately. Volume tempts teams to let whoever approved something be its only owner. Spread understanding the way you’d spread any other single point of failure.
Judgment is always the point
This is the same shift I wrote about when judgment, not the artefact, turned out to be the actual work of product management: AI makes the surface activity easier without touching the underlying thinking, and the gap between people who produce and people who understand becomes visible in exactly the moment it matters, which is never a convenient one.
Nadella’s marginal-cost argument was really an argument about waste: stop spending expensive tokens on cheap problems. The engineering version of that argument is sharper. Stop spending your team’s scarcest resource, the understanding of what you’ve built, on producing more of what nobody will ever have to explain.
The code was never the product. It was always the thing that let you deliver an outcome you could stand behind. AI writing the code faster doesn’t change what you’re actually accountable for.
It does make it easier to forget you‘re still accountable for it.
Leave a Reply