Thanks CodeRabbit for supporting today’s article!
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.
CodeRabbit CLI is an external reviewer for AI-generated code - the lowest-noise, most-trusted review tool, used by Nvidia, Indeed, and 15,000+ other teams. Different agent, 40+ static analyzers, zero attachment to what it wrote. It flags the parts that don't hold up, so the problems you'd have skimmed past are the first thing you see.
You still own the code. CodeRabbit just makes sure you actually know what's in it.
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.
How did we get here?
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.
It’s very hard to resist
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:
I started with a vague idea of what I want to accomplish
I didn’t understand enough in the area I worked in
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.
The alternative
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.
The skills you are willing to lose
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):
Look at the history of civilizations and you’ll see this happen many times.
Ancient Egypt was able to build incredible pyramids and forgot how to build pyramids. Then they forgot how to read hieroglyphics. In Rome, they were able to build incredible roadways, aqueducts, and indoor plumbing - they forgot how to do all those things. There are many examples in history.
Entropy is not on our side.
Look at American manned space missions: We were able to go to the moon in 1969, then the space shuttle could only go to low earth orbit. Then the space shuttle retired and for almost a decade America had no access to space for humans.
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:
Writing code manually
Language syntax
CSS especially
But I’m NOT willing to lose my ability to:
Understand how software systems are built
Analyze tradeoffs
Read the fucking code and see it makes sense
Read and understand design plans
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.
Discover weekly
On mid-career (dis)satisfaction. On your ability to combat career envy when it arises.
24 tips for giving amazing demos as an engineer. Most developers don’t invest in learning how to demo well - probably because we enjoy building things more than presenting them. Worth 5 minutes of reading to get better at it!
Your AI strategy has a trust problem, not a tooling problem. Even the best employees with all the most magical tools will get trapped… if your org structure and culture don’t adjust.
