👋 Hey, it’s Stephane. I help engineers become great engineering managers - whether you want to become one or are already leading a team.
Paid subscribers get 50 Notion Templates, The EM’s Field Guide, and access to the complete archive.
There’s a lot of talk about AI creating more code, bigger PRs and more work to review them.
But I don’t think the volume explains why reviewing code this period feels so exhausting.
Senior engineers have spent years learning how to read code written by other people.
They could tell where someone wasn’t sure about something. Naming of a variable would be a bit weird, a leftover comment explaining something that probably doesn’t need explaining, or just generally code that was a little bit off.
AI-generated code is different.
Naomi Lurie at Faros AI makes this point: AI-generated code can look tidy, idiomatic and completely confident even when it’s wrong.
So one of the signals reviewers used to get has disappeared.
Do you understand the code?
In the past, when someone would open up a PR, you’d review the code, but also their judgement. You’d ask question about the decisions they made, hear what they had to say, maybe challenge it, and over time you’d start trusting their judgement more or less.
That’s how a lot of learning and trust-building used to happen.
Now, when AI writes so much of the code, and the “author” just reviews it, how exactly is the author’s judgement assessed?
I feel like this is part of why code reviews feel more exhausting today.
Reviewers are a lot more cautious and are also trying to understand if the author understands that code well enough.
That’s a new thing reviewers are verifying nowadays.
Using AI isn’t the problem
You surely don’t want to start policing whether engineers use AI or not.
I do think though, that you need to be sure that they still understand what they ship.
Anthropic did a randomized study on how AI assistance affects skill formation with engineers learning an unfamiliar Python library. Surprise surprise, the AI-assisted group scored 17 percentage points lower on comprehension.
But what I found interesting is how people used AI.
People who delegated most of the work or repeatedly pasted errors back into the assistant did badly. People who asked conceptual questions, asked for explanations or deliberately worked through generated code did much better.
I think we should care a lot about code understanding.
Do you understand what you’re putting into production?
I’ve written before about growing high-potential juniors, and I think this is increasingly becoming part of that job.
Three questions to ask
There are some good practices emerging.
Simon Willison argues that dropping giant untested AI-generated PRs on colleagues is basically a dereliction of duty. Addy Osmani suggests a PR contract where authors should explain intent, proof, risk and how AI was used.
I like both to be honest.
But they still rely on the engineer telling you that they understand changes they make.
So I think I’d add one more thing.
Spend a few minutes checking whether the person who opened the PR can actually explain it.
You can use three questions for this:
👇👇👇 (access with a paid subscription)
