When AI Agents Take Over Work, How Do We Maintain Critical Thinking?

Author: Addy Osmani (Anthropic Claude Code team; renowned technical architect)

Compiled by TechFlow

TechFlow Editor's Note:As Agentic Workflows become fully mainstream, software engineers and product teams are undergoing a dramatic reshaping of the human-AI collaboration paradigm. The cognitive buffer that once nurtured thinking between question and answer has now been compressed to just a few seconds. As large models become increasingly humanlike and accurate, overt errors sharply decline, yet people gradually drift into cognitive surrender amid pleasant compliance, while systematic understanding and foundational capabilities quietly erode at an accelerating pace.

As the former Google Chrome engineering lead and a core member of the Anthropic Claude Code team, Addy Osmani systematically dissects the spectrum drift phenomenon from cognitive offloading to deferral to cognitive surrender in this article. He not only unpacks the hidden accumulation mechanism of systemic understanding debt, but also proposes a set of practical and defensive proactive reading and adversarial questioning strategies for everyday workflows, explaining why humans must still firmly hold the responsibility baseline and critical thinking skills even in a future where AI has a higher success rate.

Once upon a time, critical thinking taught in schools meant approaching new information with humble curiosity and measured skepticism: drawing on many perspectives, listening widely to see clearly, and ultimately forming independent judgment. That principle still applies today, but now, with most of my daily work run by agents, almost nothing in reality passively forces me to use critical thinking anymore.

To engineers and product professionals who have fully embraced Agentic Workflows, run multiple sessions in parallel every day, and quietly wait for model performance to keep improving: first, let me say that I am a devoted user of these tools myself. I am writing this article not to advocate reducing the use of Agentic Workflows.

My core goal is to help you firmly maintain your own critical thinking in a world where almost anything can be easily outsourced to agents.

In the past, much of human cognitive processing and aesthetic judgment was nurtured in the gap between question and answer. Today, that gap has shrunk to just a few seconds. The deeper you go into Agentic Workflows, the harder it becomes to stay alert, though not necessarily in the way most people expect: as models keep improving, the share of obviously absurd errors drops sharply. Most generated results are highly polished and broadly correct, and it is precisely this seemingly flawless polish that makes people unwilling to take a second look.

Even if you run a dozen agents in parallel, the person ultimately reviewing the outputs is still your own naked eye.

You must deliberately embed critical thinking into your daily workflow, because by default no external force will check for you.

Part of why people find it hard to self-correct is that the Agentic Workflow experience is simply too pleasant. On a chaotic workday, getting ready-made answers that are polished, comfortable, and broadly correct so quickly is indeed refreshing; but it is also fertile ground for letting one's guard down completely and surrendering.

Offloading, Deferral, and Cognitive Surrender

When discussing this phenomenon with peers, I usually describe it as a continuous spectrum:

At the top of the spectrum is cognitive offloading: delegating specific tedious tasks to AI while humans retain absolute ownership and responsibility for the final outcome. I do this all day, and you should too.

In the middle of the spectrum is deferral: the tool's output becomes the direct input for your next step, and the generated content is no longer treated as a hypothesis that needs validation.

At the bottom of the spectrum is cognitive surrender: AI output quietly becomes your own claim, and you instinctively feel no need to verify it.

The term cognitive surrender was proposed by Steven Shaw and Gideon Nave of the Wharton School. It precisely confirms what I have seen recently: as trust in tools increases, or as inertia takes hold, people unconsciously slide down this spectrum.

This kind of drift is often extremely subtle and hard to notice, because each step happens gradually and seems reasonable in the moment: you carefully read the previous answer in full, so the next time you only skim it; the time after that, you glance only at the skeleton outline; until one day, when someone points to a line of code and asks you about it, you realize that even with an agent's help, you cannot explain its underlying logic to them at all.

This is a classic case of cognitive surrender. It is the quiet source of Cognitive Debt. This debt usually becomes fully visible only when you try to call on a global mental model of the system and find your mind completely blank.

Scholar Margaret-Anne Storey has written that, in team collaboration, this shows up as a steady erosion of shared understanding of the system theory. I have also written about the corresponding phenomenon at the code level, which I call Comprehension Debt, a term coined by Jeremy Twei. In day-to-day coding, this debt is completely invisible: the codebase looks clean and elegant, and all automated tests pass green. Yet the moment the system needs an architecture-level refactor, everyone is left staring at one another in awkward silence: no one on the team can truly read and understand the system anymore. The same problem arises when you only glance at the table of contents of a strategy proposal or technical specification and casually sign off on it.

To be clear, I am not advocating unrealistic perfectionism. It is impossible to require engineers to maintain a complete mental model of an entire large modern codebase in their heads at all times. The Claude Code team has publicly said that they now use a strategy of rebuilding understanding on demand: when they need to modify a module, they ask Claude to explain the logic of that slice on the spot, rather than trying to keep the whole picture in their heads.

As I noted earlier, this local comprehension debt is actually easier to remediate than most engineers think. As long as you can rebuild understanding locally whenever needed, you do not need to maintain the full picture at all times. But the bottom line is this: you must clearly know where your blind spots are.

For trivial matters where the cost of trial and error is extremely low, you can safely hand over decision-making entirely. But once you face a critical question and cannot explain its underlying answer even with an agent's help, you have effectively given up ownership of the system.

Of course, this does not mean every scenario must be treated like a crisis. Not long ago, I needed to record a course and had to choose a venue among three hotels with similar ratings. I genuinely did not have time to read through a huge volume of guest reviews line by line, so I delegated the decision entirely to an AI. The result was very satisfactory, and I would do the same next time in a similar situation.

But when it comes to major investments involving core assets, planning my children's career paths, or deciding at work which features to develop, which real users will be affected by changes, and whether the code meets the standards for a safe release, I would never hand over decision-making. In peripheral areas where the cost of mistakes is low, you can freely delegate; but in core areas where others must bear the consequences, you must hold firmly onto human reasoning.

The core questions I often ask myself

When my thinking used to become tangled, I would retreat to a very plain list of basic questions: How do I know that the problem I am solving is the right one? How do I know that the path I have chosen to solve it is correct? Is there solid objective evidence supporting my conclusion? How do I confirm that this work is truly complete? Most of the time, this is just the classic journalism five Ws and one H: who, what, where, why, when, and how. On paper, they may seem childish, but they force you to examine the problem from blind-spot dimensions that are easy to overlook.

In today's era, people are too tempted to skip all this painful thinking and simply ask an agent, 'what do you think I should do'. Therefore, I have updated a new reflection checklist for myself for the age of agents:

• Before I ask, have I already formed my own initial hypothesis?Before letting an agent handle any nontrivial task, I force myself to write down, in my head or on a sticky note, the possible directions I think the answer might take. It does not matter if it is a rough, bad guess. After seeing new information, you can always overturn it and change your mind. But once you first read a generated answer that is extremely elegant and fluent, it becomes hard to imagine any other possibility. If you have no idea where to start, try what Thariq Shihipar calls the 'blind-spot probing method': lay out all the facts you know and have the model specifically help you find the unknown unknowns.

• Am I using it to assist my thinking, or outsourcing thinking itself to it?Both modes are acceptable; the key is to stay absolutely clear-headed and know which state you are currently in.

• What assumptions must hold for this plan to fail completely?Once you have thought it through, go validate it in practice immediately. A model's self-assessed confidence in its answer is far less useful than actually running a real test, so give it a real verification gate.

• Have I listened to counterarguments from the opposing perspective?When I form a firm position on an open-ended question, I ask the model to act as a demanding adversary and list the strongest counterarguments against my position. This is not necessarily to overturn my decision, but to force myself to confront the unfavorable blind spots I would normally filter out when things are going smoothly.

• If I had to defend this result myself, what would I say?Close the agent window for a moment and try to explain the plan to a colleague in your own plain language. If you find yourself stumbling and unable to explain it clearly, you have not truly understood it; at that point, you are only mechanically acting as an AI mouthpiece.

Active Reading vs. Passive Reading

In passive reading mode, your brain mechanically skims the given text and passively receives the information flow. Because agent-generated prose is usually fluent, polished, and grammatically flawless, passive reading in this environment can easily make you believe you have fully grasped the essence. It is like watching a top instructor demonstrate a seamless architecture workflow at a tech conference: you nod along from the audience and assume it is obvious, but once you return to your hotel room and open a blank editor, you cannot write the first line of code.

Active reading is an act of scrutiny with adversarial assumptions. It does not only care about what the text says, but interrogates it relentlessly: why is this written here? What core difficulties does it avoid? Why did it choose this solution instead of another?

For long agent-generated plans, I usually read them with two very specific skeptical lenses:

First, look for the 'missing context': what assumptions does it take for granted? Does it omit any edge cases? When two requirements conflict, what principle did it quietly use to make trade-offs on my behalf?

Second, actively raise 'adversarial questions': if concurrent traffic suddenly increased 10x, how would this design collapse? If a third-party external dependency went down for 30 minutes, what cascading failures would the system experience? Instead of passively reading pages of ready-made answers, actively take a scalpel and stress-test them.

Reading Through Agents

Agents can do more than produce lengthy text; they can also be trained to become powerful allies in helping you perform deep, critical reading. The key is not to let them only output conclusions that please everyone, but to make them expose the disagreements and fractures behind them:

You can have it cross-examine two seemingly opposing architecture designs and point out what each side compromised; you can have it play a harsh code reviewer, specifically identifying bad code that passes tests but hides future maintenance traps; you can even have it, after producing a long response, randomly pick 3 details from the middle and ask you questions about them to test whether you truly understood the context.

Treat the agent as a whetstone for your thinking, not a replacement for it.

The Supervision Paradox: Who Is Reviewing Whom?

Writing code and reviewing code are completely different thinking skills. Faced with massive streams of generated code, human review can easily degenerate, out of fatigue, into a blind 'rubber stamp'.

Therefore, when reviewing code changes (diffs), please act as if this code was not written by a powerful AI at all, but was submitted by a brand-new intern. More importantly, do not only focus on added and deleted lines; look beyond the surface code and ask what major micro-decisions the agent quietly made on your behalf: What default values did it choose? What complex logic did it silently exclude from this scope? When two product requirements conflicted, which one did it quietly reinterpret?

If a report merely tells you 'all clear, all tests passed', you will never see the reasoning behind any key decisions. Therefore, explicitly require it to provide a separate list explaining what subjective assumptions and trade-offs it made during this task. Then, randomly audit yourself: pick two or three key lines of code and ask why they were written this way. If it were a design document, close the page and try to explain its core arguments to someone else entirely from memory. I really like a strict rule some teams have adopted: have the agent append a self-test to the end of the change report, with the hard rule that 'code may only be merged when I get 100% of the test answers correct'.

Make sure you understand and are confident enough in the product you deliver to production to defend it at any time, because someday someone will definitely come to you with questions.

At the same time, agents can also help us build a valuable line of defense for our attention. For example, I maintain a large open-source project that receives a huge volume of Pull Requests. I use agents to do the initial screening: identify which submissions violate community contribution guidelines and which ones need my focused attention. I never let an agent make the final merge decision for me, but they can help narrow my attention funnel precisely, so I can concentrate real human cognitive bandwidth on 'whether these changes are solving the right problems in the right way'.

Finally, we must face the psychological inflation caused by the explosion in output. I call this the 'Orchestration Tax': essentially the huge gap between the massive volume of industrial-grade output generated by agents and the volume of high-quality work you can genuinely stand behind under your own name. If output accumulates far faster than your physical limits for careful review, opening another concurrent session will not help: you must either tighten automated validation or decisively slow down.

When what you produce exceeds what you can personally vouch for, you are no longer conducting a professional review; you are just hoping for the best.

Input determines output: high-quality input leads to high-quality output

In human-AI collaboration, the human mental model has not disappeared; its center of gravity has shifted. It moved from the long middle coding stage to the very front of task input and the very end of output acceptance. You devote all your cognitive energy to early task decomposition, context feeding, and later rigorous audit loops. This is exactly why the quality of Prompting has a decisive impact on the final result; I have always regarded excellent prompt engineering as a core craft of advanced critical thinking.

In the past, if you gave a human colleague a vague requirement, they would immediately push back, and through their questions you would realize: 'I never actually thought this through.' However, agents often do not stop you at that point. They silently fill in all the details you omitted and then return a deliverable that looks extremely polished and complete, even if the core intent behind it remains muddled. I call this phenomenon 'Intent Debt': the hidden goals and constraints quietly embedded in the deliverable that even you have not truly scrutinized. Unlike other debts, no one can pay off Intent Debt for you; the core intent must come 100% from you.

The prompt you write is precisely a mirror of how deeply you understand the problem; if you cannot express it in clear and precise language, that often means it is already tangled in your mind.

Before seeking external compute assistance, first write a task requirements outline in your own plain language. Clearly identify the target audience, define the absolute boundaries that must not be crossed, and provide objective acceptance criteria for full completion (Definition of Done). If the second round of revisions still fails to meet expectations, immediately stop blind fine-tuning and completely rewrite your input prompts.

You can also use agents to pressure-test the quality of your inputs. Philosopher Andy Clark drew a profound distinction between 'delegating tasks unidirectionally to AI' and 'engaging in deep, bidirectional collaboration with AI.' In a true collaborative mode, you enter a positive flywheel of mutual empowerment: your precise prompts refine exceptional outputs, and those outputs in turn force deeper prompts, ultimately substantially deepening your own mental model of the system. If you are unsure whether the logic is comprehensive, have the agent interview you in reverse and probe the blind spots it does not yet understand. If, by the end of a session, the logical loop in your own mind has been elevated, that is the true mark of success.

In addition, you must be highly vigilant about context contamination. When multiple agents collaborate, it is easy for a later agent to continue working solely on the compressed summary produced by the previous agent. With layer-by-layer degradation, the third agent may never even have read the original core document from start to finish.

At the same time, you must establish your own aesthetic and quality baseline. I have repeatedly experimented with AI across many different creative and engineering fields, and the vast majority of outputs were never published because they did not meet my personal standards. In today's environment, all model outputs can be packaged with extremely polished formatting and confident certainty, so 'surface polish' is no longer an effective signal of quality.

AI may have dramatically increased the pipeline speed for producing content, but if an output makes me feel unwilling to put my name on it, I will never allow it to be published externally.

When an output fails to meet the standard, document the specific reasons for failure in black and white in shared configuration files, Git hooks, or automated test cases to ensure the same mistake is never repeated. This is the right path for taste and standards to compound over time, and clearly recording what did not meet the threshold is itself a highly valuable cognitive discipline.

Models will be stronger than me in the future.

If you share the firm bullish conviction about the future of AI held by many fervent practitioners around me, you may have had this thought while reading the first few chapters: 'In a year or two, models' error correction and insight will inevitably surpass me completely, so why should I still exert so much effort to maintain this skill of critical review?'

For many purely technical metric checks, your prediction may be entirely correct, and I myself have long advocated transferring more and more automated inspection authority to agents. But why will maintaining this capability remain critically important in the future? There is only one reason: ultimately, a flesh-and-blood human must bear full responsibility for the real deliverables that go live. No matter how much compute is invoked behind the scenes, only real humans will face accountability or bear the consequences.

Deciding how much trust to grant an agent in a specific task is itself a qualitative judgment that requires very high wisdom. To maintain precise calibrated judgment at all times, you must continue to personally review the work, because the strange patterns of model errors are always evolving dynamically. In its longitudinal research tracking top engineers and researchers, Anthropic sharply identified the fatal trap of this 'Paradox of Supervision': the advanced engineering and architectural expertise required to supervise and wield Claude is precisely the core skill most likely to rapidly degrade when humans over-rely on AI.

The following ultimate questions are the ones I value most, and no matter how powerful a large model is, it can never answer them for you: Why exactly are you building this product? What social and commercial value does it actually have? Which specific people will it deeply affect? What costs and compromises are you willing to accept to achieve it? All of these must be answered by you personally. Agents can shine in working through the reasoning behind these questions, and I welcome that, but the final seal of decision will always remain in your own hands.

You can offload the concrete labor and even much of the auditing to algorithms, but you can never offload ultimate accountability and responsibility.

Daily practice principles

You do not need to rigidly and mechanically follow every dogma; simply choose the practices that fit your workflow and incorporate them naturally:

• One weekly offline deliberate-practice session: Set aside a fixed period each week to completely disconnect from agent assistance, write a critical piece of code by hand, or personally complete a core task whose degradation would have severe consequences if neglected. I call this a cognitive calibration exercise; it is not a moral ultimatum.

• One monthly capability inventory: Once a month, regularly review a list of things you stopped doing yourself because you relied on AI, and seriously examine: which capabilities are you truly comfortable losing forever? A question I raised in an old blog post years ago still rings true today: if AI suddenly disappeared entirely, how paralyzed and lost would you become?

• Personally dig into anything you do not understand: If you encounter a concept beyond your current understanding, you must systematically learn it yourself. When writing an article, if I run into an unfamiliar term, I could simply search a ready-made wiki explanation and drop it into the text, but I prefer to take a short period for a deep-dive micro-research, understand its causes and consequences, and clearly see its ecological niche in the knowledge landscape.

• Schedule reviewing machine output as formal work: Truly rigorous review of machine output is itself extremely demanding, high-intensity cognitive labor. Pretending this work is easy is often what causes many teams to abandon review entirely and invite catastrophic consequences. Review is never a free lunch; put it squarely on your daily work schedule so that you can actually have the bandwidth to do it properly.

• Skills you stop exercising will degrade rapidly: Any cognitive muscle you leave unused for a long time will atrophy quickly, often faster than your intuition expects. Keep practicing by hand the core crafts you are unwilling to surrender.

Core action checklist

• Maintain clear intent: Agents can absolutely test you in reverse, interview you, and show you the underlying evidence, but only if you proactively design and configure this collaboration mechanism. So build it now.

• Be honest about your real ecological niche on the spectrum: If you cannot even explain to others the reasoning behind an answer without agent-side prompts, then admit it: you have fallen into cognitive surrender.

• Always ask with a preset hypothesis: Before posing a question to AI, form your own guess in your mind, whether good or bad.

• A green checkmark only means one test passed: Always ask: what exactly did it check? What did it quietly miss?

• Look at objective evidence first, then read subjective conclusions: Before skimming its polished summary, inspect line by line what real commands it executed and what underlying data it retrieved.

• Read with sensitivity to decisions: Figure out which micro-decisions the agent unilaterally made on your behalf in this output.

• Refine your input prompts carefully: The depth and structure of your prompt directly reflect your real command over the essence of the problem.

• Set an absolute delivery gold line and hold it firmly: If you would not be willing to put your name on it, do not let it pass.

By continuously practicing the essential core crafts by hand, keep yourself firmly at the center of the board. One minimal micro-habit you can try immediately in daily work: before asking an agent, write down your predicted direction on a sticky note; after the agent finishes, immediately write down one blind spot it did not cover. See whether this small adversarial habit can fundamentally change the depth of your thinking when reviewing AI output. Think independently, ask sharper and higher-quality questions, and take full responsibility for the final result.

Image: Maintaining independent thinking and a closed responsibility loop in AI agent workflows

Source: TechFlow