Who's Genuinely at Risk, and Why It Isn't About Seniority

The assumption is that juniors are exposed and seniors are safe. Seniority correlates with exposure, but it isn't the variable — and treating it as one leaves some senior engineers comfortable when they shouldn't be, and some juniors more frightened than the situation warrants.

The actual variable is what proportion of your value comes from producing artifacts versus from holding context and making decisions.

The exposure axis

Position anyone on one question: if implementation became free tomorrow, how much of what you contribute would remain?

High exposure, regardless of title:

• The senior engineer whose value is being very fast at writing well-structured code in a familiar stack. Real skill, and it's precisely the skill that got cheap.
• The specialist in a framework whose expertise is API surface knowledge. That knowledge is exactly what a model has absorbed most thoroughly.
• Anyone whose work arrives as complete specifications and departs as implementations. Contractors and outsourced teams often sit here structurally.
• The engineer who has been at one company for years without accumulating decision authority — the context is there, but the role doesn't use it.

Low exposure, regardless of title:

• Anyone who decides what gets built.
• Anyone holding context that isn't written down — why the system is like this, what was tried, what's fragile.
• Anyone accountable for an outcome rather than an output.
• Anyone whose work is mostly ambiguous inputs and negotiated requirements.
• The junior who has become the person who understands one gnarly subsystem better than anyone.

→ That last one matters. A junior with deep ownership of something real is less exposed than a senior whose value is fluent implementation. Titles don't sort this; the nature of the contribution does.

Why juniors are still under pressure

Both things are true, and it's worth being precise about the mechanism rather than treating it as a contradiction.

The task profile of traditional junior work is highly exposed: well-specified pieces, tests to a pattern, small scoped fixes. And the hiring case was always partly an investment — accept lower output now for capability later. When the near-term output gap narrows, the investment gets harder to justify even where it's still correct.

But that's a statement about entry-level hiring, not about individual junior engineers. A junior already inside an organization, accumulating context and ownership, is moving along the low-exposure axis. The hard part is the entry, not the position.

⚠️ Which is a genuine collective problem: seniors come from somewhere, and an industry that stops hiring juniors is drawing down a stock it isn't refilling. The consequence arrives on a delay long enough that no individual hiring decision feels responsible for it.

The comfortable seniors who shouldn't be

The category worth naming, because it's the one that gets missed: the experienced engineer whose seniority is measured in years and output rather than in decision authority or irreplaceable context.

Signals to check honestly:

• Your work arrives as tickets that are already well specified.
• You're valued for speed and quality of implementation.
• You aren't in the conversations about what to build.
• Your knowledge is about technologies rather than about this system and this business.
• Someone could read your PRs and learn most of what you contribute.

None of those are failings. They describe a role that was well-defined and valuable for a long time, and it's the role most directly overlapping with what agents do well.

✅ Moving along the axis

The moves are the same regardless of title, and they're unglamorous:

• Take ownership of an outcome, not a set of tasks. Be the person accountable for whether something works, not for whether it was built.
• Accumulate context deliberately. Learn why the system is shaped this way. Talk to whoever remembers. Become the person who knows.
• Get into the decision. Ask to be in the conversation where scope is set. Contribute there, not just downstream of it.
• Develop verification skill. Judging whether a change is right — including whether it's the right change — is the constraint now, and it's distinct from producing it.
• Stay close to the domain, not just the technology. Technology knowledge is what generalizes and therefore what's most replicated; domain knowledge is specific and stays scarce.

The takeaway

Exposure tracks the production-versus-judgment split, not years of experience. A junior owning a subsystem is safer than a senior producing well-specified implementations quickly. Check your own position with one question — if implementation were free, what would remain of what you contribute? — and if the answer is thin, the moves are available and they don't require a title change to start.