👋 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.
Where AI Adoption Stalls (sponsored)
Most teams experience the same pattern: developers become more productive, yet organisation-wide delivery barely changes.
The problem isn’t the AI tools - it’s the system around them.
This paper introduces the AI Adoption Ladder, explaining why gains flatten, the nine stages of AI coding adoption, and the bottleneck that prevents teams from reaching the next level. If you’re leading engineering, this framework will help you understand where your organisation is today and what comes next.
Thanks to re:cinq for sponsoring this newsletter!
One of the engineers I mentor, a senior developer, told me he no longer enjoyed the job.
Every feature followed the same pattern. He’d ask the AI to write it. It would miss an edge case. He’d point it out, the AI would fix it but break something else, and they’d go back and forth until it finally worked.
His frustration wasn’t that the AI made mistakes. It was that the job had changed. Instead of solving problems, he felt like he was reviewing someone else’s work all day.
He told me that by the end of it, he’d often spent just as long as if he’d written the feature himself, except he understood it less.
I’ve heard versions of this from several engineers I’ve coached over the past year, and I’ve felt it myself. Sometimes the back-and-forth with an AI takes longer than just writing the code in the first place.
This isn’t a “use AI less” post
When I talk about this with engineers I mentor, I usually hear one of two reactions.
The first is frustration. One Staff engineer I’ve coached for years told me he’s seriously thinking about leaving software engineering. Spending all day reviewing AI-generated code isn’t the job he signed up for, and he doesn’t see that changing.
I understand that feeling. But leaving isn’t really a good solution for most.
The second reaction is that you should just get used to it. If AI writes the code, then reviewing it is the new job.
That works for some people. One engineer I mentor genuinely enjoys working that way. But for others, it takes away the part of the job they love. Telling them to “just enjoy reviewing” doesn’t solve that.
One engineer found a better approach.
Instead of asking AI to write the first version, she writes the first draft herself whenever a problem is genuinely complex. Then she asks the AI to review it, suggest improvements, and look for edge cases.
She still uses AI for repetitive work like CRUD endpoints, CI/CD configuration, and unit tests. But when the real thinking starts, she does that part first.
She told me the fun came back. She understood the code better, and it usually didn’t take any longer than the endless cycle of prompting, fixing, and prompting again.
Going first
I tell senior engineers I coach to do the same thing in design reviews: think through the problem yourself before you look at what AI is suggesting.
A few weeks ago I even suggested to an engineer to write an ADR completely by hand - and comparing it to AI’s output, his was much better.
If you see AI’s suggestion first, it’s hard to think independently. You naturally start looking at the problem through that perspective, including assumptions and blind spots.
When you think through it yourself first, the differences become valuable. You can compare your notes to AI’s and see what you missed, what it missed, and why one approach is better than the other.
That’s where the learning happens.
There’s also a lot of research showing that trying to generate an answer yourself helps you learn more than simply reading one.
The evidence
In 1978, psychologists compared two groups of people. One group simply read information. The other had to generate part of the answer themselves. The people who generated the answer remembered it much better.
This is known as the generation effect, and many later studies have found the same result.
When you have to think through a problem yourself, it feels harder. But that extra effort helps you understand and remember the solution for longer.
The opposite is also true. Reading someone else’s answer feels fast and easy, but you don’t learn as much from it.
That’s why the endless prompt-and-fix cycle with AI can feel productive while leaving you with a weaker understanding of the code.
There is an important exception, though.
This only works if you already know enough to attempt the problem. If you’re completely new to a topic, or you’re under so much time pressure that you can’t think it through first, forcing yourself to write the solution isn’t helpful.
Back in 1985, computer scientist Peter Naur argued that the most valuable part of programming isn’t the code itself. It’s the understanding the programmer builds while creating it. The code is just the result.
That idea feels especially relevant today. AI can generate code very quickly, but it can’t build your understanding for you.
The goal should always be to make sure you’re still doing the thinking that helps you understand the system. That’s the part of the job that makes you a better engineer.
So what does that look like in practice? Here’s the approach I’d recommend to any senior engineer today: