The easy version of the AI jobs argument is boring now.
One side says developers are doomed. The other side says employment is still fine, so everyone should calm down.
The Stanford and ADP numbers make both versions look too clean.
The headline is not mass unemployment. Across all workers, the Canaries Dashboard shows the most AI-exposed occupations down only 0.2% year over year as of April 2026, while the least-exposed roles grew 0.1%. Since ChatGPT shipped, ADP says annual employment growth in AI-exposed occupations is still up 1.1%, compared with 2% for the least-exposed roles.
So no, the whole labor market did not fall through a trap door.
But when you cut the data by career stage, the story changes. For workers aged 22 to 25, employment in highly AI-exposed occupations is shrinking by 3.8% a year, while the least-exposed jobs for the same age group are still growing at 2% a year. The underlying Stanford paper is sharper: after controlling for firm-level shocks, early-career workers in the most exposed occupations saw a 16% relative employment decline.
That is the part developers should care about.
AI may not be replacing the job. It may be replacing the first job.
This is uncomfortable because a lot of entry-level software work looks silly from the outside.
Fix this flaky test. Add logging. Write the migration. Update the integration. Clean up the weird CSV import. Read the support ticket and reproduce it. Move a button without breaking the form. Rename the field everywhere, including the one place nobody remembers.
None of that sounds glamorous. Some of it is exactly the work senior developers are thrilled to hand to an agent.
I get the temptation. If a model can write the boilerplate, summarize the ticket, generate the test case, and propose the patch, why spend a headcount slot on someone who is still learning where the config lives?
Because that work was never just output.
It was the training loop.
Junior developers learned production taste by doing small, slightly annoying jobs next to people who had scars. They learned where code review gets picky. They learned that the migration is easy and the rollback is the work. They learned that a passing test can still prove the wrong thing. They learned that the fastest fix is sometimes the one you revert before lunch.
If you automate all of that away, you do not just save senior time. You remove the path that produced the next senior developer. That is the ladder problem.
The useful part of the Stanford paper is that it does not treat AI exposure as one big blob.
The authors separate work where AI appears to automate tasks from work where AI appears to augment people. That distinction matters. They find employment declines for young workers in occupations where AI usage is more automative, but not the same pattern in occupations where AI usage is more augmentative.
In plain English: the problem is not "this job touches AI." The problem is "the junior-shaped parts of this job can be fully delegated."
That matches what I see in agent workflows.
Agents are good at bounded, text-heavy tasks with clear inputs and expected outputs. That covers a lot of early-career work: first-pass code, small refactors, summaries, documentation edits, customer-support drafts, QA checklists, and spreadsheet glue.
Agents are much worse at the parts that look like judgment: choosing which bug matters, noticing that two teams mean different things by the same word, deciding whether a clever patch makes the system harder to own, or knowing when the model is confidently papering over missing context.
The catch is obvious. You only get good judgment by surviving enough bounded tasks first.
Companies can talk themselves into a very tidy story here.
Hire fewer juniors. Give seniors agents. Ship faster.
For a quarter or two, that may even work. The problem shows up later, and it shows up as engineering debt.
First, senior developers become the only people allowed to hold context. They review agent output, own the incident response, make the architecture calls, and explain the old decisions. Every workflow routes through the same overloaded people.
Second, the organization loses cheap mistakes. A junior breaking a dev environment while learning migrations is annoying. A senior-approved agent breaking production because nobody had time to inspect the edge case is worse.
Third, the hiring market gets weird. If nobody trains juniors, everyone competes for the same shrinking pool of people who already know how to operate in production. Then hiring managers complain that candidates have no experience. Very mysterious.
The industry has done versions of this before. We underinvest in maintenance, onboarding, docs, test suites, and internal tools, then rediscover that the boring stuff was load-bearing.
Junior work is boring in the same way.
I would not respond by banning agents from junior work. That is fake discipline. People will use the tools anyway, and they should.
I would change the shape of junior work.
Give juniors agents, but make them accountable for the review, not just the prompt. A useful entry-level task in 2026 is not "write this function from scratch." It is "use the agent to draft the patch, then explain every line you kept, every line you changed, and every test you added."
Pair juniors with agents on tasks where the output is inspectable. Small migrations, test repairs, docs tied to code, reproduction scripts, data cleanup, internal tools. The point is not to protect hand-written boilerplate as a sacred craft. The point is to keep the feedback loop.
Make review check judgment, not typing speed. Ask: what assumptions did the model make? What context did it miss? What would fail in production? What would you log? How would you roll it back?
Keep some work intentionally human at first. Not because humans are better at every step, but because a developer who has never manually debugged a failing deploy is going to trust the agent's deploy plan too much.
And track the ratio. If a team has ten senior developers, twenty agents, and zero juniors, that is not an AI strategy. It is succession planning with the succession removed.
I do not think AI is about to erase software developers as a category.
I also do not think the "nothing is happening" crowd is reading the right slice of the data.
The aggregate labor market can look stable while the bottom rung quietly weakens. That is exactly the kind of problem a dashboard like Canaries is built to catch early. Not because it proves a final answer, but because it shows where to look before the headline number moves.
For developers, the practical takeaway is simple: stop measuring AI adoption only by how much senior time it saves. Also measure what it does to the training path.
If agents remove the boring half of software work, teams need a new way to teach the judgment that boring work used to create. Otherwise the industry gets a nice productivity bump now and a much stranger hiring problem later. The junior task was never just a task.
It was how the next developer learned not to break the system.
Where do you draw the line between useful automation and cutting away the ladder?