The discourse says AI coding agents will delete the engineering manager: smaller teams, fewer coordination problems, no need for the person in the middle.
From the mentoring chair, I see the opposite failure mode arriving first. The teams aren’t shrinking yet, but the weak management is getting exposed faster.
“AI adoption at team level, without chaos” is now one of the most demanded topics across my 3,611 sessions. Leaders don’t come asking how to cut headcount, they come asking how to adopt the tools without the chaos that has already started. It’s also why they increasingly look for an AI mentor rather than another course: the chaos doesn’t wait for module 7.
What actually changed
An AI agent compresses the loop between “decision” and “consequence”. Work that took a sprint takes a day. Which means:
- Bad prioritization surfaces in days, not quarters. When shipping was slow, a manager who couldn’t say no had a quarter of cover. Now the team builds the wrong thing at triple speed, and the wrongness is visible by Friday.
- Review becomes the bottleneck, and review is a management problem. Agents produce more code than the team can responsibly read. Deciding what gets deep review, what gets sampled, and what gets trusted is a judgment call about risk, and that call belongs to the lead and the EM. Most teams are making it by default instead of by design.
- The junior pipeline question lands on the EM’s desk. If agents do the work juniors learned on, where do the next seniors come from? So far most companies answer this by accident. The managers I mentor don’t have that luxury, they have to answer it deliberately, team by team.
- Spans are drifting up quietly. Nobody decided AI enables bigger teams; backfills just get frozen “since we have Copilot now” while the coordination load stays. The span math changed without the support structure changing.
In practice, none of these four are coding problems, they’re first-line management problems. What the agent removed is the slack that used to hide whether the manager was any good.
The part of the job that grows
Strip away status collection, ticket shepherding, and progress reporting, and agents genuinely do eat those. What remains is the part that was always the actual job: deciding what’s worth building, saying no with a reason, growing people through work that stretches them, making the risk calls on what to trust, and translating between the business and the team in both directions.
If that list describes 20% of an EM’s current week, agents are a threat. If it describes 80%, agents are the best thing that happened to the role since someone invented the 1:1.
What I’d do this quarter as an EM
- Write down the team’s review policy for agent-generated code, with explicit risk tiers. One page is enough.
- Re-negotiate your span assumption with your director before it drifts another two heads.
- Pick one junior and design their growth path assuming agents exist. If you can’t, escalate that as the org problem it is.
- Track one number: how often the team ships something fast that turns out to be the wrong thing. That number is your management exposure.
The managers doing this now aren’t fighting the agents, they’re using the compressed loop to find their own gaps before somebody above them does.
This post is the diagnosis. The decision that follows it, whether your next role is AI engineering manager or staff AI engineer, is the harder question, and it has a clock on it.
If you’re the EM or director in the middle of this, that pressure is precisely what 1:1 mentoring is for. First session free, and yes, “my CTO thinks AI means I need half the team” is a session topic already.
