Short answer
Will AI replace software engineers? The 2026 data says no for the profession and yes for parts of the job. BLS still projects 10% growth for software developers to 2035, but Stanford found employment of 22 to 25 year-olds in AI-exposed jobs 19% below trend. Typing code shrinks; writing intent, checking evidence and owning outcomes grow.
Every engineer I know has asked some version of this question in the last year, usually late at night and after watching an agent write in ten minutes what used to take them a day. If the machine writes the code, what exactly am I for?
The question deserves a better answer than “AI is just a tool” or “coding is dead”. So here is what the labour data actually says in late 2026, what it doesn’t say, and which parts of the job I think are moving to machines and which are growing.
The short answer: the job changes faster than the headcount
AI is replacing tasks inside software engineering faster than it is replacing software engineers. The profession is still projected to grow. The entry level is clearly getting harder. And the work that remains looks less like typing code and more like deciding what the code should do and proving that it does.
That last part is my opinion, not a statistic. The rest of this article separates the two.
What the BLS projects for software developers
The US Bureau of Labor Statistics publishes the most cited long-range projection. Its current Occupational Outlook Handbook entry counts 1,717,800 software developers in 2025 and projects employment to grow 10% from 2025 to 2035. The average for all occupations is 3%. For the combined group of developers, QA analysts and testers it projects about 106,100 openings a year. The median annual wage for software developers was $135,980 in May 2025.
Two things to keep in mind. These projections are made by economists modelling demand, not by watching what agents can do this month, and they get revised. And “growth” here means headcount, which says nothing about what those people do all day. Still, the official view is not a collapse.
What job postings show: a bust that started before agents
Indeed publishes a daily index of software development job postings, set to 100 on 1 February 2020. It is the closest thing to a live hiring signal.
Software development job postings on Indeed, US
Index, 1 February 2020 = 100
Data as a table
| Postings index | |
|---|---|
| Feb 2020 | 100 |
| Feb 2021 | 98 |
| Feb 2022 | 225 |
| Feb 2023 | 121 |
| Feb 2024 | 71 |
| Feb 2025 | 67 |
| Feb 2026 | 69 |
| Oct 2026 | 82 |
The index peaked at about 234 on 28 February 2022, fell to about 61 in May 2025, and stood at about 82 on 30 October 2026. So postings are still below their pre-pandemic level, but they have been recovering for over a year.
The shape matters. Most of the fall happened in 2022 and 2023, when interest rates rose and the pandemic hiring boom unwound, before coding agents were good enough to replace anyone. Blaming the whole drop on AI is wrong. Ignoring AI as one cause of the slow recovery is probably also wrong. Postings are not employment either: a company can stop posting junior roles and keep every senior engineer it has.
The canaries: early-career developers are hit first
The most careful study of AI and employment I have found is “Canaries in the Coal Mine?” by Erik Brynjolfsson, Bharat Chandar and Ruyu Chen at Stanford’s Digital Economy Lab. It uses ADP payroll data covering millions of US workers, and the August 2026 revision runs through June 2026. Software developers sit in the top fifth of occupations by AI exposure in their measure.
The headline finding is about age, not the profession as a whole.
The authors put employment of 22 to 25 year-olds in AI-exposed occupations 19% below where it would be had it kept pace with less-exposed peers. Experienced workers show no comparable gap. The effect works mainly through fewer hires of young workers, not more firings, and it is concentrated where AI is used to automate work rather than to help people do it. Where usage mostly complements workers, employment is flat or rising. The pattern also holds when the authors drop technology firms and computer occupations, so it is not a story about tech alone.
They are also careful about what this is not. They find no evidence of widespread, economy-wide job displacement, and they call these early, descriptive indicators rather than causal estimates. I read it the same way: AI is not removing software engineers, but it is removing some of the work that used to be how people became software engineers.
Which parts of the job move to machines
Most engineers already use AI daily. DORA’s 2025 report found about 90% of respondents using it, for a median of two hours a day. Assistants alone do not make experienced people faster on their own code, though: METR’s randomised trial found experienced open-source developers 19% slower with AI, while they believed they were 20% faster. The gain comes when the work is reorganised, not when a tool is added.
When it is reorganised, here is how I would expect an engineer’s week to change. This is a model, built from the way I see agent pipelines shift work, not a survey.
An engineer's 40-hour week, before and after agents
Modelled hours by kind of work
- Writing code
- Reading and reviewing code
- Specs, criteria and decisions
- Users, incidents, meetings
Data as a table
| Writing code | Reading and reviewing code | Specs, criteria and decisions | Users, incidents, meetings | |
|---|---|---|---|---|
| Before agents | 18 | 8 | 6 | 8 |
| Agents write code | 6 | 16 | 10 | 8 |
| Agents write and review | 2 | 4 | 20 | 14 |
The middle column is where many teams are right now: code arrives faster, so reading it becomes the job. Faros found review time per pull request up 91% on high-AI teams, which is the same effect measured. I wrote about it in code review is the new bottleneck. The right column is what happens when review moves to an independent model checking evidence, and the person’s time goes to intent and to the people who use the software.
What moves to machines, roughly in order: boilerplate and glue code, tests for known behaviour, first-pass review of routine diffs, dependency upgrades, migrations between versions of a framework. These are the tasks junior engineers used to learn on, which is why the canaries study finds the effect at the entry level.
Which parts of the job grow
The work that grows is the work agents need from people.
- Writing intent precisely enough that a machine can check it. A ticket with vague acceptance criteria produces confident wrong code, and someone has to write the clear version.
- Designing verification: scenarios, tests and checks that tell you a change is correct without anyone reading it line by line.
- Owning a product end to end. When one engineer can run a product with agents, that engineer needs product judgement, which I model in from nine developers to one.
- Building and running the pipelines themselves: harnesses, reviewer setups, guardrails, budgets.
- Talking to users, handling incidents, and making the decisions nobody should delegate: what to build, what to drop, what risk to accept.
A bad response to all this is to compete with the agent on typing speed, or to refuse to use it on principle. A good one is to move up a level: get good at specifying, verifying and owning outcomes, and use agents for the rest.
What to do if you are early in your career
The data says the entry door is narrower, so the advice is practical.
- Show that you can ship, not that you can type. A public project built with agents, with tests, a deploy and real users, says more than a list of languages.
- Learn to verify. Write the acceptance criteria and tests first, then let an agent write the code and prove to yourself that it is right. That skill is scarce.
- Read code you did not write, a lot. Reviewing agent output is half the job for the next few years, and spotting what’s missing is a skill you build by practice.
- Learn one domain properly. Agents are generalists. An engineer who understands payments, health records or logistics can tell when correct-looking code is wrong for the business.
- Pick employers that use agents seriously. You will learn the new shape of the job faster there than somewhere that bans them.
None of this guarantees a job. It does put you on the side of the work that is growing. If you want a sense of how far automation can go, the dark factory levels lay out where teams are now and where the top end is.
Questions
Will AI replace software engineers in 5 years?
The official projection says no: BLS expects software developer employment to grow 10% from 2025 to 2035. What will change is the job itself, with much less hand-written code and much more specifying, verifying and owning outcomes.
Is software engineering still a good career in 2026?
Yes, with a narrower entry. Median pay for software developers was $135,980 in May 2025, and postings have recovered from their 2025 low, but early-career hiring in AI-exposed jobs has fallen behind.
Are junior developer jobs disappearing because of AI?
They are shrinking. Stanford’s study finds employment of 22 to 25 year-olds in AI-exposed occupations 19% below trend, mainly through fewer hires, while experienced workers show no such gap.
Why did software developer job postings drop?
Most of the drop came in 2022 and 2023, when the pandemic hiring boom ended and interest rates rose. AI is one factor in the slow recovery since, not the cause of the original fall.
What skills should software engineers learn to stay relevant?
Writing precise specifications and acceptance criteria, designing tests and checks that verify behaviour, reviewing code you did not write, and running AI agent pipelines. Domain knowledge matters more than knowing another language.