Knowing how is cheap. Knowing what is everything.

Everyone draws the engineering ladder with years and job titles. Three years here, a "senior" badge there, a number on a salary band. It's mostly theatre. The real ladder has nothing to do with how long you've sat in the chair. It comes down to which of two questions you can answer on your own:

How do I build this? — and — What should I build?

That's the whole thing. Junior, middle, senior — the entire hierarchy is just a story about who can answer which question. Let me draw it the way it actually works, including the parts nobody puts on the org chart.

Junior: knows neither

A junior developer doesn't know what to do, and doesn't know how to do it. That's not an insult — it's the definition. You hand them a task, and you have to hand them the task and the recipe. "Make the save button work." Okay — which button, save what, where does it go, what happens if it fails, and what does "work" even mean here? Each of those is a question they can't yet answer alone, and that's completely fine. Everybody starts here.

The real tell of a junior isn't messy code. It's their relationship with the word "works." To a junior, working software and good software are the same thing. The button clicks, the demo runs, ship it. The idea that code can work and still be wrong — wrong shape, wrong place, a tripwire for the next person who touches it — hasn't landed yet. They optimise for "it runs," because that's the only signal they can read so far.

Their superpower is volume. Give a junior a crisp, well-scoped task and they'll grind right through it. They're the hands. Which — file this away for later — is exactly the part a machine is also delighted to do.

Middle: knows how, not what

A middle developer knows how. This is a real, hard-won skill and a big jump. Hand them "build a rate limiter" or "add retries with backoff" and they'll do it cleanly — tested, sane, the way it's supposed to be done. They've internalised the how. You can hand them the recipe and walk away.

What a middle still can't do reliably is answer what. Give them a vague business problem — "users keep churning right after signup" — and watch: they'll build something. Something lovely. Gorgeously architected, fully tested, a joy to read. And quite possibly the wrong thing entirely, because nobody told them which thing, and "which thing" was the actual problem.

This is the most expensive misunderstanding in the whole field, so let me say it flat out: a middle developer is a superb answer to a question someone else has to ask. Point them at a clear target and they're worth their weight in gold. Point them at a fuzzy business pain and they'll execute flawlessly in the wrong direction — and you won't find out for three sprints.

(If you've ever shipped a flawless feature that moved exactly zero metrics, congratulations: you met a middle. You may have been the middle. I have been the middle.)

Senior: knows what

A senior knows what. Not in a mystical way — in a boring, load-bearing way. Their value isn't that they type faster or know more frameworks. It's that they can take a fuzzy business problem and find the one thing that actually fixes it — and, just as often, the nine things you shouldn't build at all.

Watch a real senior catch "users keep churning right after signup." They don't open an editor. They ask why. They find out the onboarding emails quietly stopped sending two weeks ago, or that the signup form demands a tax ID before anyone trusts the product yet. The fix might be one line, or a conversation with marketing, or deleting a feature instead of adding one. A senior's best work often removes code. Their highest-value pull request is sometimes the one that says "we don't need this."

The how isn't gone — a senior usually knows it cold. They've just stopped being paid for it. They're paid for what, because choosing the right thing to build is the decision everything else multiplies against. Build the wrong thing perfectly and you've produced expensive nothing. Build the right thing roughly and you've moved the business. Seniors live on that asymmetry.

The ladder is one relay

Here's what makes it a hierarchy and not three unrelated jobs: each level exists to remove a kind of uncertainty for the level below it.

The business shows up with fog — "growth is stalling," "this is too slow," "customers are furious." The senior turns the fog into a what: a specific thing worth building. The middle turns the what into a how: an architecture, a plan, a clean implementation. The junior turns the how into the thousand small keystrokes that make it real.

It's a relay that converts business ambiguity into shipped software, and at every handoff the problem gets less vague and more concrete. Seniors absorb the most uncertainty and pass down a clear target; juniors absorb the least and need the clearest one. That's the whole machine. (Above seniors it keeps going — staff engineers, architects, product — people who own "what" at the scale of a whole system or a whole company. Same axis, more zeros.)

Enter the machine

This is where it gets interesting, and a little uncomfortable.

An AI coding agent is the best answer to how the industry has ever produced. Functionally, it's the most capable junior-to-middle developer you will ever work with: it knows every API, never tires, writes the tests, and does the grunt work at 3 a.m. without a single Slack message. Point it at a crisp task and it executes. The "how" — the thing it takes humans years to climb from junior to middle to learn — the machine now does on tap.

So which rung does it saw off first? The bottom one. The grunt work that was a junior's entire job is precisely what the agent does best, and the data already shows it: employment for the youngest developers is down sharply, entry-level tech hiring has fallen off a cliff, and internships are drying up. The numbers aren't subtle. The training ground is being paved over.

And here's the genuinely worrying part — the one the "AI replaces juniors, great, cheaper!" crowd hasn't thought through: the bottom rungs are how you grew seniors. You don't get senior judgment from a seminar. You get it by spending years answering "how," shipping things, watching some of them turn out wrong, and slowly learning to ask "what" before you build. Saw off the bottom of the ladder and you don't just lose juniors — you quietly stop manufacturing the seniors you'll need in ten years. The forecasters are already predicting exactly that crunch.

So where's the human?

Right where they always were — just higher up. Because the one thing the agent still can't do reliably, on its own, is answer what.

Ask an agent to build the wrong thing and it will build it, beautifully, with full test coverage, and thank you for the opportunity. It has no taste, no skin in the game, no model of your business, and no nerve. It is the most gifted middle developer in history with absolutely no idea what's worth doing. It needs a "what" — and "what" is the senior's whole job.

Which makes the advice almost rude in its simplicity: stop racing the machine on how. You'll lose, and it was the cheap half anyway. Climb to what as fast as you can — and use the machine to get there. The luckiest junior alive right now is the one who lets the agent handle the grunt work and spends the hours it frees up asking the senior question from day one: what problem are we actually solving, and is this the thing that solves it?

The machine is the best junior you will ever hire — infinitely fast, tireless, fluent in every "how" ever written. It just has no idea what to build.

That part is still yours. It was always the part worth the most.