The "I don't know, Claude wrote this" pandemic

An engineer in your team asks you to go over a PR. It’s quite a big one, tens of files, 1000+ lines of code added.

You roll up your sleeves and start to dive into it. You leave a couple of comments, but after 15 minutes, you feel there are too many things that don’t make sense to you, so you ping the engineer for a quick huddle.

You ask a question (not a small syntax question, a fundamental software architecture question) and receive a response that makes you want to scream:

“I don’t know, Claude wrote this”.

NO NO NO. YOU wrote this. YOU opened the PR. YOU are responsible for it. Claude is just a tool, it’s not the one making the decisions.

A viral post on reddit sparked a debate about it:

Turns out it’s becoming a widespread issue:

Addy Osmani (Director of eng in Google) covered it in a recent article, calling it ‘cognitive surrender’.

Cognitive offloading is delegating to the AI and still owning the answer. Cognitive surrender is when the AI’s output quietly becomes your output and there is 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.

You have a task you need to complete, and it’s not small. So you start a planning session with Claude. You use the famous superpowers brainstorming skill, it explores the codebase, asks you clarifying questions, and you get a plan. You read the plan in depth, correct a couple of problems, and send it off to execution.

You review the code, and it looks good. You correct the small problems with a couple of prompts, and send it to review.

Next comes a bigger task. It’s a bit ambiguous. In a pre-AI world, you would have split the task into smaller pieces. But you're in a rush. 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.

You just skipped the part where you actually understood what's going on.

In the best case scenario, the reviewing engineer will ask you questions that you don't fully understand. Hopefully you won't just forward those comments to Claude, but try to understand what's going on.

Worst case scenario, it's a very big PR, everyone is rushed, and it's just approved and merged. Nobody understood, not the author and not the reviewers.

Instead of driving yourself, you let Claude drive your car of the cliff.

A couple of weeks ago, I spent 2-3 hours in a planning session with Claude. I tackled an ambitious mission, and the plan was quite big. I really wanted to accomplish it, and it felt so much ‘in reach’. Just a couple of prompts away!

Halfway during the execution, I felt lost. There were just too many moving parts and decisions that Claude made. I ended up typing /clear and resetting everything,

There were 2 problems:

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

I had a relatively small task in our internal AI agents infrastructure. I needed to add event tracking through Segment, so we could see what tools were used.

I haven't worked in this repo before. So I planned with Claude, used the brainstorming skill, answered some questions. Plan made sense, so sent of to execution.

Right before add the files to be committed, I reviewed every change in the IDE. The ones I didn’t understood, I asked Claude about. When the answer didn’t make sense, we changed the code and I reviewed it again.

By the time I understood every file change, by definition, I understood the full solution.

I opened the PR and got some great comments from our most senior engineers. I was able to understand the comments, jump on a quick call to discuss the best way forward, and not hide like a fish behind Claude.

I recently finished reading The Book of Elon (a great one, no bullshit at all). Here’s a great quote (about how civilizations lose skills):

We are living in an era when we constantly give up some of our skills. Since Google Maps and Waze almost nobody can navigate without them. In 2026, it feels like everybody lost the ability to write long-form essays without LLMs.

EMs and engineers need to decide which skills are they willing to lose. For me, those are things like:

But I’m NOT willing to lose my ability to:

I want to still be able to ‘drive’ Claude in the direction I want, and not to be driven by it - and that’s the expectation I have from all of my engineers.