👋 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.
If you have an Engineering Manager interview coming up - watch this video!
I haven’t made a video in 3 years and it’s been on my mind all this time.
I am now happy to commit to a process and workflow that works for me.
First of many more to come!!
It’s so common nowadays to be producing code through agents.
Sometimes engineers working on a big feature go head down and have multiple agents running in parallel until they’re able to have the feature done. Which doesn’t take long. But the output is many PRs that need to be reviewed.
This is code, that once merged it’ll need to be maintained. A friend of mine says that once code is merged it immediately becomes “legacy code” these days.
When that feature will need to be extended it’s a good starting point if it fits the rest of the system well. At times though you’ll find that maybe there’s a new field somewhere that means almost the same thing as an existing one, or a component owns behaviour it shouldn’t.
And these are decisions that in the rush of reviewing and approving PRs might get missed.
Agents are capable of producing good code, but they also make tiny decisions, which over time require us to understand them.
We used to think while coding
Dax, co-founder of OpenCode, said in a conversation with The Pragmatic Engineer that before AI, he spent about 95% of his energy thinking about what to do and 5% doing it.
What does that even mean?
Writing code was already a small part of his work and most of his effort went into deciding what was worth building, how it should work, and whether the result was good. He’s now pushing himself to have the same split (96% thinking and 4% doing).
“Coding” used to involve things like looking at an old function, understanding why it was awkward, and thinking about how to best refactor it. Finding an edge case halfway through implementation. Or discovering that the approach you’d planned didn’t quite work with an existing service.
Agents can take some of that load and allow us to lean on spending more time “doing” than “thinking”. Engineers still need to have a really good picture of the system.
You can have multiple agents running at once, but can you keep a useful mental model of all changes at the same time? And can they be presented in a way the rest of your team can review them properly?
Stay close to the decisions
You don’t really want to have engineers write a design doc before every prompt - that would be ridiculous.
For certain changes though, we need to slow down a bit. A new data model, interface, component, or a change in operational behaviour. These changes can have long term impact if done badly.
Before implementing that kind of change, I’d want the owner of that feature (a human) to be able to explain
What are we changing, and why does it belong here?
What must still be true when we’re done?
Which choice would be painful to reverse later?
It can be as simple as having a mini ADR for it that is shared with the team.
What I tend to recommend to engineers who struggle with multi-tasking is:
having a substantial task as their main focus
using an agent to explore options and implement parts of it
review those parts before proceeding
They can have small tasks run on the side when you already understand them well.
A PR needs someone who can explain it
When reviewing code, I’d look at the shape of the change before getting lost in the implementation.
Are there new dependencies? Do we have a new way to do something that was already possible? What are the failure modes of this change?
Sometimes it’s not unreasonable to ask the author to explain the choices they made.
As I am writing this, I remembered a study from Anthropic from earlier in the year that engineers using AI while learning a new library scored lower on a follow-up quiz compared to ones who didn’t. It was mostly made with junior participants so take it with a pinch of salt (as always). But I would ask whether our engineers are learning enough about what they ship to be able to fix it when it breaks.
Review capacity
Like we said, it’s easy to spin up a new agent while the first one is still running. At some point though, you’ll have to naturally start reviewing the work agents did.
And there are only so many hours in one day.
If engineers start opening many PRs per day (some of which will be slop grenades), can they explain the decisions in all of them? Can other engineers review them? And will useful information from them be shared across the team accordingly?
How many PRs can an engineer review thoroughly in a day while also being able to progress their own tasks? That’s a hard question to answer.
Not all PRs are equal of course. Some bigger than others. Some more dangerous than others.
A large mechanical change can be straightforward. A tiny change to a data model might deserve a long conversation.
So we’re not looking for a number here.
The useful question I think is: “can a reviewer trace the important decisions and failure cases in a reasonable timeframe given to review a given PR?”. If not, the PR needs to split into smaller ones.
As managers, if we only praise whose PR throughput is high and barely notice how much time is spent in PR reviews, we’re missing an important metric to monitor.
Try this
Experiment with this to get a sense yourself. When you see a big feature getting close to being delivered and PRs being up for review for it, ask the owner:
What decisions were made that will be hard to undo? (we love two-way doors, one-way doors need to be conscious)
What are assumptions made / behaviour we’re relying on? including where it might fail and what will be the outcome
What’s the part you’d like most a reviewer to challenge? and why?
This will quickly surface whether the author understands the changes they’re proposing and whether a reviewer has a realistic chance of properly reviewing it.
Agents have taken away a lot of the effort of producing code which is great, but I also think that a lot of the thinking used to happen during that effort too. I strongly believe that we need to make room for it and not just let it slip away.
See you in the next one,
~ Stephane