Cognitive Surrender: When AI Agents Write Code You Don't Understand

You ping an engineer about a big PR. You ask one real architecture question, and they can't answer it. Nobody can. It's a huge diff, everyone's rushed, so it gets approved and merged unread. That's what AI reviewing its own code looks like. Asking the same agent to check its own work is a student grading their own exam. It always passes.

This scenario is the centerpiece of a recent article on Manager.dev that explores what happens when developers hand over not just code generation but decision-making to AI assistants like Claude. The author, writing about the "I don't know, Claude wrote this" response, highlights a growing problem: cognitive surrender.

What Is Cognitive Surrender?

The article distinguishes between two terms:

• Cognitive offloading — delegating to the AI but still owning the answer.
• Cognitive surrender — when the AI's output quietly becomes your output and there's nothing you feel is left to check.

For software engineers, the line between the two moves under your feet most days, and most of us are crossing it without noticing. The problem is compounded when AI-generated code goes unreviewed, leading to a situation where neither the author nor the reviewers understand the codebase.

How It Happens

The article describes a typical scenario:

1. You have a task that's not small, so you start a planning session with Claude, using the famous superpowers brainstorming skill.
2. You read the plan in depth, correct a couple of problems, and send it off to execution.
3. You review the code, it looks good, you correct small problems with a couple of prompts, and send it to review.
4. Next comes a bigger task. It's ambiguous. In a pre-AI world, you'd split it into smaller pieces, but you're in a rush.
5. Claude produces a plan that sounds reasonable, so you move straight to execution. The result works. You skim the code, open a PR, and move on.
6. You just skipped the part where you actually understood what's going on.

In the best case, the reviewing engineer asks questions you don't fully understand. In the worst case, it's a very big PR, everyone is rushed, and it just gets approved and merged. Nobody understood — not the author, not the reviewers.

Why It's Hard to Resist

The author shares a personal experience: spending 2-3 hours in a planning session with Claude on an ambitious mission. Halfway through execution, they felt lost — too many moving parts and decisions Claude made. They ended up typing /clear and resetting everything. There were two problems:

• They started with a vague idea of what they wanted to accomplish.
• They didn't understand enough in the area they worked in.

When your plan is vague and you don't know enough to make decisions yourself, you'll end up delegating the decisions to Claude. As Google's Director of Engineering Addy Osmani wrote, the line between using Claude and letting it drive is very blurred, and it takes a lot of effort to resist the temptation.

One Approach: Review Every Line

The article offers an alternative approach. For a smaller task — adding event tracking through Segment to internal AI agents infrastructure — the author planned with Claude, then reviewed every change in the IDE before committing. For files they didn't understand, they asked Claude for explanations. When the answer didn't make sense, they changed the code and reviewed it again. By the time they understood every file change, they understood the full solution.

The author opened the PR and got great comments from senior engineers — and could actually respond to them, rather than hiding like a fish behind a rock.

Key Takeaway

When using AI coding agents, ensure you understand the code you're responsible for. Don't let the AI make all the decisions. Review each change, ask questions, and never open a PR you don't understand.