Junior software developer

CRUD endpoints, forms, standard integrations, tests for known patterns.

Finding why something broke when the cause is not where the symptom is.

Reading plausible code carefully enough to catch what is confidently wrong.

Asking the questions that reveal what should actually be built.

Choosing structure and trade-offs that will still hold in two years.

● 2 verified events for this occupation, plotted at the date it happened — the parts of the line near a marker are anchored to something checkable.

Experienced maintainers on large, mature repositories they know well (about 5 years each); tools were mainly Cursor Pro with Claude 3.5/3.7 Sonnet. The authors explicitly do not claim the result generalises to most developers or to greenfield or junior work.

Failure, rollback, regulation or cost is suppressing adoption. Can lower an assessment or widen its uncertainty.

One large technology company, company-reported, with no definition of how 'generated' is measured (autocomplete versus whole functions). Says nothing about hiring; the review step stayed with engineers.

An employer has put it into production. Can move the baseline — weighted by scale and how similar the setting is.

This occupation has the sharpest split between entry-level and senior of anything in the first batch. The tasks that made junior roles economically worth creating are the ones being automated, while the tasks that define senior work are not. The risk is not that programming stops being a career — it is that the ladder's bottom rung is being removed while the top is intact. Concretely: you need to demonstrate judgement, not throughput, and you need to do it before anyone would normally expect it of you.

Your position is comparatively strong, but it depends on a supply of people who learned judgement the slow way. If the entry rung stays broken, the constraint arriving in a few years is not automation — it is that nobody built the experience to review what the tools produce. Worth thinking about as a hiring and mentoring question now rather than later.

Stay and strengthen

Build judgement faster than the ladder expects

The scarce thing is someone who can tell whether generated code is right. You can start demonstrating that on day one instead of waiting two years.

Reshape the role

Specialise where correctness is expensive

Payments, security, data integrity, infrastructure — domains where a confident wrong answer costs real money keep humans firmly in the loop.

Adjacent move

Roles that sit between engineering and the problem

Solutions engineering, developer experience, technical product — jobs where the value is understanding both the system and what someone needs from it.

Cross-industry

Apply engineering thinking in a non-software domain

Many sectors have almost no one who can both understand their domain and build. That combination is scarce and does not compete with generation.

Yes, but for a different reason than five years ago. Learning to code used to be about being able to produce code. Now the value is in being able to judge it — and you cannot judge code you could not have written. The training still works; what has changed is that the entry-level job market no longer reliably pays you while you acquire the judgement. Plan for that gap explicitly rather than assuming the first job will teach you.

The economic reason those roles existed — cheap throughput on well-specified work — is weakening, and that is a real structural change rather than a cycle. But teams that stop hiring juniors entirely create a problem for themselves: in a few years they have nobody who learned to judge output the hard way. Expect the role to be redefined around review and judgement rather than production, and fewer of them per team than before.