The mid-level squeeze

The middle of the engineering org chart is under more pressure than either end under AI adoption, and the engineering-management conversation about it is almost entirely dishonest. Juniors are still cheap enough to be apprentices. Seniors still own the judgment work the tool can’t do. The layer caught between them — mid-level engineers producing the steady stream of glue code that actually ships product — is the layer the tool is best at replacing, and pretending otherwise is costing careers that didn’t need to end and teams that didn’t need to thin.

This is a career-stage problem, not a performance problem. It is also not solved by telling mid-level engineers to “upskill” or “learn to prompt” or “move up the value stack.” Those phrases are what you say when you don’t want to describe the mechanism. The mechanism is worth describing.

Why the middle, not the ends

AI coding tools are strongest on a specific kind of work: the scope is bounded, the pattern exists elsewhere in the codebase or in the training data, the spec is already in the ticket, and the answer is mostly about execution rather than judgment. That description is, almost exactly, the modal ticket for a mid-level engineer. It is not the modal work of a junior, who is supposed to be building the pattern recognition the tool already has. It is not the modal work of a senior, whose value has always been in spec, review, integration, and the judgment calls that happen when the system doesn’t behave the way the docs said it would.

The shape of the displacement follows the shape of the work. The tool is good at the middle because the middle is where the work was most legibly shaped and most repeatedly patterned. The ends are safer not because those engineers are more talented, but because their work wasn’t the kind of work the tool got good at first.

This is a structural observation, not a moral one. The middle layer was hired for a market that wanted fast, reliable glue-code production. That market shrank. The engineers who were good at it did not become less skilled overnight — the work stopped being the work.

The advice that doesn’t help

Three versions of the standard advice circulate, and all three are wrong in useful ways.

“Learn to prompt.” Prompt-writing is not a meaningfully transferable skill at the level most people mean it. The valuable part of using these tools well is upstream — it is spec clarity, problem framing, constraint identification, and evaluation under uncertainty. Those are senior skills. Telling a mid-level engineer “learn to prompt” is telling them to practice the tail end of a skill stack whose front end is the bottleneck. The twenty people on the team who can write a serviceable prompt are not differentiated from each other by the prompt. They are differentiated by how well they specified the problem before typing.

“Upskill.” Into what, by when, and measured how? “Upskill” is an instruction that sounds like a plan and isn’t one. The skills that matter — spec ownership, system thinking, cross-boundary judgment, review under uncertainty — are built through years of exposure to the specific failure modes of a specific codebase with specific people. You cannot acquire them from a weekend course. “Upskill” as spoken by a skip-level is usually a way of transferring a structural problem onto the individual.

“Move up the value stack.” This one is closest to right and still usually wrong. The value stack isn’t a ladder you climb by wanting to. It is a different kind of work, with different outputs, different cadence, and different evaluation. An engineer who was measured in story points last quarter cannot simply start being measured in spec quality this quarter without the org restructuring around the change. If the work they’re assigned is still glue code, they will still be producing glue code, and the tool will still be better at it than they are. This is not personal. It is load-bearing.

What “up the value stack” actually is

Strip the phrase of its LinkedIn flavor and it resolves to four specific kinds of work that the tool is bad at and that compound across a career:

Spec ownership. Turning an unclear business problem into a precise engineering specification. The work that happens before anyone writes a prompt. Teams have been under-investing here for a decade; the under-investment is now catastrophic because the tool amplifies whatever spec it is handed. Engineers who can own this surface become the constraint on throughput and get paid accordingly.
Cross-boundary integration. The contracts between systems, the invariants that span services, the places where the codebase is only coherent if you hold three files in your head at once. The tool is structurally bad at this because its context window is narrower than the problem, and it will stay structurally bad at it for a while.
Review authority. Becoming the engineer whose review a team actually trusts — not as a gatekeeper, as a signal. This is built by deliberate exposure to many failure modes and deliberate practice at articulating why something is wrong without having to rewrite it. It is the single most leveraged skill on an AI-augmented team, and it is not taught.
Domain ownership. Knowing what the product actually does, what the customers actually need, what the edge cases mean rather than what they look like in the ticket. The tool has no domain. Your team has exactly as much domain knowledge as the people on it can hold and transmit. Engineers who invest here become irreplaceable in a way the tool cannot approach.

Note what is missing from the list: “prompt engineering,” “AI tooling fluency,” “vibe coding.” These are real, and they are table stakes. They do not differentiate. Fluency with the tool is the floor; the four above are the ceiling.

The part that is the manager’s job

A mid-level engineer cannot solve this alone, and most of the honest advice in this space is advice to managers, not to ICs. The manager’s work is to restructure how work gets assigned so that mid-level engineers are routinely handed problems instead of tickets, and given the time and authority to own them end to end.

That means:

Stop pushing tickets down. Push problems down. A ticket is someone else’s spec; a problem is an invitation to produce one. The first is work the tool can do. The second is work the tool can’t.
Protect the apprenticeship ladder. If juniors never get to do work the tool could have done, they never build the pattern recognition that turns them into seniors. The team that uses AI to eliminate all junior work eliminates its five-year senior pipeline. This is the slowest and most expensive failure mode in the space.
Change the measurement. Story points, ticket velocity, and lines-of-code metrics were always bad. Under AI they are catastrophic: they measure exactly the work the tool is replacing. If you cannot articulate what a mid-level engineer produces that a measurement system should reward, you cannot expect them to produce it.
Have the conversation honestly. “We are still figuring it out” is a responsible sentence if it is followed by specific work. It is a cowardly sentence if it is followed by nothing. The mid-level layer is not naïve; they can tell which it is, and the trust cost of the wrong choice compounds faster than the team’s velocity will.

If you are a manager and none of this is on your roadmap, the squeeze is going to happen on your team with or without your attention.

The part that is the engineer’s job

If your manager is doing the above, the honest advice is straightforward: take the harder work when offered, practice spec-writing deliberately, read more code than you write, develop opinions about review that you can articulate, and invest in domain knowledge as aggressively as you invested in tooling two years ago.

If your manager is not doing the above, the honest advice is harder: the work you were hired for is shrinking, and waiting for the org to restructure around you is usually not a strategy. You have three options, in order of effort:

Claim the work. Volunteer for the specs, the reviews, the cross-boundary problems. Refuse tickets that are too well-scoped to develop anything in you. This works when the org tolerates initiative; it fails when it doesn’t.
Change the role inside the org. Move toward teams, domains, or products where the judgment-heavy work is the main work. Staff engineer tracks, platform teams, infra teams, and early-stage product teams are all currently easier places to practice the skills that compound than mature feature-factory teams.
Change orgs. Not a moral judgment, not a loyalty question — a risk calculation. The orgs that will compress hardest under AI adoption are the ones that still measure engineers on throughput of legible work. If the org you are in is one of those and shows no sign of changing, the squeeze will arrive regardless of how good you are at what you currently do. The people who move before it arrives do better than the people who wait to be told.

None of the three options is costless. Staying in shrinking work is also not costless. The specific math is personal; the general shape is not.

What this post is not

It is not an argument that the squeeze is fair, or an argument that displacement is the price of progress, or an argument that if engineers just tried harder this wouldn’t happen. The squeeze is structural, the displacement is real, and the individuals caught in it mostly did their jobs well in a market that changed under them. That deserves to be said plainly.

It is also not an argument that mid-level engineering is going away. It isn’t. The work is changing, faster than most orgs’ measurement systems and hiring pipelines are changing. Engineers and teams that adapt around the new shape of the work come out of this period stronger than they went in. Engineers and teams that refuse to see the shift, or that allow their org to pretend nothing is happening, do not.

The squeeze is real and the advice handed to the people caught in it is mostly wrong. The work to do about it exists, and it splits cleanly between what managers owe their teams and what engineers owe themselves. Naming the split is the first honest move. After that it is work, and the work is worth doing.