👋 Hey, it’s Stephane. I help engineers become great engineering managers - whether you want to become one or are already leading a team.
To accelerate your growth see:
Get Hired as an EM (CV & job search to actually get interviews)
AI Behavioral Interview Coach (the best prep for your interviews)
PS. Paid subscribers get my 50 Notion Templates, The EM’s Field Guide, and access to the complete archive.
You’ve seen the dashboard. Your team’s PR throughput is up thirty percent. Tickets close faster. On paper, your team looks more productive than ever. The “AI era” has arrived, and the metrics seem to prove the investment was worth it.
But talking to your senior engineers, the vibe you feel is different. They’re exhausted. They feel like they’re drowning in a sea of what several practitioners call “slop”. While the “typing” part of the job has been compressed, the cognitive load of shipping a single feature has actually intensified.
We are currently living through a massive mis-measurement of engineering work. Many leaders celebrate “raw churn” (more lines, more PRs, more tickets) while they ignore the massive maintenance tax being slowly added to the balance sheet. If you aren’t careful, you aren’t building a high-velocity team. You’re building a house of cards.
The typing bottleneck was obviously a myth
The fundamental mistake most management teams make is assuming that “typing speed” was ever the constraint on software delivery. It wasn’t.
If you look at where an experienced engineer spends their time, writing the actual code is perhaps twenty percent of the effort. The other eighty percent goes toward discovery, alignment, and understanding the customer problem. AI tools primarily optimize that first twenty percent. They make the “typing” and the “boilerplate” nearly instantaneous.
When you accelerate the typing without improving the thinking, you just generate shitty code faster. The bottleneck hasn’t disappeared. It shifted downstream to the review process.
The metric to watch isn’t PR throughput. It’s the ratio of time spent reviewing and fixing AI-generated code compared to the time saved writing it. In many complex codebases, that ratio is trending toward 1:1. You haven’t increased your team’s capacity. You’ve traded “writing time” for “reviewing time”, and the latter is far more taxing for your senior engineers.
The human compiler
When a human writes code, they build a mental model of how it interacts with the rest of the system. When an agent “vibecodes” a solution, it often produces code that passes the “eye test” but contains subtle, dangerous edge cases.
This creates reviewer fatigue that can break your best people.
It is much harder to catch a bug in “almost-right” code than in “obviously-wrong” code. Your senior engineers are now acting as human compilers for thousands of lines of generated boilerplate. Their eyes glaze over. They miss the thread-safety issue or the memory leak because the syntax looks perfect.
You can ship a feature in two weeks that used to take six, but that might result in spending the next two months chasing “ghost bugs” and production incidents. The net outcome for the business will be zero - or even worse a decline in reliability that will kill customer trust.
Churn
You have to change what you value. You cannot manage a team in 2026 using 2019 metrics. Here are some metrics I am starting to think more about:
1. Time to understanding: The most valuable thing an engineer does is grok the problem. AI can act as a context search engine for the codebase or translate documentation, but it cannot replace discovery.
2. Guardrail metrics: If you celebrate higher PR throughput, you must balance it with high-integrity quality gates. This means:
Mutation testing: Ensure AI-generated tests actually fail when the code is broken.
Strict SLIs/SLOs: If velocity is up but production incidents are also trending up, you aren’t moving faster.
PR Size: Don’t let AI dump 1,000-line “refactors” into your codebase. If a human can’t reasonably review it, don’t merge it.
3. Protect your juniors: There is a real risk that a generation of engineers will never learn the fundamentals because the AI handles them. You must ensure your junior engineers aren’t just “accepting” AI output. Make them explain how the code works during the review. If they can’t explain the logic, then it shouldn’t be merged.
4. Shift from “tickets” to “impact”: A staff engineer should never measure their value in “tickets delivered”. Move your team away from being “ticket-to-code” machines. The more code the AI generates, the less valuable “writing code” becomes. The value is now in architecture, security, scale, and ensuring the system doesn’t become a tangled mess of “AI spaghetti slop”.
The industrialization of software
Leadership is messy, and AI has made it messier. We are essentially “mass producing” software now, much like the Industrial Revolution mass-produced shoes. The cost of code is trending toward zero, but the cost of broken software remains infinite.
While boots became cheaper during the industrial revolution, they also stopped lasting ten years and started lasting two. Software is following the same path. We have passed the “peak era of artisanal, hand-crafted, high-quality” software. Now we sling metric tons of code freely, but the quality is in the gutter.
Don’t let the pressure for “unrealistic dates” force you into accepting a lower standards. Your job isn’t to maximize lines of code. It’s to build systems that work and teams that don’t burn out trying to maintain them.
The next time you see a thirty percent jump in your velocity metrics, don’t celebrate yet. Go talk to your seniors. Ask them how the reviews are going. If they look tired, it might be your signal to dig a bit deeper.
If you enjoyed this article, consider subscribing to get:
✉️ Free: 1 original post every Tuesday, my favourite posts of the week every Sunday + 10 Notion Templates for Engineering Managers
🔒 Paid: Full archive + 50+ EM templates & playbooks + The EM Field Guide
You might also like some of my most popular posts:
See you in the next one,
~ Stephane