The Agent Has Finished the Work—Did the Person Signing Off Understand It?

Addy Osmani is an engineering lead on the Google Chrome team. He recently wrote a long article, “Critical thinking when agents do the work,” discussing a specific question: as Agents take over more and more work, how do people preserve independent thinking? He is not trying to persuade people to use Agents less—he uses them himself. What worries him is something else: the smoother Agents become, the more easily people hand over their judgment, and the process is very quiet.

He offers a slippery slope. At the top is cognitive offloading: handing a task to AI but still owning the result. In the middle is deferral: tool output becomes new input, and the result is no longer merely a hypothesis. At the bottom is cognitive surrender: AI output quietly becomes yours, and you feel there is no need to check it. The term cognitive surrender comes from Steven Shaw and Gideon Nave at Wharton. Every step down the slope seems reasonable: the last answer was good, so you glance at the next one; then you only look at the outline of the one after that; then someone asks about a line of code and you can't explain it, even with the Agent right there.

What accumulates this way is cognitive debt. Margaret-Anne Storey has written about what it looks like on teams: the shared theory of the system gets eroded. The code world has a corresponding term, comprehension debt, coined by Jeremy Twei. The scene looks clean, the tests are all green, and the codebase seems fine. By the time you need to change the system, you discover that no one understands it. It is the same with strategy docs and specs: you read the table of contents and sign off, and later no one can explain the key assumptions.

Addy is not asking people to maintain a complete mental model—that's impossible. The Claude Code team has said publicly that they rebuild understanding on demand: whatever part they need to understand, they ask Claude to explain that part. The debt is more recoverable than most engineers think. The precondition is that you know what you don't know. Low-risk things can be fully delegated. When recording a course, he had to choose one of three similarly rated hotels and had no time to read reviews, so he handed it to AI, and the result was usable. Investing, career advice for your children, what the company should do, whether a release is safe—these cannot be handled that way. Where being wrong is cheap, you can let go; where others bear the consequences, the reasoning has to stay in your hands.

Verification is the same. An Agent can run tests, read the output, and try again on its own, which is very efficient. But a green checkmark proves only one thing. Addy asks: What did this check prove, and what did it not prove? A test can make the same mistake as the feature and still be green. Green covers only one property. Completion criteria are best made specific: tests passing, screenshots, logs, traces. When the Agent sends a completion notice, look first at the commands it ran and the output, then at the summary. Claude Code can use a sub-agent in a fresh context to self-evaluate, which is worth baking into the loop. He also asks at the end, “Did I miss anything?”, and often gets two or three missed things out of it.

A 600-line PR is another kind of scene. The variable names are reasonable, the tests pass, and you approve it. Somewhere in there might be a change in the order of transaction boundaries, or a default value for an edge case flipped. You looked at the diff, but you only saw what you expected to see. Writing code and reviewing code are two different skills; at some point reviewing turns into stamping. When reading the diff, assume AI didn't write it, then look beyond the diff at which decisions the Agent made for you: defaults, scope, which requirement it reinterpreted when requirements conflicted. Summaries don't mention these. Have it list the decisions and assumptions, then randomly pick a few lines and ask yourself about them. For long sessions, you can ask for a change report with a short quiz, with the rule that you merge only after a perfect score.

In the comments, someone asked how a junior can build judgment if they have never written code by hand. Someone else asked whether you read the diff or only the summary. Both questions land on the same point: the very abilities supervision requires may be exactly what overusing AI wears away. Anthropic's research on its own engineers and researchers calls this the supervision paradox. Addy's answer is not slick: someone has to be accountable for what ships. Work can be outsourced, much of auditing can be outsourced, but accountability cannot.

You don't need the full routine in daily practice. Each week, write a little code without an Agent, or do something that would be a pain if you forgot it. Each month, write down what you stopped doing and decide which of those things are acceptable. Ask the old question: How lost would you be if AI didn't exist? Verification is work, not a free action. Put it on the schedule, or it won't actually happen.

At the end of the article, Addy offers a list of takeaways: have an assumption before you ask; a green checkmark means only one thing; read what it ran and what it returned before reading the summary; read the diff to know which decisions it made for you; write clear prompts, because they are your understanding of the problem; set a line you won't cross—don't ship anything you wouldn't put your name on; practice by hand the skills you don't want to lose. Agents can help you work and help you check, but the person who signs off at the end has to know what they are signing.