How I Keep Thinking Critically When AI Agents Do the Work

TL;DR

Good agents rarely make obvious mistakes. That is exactly why you start reading their output more and more loosely, until you approve something you can no longer explain. So I do not rely on how alert I am on a given day. I rely on fixed rules: evidence before the summary, for every green check the question of what it actually checked, and questions for me only in batches. Where I still lack such rules, I say so below.

"Done", twice, and nothing had happened on the page

In September I compared browser tools for my agents. Two of them repeatedly reported success while nothing had happened on the page: no click, no filled-in field, just a success message. Had I only read the message, I would not have noticed. Since then my projects carry a rule: after every action, read the state back; the exit code proves nothing.

That came back to me this week when Addy Osmani published a long piece on X: Critical thinking when agents do the work. He writes explicitly as a fan of agentic workflows, not as a critic. One sentence stuck with me: even if you run many agents at a time, you still only have one pair of eyes on the outputs.

I run several coding sessions in parallel every day. A lead session coordinates them, checks run automatically, and questions for me arrive in batches. It is pleasant, and that is the problem. Fast, well-written, mostly correct answers do not demand a second look. So while reading, I asked myself where I have quietly stopped checking.

Critical thinking with AI agents: offload, defer, surrender

Osmani describes three levels. At the top is offloading: the agent does the work, the result stays mine. In the middle is deferral, where the tool's output becomes my new starting point and stops being a hypothesis. At the bottom is cognitive surrender: the AI's answer quietly becomes my own, and I no longer feel any need to check it.

Steven Shaw and Gideon Nave at the Wharton School coined the term "cognitive surrender". In their experiments with more than 1,300 participants, one group got a chatbot that sometimes answered correctly and sometimes confidently wrong. When the AI was right, accuracy rose 25 percentage points above the group without AI. When it was wrong, accuracy fell 15 points below. Confidence still went up, even when the AI was wrong about half the time.

For my work, another finding of the study matters more. People who were rewarded for accuracy and got immediate feedback on each answer pushed back on wrong answers far more often. So the conditions make a difference. That is where I start: a check that fires immediately helps me more than the resolution to look more carefully next time.

A green check proves exactly one thing

A green test says that this one test passed. The browser tools were not the only place I learned that, and by now it has turned into several rules.

A check script that could not measure a value reports "not measurable" in my setup, not green. A merged change is not yet live, so I check production against the repo before I close an issue. A text that passes my style check is not automatically correct on the facts. And a new check only counts once I have seen it fail on purpose: I plant the bug it is supposed to catch and watch whether it fires. How I turn that into bounded work loops is in Loop Engineering.

Osmani puts this into a question worth keeping: when a check goes green, what did it prove, and what did it not? Part of that is defining what "verified" means before the work starts, because afterwards you will find a justification for any outcome. That is why every open item one of my sessions hands to the next carries a "done when".

Evidence first, then the summary

When a session reports "done", I first read which command ran and what it returned, and only then the summary. In my sessions, a review agent with a fresh context also checks the work before it reaches me. It is a fixed step in the workflow, so it does not depend on whether I remember.

Writing this post showed me how careful that has to be. An automated research step told me that the "paradox of supervision" quote from Anthropic's study of its own engineers could not be confirmed. It was in the original, word for word. Had I trusted the summary, I would have dropped a correct source.

Osmani goes one step further, and here he is ahead of me. A summary in which everything went well does not show what the agent decided along the way: which default it picked, what it dropped from scope, and which requirement it reinterpreted when two of them clashed. So he asks for a list of those decisions, and at the end he still asks: "Did I miss anything?" My session reports so far say what is done, but not systematically what was decided for me and what no check covers. I have opened a task for it: the report my sessions write at the end should get exactly these two sections.

The orchestration tax

The most honest part of Osmani's piece, for me, is the one about volume. He calls it the orchestration tax: the gap between what my agents produce and what I can put my name on. If finished work piles up faster than I can review it, another session will not help. From that point on, nobody is reviewing anymore; everyone is hoping.

For me this has led to two rules. Questions for me are bundled, at most one per item and day, with options and a recommendation. And anything that recurs routinely moves into an automated check so it never reaches me in the first place. I described what that looks like day to day in From iPhone to coding session, and the principles behind it are under How I work. Whatever reaches me should actually need my attention.

What I still do too rarely before the task

One of Osmani's habits is the one I follow least systematically. Before he puts an agent on a non-trivial task, he writes down what result he expects. The expectation may be wrong. It still does its job, because once you have read a well-written answer, it is hard to imagine any other possibility.

Part of that is a brief in your own words: who uses the result, what is explicitly out of scope, and how you will know it is done. Osmani calls the gap behind this "intent debt". An agent rarely pushes back on a fuzzy request. It fills in the gaps itself and hands back something that looks finished. His advice: if two rounds of corrections have not got you there, rewrite the brief instead of patching further. That matches my experience that an agent going in circles usually has an unclear brief, not a bad model.

Where I hand things over completely

Not everything deserves this care. Whether an agent renames a variable, sorts a list or picks a detail from three similar options, I do not check closely. Where being wrong is cheap, I hand it over entirely, and that is sensible.

I draw the line where others carry the consequences: what a change means for users, whether something is safe to ship, what appears publicly under my name. That stays with me, even when an agent helps me think the question through. Osmani's bar fits well: would I bet on this in front of the person who has to maintain it?

What you stop practicing, you lose

For its study, Anthropic surveyed 132 of its engineers and researchers. The study describes a "paradox of supervision": supervising Claude well requires exactly the skills that too much delegation can wear down. That is why Osmani suggests writing down once a month what you no longer do yourself, and deciding on purpose what you are willing to give up. I am taking that question with me. Whoever supervises a whole fleet of agents needs the ability to really read a diff more than before, not less.

What you can try tomorrow

You do not need to build a new system for this. Before your next bigger task, write down what result you expect. After the run, read what was actually executed first, then the summary. Note one thing the agent did not check. And when something was not good enough, record the reason where it will apply automatically next time: in a rule, a hook or a test.

If you want to learn this systematically, with risk classes, verifier prompts against the source and spot checks, the course Verify AI Output and Catch Hallucinations on agenticbuilders.at covers it; the newsletter there sums up new posts from my own practice, including the ones where something did not work. Why checking has become the scarcer skill than typing is in The scarce skill is not typing, it is verification. And if you want to set this up for your team, you can reach me via contact.