Engineers are shipping code they don't understand and blaming AI for it. The 'I don't know, Claude wrote this' phenomenon has gone from an awkward confession to a full-blown industry epidemic—and it's getting worse by the day.

Addy Osmani Calls It Cognitive Surrender

Addy Osmani, Director of Engineering at Google, recently tackled this trend head-on in a widely-shared article. He draws a critical distinction between cognitive offloading and what he's calling 'cognitive surrender.' Offloading is delegating tasks to AI while retaining ownership of the outcome. Surrender is when an AI's output quietly becomes your output without you feeling any obligation to verify it. For software engineers, Osmani argues, that line moves under your feet daily—and most of us are crossing it without noticing.

How Engineers End Up as Passengers

The pattern is insidious. An engineer starts a planning session with an LLM, uses brainstorming skills, gets a plan that sounds reasonable, and sends it to execution. The code works. They skim it, open a PR, and move on. But here's the problem: they just skipped the part where they actually understood what was going on. In a pre-AI world, ambiguous tasks would have been split into smaller, comprehensible pieces. Now? Just a couple prompts away! Until halfway through execution when you realize there are too many moving parts and decisions Claude made that you can't explain.

The Reset Moment

The author of the original piece admits to spending 2-3 hours in an AI planning session for an ambitious mission, only to feel completely lost during execution. Too many decisions had been delegated to the model without sufficient understanding on their end. They typed /clear and reset everything. Two problems surfaced: vague initial goals and insufficient domain knowledge. When your plan is fuzzy and you don't know enough to make decisions yourself, you'll delegate those decisions to the AI—and lose ownership in the process.

What Civilizations Forgot

The piece pulls a stark historical parallel from 'The Book of Elon': Ancient Egypt built incredible pyramids and then forgot how to build them. Rome constructed aqueducts and indoor plumbing—then forgot how to do both. America landed on the moon in 1969, then lost human spaceflight capability for almost a decade. In 2026, it feels like everyone has already lost the ability to write long-form essays without LLMs. The question every engineer needs to ask: which skills are you willing to lose?

The Line You Can't Cross

The author's answer is revealing. They're fine losing: manual code writing, language syntax specifics, CSS tricks. But they're absolutely unwilling to surrender: understanding how software systems are built, analyzing tradeoffs, reading code and actually seeing whether it makes sense, comprehending design plans. They want to drive Claude in the direction they choose—not be driven by it. And that's the standard they hold their own engineers to.

The Alternative Actually Works

The author contrasts two experiences. In a bad scenario: vague task plus insufficient knowledge equals delegating all decisions to AI, then shipping unread code because everyone's rushed. Best case, someone asks questions you can't answer. Worst case, nobody understands it—including you—and it gets merged anyway. In the better approach: before committing anything, review every change in the IDE. Ask Claude about anything confusing. When answers don't make sense, change the code and re-review. By the time all files are understood, by definition you've understood the full solution.

Key Takeaways

  • Cognitive offloading means using AI while owning the outcome; cognitive surrender means losing ownership entirely
  • The line between helpful delegation and dangerous surrender moves daily—and you might be crossing it without noticing
  • When tasks are vague and your domain knowledge is thin, you'll inevitably delegate decisions to the AI
  • Skills like manual syntax or CSS can be outsourced; understanding systems architecture cannot
  • Review every change before committing—even if Claude wrote it. If you can't explain your own PR, you've already lost too much