Blog

Will AI Replace Software Engineers? What the 2026 Data Actually Says

Key Takeaways

  • AI is not replacing software engineers as a profession. It is replacing tasks, and it has sharply cut the number of entry-level openings: only 4.5% of US software job postings were entry-level in Q1 2026.
  • The best field data so far shows AI coding agents produce about 30% more code at firms that adopt them, but no measurable increase in shipped features. Human code review became the bottleneck.
  • Demand is shifting rather than vanishing. The US Bureau of Labor Statistics still projects 10% growth for software developers through 2035, while narrow "computer programmer" roles shrink.
  • The skills gaining value are the ones agents can't own: deciding what to build, designing systems, verifying output, and taking responsibility for production.
  • Your best move depends on your career stage. A student, a junior engineer, and a staff engineer face different risks, so this article ends with a separate 90-day plan for each.

Will AI replace software engineers? Not in the way the headlines suggest. In 2026, AI agents write a large and growing share of code, and entry-level hiring has collapsed to historic lows. But employment of experienced engineers is holding up, demand for developers is still projected to grow, and the bottleneck in software has moved from writing code to deciding and verifying what that code should do.

That answer is less dramatic than "software engineering is dead," and less comforting than "nothing has changed." It's also what the data says when you read the primary sources instead of the hot takes. This article goes through those sources: the payroll data, the job postings, the randomized trials, the surveys, and the first large-scale study of what AI agents actually did inside 700 software companies. Then it turns that evidence into a concrete plan, because "it's complicated" is not advice.

Isometric illustration of small automated workers assembling a copper block structure while a human engineer on a platform reviews a blueprint
The job is moving from building every block yourself to directing and inspecting the build.

A note on sources before we start. Every number below links to where it came from. When the source is a company that sells AI tools (Anthropic, GitHub, JetBrains), it's labeled as vendor data. When the evidence conflicts, both sides are shown. That's the only honest way to write about a subject where most of the viral statistics are recycled, misquoted, or a year out of date.

What the 2026 Hiring Data Actually Shows

Start with the most uncomfortable number. According to Indeed Hiring Lab, 69.3% of US software development job postings in Q1 2026 were for senior roles, and just 4.5% were entry-level. That is the most senior-heavy mix of any occupational sector Indeed tracks. Across all US postings, by contrast, roughly 46% are entry-level.

Stacked bar chart: software development postings in Q1 2026 were 69.3% senior, about 26% mid-level and 4.5% entry-level, versus about 14%, 40% and 46% for all US postings
Source: Indeed Hiring Lab, July 2026. Mid-level share for software is derived.

Now the twist that most coverage leaves out. Software postings are not in free fall. Indeed's July 2026 analysis found software development postings up almost 15% since late February 2025, while overall postings fell 7%. Look at who the new postings are for, though: of the growth between May 2025 and May 2026, 71% came from senior roles and 37% from jobs with "AI" in the title. Postings also remain about 27.5% below their pre-pandemic level. The market is recovering, just not at the bottom rung.

Payroll data tells the same story from a different angle. Stanford's Digital Economy Lab, working with ADP payroll records, has tracked what it calls the "canaries in the coal mine": young workers in the occupations most exposed to AI. In its August 2026 update, employment for 22- to 25-year-olds in the most AI-exposed jobs was about 19% below where it would be relative to their peers in less-exposed jobs, up from a 15% gap a year earlier.

Bar chart: from November 2022 to June 2026, employment of workers aged 22 to 25 rose about 10% in the least AI-exposed jobs and fell about 11% in the most AI-exposed jobs
Source: Stanford Digital Economy Lab, "Canaries in the Coal Mine" update, August 2026.

Two details in that update matter more than the headline. First, the gap works mainly through reduced hiring, not layoffs: companies are bringing in fewer young people rather than firing the ones they have. Second, the authors are explicit about what they are not seeing:

"We do not see widespread, economy-wide job displacement associated with AI."

Stanford Digital Economy Lab, August 2026

The official projections point the same way. In August 2026 the Bureau of Labor Statistics published its 2025–2035 outlook, and it still projects employment of software developers to grow about 10%, from roughly 1.72 million to 1.89 million jobs, much faster than the 3% average for all occupations. BLS even names AI as a source of demand, citing "the continued expansion of software development for artificial intelligence." That forecast is a real downgrade, though: the previous cycle projected 15.8% growth. And the narrower category of computer programmers is projected to shrink by about 7%, with BLS pointing to AI automating repetitive programming tasks.

Here's every major data source in one place, with what it actually measures.

SourceWhat it measuresKey findingCaveat
Indeed Hiring Lab (Jul 2026)Job postings by seniority4.5% of software postings entry-level; 69.3% seniorPostings are not hires
Indeed Hiring Lab (Jul 2026)Posting volumeSoftware postings up ~15% since Feb 2025; 71% of May 2025–May 2026 growth was seniorStill ~27.5% below pre-pandemic
Stanford DEL / ADP (Aug 2026)Payroll employment by ageAges 22–25 in AI-exposed jobs 19% below peersCausality disputed by some economists
BLS projections (Aug 2026)10-year employment outlookDevelopers +10% to 2035; programmers about −7%Cut from +15.8% in the prior cycle
Chen & Stratton, Harvard (2026)Engineering activity at 700+ firmsNo significant employment change attributable to AIWorking paper; vendor (Jellyfish) data
Anthropic (Oct 2026)One AI lab's own hiringJunior share of technical hires fell from 27% to 9%Vendor; a single, unusual employer

Read together, the picture is consistent. The job isn't disappearing. The way into it is.

Is Software Engineering Dead? The Door Shrank, the House Didn't

The "software engineering is dead" argument usually rests on three things: layoffs, AI writing code, and how hard it is for new graduates to get hired. All three are real. None of them adds up to a dead profession.

Start with the distinction the BLS draws between "computer programmers" and "software developers." The first is a narrow role, translating specifications into code. The second covers designing, building, and owning software systems. The narrow role has been shrinking for years and AI is accelerating that. The broad role is still projected to grow. If your job was mostly typing out code someone else had already designed, the threat is real. If your job is deciding what the code should be and making sure it works, demand is still there.

Layoffs deserve the same care. Some companies are now explicitly tying cuts to AI. In February 2026, Block laid off about 4,000 people, roughly 40% of its staff, with leadership pointing to AI. That's a genuine data point, and it's why anxiety is rational. But the most rigorous firm-level study so far found something different on average: when researchers at Harvard looked at hundreds of companies before and after they adopted AI coding agents, they "cannot attribute significant employment changes to AI." We'll get to that study in detail below.

The hardest hit group is new graduates. The New York Fed's college labor market data puts unemployment for recent computer science graduates around 7% in its most recent annual figures (2024 data, ages 22–27), among the highest of any major. A degree used to be close to a guarantee of a first job. In 2026 it isn't.

So the honest summary is this: the house is still standing, and the people inside it are, if anything, more valuable. But the front door got much smaller, and that has consequences for everyone, including the seniors, as we'll see.

How the Work Changed: From Writing Code to Directing Agents

To understand where the field is going, it helps to see how fast the tools moved. In 2021, AI meant autocomplete inside your editor. By 2026, it means agents that read your repository, plan a change, edit dozens of files, run your test suite, and open a pull request while you do something else.

Timeline of AI in software engineering from 2015 to 2026, from IDE autocomplete through GitHub Copilot, ChatGPT, Devin, Claude Code and vibe coding to agent-heavy workflows and the 2026 hiring data
Four eras in ten years. The last one arrived fastest.

Adoption followed. JetBrains' 2026 survey of more than 15,000 professional developers (vendor data: JetBrains sells its own AI tools) found that 90% use AI coding agents at work at least weekly and 68% use them daily. Claude Code went from 18% of developers in January 2026 to about 39% by mid-year, and OpenAI's Codex from 3% to 16%. GitHub Copilot, which started the category, fell from 29% to 21%. Stack Overflow's 2026 Developer Survey of more than 30,000 developers found 66% using coding assistants or agents and only 17.2% using no AI at all.

Bar chart of AI coding tool adoption at work, May to July 2026: Claude Code 39%, GitHub Copilot 21%, Codex 16%, Cursor 12%, JetBrains AI about 9%, OpenCode 7%, Google Antigravity 6%
Source: JetBrains, August 2026. Tool categories: terminal agents, AI-native IDEs, IDE assistants, and cloud agents.

The market consolidated around these tools just as quickly. Cursor, one of the most popular AI-native editors, was acquired by SpaceX in August 2026. Windsurf was split between Google, which licensed the technology and hired its leaders, and Cognition, which bought the rest and later folded it into Devin.

Inside the companies building these models, the change is starker still. Anthropic reported in October 2026 (vendor data) that hours worked by its AI agents now outnumber its employees' hours six to one, and that commits per engineer are five times what they were six months earlier. Anthropic is an extreme case, a lab that builds the tools and uses them aggressively, but it shows where the most advanced teams already are.

What does the work look like now? The steps of building software haven't changed much. Who does each step has.

Side-by-side comparison of a traditional workflow where the engineer writes every line and an AI-native workflow where the engineer frames the problem and writes the spec, agents implement and test, and the engineer verifies, reviews and owns the result
In the AI-native workflow, the engineer's time moves to the first two steps and the last two.

Three practices define the new workflow.

Context engineering

Agents are only as good as what they know about your codebase. Teams now maintain context files that describe conventions, architecture, and the commands to build and test, so every agent session starts from the same shared understanding. Writing good context is a skill, and it looks a lot like the documentation engineers always said they would write.

Spec-driven development

The more precisely you describe what you want, including acceptance criteria and edge cases, the less time you spend fixing what you got. Many engineers now write a short spec before any code exists and hand it to an agent. The spec becomes the unit of work, and writing it forces the thinking that used to happen while typing.

Agentic engineering

Simon Willison's guide to agentic engineering patterns defines the practice simply as "building software using coding agents." It's the disciplined counterpart to "vibe coding," the term Andrej Karpathy coined in February 2025 for accepting AI output without really reading it. Vibe coding is fine for a throwaway prototype. Agentic engineering is how professionals ship: running agents in parallel on separate branches, breaking work into reviewable pieces, using CI as the gate, and keeping a human accountable for every merge.

Abstract diagram of one large node branching to several parallel agent nodes whose output passes through a single verification ring before joining a finished structure
Parallel agents, one verification gate.

Which brings us to the most important finding of 2026: the gate is where everything piles up.

The Productivity Question Nobody Has Settled

If AI makes engineers dramatically more productive, companies need fewer of them. If it doesn't, the panic is overblown. So how much faster are engineers with AI? The honest answer is that nobody has measured it convincingly, and the best attempts point in opposite directions.

The most rigorous study is a randomized controlled trial by the research group METR. In early 2025, it gave 16 experienced open-source developers 246 real tasks on their own repositories, randomly allowing or forbidding AI tools. Before starting, the developers predicted AI would make them 24% faster. Afterward, they believed it had made them about 20% faster. In fact, tasks took 19% longer with AI.

Diverging bar chart from METR's 2025 trial: developers expected to be 24% faster with AI and believed they were 20% faster, but were measured 19% slower
Source: METR, July 2025 and February 2026.

That study is now dated; the tools have improved a lot since early 2025. METR ran a larger follow-up and, in February 2026, reported that returning developers now came out roughly 18% faster, with a confidence interval wide enough to include no effect at all. METR itself calls the data "an unreliable signal," partly because so many developers now refuse to take part in a study that requires them to work without AI. It believes developers probably are faster now. It just can't prove by how much.

The most important new evidence comes from the field rather than the lab. In a 2026 working paper, Harvard researchers Fiona Chen and James Stratton analyzed engineering activity data from Jellyfish covering more than 700 software firms and hundreds of thousands of workers from 2021 through March 2026. Using differences in when firms adopted AI coding agents, they measured what changed. As Ars Technica reported, lines of code rose 30%, commits 20%, and pull requests 23%. The rate at which firms resolved Jira issues and epics, the actual features and fixes, did not change in a statistically significant way.

Bar chart from the Harvard study: after AI agent adoption, lines of code rose 30%, pull requests 23% and commits 20%; time from pull request to merge rose 49%, comments per pull request 35%, and resolved issues showed no significant change
Source: Chen & Stratton (Harvard), working paper, 2026, via Ars Technica.

Where did the extra output go? Into review. Time from pull request to merge rose 49%. The share of pull requests needing changes nearly doubled, comments per pull request rose 35%, and the share of engineers doing code review rose 14%. The coding speedup, in the authors' words, was "absorbed by downstream constraints in the production process."

Code got cheap. Confidence that the code is right did not.

That matches what developers themselves report. Stack Overflow's 2026 survey found that only 6.6% of developers trust AI for important decisions, and nearly half trust it only when they can easily verify its work. In the 2025 survey, 66% named "almost right, but not quite" as their biggest frustration with AI code. Google's DORA 2025 report summed up the pattern: AI is an amplifier. Teams with strong practices get better; teams with weak ones get worse, faster.

Illustration of a huge pile of copper blocks pouring into a narrow funnel, with a magnifying lens inspecting blocks as they pass through one at a time
The bottleneck moved from writing to verifying.
EvidenceTypeWhat it says about productivity
METR (2025)Randomized trial, 16 developers19% slower, while believing they were 20% faster
METR (2026)Follow-up, 57 developersProbably faster now, about 18% in raw data, but "unreliable"
Chen & Stratton, Harvard (2026)Field data, 700+ firms30% more code, no significant change in shipped work
Anthropic (2026)One company's own metrics (vendor)5x commits per engineer in six months
DORA (2025)Survey, about 5,000 respondentsOver 80% feel more productive; AI amplifies existing team quality

Notice what the most optimistic numbers measure: commits, lines, and feelings. Notice what the skeptical ones measure: time to finish real tasks and features actually shipped. Until that gap closes, be suspicious of anyone, including yourself, who quotes a productivity multiplier without saying how it was measured.

Tasks AI Does Well vs. Tasks That Still Need You

"Will AI replace engineers?" is the wrong level of analysis. Jobs are bundles of tasks, and AI is very good at some tasks and poor at others. The useful question is which of your tasks fall where.

Three-column matrix of software tasks: AI does well at boilerplate, CRUD, first-draft tests and translation; shared tasks include debugging, specs and security review; humans still own deciding what to build, architecture, verification, production ownership and mentoring
Boundaries move as models improve, but the right-hand column has moved the least.

The left column is work that was always the most mechanical: scaffolding, glue code, straightforward endpoints, first-draft tests, translating code between languages. Agents do it quickly and well enough that reviewing their output beats writing it yourself. If most of your week was this kind of work, your week is changing whether you like it or not.

The middle column is where most engineers now spend their time: AI drafts, a human decides. Debugging is the best example. An agent can propose five plausible causes in seconds, but someone has to confirm which one is real, and an agent that "fixes" the wrong cause can make things worse while making the tests pass. In the Hacker News discussion of the Harvard study, one engineer wrote that for every defect serious enough to need a formal root-cause analysis this year, "AI generated tests asserted that the defective behavior was correct" was a contributing factor.

The right column is where accountability lives. Deciding what not to build. Choosing an architecture you'll live with for five years. Being the person who gets paged at 3 a.m. and understands the system well enough to fix it. None of this is beyond AI in principle, but it requires context, judgment, and responsibility that organizations aren't handing to software, and won't soon, because someone has to answer for the result.

Will AI Replace Junior Developers? An Honest Analysis

This is the question with the most anxiety behind it, and it deserves a straight answer: entry-level software jobs have shrunk dramatically, and AI is a big part of why. The evidence is not seriously in doubt anymore. Indeed's 4.5% entry-level share, Stanford's 19% employment gap for young workers in exposed jobs, and the elevated unemployment of recent CS graduates all point the same way.

Even the companies building the tools show it. At Anthropic, the junior share of technical hires fell from 27% to 9%, according to its own October 2026 report. When the employers most fluent in AI hire fewer juniors, others notice.

But there are real caveats. Some economists disagree. In a guest analysis published by the Economic Innovation Group, Google economists Zanna Iscenko and Fabien Curto Millet argue that the timing doesn't fit AI as the main cause, pointing to interest rates, pandemic over-hiring, and tighter budgets as alternative explanations. Stanford's own data shows the gap persists even outside tech firms and computer occupations, which cuts against a purely tech-cycle explanation, but the debate is far from closed. The likeliest answer is both: a post-pandemic correction and AI arrived at the same time, and AI makes it easier for companies to not reopen junior roles they cut.

Illustration of a ladder crowded with figures at the top whose lowest rungs are missing, with figures on the ground looking up and one person building a new rung from blocks
If nobody hires juniors, where do future seniors come from?

The pipeline paradox

Here's the problem with cutting junior roles: every senior engineer was once a junior. If companies stop hiring and training new engineers because an agent can do entry-level tasks, they're also deciding not to grow the senior engineers they'll need in five years, who are precisely the people who can supervise agents well.

Some leaders are saying this out loud. AWS CEO Matt Garman called replacing junior developers with AI "the dumbest thing I've ever heard," as reported by The Register, arguing that juniors are often the most fluent with AI tools and are the future of any engineering organization. IBM said in February 2026 it plans to triple entry-level hiring in the US, with those roles redesigned around AI rather than eliminated by it.

So the honest answer is: AI is not replacing junior developers wholesale, but it is replacing the tasks junior developers used to learn on. The juniors who get hired in 2026 are expected to start closer to where mid-level engineers used to be. That's harder, but it's a higher bar, not a closed door.

What juniors can do about it

  • Use AI to go faster, but never let it do your learning. Once a week, debug something by hand and review a diff line by line.
  • Own one thing end to end, even if it's small: a service, a tool, a feature with real users. Ownership is the signal employers can't get from a portfolio of generated projects.
  • Get good at reviewing code you didn't write. It's the skill everyone now needs and few juniors practice.
  • Be able to explain every line you submit. Interviewers increasingly test exactly that, as we'll see below.

Why Senior Engineers Are Becoming More Valuable, and When They Aren't

The same data that's grim for juniors is good news for experienced engineers. Senior roles made up 71% of the growth in software postings between May 2025 and May 2026. The work that AI made more abundant, code, is the work seniors are best at checking. The work AI made scarcer, judgment, is what they're paid for.

Addy Osmani, a longtime engineering leader at Google, describes the risk that makes experience so valuable. In "The 80% Problem in Agentic Coding", he explains that writing code and reading code are different skills, and that you can lose the first while keeping the second, up to a point:

"There's a threshold where 'review' becomes 'rubber stamping.'"

Addy Osmani, January 2026

He calls the result comprehension debt, a term he credits to Jeremy Twei: code that works today but that nobody on the team really understands. It accumulates silently and gets paid back during outages. An engineer who can spot that debt before it ships is worth more in 2026 than one who can type twice as fast.

But seniority alone is not protection. Two kinds of experienced engineers are at real risk. The first are those whose value was mostly output: the fast, reliable implementer whose throughput an agent can now approximate. The second are those who refuse to adapt. A staff engineer who dismisses the tools ends up reviewing a workflow they don't understand, and the 2026 hiring market is quietly filtering for people who've made the transition. The safe position is not "senior." It's "senior and fluent."

The Modern Engineer's Skill Stack

If the bottleneck moved from writing to verifying, the skills that matter moved with it. Here's how the stack has shifted.

Infographic of skills rising in value, including verification and code review, system design, specs and context engineering, directing agents, testing strategy, product judgment and security, and skills declining as differentiators, including typing speed, boilerplate, memorized algorithm puzzles, framework trivia and solo heroics
Fundamentals sit underneath everything: you can't verify code you couldn't have written.

A few of these deserve a closer look.

Verification and review. This is now the single most valuable everyday skill. It means reading a large diff quickly, knowing where bugs hide, checking behavior rather than trusting tests, and being willing to reject plausible-looking work. Osmani cites survey data showing only 48% of developers consistently check AI-assisted code before committing it. Being in the half that does is a career advantage.

System design. Agents are good at the parts and weak at the whole. Deciding how services fit together, where data lives, and what happens when something fails is still human work, and it's the work that determines whether a fast team builds something durable or a fast mess.

Specs and context. The engineers getting the most out of agents are the ones who can turn a fuzzy request into precise instructions with clear acceptance criteria. It's the same skill as writing a good ticket, raised to the level of a craft.

Testing strategy. When code is cheap, tests are the specification. Deciding what correct behavior is, before any code exists, is how you keep agents honest.

Notice what's on the declining side: typing speed, boilerplate, framework trivia, and memorized algorithm puzzles. None of these is worthless. They've just stopped being what sets you apart, because an agent can produce a passable version in seconds.

A 90-Day Plan for Every Career Stage

The right response depends on where you are. A computer science student and a staff engineer aren't facing the same risk, so they shouldn't follow the same plan.

Decision framework table showing the biggest risk and highest-leverage 90-day move for students, juniors, mid-level engineers, senior and staff engineers, and managers
The risk changes with seniority, and so does the best response.

Students

  1. Weeks 1–4: Pick one project that solves a real problem for real people, even a small group. Build it with AI tools, and keep a log of every place the AI was wrong.
  2. Weeks 5–8: Rebuild the hardest part of it without AI. Write tests that define correct behavior first. If you can't explain a piece of the code, you don't understand it yet.
  3. Weeks 9–12: Get users, fix what breaks, and write a short post-mortem. That story, what went wrong and how you knew, is worth more in an interview than any number of generated repositories.

Junior engineers (0–2 years)

  1. Weeks 1–4: Volunteer to review pull requests, including AI-generated ones. Ask why for every change you don't understand.
  2. Weeks 5–8: Take ownership of one small system or recurring task: a service, a pipeline, the flaky test suite nobody wants. Become the person who knows how it works.
  3. Weeks 9–12: Keep one hour a week of AI-free practice, such as debugging or a small feature by hand, so your judgment keeps growing alongside your speed.

Mid-level engineers (3–7 years)

  1. Weeks 1–4: Become your team's best reviewer. Track the bugs you catch in AI-generated code and the patterns behind them.
  2. Weeks 5–8: Write the specs and context files for your team's agents. It's the highest-impact work on the team, because it makes every engineer and every agent better.
  3. Weeks 9–12: Take design ownership of a service. Write the design doc, defend the trade-offs, and own its production behavior. That's the step from "produces output" to "makes decisions."

Senior and staff engineers

  1. Weeks 1–4: If you haven't fully adopted agents, do it now. Run them in parallel on a real project until you know their failure modes personally.
  2. Weeks 5–8: Build your team's agent practices: shared context files, review gates for AI-generated pull requests, and checks for the mistakes agents make most often.
  3. Weeks 9–12: Measure what matters. Track review time, change failure rate, and shipped outcomes before and after, so your team's AI story is based on evidence rather than vibes.

Engineering managers

  1. Weeks 1–4: Stop measuring output in lines or commits. The Harvard data shows those can rise while shipped work stays flat. Measure lead time, review time, and outcomes.
  2. Weeks 5–8: Find your review bottleneck. If pull requests are waiting longer, invest in review capacity, smaller changes, and automated checks before adding more agents.
  3. Weeks 9–12: Protect the pipeline. Keep at least one apprenticeship-style path for new engineers, paired with seniors, because the seniors you'll need in 2030 are the juniors you hire now.

For students and anyone job hunting, the plan only pays off if you can show it in an interview, which is the next problem.

How AI Is Changing Tech Interviews

Interviews are where the shift becomes personal, and right now they're a mess. "I would say AI has hit engineering interviewing like an atomic bomb," Stefan Mai, a former Meta and Amazon engineer who cofounded the coaching service Hello Interview, told CNN in May 2026. Companies agree that the old format no longer measures the job. They don't agree on what should replace it.

Some companies now expect you to use AI in the interview. Canva announced in 2025 that "we now expect Backend, Machine Learning and Frontend engineering candidates to use AI tools," and evaluates how well candidates guide the tools and fix what they produce. Meta, according to candidates and interview-prep firms such as interviewing.io, has introduced an AI-assisted coding round in which interviewers probe whether you can verify and explain code the assistant wrote.

Others forbid it entirely. Anthropic's guidance to candidates for live interviews and take-home work is blunt: "no AI assistance unless we indicate otherwise." So the first rule of interviewing in 2026 is to ask, for every round, which format you're in.

Either way, the skills being tested converge on the ones in this article. In an AI-allowed round, you're judged on how you frame the problem, how critically you review the output, and whether you can explain and defend the final code. In an AI-free round, you're showing the fundamentals that make that judgment possible. Both reward the same preparation: understanding, not memorization.

This is also where most candidates lose offers, and not on the code. Communicating your reasoning, describing your past work clearly, and handling behavioral questions honestly matter more when everyone has access to the same coding assistant. StackChief's interview prep hub collects our guides, and the interview readiness checklist covers the week before an interview step by step. If you're preparing for a role in a specific stack, our Java HashMap interview questions are a good place to practice explaining, not just answering.

The Next 2–5 Years: What's Consensus and What's a Bet

Forecasts about AI have a poor track record, including from the people building it. Speaking at the Council on Foreign Relations in March 2025, Anthropic CEO Dario Amodei predicted that within three to six months AI would be writing 90% of the code. Whether that came true depends entirely on how you count, which is the point. So instead of one more prediction, here's a map of where the evidence agrees and where it doesn't.

Two-column graphic listing consensus forecasts, such as agents becoming the default and review becoming the bottleneck, and contested questions, such as the true productivity gain and whether AI caused the junior hiring slump
Plan around the left column. Hedge against the right.

On the consensus side: agents are the default way to write code; review and verification are the bottleneck; entry-level hiring will stay tight; AI amplifies the quality of the team that uses it; and the narrow programmer role shrinks while the broader developer role keeps growing. Several independent sources support each of these. Plan as if they're true.

On the contested side, smart people with good data disagree. The size of the productivity gain is unresolved, with Anthropic's internal numbers and Harvard's field data pointing in different directions. Whether cheaper code means more software engineers, as cheaper computing once did, or fewer, as Block bet, is open. Capability keeps compounding: METR's measurements show the length of tasks AI can complete doubling about every 131 days since 2023. And even the question of whether software engineering stays a lifetime career is live; a Hacker News discussion of exactly that drew nearly 500 points and more than 760 comments, with experienced engineers on both sides.

The practical conclusion is to bet on the consensus and stay flexible on the rest. Build the skills that are valuable under every scenario on the right-hand side: judgment, verification, system design, communication, and ownership. They're the skills that pay off whether AI gets twice as capable or stalls where it is.

Software engineering in 2026 isn't ending. It's becoming a profession of people who decide what should be built and make sure it's right, with machines doing more of the typing. That's a harder job to get into than it used to be, and a more interesting one to do.

FAQ

Will AI replace software engineers in 5 years?

Unlikely, based on current evidence. The BLS still projects 10% growth for software developers through 2035, and the largest field study so far found no significant employment change at firms that adopted AI coding agents. What will change is the work: more specifying, reviewing, and owning systems, and less writing routine code.

Is software engineering still a good career in 2026?

Yes, but it's harder to enter. Experienced engineers remain in demand, and senior roles drove most of the recent growth in job postings. New graduates face the toughest market in years, with only 4.5% of software postings aimed at entry level, so they need stronger evidence of real skills to get hired.

Should I still learn to code?

Yes. You can't direct, review, or debug code you don't understand, and those are now the most valuable parts of the job. Learn the fundamentals deeply, use AI tools to go faster, and practice regularly without them so your judgment keeps developing.

Which software jobs are most at risk from AI?

Roles built mostly on routine implementation are most exposed: translating finished specifications into code, boilerplate-heavy work, and entry-level tasks. BLS projects computer programmer jobs to shrink by about 7% through 2035, while broader software developer roles grow.

What skills should software engineers learn for the AI era?

Focus on verification and code review, system design, writing precise specs and context for agents, testing strategy, and product judgment. Strong communication matters more too, both on the job and in interviews where everyone has the same AI tools.

Further Reading

Written by Sam Erickson

Software engineer. I write every article on StackChief myself. Author of Mastering the Tech Interview. More about me