You Cut Junior Hiring to Pay for Agents. Now Who Reviews the Code?

Anthropic published a workplace report on Friday, and buried a few lines under the productivity charts is the number that should worry you most: the share of junior technical hires fell from 27% to 9% since early 2025. Not 27% to 20%. To 9%. The share of junior-level people inside technical departments dropped from 21% to 14% over the same period.

The company frames this as an AI-adoption story — partly "natural expansion of business functions," partly "coding tools increasingly allowing non-technical employees to make software themselves." Fine. They are a company with an unusual amount of internal tooling and an unusual tolerance for experimentation.

But the same report says something that undercuts the celebration. It describes "human attention and judgement" as a growing bottleneck, because the model produces a "deluge" of text that someone has to read and organize. Twenty percent of employees said their job had shifted "from actually doing work to managing Claudes." One engineer compared it to babysitting: every child shows up with a concern that demands equal attention.

Read those two facts together and you get the argument of this piece. You cut the bottom of the ladder at exactly the moment you made the top of the ladder the constraint. Junior hiring is how you manufacture reviewers. You cannot buy them later at the speed you now need them.

The scarce thing moved from typing to understanding

For most of software history, the expensive input was code production. Someone had to type the thing. Review was a checkpoint you squeezed in between building.

That ratio has flipped. Drafting a function, a test, a migration script — that work is now cheap enough that the cost is measured in tokens and a couple of minutes. What is not cheap is deciding. Should this ship? What does it do when the vendor times out? Which of the four plausible failure modes is the one that will page someone at 3am?

That decision requires a specific skill: you have to be able to hold the change in your head and simulate it going wrong. A reviewer who cannot predict how a diff fails is not reviewing, they are approving. And approval without prediction is exactly the behavior that turns an agent-driven pipeline into a very fast way to distribute bugs.

The gap shows up physically. The report notes meeting time per employee is up 20% year over year, and up 16% for technical contributors — attributed to the need for "human trust and accountability." When artifacts get cheap, people spend more time agreeing about them. That is coordination cost, and it is not a sign that the work got easier.

Reviewers are built by doing the work badly, once

Here is the uncomfortable part. Nobody is born knowing that an event handler which saves an id before calling a payment provider will double-charge on retry, and a different ordering will silently drop the charge. That knowledge comes from one of two places: you wrote the bug, or you sat close enough to someone who did that it stung.

The current tooling trend actually makes this point better than any essay. A GitHub hook called Sphinx, released this year, pauses your push and asks you a question generated from your own diff: what happens on the retry? You answer, you get it wrong, it asks again, and it will not let the push through until you demonstrate you understand the change your agent just wrote. That product exists because a model could write the code, and a human could not explain it. The gap between "written" and "understood" became a thing worth building a company around.

You cannot short-cut that gap with documentation. You close it by shipping two hundred small diffs, eating feedback on each one, and slowly building a mental library of how systems break. That library is review capacity. Junior hiring is the way you build it at scale.

The trade-off is real, and it isn't in year one

Let me steelman the other side, because you are already thinking it: juniors genuinely cost senior time. A first-year engineer needs design discussions, careful review, and someone to tell them why the naive caching layer will break under concurrency. That attention is precisely the resource Anthropic identifies as the new bottleneck. Adding juniors while your seniors are already supervising six agents feels like pouring water into a full bucket.

So the honest accounting looks like this:

• Year 0–1: Reduced junior intake looks like a win. Senior hours per shipped feature fall because agents draft, and nobody is paging anyone about a mentee's pull request.
• Year 1–2: Velocity holds or improves. Your senior group is still deep enough, because those people were hired before everything changed.
• Year 3–5: The constraint becomes who can approve. You have the same three people who can review the billing path, and they now receive five times as many changes. Onboarding a senior hire from outside takes 6–18 months of context before their approvals mean as much as an insider's.

The costs are deferred and the benefits are immediate, which is why this decision gets made badly by default. It is the same failure mode as skipping tests: nothing breaks today.

And note that "hire a senior instead of two juniors" doesn't fix it. A senior reviewer answers the question — is this safe? An internal apprentice becomes a reviewer who answers it too, in three years, for a third of the cost. The pipeline and the hiring bar are solving different problems, and most teams only fund one.

Three numbers to measure whether you're still building reviewers

1. Comprehension coverage. Out of last week's merges to protected branches, what fraction had a named human who could explain an edge case in the change without opening the file? Sample ten of them. If you're under about 70%, your agents are shipping artifacts that nobody verifies beyond "CI is green." A diff-derived question before merge — whether you use a hook like Sphinx or just a person asking in review — is a reasonable mechanism. Watch the skip rate. Every such gate has a bypass, and if a fifth of your pushes take it, you have installed theater.
2. Reviewer concentration. For each of your three riskiest modules, how many people can approve a nontrivial change without help? If the answer is one, agent output is compounding on a single nervous system. Aim for a minimum of two, and treat a drop to one as an incident, not a staffing quirk.
3. Manage-versus-understand ratio. Rough hours per engineer spent directing agents (prompting, re-prompting, triaging output) against hours spent reading the artifacts themselves. That 20%-of-employees "managing Claudes" figure is a warning, not a benchmark. When the second number rounds to zero, you are not reviewing code, you are routing it.

What to actually change

Name a human author on every agent-assisted change. Not the model, not the tool. If two people cannot answer a question about the diff, it isn't ready. This single convention changes behavior more than any policy document, because it puts a specific name next to an output that used to have none.

Put juniors on agent review, not only on greenfield tickets. Reviewing an agent's small, frequent, semi-plausible diffs is unusually good training: it is dense in decisions and low in typing. Give them a question log — every "why is this here?" that went unanswered, rotated weekly. That log is your real onboarding curriculum, and it is written by the work you already have.

Run a 30-minute "how does this break?" session weekly, using one real incident or one real nasty diff. The Sphinx example is the template: ask, get a wrong answer, ask again. Adults learn failure modes much faster from a story with a consequence than from a style guide.

Count reviewers in your staffing plans. If you engage a partner team or a near-shore group, the useful question is not "how many developers" but "how many people can approve a change to the payment path by month six." Capacity that can't approve is capacity that still needs your scarcest people.

None of this argues for hiring juniors out of sentiment or for keeping an apprenticeship model that no longer matches the work. The old ladder — two years of CRUD, then trust — was itself wasteful, and agents have arguably killed it. What hasn't changed is the arithmetic: understanding is the bottleneck, understanding is built by exposure, and exposure requires someone to be in the room who isn't yet good at it.

You can outsource the typing. The comprehension you have to grow.

Key Takeaways

• The bottleneck moved from producing code to understanding it; review capacity is now the constraint that limits how fast you can ship safely.
• Anthropic's own numbers — junior technical hires down from 27% to 9% — show the bottom rung being removed while the need for the top rung grew.
• Reviewers are made by shipping small diffs and eating feedback, not hired fully formed. You cannot buy five years of context in a month.
• Cutting junior intake looks free in year one and costs you your second reviewer in year four; the bill arrives as a single-person dependency on your riskiest module.
• Track three numbers: comprehension coverage on merges, reviewer concentration per critical module, and the ratio of managing agents to reading artifacts.
• Bypass rates decide whether your comprehension gate is a control or a ritual — audit the skips, not just the successes.