When AI agents take over work, how should we maintain critical thinking?
Author: Addy Osmani (Anthropic Claude Code Team, Distinguished Technical Architect)
Compiled by: TechFlow
TechFlow Summary: With the widespread adoption of agentic workflows, software engineers and product teams are undergoing a drastic reshaping of human-machine collaboration paradigms. The cognitive buffer zone that once nurtured thought between questioning and answering has now been compressed to mere seconds. As large models become increasingly realistic and highly accurate, explicit errors have plummeted, yet this pleasant compliance gradually leads people toward "cognitive surrender," causing systematic understanding and underlying capabilities to accelerate their silent atrophy.
As a former Google Chrome engineering lead and current core member of the Anthropic Claude Code team, Addy Osmani systematically dissects the spectrum shift from "cognitive offloading" and "deferral" to "cognitive surrender." He not only delves into the hidden accumulation mechanism of comprehension debt liability but also proposes a set of practical and defensive proactive reading and adversarial questioning strategies for daily workflows, explaining why humans must firmly maintain accountability bottom lines and critical thinking abilities even in a future where AI holds higher win rates.
Once upon a time, critical thinking taught in schools required facing new information with humble curiosity and a moderate degree of skepticism: gather strengths from many sources, listen to both sides to be enlightened, and ultimately form your own independent viewpoint. This principle still applies today, but now, as most of my daily work is handed over to agents to run, reality almost never passively forces me to exercise critical thinking.
For those who have fully embraced agentic workflows, running multiple sessions concurrently in daily practice and quietly awaiting continuous improvements in model performance—engineers and product staff alike—I want to first state: I myself am a loyal advocate of these tools. I write this article not to advocate for reducing the use of agentic workflows.
My core objective is: in a world where anything can be easily outsourced to agents, to help you firmly retain your own critical thinking.
In the past, most of human cognitive processing and aesthetic judgment were born in the blank space between questioning and answering. However, today, the scale of this gap has shortened to mere seconds. The deeper you use agentic workflows, the harder it becomes to stay awake (though the nature of this difficulty may differ from popular expectations): as models continuously improve, the proportion of obviously absurd errors drops significantly. Most generated results are written very neatly and are largely correct, but precisely this seemingly flawless neatness makes people hardly want to glance at it a second time.
Even if you are running a dozen agents concurrently at the same time, it will always be your own eyes that ultimately review the output.
You must proactively embed critical thinking into your daily routines, because in the default state, no external force will gatekeep for you.
Part of the reason people struggle to self-correct lies in the fact that the experience of agentic workflows is simply too pleasing. On a busy workday, getting neat, comfortable, and largely correct ready-made answers so quickly is indeed refreshing; but this is exactly the breeding ground where people easily let down their guard and surrender.
Offloading, Deferral, and Cognitive Surrender
When discussing this phenomenon with peers, I usually depict it as a continuous spectrum:
At the very top of the spectrum is "Cognitive Offloading," where specific tedious tasks are delegated to AI for execution, while humans always retain absolute ownership and responsibility for the final outcome. I do this all day long, and you should too.
Located in the middle of the spectrum is "Deferral," where the result spitted out by the tool directly becomes the new input for your next step, and the output content is no longer viewed as a hypothesis requiring verification.
Sliding to the very bottom of the spectrum is "Cognitive Surrender": the AI's output quietly and unknowingly transforms into your own claims, and you instinctively feel there is absolutely no need to verify it.
The term "Cognitive Surrender" was proposed by Steven Shaw and Gideon Nave of the Wharton School. It accurately corroborates what I've recently observed: as trust in tools increases (or laziness breeds), people unconsciously slide down this spectrum.
This shift is often extremely subtle and hard to detect, because each step occurs progressively and seems perfectly reasonable at the moment: you carefully read the previous answer thoroughly, so next time you just skim it roughly; the next time, you only glance at the skeleton outline; until one day, when someone points to a line of code asking you about it, you suddenly realize that even with the agent's help, you cannot clearly explain its underlying logic to them.
This is a typical case of cognitive surrender. It is exactly the source of the quiet accumulation of "Cognitive Debt." This debt is usually completely exposed only when you try to invoke a global mental model of the system, only to find your mind utterly empty.
Scholar Margaret-Anne Storey once wrote that this manifests in team collaborations as a continuous erosion of shared theoretical understanding of the system. I have previously written about the corresponding phenomenon at the code level, namely "Comprehension Debt" (a term coined by Jeremy Twei). In everyday coding, this debt is completely invisible: the codebase looks clean and elegant, and all automated tests pass with flying colors. However, once the system requires an architectural-level refactoring, everyone falls into an awkward silence: there isn't a single person on the team who truly understands how this system works anymore. The same problem occurs the moment you casually glance at the table of contents of a strategic plan or technical specification and then sign off approvingly.
It needs to be made clear that I am not advocating for unrealistic perfectionism. Requiring engineers to constantly maintain a complete mental model of an entire massive modern codebase in their minds is impossible. The Claude Code team had previously stated publicly that they now adopt a "rebuild understanding on demand" strategy: when needing to modify a certain module, directly ask Claude to explain the logic of that slice on the spot, rather than forcing oneself to maintain a global picture in the brain.
As I pointed out earlier, this kind of localized comprehension debt is actually easier to remedy than most engineers imagine. As long as you can rebuild understanding locally whenever needed, you don't need to constantly maintain the entire panoramic view. But the bottom line is: you must clearly know exactly where your blind spots lie.
On trivial matters with extremely low trial-and-error costs, everyone can safely hand over decision-making power entirely. But once you face a critical issue, or even when you cannot explain its underlying answer with the help of an agent, you have de facto completely given up systemic ownership.
Of course, this doesn't mean every scenario requires treating it like a major crisis. Just recently, I needed to record a course and faced choosing a location among three hotels with similar ratings. I genuinely didn't have the time to go through countless guest reviews item by item, so I directly entrusted this decision entirely to an AI. The result was very satisfactory, and I would still do the exact same thing in similar scenarios next time.
However, when it comes to core asset investments, career planning for children, or deciding which features to develop at work, what changes will affect real users, and whether the code meets safe release standards, I absolutely will not hand over decision-making power. In peripheral areas where error costs are cheap, you can hand things over freely; but in core links where others must bear the consequences for failures, you must firmly guard human logical deduction.
The Core Questions I Often Ask Myself
In the past, when my thoughts fell into chaos, I would typically retreat to a list of extremely basic fundamental questions: How do I know I'm solving the right problem? How do I know I'm taking the right approach to solve it? Is there solid objective evidence supporting my conclusion? How do I confirm this work is completely finished? Most of the time, this is just the classic journalism Five Ws and H (Who, What, Where, Why, When, and How). Written on paper, they seem childish as a joke, but they force you to examine from dimensions of blind spots that are usually easily ignored.
In this era, people are too prone to skip all these painful thoughts and turn to agents to ask, "What do you think I should do?" Therefore, I have updated a brand-new reflection checklist for the agent era for myself:
• Have I already formed my own initial assumption before asking? Before initiating an agent to handle any non-trivial task, I force myself to write down in my mind (or on a sticky note) where I think the possible answer might lean. Even if it's just a rough, poor guess is perfectly fine. After seeing new information, you have the right to overturn and change your mind at any time. But once you've read a newly generated answer that is exceptionally elegant and fluent, it's hard to imagine any other possibilities. If you're completely clueless, you can try what Thariq Shihipar calls "blind spot probing questioning": lay out all the facts you know, and let the model specifically help you search for unknown unknowns.
• Am I having it assist my thinking, or am I outsourcing the thinking itself to it? Both modes are actually allowed; the key is you must maintain absolute clarity, knowing explicitly which state you are currently in.
• Under what prerequisite conditions would this solution fail completely? Once figured out, immediately go out and test it manually. A model's self-assessment of confidence in its own answers has far less reference value than you personally running a real test, so set up a genuine checkpoint for it.
• Have I listened to counterarguments from opposing perspectives? When I form a firm stance on an open-ended question, I ask the model to act as a critical opponent, specifically listing the strongest counterarguments against that stance for me. This isn't necessarily to overturn my decision, but to force myself to face those unfavorable blind spots that would otherwise be subconsciously filtered out when things are going smoothly.
• If I must personally defend this result myself, what would I say? Please temporarily close the agent window and try to explain this solution to a colleague using completely plain language of your own. If you find yourself stumbling and unable to explain it clearly, it means you haven't truly grasped it; you are merely mechanically acting as an AI megaphone.
Active Reading vs. Passive Reading
In passive reading mode, your brain simply mechanically slides along the predetermined text, passively receiving the information stream. Since the text spit out by agents is usually fluent, rhetorically neat, and grammatically flawless, passive reading in this environment very easily leads people to mistakenly believe they have thoroughly grasped the essence. It's like watching a top-tier lecturer on stage demonstrate seamless architectural operations at a tech conference; you nod along downstairs feeling it's natural, but once you return to the hotel and open a blank editor, you discover you fundamentally cannot write the first line of code.
Active reading, however, is a scrutiny behavior with adversarial assumptions. It not only focuses on what the text says, but rigorously interrogates: Why did it write this here? What core difficulties does it avoid? Why did it choose this particular solution instead of another?
For long-form plans produced by agents, I usually read with two extremely clear critical perspectives:
First is looking for "missing context": What are the default premise assumptions? Did it omit certain edge cases? When two requirements conflict, on what grounds did it quietly make trade-offs for me?
Second is proactively launching "adversarial questioning": If concurrent visits suddenly increase tenfold, how will this design collapse? If a third-party external dependency service goes down for half an hour, what chain reaction disaster will occur in the system? Rather than passively reading ready-made answers covering pages, it's better to proactively pick up a scalpel and put it under stress testing.
Reading Through Agents
Agents can not only be used to write long essays; they can equally be trained to become powerful allies assisting you in deep critical reading. The key is, you shouldn't just let it output universally pleasing conclusions, but make it expose the underlying disagreements and fissures:
You can have it cross-examine two seemingly contradictory architectural designs, pointing out what each side compromised on; you can have it play a harsh code reviewer, specifically picking apart rotten code that passes tests but harbors future maintenance traps; you can even have it, after finishing a long text output, randomly draw three details from the middle to quiz you backwards, thereby testing whether you truly understood the context.
Treat agents as whetstones for thinking, not replacements for thinking.
The Supervision Paradox: Who Reviews Whom?
Writing code and reviewing code are completely different thinking skills. Faced with massively generated streams of code, human review very easily degenerates into stamping a "rubber stamp" with eyes closed out of fatigue.
Therefore, when reviewing code diffs, please pretend this code was not written by a godlike AI, but submitted by a newly hired intern. More importantly, don't just stare at the added/deleted lines of code; pierce through the surface code and interrogate what major micro-decisions the agent secretly made for you behind the scenes: What defaults did it choose? Which complex logics did it quietly exclude from this scope? When two product requirements conflicted, which one did it secretly reinterpret?
If a report merely tells you lightly that "everything went smoothly, all tests passed," you will forever see nothing of the interior of key decisions. Therefore, explicitly require it to list a separate checklist: detailing what subjective assumptions and compromise choices it made during this task. Then, conduct random spot checks on yourself: arbitrarily circle two or three critical lines of code, and ask yourself exactly why they were written this way? If it's a design document, close the page, and try to recount its core arguments completely from memory to someone else. I really love a hardcore rule implemented by some teams: having the agent append a self-testing quiz at the end of the submission report. The team's strict rule is "the code is only allowed to be merged when I answer 100% of the quiz questions correctly."
Please ensure you possess sufficient deep understanding and confidence in the products you deliver to production, able to stand up and defend them at any moment. Because on a future day, someone will definitely come knocking with questions.
Meanwhile, agents can also help us construct valuable attention defense lines. For example, I maintain a large open-source project receiving massive pull requests. I have agents help me with initial screening: identifying which commits violate community contribution guidelines, and which require my focused effort to intervene. I absolutely will not let the agent directly decide whether to merge or not on my behalf, but they can help me precisely narrow the attention funnel, allowing me to concentrate true human cognitive bandwidth on "whether these changes are solving real problems via the right path."
Finally, we must confront the psychological inflation brought by explosive output volume. I call it the "Orchestration Tax"; essentially, it's the huge gap between the industrial-scale volume of mass outputs generated by agents and the premium volume you are truly willing to put your name to without remorse. If the speed of output accumulation far exceeds your physiological limit for meticulous review, then opening a new concurrent session solves absolutely nothing: you must either tighten the automated validation process or decisively slow down.
When the things you produce exceed the scope where you can stand and take responsibility, you are no longer conducting professional review; you are merely praying lucklessly for nothing to go wrong.
Input Determines Output: High-Quality Input Forges High-Quality Output
In human-machine collaboration systems, the human mental model hasn't disappeared; its center of gravity has simply shifted: from the originally lengthy intermediate coding phase, it's been entirely transplanted to the forefront task input stage and the ultimate output acceptance stage. You pour all your cognitive energy into early task decomposition, context feeding, and later rigorous audit closing loops. This is exactly why prompt quality has a decisive impact on final results; I consistently regard excellent prompt engineering as a core skill of advanced critical thinking.
In the past, if you threw a vague, unclear requirement at a human colleague, they would immediately push back at you, and you would also suddenly enlighten through their questions: "Turns out I never actually figured this out clearly." However, agents rarely stop you at this point. They silently fill in all the details you omitted, then seemingly extremely efficiently hand back a delivery that appears incredibly neat and complete on the surface, even if the core intent behind it remains a mushy mess. I call this phenomenon "Intent Debt": the implicit goals and constraints quietly embedded in the deliverables that you yourself haven't truly deliberated over. Unlike other debts, no one can pay off intent debt for you; the core intent must originate 100% from yourself.
The prompts you write are precisely a mirror reflecting your own depth of understanding of the problem; if you cannot express it in clear, precise language, it often means it's inherently a tangled mess in your mind.
Before seeking external computational assistance, please first write a task requirement outline in your own plain language. Clearly specify the target audience, define absolute boundaries that must not be touched, and provide objective completion acceptance criteria (Definition of Done). When the second round of modifications still fails to meet expectations, immediately stop blind fine-tuning patching and thoroughly rewrite your input prompt.
You can similarly leverage agents to force-improve your input quality. Philosopher Andy Clark once drew a profound distinction between "unilaterally delegating tasks to AI" and "engaging in deep bidirectional collaboration with AI." In a true collaborative mode, you enter a positively empowering flywheel: your precise prompts polish out excellent outputs, which in turn force-feed back into deeper prompts, ultimately greatly deepening your own mental model of the system. If unsure whether the logic is thorough, let the agent interview you backwards, probing the blind spots it still doesn't understand. If at the end of a session, the logical closed loop in your own mind achieves elevation, only then is it a true sign of success.
Addition, context pollution must be vigilantly guarded against. When multiple agents collaborate, it's very prone to the drawback of the next agent merely continuing work based on the compressed summary of the previous agent; under layer-by-layer attenuation, the third agent may not even have read the original core document from start to finish.
Meanwhile, you must establish your own aesthetic and quality gold standard. I have repeatedly tested AI across many different creative and engineering domains; the vast majority of outputs have never been published publicly because they fundamentally don't meet my personal standards. In this era today, all model outputs can be packaged exquisitely formatted and confidently assured, so "surface smoothness" has long ceased to be an effective signal for measuring quality.
AI may greatly improve the pipeline speed of content manufacturing, but as long as any output makes me feel embarrassed to put my name to it, I absolutely will not allow it for public release.
When an output fails to meet standards, please document the specific reasons for failure in black and white into shared configuration files, Git intercept hooks, or automated test cases, ensuring the same mistakes absolutely never happen again. This is the correct path for taste and standards to achieve compound interest accumulation; and consciously recording which things fall below the threshold itself is a highly valuable cognitive cultivation practice.
Models Will Be Stronger Than Me in the Future
If you share the steadfast bullish belief in AI's future with many fanatical practitioners around me, you likely popped up this thought while reading the first few chapters: "In a year or two, the model's error-correction and insight capabilities will inevitably completely overwhelm me, so why bother wasting heart and strength to maintain this critical review skill?"
In many pure technical indicator tests, your prediction is probably completely correct; I myself have been vigorously advocating handing over more and more automated detection authority to agents. But why does sticking to this ability remain extremely crucial in the future? There is only one reason: ultimately, it must be a flesh-and-blood human who bears full responsibility for the truly delivered outcomes. No matter how much computing power was invoked behind the scenes, the ones who eventually walk onto the stand or bear the consequences are exclusively real humans.
Deciding exactly how much trust to grant an agent for a specific task is itself a qualitative ruling requiring extremely high wisdom. And to maintain precise calibration judgment at all times, you must continuously dive in and personally review homework, because the bizarre patterns of model errors are constantly evolving dynamically. Anthropic's tracking study of its top engineers and researchers profoundly pointed out the fatal trap of this "Paradox of Supervision": the high-end engineering and architectural expertise necessary to supervise and master Claude are exactly the core skills that humans accelerate their degradation and atrophy in most easily after over-relying on AI.
These ultimate questions are propositions I value most, and that no matter how powerful a large model is, can ever answer for you: Why are you making this product exactly? What social and commercial value does it truly possess? Which specific people will it profoundly impact? To achieve it, what costs and compromises are you willing to pay? All of these must be answered by you personally. Agents can shine brilliantly in clarifying the deduction of these questions, and I am happy to see it happen, but the final decision seal is always held solely in your hands.
You can offload specific labor even a massive amount of auditing steps entirely to algorithms, but the ultimate accountability and responsibility, you can never offload.
Daily Practice Rules
You absolutely don't need to rigidly and mechanically practice all dogmas; just select methods that fit your workflow and naturally integrate them:
• Weekly Offline Deliberate Practice: Set aside fixed time every week to completely disconnect from agent assistance, manually write a segment of critical code, or personally complete a core business operation where once rusty it would bring severe consequences (I call this cognitive calibration exercise; this is by no means any moral kidnapping).
• Monthly Capability Inventory Check: Regularly sort out a list every month, writing down things you stopped personally doing due to relying on AI over the past month, and seriously examine: which of these capabilities are you truly able to peacefully accept as permanently forgotten? The questioning I raised in an old blog years ago still rings loudly today: If AI suddenly vanished completely one day, how paralyzed and lost would you fall into?
• Inevitably Deep-Dive Into Unknowns: If you encounter a concept exceeding your current comprehension scope, you must personally study it systematically. If I encounter an unfamiliar jargon term while writing an article, while I could certainly search for a ready-made Wikipedia explanation and casually stuff it into the text, I prefer to carve out a small amount of time for a deep micro-research, understand its cause and effect, until I completely see its ecological niche in the knowledge panorama.
• Schedule Reviewing Machines as Formal Work: Conducting truly rigorous audits on machine outputs is itself an extremely arduous high-intensity cerebral labor. Pretending this work is effortless is exactly the root culprit that causes many teams to eventually abandon review entirely and bury catastrophic disasters. Reviewing is by no means a free lunch; please place it openly and honestly on your daily work schedule, so you can truly have the energy to implement it properly.
• Skills Ceased From Exercise Will Eventually Atrophy Rapidly: Any cognitive muscle left unused for a long time will accelerate atrophy, its fading speed often far exceeding your intuitive estimation. Please must continue to personally practice those core crafts you absolutely refuse to hand over.
Core Action Checklist
• Maintain Clear Intent: Agents can absolutely test you backwards, interview you, and show you underlying arguments, but on condition that you must actively design and configure this collaboration mechanism yourself. So, build it up immediately.
• Honestly Face Your Real Ecological Niche on the Spectrum: If you cannot even clearly explain the ins and outs of an answer to others without an agent prompting alongside, then please admit: you have fallen into cognitive surrender.
• Always Ask With Presumed Assumptions: Before throwing a question to AI, regardless of good or bad, first formulate your own guess in your mind.
• A Single Green Checkmark Only Represents One Test Passed: Always keep asking: What exactly did it check? What did it quietly overlook?
• Review Objective Evidence First, Then Read Subjective Conclusions: Before browsing its gorgeous summaries, first read line by line what actual instructions it executed and what underlying data it fetched.
• Read With Sensitivity To Decisions: Figure out exactly what micro-decisions the agent unauthorizedly decided for you in this output.
• Finely Polish Your Input Prompts: The depth and structure of the prompts you write directly reflect your true grasp of the essence of the problem.
• Establish An Absolute Delivery Gold Line And Defend It To The End: If you yourself feel embarrassed to put your name to this thing, resolutely do not allow it to pass.
By continuously personally practicing those crucial core crafts, keep yourself firmly located at the center of the chessboard. An extremely micro habit you can try immediately in daily life: Before asking an agent, write down your predicted possible trajectory on a sticky note; immediately after the agent delivers completion, write down one blind spot it failed to cover. See if this minor adversarial habit can completely reverse the depth of thinking when you scrutinize AI outputs. Think independently, raise sharper high-quality questions, and take full responsibility for the final results.
Fig.: Maintaining Independent Thinking and Closed-Loop Responsibility in AI Agent Workflows