AI Won't Replace Your Seniors — It'll Expose Your Juniors

Here’s a pattern I’m seeing on real teams, including my own.

Engineers are shipping faster than ever. Pull requests are flowing. Code is compiling. Features are getting marked as done. Velocity metrics look incredible.

And the engineers who actually understand the codebase are spending more time than ever reviewing, reverting, and quietly rewriting code that technically works but fundamentally misunderstands the problem.

AI didn’t create this dynamic. It’s accelerating it in ways most engineering managers aren’t prepared for.

The Productivity Illusion#

AI coding tools are impressive at producing code that looks right. It compiles. It passes the obvious test cases. It follows the patterns in your codebase. For an engineer who doesn’t have deep expertise in the area, this feels like a superpower. The barrier between “I don’t know how to implement this” and “I have working code” has collapsed.

But “working code” and “correct code” are not the same thing. Neither are “correct code” and “good code.”

The gap between these levels has always existed. What’s changed is the first level is now trivially accessible. The other two are exactly as hard as they’ve always been. You still need judgement to write correct code. You still need experience to write good code. AI doesn’t teach you either.

It’s About Skill, Not Title#

I wrote about what actually makes a senior engineer senior. It’s not years of experience or a title on LinkedIn. AI is making that distinction sharper than ever.

Some engineers know what to ask for because they already know what the solution should look like. They catch subtle bugs because they’ve been burned by those bugs before. They’re getting more productive. AI is a force multiplier for them.

Other engineers can’t tell you whether the output is the right solution for the context. They don’t have the instinct to spot the race condition or the N+1 query. They’re producing volume that creates an illusion of progress. They’re moving fast in a direction that might be wrong.

Here’s the uncomfortable part. This isn’t just a junior engineer problem. Some engineers with “senior” in their title are in the same camp. AI doesn’t care what’s on your LinkedIn. It exposes anyone who’s been getting by on output volume rather than deep understanding. Title inflation has been a problem for years. AI is making it visible.

The Overwhelm Problem#

Here’s something I’ve seen firsthand. A single engineer who leans heavily on AI can overwhelm an entire team with review requests. PRs flowing in faster than anyone can review them. The code compiles, the tests pass, but nobody has had time to actually evaluate whether the approach makes sense.

Just because you can produce ten PRs a day doesn’t mean you should. Especially when your seniors don’t have proportional force multiplier tools to handle the increased review load. We gave one side of the team a productivity boost and left the other side to deal with the consequences.

That imbalance is a real problem and most teams haven’t figured it out yet. AI can help with reviews. I use it that way myself in my solo workflow. It’s not the whole answer. Process plays a part. Architecture plays a part. If your codebase is well-structured with clear boundaries, there’s less surface area to review. If your process routes the right PRs to the right people, you’re not wasting senior time on things that don’t need their expertise.

There’s no single fix. But pretending the review bottleneck doesn’t exist, or blaming seniors for being “too slow” to review, misses the point entirely.

The Learning Gap#

Here’s what worries me most.

The traditional path from inexperienced to expert was paved with friction. You’d spend a day debugging a memory leak and come out the other side understanding how the garbage collector actually works. You’d write a database query that brought down staging and learn about query planning the hard way. You’d ship a feature that seemed simple and spend two weeks handling edge cases you didn’t anticipate.

That friction was the learning. Not a byproduct of it. The actual mechanism.

When AI generates the code that handles the edge cases for you, you ship faster. You also skip the part where you understand why those edge cases exist. The next time a similar problem appears in a different context, you don’t have the instinct to recognise it. You just ask the AI again.

The result is engineers who’ve shipped a lot of code but built very little understanding. They have a portfolio of outputs but not a foundation of knowledge. When they encounter a problem AI can’t solve, an architecture decision, a production incident, a trade-off with no clear answer, they’re stuck.

Learning vs Delivering#

I want to be clear. I’m not anti-AI. I use it constantly. I talked about using AI as a rubber duck that talks back in The Weekend Deploy. It’s a powerful tool. But there’s a distinction between learning and delivering that’s always existed, and it matters more now than ever.

When you’re delivering, use every tool you’ve got. Ship fast. Automate the boring stuff. Let AI handle the boilerplate. That’s what it’s for.

When you’re learning, the friction is the point. I still do LeetCode and CodeWars problems by hand. AI could solve them instantly. That’s not the point. The cognitive load, the struggle, the “why doesn’t this work?” loop. That’s where the understanding gets built. Skip it and you skip the growth.

The judgement about when to struggle and when to automate is itself a skill that needs to be developed. Managers need to actively support it.

What This Means for Managers#

If you manage a team, here’s what I’d be paying attention to.

Velocity is no longer a signal of capability. An engineer shipping ten PRs a week might be less capable than one shipping three. The question isn’t “how much are they shipping?” It’s “how much do they understand about what they’re shipping?” If you’re measuring output without measuring comprehension, you’re tracking the wrong thing.

Code review is more important than ever, and more strained. The review isn’t just about code quality anymore. It’s the primary mechanism through which engineers learn why something should be done differently. If your experienced engineers are too overloaded to review thoroughly, or if they’re approving AI-generated code on autopilot because it “looks fine”, you’re losing the most valuable feedback loop your team has.

The seniority gap has changed shape. The traditional gap was about implementation. Junior engineers needed help writing code. The new gap is about judgement. Engineers can produce a solution to any problem. The question is whether they can tell you if it’s the right solution. This requires different mentoring. Less “here’s how to write this function” and more “here’s how to evaluate whether this approach is correct for our context.”

Give people space to learn. When you see someone struggling with something AI could solve in seconds, resist the instinct to say “just ask Copilot.” At least sometimes. Create deliberate space for learning: code katas, architectural exercises, debugging challenges where the goal is understanding, not output. The learning vs delivering split has always existed. AI just makes it more important to be intentional about which mode your team is in.

The Bifurcation#

I don’t know exactly when it happens, but we’ll see a clearly visible split across engineering teams. Engineers who used AI to accelerate their learning, who used the time saved on implementation to go deeper on understanding, will be dramatically more capable than their peers. Engineers who used AI to replace their learning, who stopped at “it works” and never asked “but why?”, will have years of experience on paper with months of actual skill development.

The split cuts across titles and experience levels. Some engineers five years in will have deep understanding. Others with the same tenure will have been leaning on AI so heavily they can’t debug a production issue without it.

The advantage compounds. Every problem an engineer works through without outsourcing the thinking becomes pattern recognition for the next one. Every problem they hand off entirely to AI leaves them at the same capability they started the day with.

As a manager, the question to ask yourself is: which kind of engineers is your team producing?

The answer isn’t about the tools. It’s about the culture. Do your engineers have space to be slow when it matters? Do your experienced engineers have time to teach, not just review? Does your team value understanding, or just output?

AI won’t replace the engineers who understand what they’re building. It might prevent the ones who don’t from ever getting there. That’s the problem worth solving.