Claude Code team's Addy Osmani on how to retain critical thinking when using Agents

The Agent has finished the work, but you still have to keep the critical thinking

From a share by @addyosmani of the Claude Code team, he doesn't advocate using Agents less, but reminds: the better the model and the more pleasing the output, the less anyone forces you to think it through again; critical thinking doesn't happen automatically, you have to build it into your daily habits -- you can hand the work to tools, but you can't hand off being accountable for the results.

Where the problem lies Previously, a lot of thinking happened between "just asked" and "answer comes out"; now that gap is only a few seconds. Open many sessions in parallel, and the only pair of eyes watching the results is still yours. As models get stronger, the errors you can spot at a glance become fewer; most results are written decently and broadly correct, which actually triggers "take another look" less often. And the workflow is so comfortable that it's easiest to slack off when you're busy.

The author is very clear: he likes these tools, and this article isn't meant to persuade people to use them less, but to help those who already use Agents deeply to keep their independent judgment in an environment where "anything can be thrown out."

Three ways of using it: offloading, deferring, and surrender At the top is cognitive offloading: hand the work to AI, but the result is still yours; he does this all day himself and recommends others do the same. In the middle is deferring judgment: the tool's output becomes the direct input for the next step, no longer treated as a hypothesis. At the bottom is cognitive surrender, a term proposed by Wharton scholars: what AI says quietly becomes your own words, and you don't want to verify it anymore.

The slippery slope often looks reasonable at every step: last time you read it carefully, this time you skim, next time you only scan the skeleton, until someone asks about a certain line and even the Agent can't explain it. In a team this shows up as an increasingly thin shared understanding of the system; in code it's comprehension debt -- tests are green, the code looks clean, and only when you really need to change the system do you find nobody understands it.

The Claude Code team has said publicly that they have Claude explain whichever part they're working on, rather than keeping a whole-repo model in their heads; the key is knowing which part you're missing. Low-risk things (like choosing a recording venue from three similar hotels) can be fully handed to AI; for investments, career advice for your kids, and at work what product to build, which users a change affects, and whether it can ship, the reasoning still has to stay in your hands. If the cost of being wrong is low, you can let go; if it affects others, don't hand off the reasoning.

Ask yourself a few questions before you start He now often asks himself: · Before starting, did I set even a bad hypothesis first (otherwise, after reading a polished answer, it's hard to imagine other possibilities) · Am I asking it to help me think, or to think for me · How can I prove it's wrong · Have I had another model play devil's advocate · Can I vouch for the result in front of the maintainers · Which skills am I deliberately no longer practicing

When you have no direction, you can also do a "blind-spot scan" first: give the model what you know and let it help you find what you don't know you don't know.

Make verification a habit, don't blindly trust green lights Verification has gone from "writing code" to the bottleneck: give the Agent end-to-end tests, property tests, or real-device interaction, so it tests after changing, reads the results, and changes again. But a green light can also be false reassurance; if the test and the feature make the same mistake, they'll pass together, and one metric doesn't equal full coverage.

So agree first on "what counts as verified," look first at what commands it ran and what the output was, then look at the summary; you can use a newly opened subagent to self-check, and get in the habit of asking "what else is missing." The Claude Code team has a rule of thumb: if you can't explain what these checks would miss, don't rush to click approve. The same goes for customer interview summaries and competitor analyses: spot-check the original text and key numbers.

Actually read the output, don't just scan the structure Facing a PR of hundreds of lines, don't just stare at the places you already thought would go wrong: read the diff as if a human wrote it, then ask the Agent what default choices it made for you, what scope it drew, and how it traded off conflicting requirements; you can have it list decisions and assumptions, or even give you a little quiz -- pass it before merging.

The speed of output exceeds the speed at which you dare to put your name on it -- that's what he calls orchestration cost; opening another round of sessions won't help, you either tighten the checks or slow down. When the amount you dare to sign off on can't keep up, you're no longer reviewing, you're gambling.

Input and taste are still at both ends Human effort moves to both ends: at the front end, write clearly the task, audience, out-of-scope, and what counts as done; at the back end, gatekeep by your own standards.

Humans will press on ambiguous requirements, while Agents often just fill the gaps, creating intent debt -- intent can only come from you. If the prompt isn't clear, it often means the problem isn't clear in your own head either; if it's still wrong after two rounds of tweaks, don't just fine-tune, rewrite the requirement. Confident formatting no longer equals quality; if you wouldn't put your name on it, don't send it out. Record the reasons for falling short in shared configs, hooks, or tests, and taste will accumulate bit by bit.

Stronger models still can't take accountability Models may get better at catching errors in the future, but "what to do, why it's worth it, who it affects, what you're willing to sacrifice" still belongs to humans. Anthropic research has also pointed out the oversight paradox: supervising Claude requires exactly the coding ability that may atrophy from over-reliance.

Work and a lot of verification can be offloaded, but being accountable for the results cannot.

What you can do day to day Do one thing by hand each week that would hurt to forget; each month take stock of what you've stopped practicing and what's acceptable; schedule serious verification into your time as real work. Skills you stop practicing will decline, and possibly faster than you think.

Start putting it into practice now: set up checks deliberately; be honest about whether you're still carrying the results; hypothesize first; a green light proves only one thing; evidence before summary; see clearly the decisions it made for you; your prompt reflects your understanding of the problem; if it doesn't meet the bar for signing your name, don't send it out.