The AI productivity story has two winners. Juniors are shipping faster than before. Seniors are doing more architecture with less implementation effort. Neither group is where the hidden cost of AI productivity landed.
LeadDev's July 6 analysis put it bluntly: mid-level engineers are quietly drowning, spending most of their time catching AI mistakes that never show up on any dashboard. They're not generating the code. They're not designing the systems. They're absorbing the gap between the two — and the gap has gotten wider.
What the Role Distribution Actually Looks Like Now
When AI tools arrived in force, they didn't distribute gains evenly. The structure of software development has three rough layers, and AI's impact broke along those same lines.
Juniors gained the most obvious speed boost. The tasks that consumed most of a junior's day — CRUD operations, boilerplate, straightforward bug fixes — are exactly what AI handles well. A junior with Cursor or Claude Code can generate a working feature in the time it previously took to set up the environment and read the relevant file. The output increased.
Seniors gained a different kind of leverage. They were already doing the high-value work AI struggles with: decomposing ambiguous requirements into precise specs, making architectural decisions, holding the mental model of how the whole system fits together. AI handles more of the implementation once a senior provides the specification. Their judgment now governs more surface area. Opsera's 2026 benchmark study, covering 250,000 developers, found senior engineers capturing nearly five times the productivity gains of junior engineers — because seniors have the judgment to know when to trust AI output and when to override it.
Mid-level engineers are somewhere between those two descriptions. They write code, but they also know why the code is structured the way it is. They're not yet doing pure architecture, but they've been in the codebase long enough to know where the bodies are buried: the module that breaks when you touch it, the interface that assumes a specific execution order no one documented, the third-party integration that silently returns null on certain edge cases because of a bug in the vendor's API from 2023.
That knowledge is not in the codebase. It's not in any spec. It's carried by the people who have lived in the system long enough to accumulate it. When AI generates code, it generates against the visible context. The invisible context — the tribal knowledge of why things are the way they are — belongs to mid-level engineers.
The Gap That Opened
Before widespread AI adoption, the flow of work had natural friction that distributed knowledge transfer. A junior developer would write a function, hit a weird edge case, ask a senior or mid-level, and learn something about why the system worked that way. Code review was partly about catching mistakes and partly about propagation of that institutional understanding.
AI removed the friction. Juniors now generate code that compiles and passes tests without necessarily understanding the constraints that govern it. The questions that would have come in a Slack thread now don't come — they don't need to ask, because AI answered. But AI answered from the visible context, not the institutional one.
The resulting PRs look fine until someone who knows the codebase reads them. An async pattern that works in tests but breaks under production concurrency. An API call that assumes the vendor's documented behavior instead of the documented-plus-the-behavior-they-actually-implemented. A data migration that doesn't account for the legacy rows that predate the constraint.
Catching these is not a coding task. It's a comprehension task. You have to know enough about what the system has been through to understand what the generated code is missing. That work lands on mid-level engineers because they're the ones with both proximity to the code and enough history to see the gap.
And it lands silently. It doesn't produce a commit. It produces a review comment, sometimes a back-and-forth with an agent, sometimes a direct correction. The Harness 2026 State of Engineering Excellence report found that 31% of the average developer's workday is now invisible AI overhead — reviewing AI-generated code, debugging AI-introduced bugs, steering drifting agentic sessions. That overhead is not distributed equally. Mid-level engineers, with the highest ratio of review responsibility to generation work, absorb a disproportionate share.
The Measurement That Doesn't Exist
Nothing in standard engineering metrics sees this work. PR count measures how much gets merged, not how much gets caught before merging. Commit velocity measures what lands, not what a reviewer pulled back. DORA metrics capture deployment frequency and change failure rate downstream — useful signals, but aggregated to the team level in ways that mask who is carrying the load.
The oversight work isn't even clearly assigned. A mid-level engineer reviewing a PR from an AI-assisted junior is doing engineering quality work that would previously have taken a more experienced person a few hours and now takes less time, but that now happens far more often. The per-unit time dropped. The frequency increased. Total hours spent in this mode, spread across a week, is not a number most teams track.
The developers doing this work are aware of it. They're also aware that the metrics their performance is evaluated against don't capture it. They can see their commit count fall while their review comments increase, and they know which direction performance reviews tend to move when the numbers trend that way.
The Long-Term Problem This Creates
Mid-level engineers are the next senior engineers. The institutional knowledge they carry was accumulated over years of close contact with the codebase, over production incidents that forced understanding of how the system actually behaved under load, over the kind of sustained debugging that builds a mental model no spec can substitute for.
If mid-level engineers burn out and leave, you don't lose mid-level engineers. You lose the future senior engineers who would have held your system together in 2028 and 2030. The knowledge they carry leaves with them. The agents they were correcting keep generating against the visible context, without the invisible one, and the gap between AI output and institutional reality grows.
The AI-driven compression of development teams has already thinned the junior pipeline — Stanford's AI Index found developer employment for 22-25 year-olds fell nearly 20% since 2024. The mid-level pipeline thinning will follow a different mechanism: not displacement, but attrition from invisible burden.
What the Data Would Show
If you tracked developer time at the application level — not just editor time, but the full set of tools each person uses across a workday — you'd see the mid-level signal.
A typical senior engineer's day has grown heavy in spec documents, Linear, GitHub discussions early in tickets, and lighter in the code editor relative to before. A typical junior's day looks different than it used to: more time in Cursor or the terminal, shorter review sessions, faster PR cycles. A mid-level engineer's day increasingly looks like: GitHub review tabs, terminal debugging post-review, Slack threads resolving ambiguities in AI output, then eventually their own generation work.
The review and debugging time is not tracked by anything designed to measure it. WakaTime captures the editor. GitHub captures commits. Neither captures the hour a mid-level engineer spent understanding why an AI-generated database migration would have silently dropped six rows that a constraint was supposed to protect.
At xeve, app-level tracking captures this because it logs all applications, not just the editor. The pattern is visible in the data: mid-level engineers show the highest ratio of review and communication tool time to generation tool time, and that ratio is increasing as AI adoption scales on the teams around them.
That ratio is the metric that matters for understanding where the institutional overhead is accumulating. It's not showing up on any productivity dashboard anyone is currently running.
What Gets Measured Gets Managed
The LeadDev analysis frames this as a crisis in engineering pipeline: the people doing the invisible institutional work are not being credited for it, and they won't stay for a career of invisible work. The fix it identifies — making oversight explicit, measuring and acknowledging the review burden — is correct but requires actually having a measurement.
You cannot make oversight explicit if you don't have data on where it's happening. Which developers are spending the most time in review mode versus generation mode, which PRs are requiring the most back-and-forth before merge, which parts of the codebase are generating the most correction work — these are the signals that would tell you where the mid-level burden is concentrating and who is carrying it.
Senior engineers are getting more leveraged. Junior engineers are generating more. The question worth asking is what your mid-level engineers' day looks like right now, and whether the answer is anywhere in your current metrics.