Five years ago, a junior developer stuck on a gnarly bug had two options: read the source code or ask a senior colleague. Both paths forced understanding. Today, that same developer pastes the error into ChatGPT, gets a fix, ships it, and moves on without ever learning why it broke.
That shift is fueling a growing argument among engineering leaders: AI coding assistants aren't destroying the junior-to-senior development pipeline. They're revealing that no such pipeline ever existed on purpose.
The Accidental Training Ground
The case, laid out in a recent essay by developer Bryan Liles, goes like this. The software industry never built a deliberate system for turning junior engineers into senior ones. What it had was an environment full of friction - bad documentation, limited tooling, production systems that would bite you if you cut corners. Junior engineers grew into senior engineers the same way people learned to cook before YouTube: by burning things and figuring out why.
Liles identifies three conditions that accidentally produced growth: productive struggle (wrestling with a problem until you actually understand the system), consequence exposure (watching your bad deploy take down a service at 2 AM), and graduated autonomy (getting harder problems with less hand-holding over time). None of these were designed. They were just side effects of software being hard.
AI tools are systematically removing all three. When a developer can get a working answer in seconds, the productive struggle disappears. When AI-generated code passes tests but the developer can't explain what it does, consequence exposure gets delayed until the problem is much bigger. And when AI handles the hard parts, graduated autonomy never kicks in.
Coding Skill Is Table Stakes Now
The more interesting claim here isn't about what's being lost - it's about what "senior" should have meant all along. Liles argues that the industry conflated coding proficiency with seniority, when the actual markers of a senior engineer are harder to automate: breaking an ambiguous business problem into buildable pieces, understanding how a change in one service ripples across a system, navigating organizational politics to get the right thing built, and developing taste for when a "good enough" solution is correct versus when it's technical debt.
These are skills that AI tools don't teach and can't replace. They're also skills that most companies never intentionally developed in their engineers. The old environment just happened to force some people into situations where they picked them up.
What Companies Actually Need to Build
This framing puts the responsibility squarely on engineering organizations, not on the tools. If AI removes the environmental friction that accidentally produced senior engineers, companies need to replace it with something intentional. That means structured mentorship programs, deliberate exposure to system-level problems, and evaluation criteria that go beyond "ships code fast."
The essay doesn't include data - it's a conceptual argument, not a study - but it maps onto patterns that are hard to ignore. Stack Overflow's 2025 developer survey found that 82% of professional developers use AI coding tools regularly. GitHub reports that Copilot users accept AI suggestions for roughly 30% of their code. That's a lot of productive struggle being skipped.
The practical takeaway for anyone managing developers: if your plan for growing senior engineers is "they'll figure it out," AI just broke that plan. Not because AI is doing anything wrong, but because "figure it out" was never actually a plan. It was just what happened when everything was hard enough that you had no choice.