Cognitive Surrender: The Claude Code Engineer Who Wants You to Stop Trusting AI

Addy Osmani, who spent 14 years at Google and now builds AI coding tools at Anthropic.

Addy Osmani helped build Chrome DevTools, Lighthouse, and Core Web Vitals during his 14 years at Google. He's now at Anthropic, working on Claude Code ,one of the most powerful AI coding tools in existence. And he just published a long essay warning engineers that AI coding assistants might be making them worse at their jobs.

The irony isn't lost on him.

The three stages of giving up

Osmani's core concept is what he calls cognitive surrender, which was borrowed from a Wharton School paper by Steven Shaw and Gideon Nave. It doesn't happen all at once. It's a gradual slide through three stages.

Stage one: cognitive offloading. You delegate the grunt work to AI but still understand the task and can judge the output. This is healthy. This is what the tools are for.

Stage two: judgment deferral. The AI's answer starts becoming your default starting point. You still glance at it, but you're no longer forming an independent view before you look.

Stage three: cognitive surrender. The AI's output quietly becomes your output. You've stopped constructing a parallel view to compare against. If someone asks why the code works this way, you can't explain it — because you never understood it. You just approved it.

Osmani puts it bluntly: "Cognitive surrender is where you blindly give in to whatever the AI says as your answer. Its answer becomes your answer. You start to really let go of critical thinking."

The 600-line pull request problem

Here's his example. An AI agent submits a 600-line code change. The developer looks at it: structure is clean, tests pass, everything's green. They merge it.

What they didn't notice is that the agent quietly changed the order of transaction handling in one function, or adjusted a boundary condition in another. Nothing broke immediately. But weeks later, when the system fails in production, the developer can't explain why the code behaves the way it does ,because they never actually read it.

Osmani calls the accumulation of this gap comprehension debt. The codebase grows. The features multiply. But the developer's understanding doesn't keep pace. They've built a building they can't navigate.

This isn't a distant hypothetical. Research by SonarSource found that only 48% of developers consistently check AI-assisted code before committing it. Apiiro reported that 48% of AI-generated code contains security vulnerabilities. The numbers align with Osmani's concern: people are shipping code they haven't read.

Five ways to fight it

Osmani doesn't just diagnose the problem. He offers a set of concrete practices — and the most striking one is this: make the AI quiz you.

1. Let the agent become your examiner. After Claude finishes a major code change, don't approve it immediately. Ask it to summarize what it changed and why, then generate a short quiz based on the modifications. Set a rule: you can only merge the code if you pass the quiz. If you can't answer questions about code you're about to ship, you shouldn't be shipping it.

2. Write your own requirements before prompting. AI agents are dangerously good at filling in gaps you didn't know existed. If you haven't defined your goals, constraints, and scope clearly, the agent will decide them for you and you'll never know what choices it made on your behalf. Osmani calls this intent debt. His rule: if you've adjusted the prompt twice and still aren't getting what you want, stop prompting and go back to your requirements.

3. Ask the agent what it decided without your permission. This is especially important for long-running tasks. Agents make silent decisions: default parameters, scope adjustments, trade-offs between conflicting requirements. They don't always report these. After a task completes, ask directly: "What decisions did you make that I didn't explicitly authorize? What assumptions did you rely on? What didn't you verify? What changes might affect other parts of the system?"

4. Don't trust green tests, instead, ask what wasn't tested. Passing tests only prove that the conditions covered by the tests passed. If edge cases weren't written into the tests, the agent can deliver a clean report while hiding real problems. For high-risk changes, Osmani suggests running a second, independent agent to look for issues the first one might have missed.

5. Once a week, code without AI. This sounds almost retro. A Claude Code engineer telling developers to occasionally stop using Claude Code. But Osmani's point is practical: skills you don't use atrophy. Periodic unassisted coding lets you calibrate your actual ability. Each month, take stock of which skills you've outsourced to AI, which ones you can safely delegate, and which ones you need to keep sharp. The side benefit: you'll know exactly how much you can still do if the tools go down.

https://www.youtube.com/watch?v=4xKUAixmrOE

The multi-agent trap

One more risk Osmani flags: as developers start running multiple agents in parallel ,one on the frontend, one on the backend, one on testing ,information degrades at every handoff. One agent's summary becomes the next agent's input. By the third relay, critical details from the original material may have vanished entirely.

His advice: for important tasks, always preserve the original source material and verification evidence. If your review queue has grown so large you can't meaningfully check everything, either add automated verification or reduce the number of parallel agents. Scaling up agents without scaling up oversight isn't productivity. It is gambling

"When you're generating more content than you can be responsible for," Osmani writes, "you're no longer reviewing. You're betting it's fine."

The simplest self-test

At the end of his essay, Osmani offers one dead-simple habit anyone can adopt immediately: before you send a prompt, write down what you expect to happen. After the AI delivers, try to identify one thing it might have missed.

Two moments of independent thought per interaction. That's the minimum to keep your brain in the loop.

He closes with a question that lingers: "If AI went on strike tomorrow, how many days could you last before things fell apart?"

It's a joke, but only barely. And it's worth answering honestly.