A junior is the cheapest instrument you own for finding out whether your specs are actually complete. They fail where your agents fail, months earlier, out loud, with a name attached.
By JP LeBlanc
Yes, keep hiring them, and not for the reason you're used to hearing. The pipeline argument, that you'll need senior engineers in 2031 and they don't appear from nowhere, is true and it will not survive contact with a headcount review this quarter. There's a better argument sitting right next to it that nobody's using: a junior is the cheapest instrument your org owns for finding out whether what you wrote down is actually complete. They fail in exactly the places your agents fail. They just do it out loud, months sooner, and with a person you can ask why.
The budget case for cutting junior hiring in 2026 writes itself, and almost every counter-argument in circulation is about the world in five years. It's not a bad argument. It's just the wrong register for the room it's being made in. Ask a VP staring at a budget line to trade a hire against a forecast that far out and the forecast loses, every time, because a forecast competes on the same footing as every other bet a finance team could make with that money, and most of those bets pay back sooner.
The argument that would actually win this quarter isn't about talent five years from now. It's about a defect you're currently shipping and don't know you're shipping.
Every organization has a gap between what it means and what it actually writes down. It's always existed. For thirty years it got closed silently, by senior judgment, at the point of execution, so quietly that most companies never had to notice the gap was there at all. A senior engineer reads an underspecified ticket, fills in the missing piece from experience, ships something close enough, and everyone moves on.
Agents don't close that gap. They don't even see it. Handed the same underspecified ticket, an agent produces a plausible, syntactically correct answer to the ticket as written, missing context and all, with total confidence and no flag raised anywhere. The gap didn't get smaller. It got invisible, which is worse, because invisible gaps don't show up until they've shipped.
A junior hits the same gap differently. Picture one three months in, handed a ticket to add a discount code path to checkout. A senior would silently assume the obvious edge cases, apply an existing pattern from memory, and move on. An agent would generate a clean implementation of exactly what the ticket says and nothing it doesn't. The junior asks what happens when two discount codes get applied to the same order, because nobody told them the answer and they don't yet have the instinct to invent one. That question is a free defect report on your spec, and it lands while the feature is still in review, not three weeks after a customer found the gap for you.
Three detectors, one intent gap. One closes it silently. One doesn't see it. One raises a hand. If the third detector disappears from your hiring plan, you haven't removed a cost. You've removed your cheapest warning system and kept the same underlying gap, now undetected until it reaches someone who can't be asked why.
None of this means hire juniors and run the old apprenticeship. The old one ran on writing a lot of mediocre code and getting it corrected in review, and that loop assumed the expensive skill was syntax, learned slowly, through volume. Syntax is close to free now. The investment has to move toward system design and judgment, lighter on the mechanics an agent already handles well.
That's a heavier lift for a manager than it sounds. It means a junior reviewing more than they write, which feels backwards to anyone who came up the old way, where review was the senior's job and writing code was how you proved yourself. I had juniors through the agentic year at CircleCI, and their growth accelerated. They reviewed more than they wrote, and shipped sooner. Writing teaches one solution. Reviewing teaches evaluation across many, which is what judgment is. That ran on a very senior team with a strong validation harness around it, and a junior reviewing agent output only learns if the surround is competent enough to correct them. Reading is the job now, earlier than it used to be.
Onboarding built around this looks different in the first thirty days: reading the system before writing in it, pairing on review instead of implementation, then an apprenticeship loop where the junior writes the spec, an agent implements it, the junior reviews the result, and a senior reviews their review. What you're training isn't code output. It's the ability to write intent clearly enough that nobody downstream has to guess what you meant, which is the actual scarce skill now, for juniors and agents both.
Hiring for it means the interview loop has to test for it too, not for whiteboard syntax fluency that an agent already beats everyone at. A loop redesigned around ambiguity, asking a candidate to write the spec for an under-defined request or find the planted defect in an agent-authored diff, predicts something closer to what the job now requires. The usual failure is quieter: a loop calibrated to a job that already changed underneath it, still scoring syntax rounds, still passing candidates who ace them. Nothing flags it until the hire is already on the team.
The pipeline argument will still be true in five years, and it's worth making to a board that thinks in decades. It just won't win the budget meeting happening this month. The argument that will is smaller and colder: every junior you don't hire is a defect detector you've turned off, on a system that is currently shipping gaps you can't see any other way.
Cut the hire if you want. Just be honest that what you're cutting is the part of your review process that used to work for free.