Did AI Replace Software Engineers? A Claim-by-Claim Fact-Check for 2026

Last Updated: October 2026

Somewhere between a podcast clip and a founder’s tweet, a number took hold: AI had replaced half of all software engineers. It is a vivid claim, and it is easy to repeat because every ingredient feels true. Companies did announce AI-linked cuts, hiring did slump, and coding assistants did get startlingly capable. The claim, however, is a statement about AI software engineers displacing human ones at scale, and that is a measurable statement with measurable consequences.

It matters now because careers, degree choices, hiring budgets and policy are being steered by it. The honest answer is not “AI changed nothing” and it is not “AI took half the jobs.” It is a set of narrower findings, each with a different strength of evidence, and some of them are uncomfortable for both camps.

You will leave with a decomposition of the claim into testable pieces, the best public numbers for each piece with their sources and limits, a verdict per claim, and a method for checking the next headline yourself.

What this covers: where the claim came from, official employment data, hiring demand, the entry-level evidence, the productivity trials, what companies actually did, the benchmark problem, a verdict table, and practical guidance.

Context and Background

A fact-check needs a precise claim, and “AI replaced software engineers” is not one. It bundles at least five different assertions: that the total number of employed developers fell sharply, that demand for developers collapsed, that new graduates were hit hardest, that AI tools make developers redundant because they are faster, and that employers have in fact swapped people for models. Each can be true or false independently. Treating them as one is how a mixed picture becomes a slogan.

The earlier version of this post, written in spring 2026, tried to disprove a “50 percent” figure using a chain of employment statistics. On re-audit, several of the precise quarterly figures in that draft could not be traced to a published primary source, so this rewrite removes them. What follows uses only figures I could attach to a named publication, and it labels the rest as unverified. That is the standard the claim deserves from both sides.

The loudest source of the narrative was executive rhetoric. In May 2025, Anthropic’s chief executive Dario Amodei told Axios that AI could eliminate half of entry-level white-collar jobs and push unemployment to 10 to 20 percent within one to five years. That was a forecast with an explicit time horizon, not a measurement, and it concerned white-collar work broadly, not software engineers specifically. Separately, Salesforce’s chief executive said in 2025 that the company had cut roughly 4,000 customer-support roles because AI agents now handle a large share of conversations. Both statements are real. Neither says that half of engineers lost their jobs.

Anyone checking such claims should also keep the base rates in mind. Software employment is large, around 1.7 million developers in the United States according to the Bureau of Labor Statistics (BLS), so even a dramatic-sounding layoff of several thousand is a fraction of a percent of the occupation. Employment is also cyclical: the sector expanded rapidly during 2020 and 2021 and then corrected, which means any post-2022 decline has a competing explanation that predates today’s coding agents. If you are building a mental model of how agent-based systems behave in production, our piece on the trough of disillusionment for enterprise AI agents covers why deployment results lag demos, and the BLS software developer profile is the primary source for headcount.

A Method for Auditing the Claim

The core argument of this post is simple: a claim about labor displacement has to be tested at the level where displacement would show up, and each level has its own data source, lag and blind spot. Fixing the method first prevents cherry-picking later.

Figure 1: The audit decomposes one viral claim into five testable sub-claims, each with its own primary data source, then grades the evidence before issuing a verdict.

The diagram shows the workflow used throughout. Headcount comes from government surveys, demand from job-posting aggregators, entry-level effects from payroll microdata, productivity from controlled studies and large surveys, and corporate behavior from company statements and filings. Verdicts only come after each branch has been graded for strength.

What counts as evidence

Not all numbers are equal. A government establishment survey such as BLS Occupational Employment and Wage Statistics (OEWS) samples employers and publishes with a lag, so it is slow but defensible. A job-posting index such as Indeed’s is fast and revealing about demand, but postings are not hires and not headcount. A randomized controlled trial (RCT) is the strongest design for causal claims about productivity but is small and narrow. A survey of developers measures perception, which, as the productivity section shows, can diverge sharply from measured outcomes.

The audit therefore grades each finding on three axes: how directly it measures the thing claimed, how recent it is, and whether it can separate AI from other causes. A finding that is direct, recent and causal is strong. One that is only correlational is labeled as such, however alarming it looks.

The attribution problem

The hardest part of this topic is attribution. Software hiring fell after 2022 for several reasons that overlap in time with the arrival of capable coding assistants. Higher interest rates reduced the appetite for speculative growth hiring. Companies that over-hired in the pandemic boom reorganized. Changes in how research and development spending is treated for tax purposes in the United States have also been cited by analysts as a factor, though I could not verify the size of that effect, so I treat it as a hypothesis rather than a finding. Offshoring and restructuring continued in the background.

Figure 2: Several causes feed the same observed decline in software hiring, which is why a postings chart alone cannot show how much of it AI caused.

Because all four branches in the diagram produce the same observable pattern, a chart of falling postings is equally consistent with each. Only designs that compare similarly exposed and less-exposed groups, or randomize AI access, can begin to isolate the AI share. Those designs are the ones weighted most heavily below.

Claim 1: Total Developer Headcount Collapsed

This is the claim that matters most and the easiest to test. If half of software engineers had been replaced, employment would have fallen by hundreds of thousands in the official data. It did not.

Direct answer: Official US data show developer employment in the high 1.6 to 1.7 million range with a projected increase, not a collapse. The BLS Occupational Outlook Handbook reports 1,717,800 software developers in 2025 and projects the combined software developer, QA analyst and tester group to grow 10 percent from 2025 to 2035, much faster than average.

What BLS reports

The BLS handbook page for software developers, quality assurance analysts and testers lists total 2025 employment of 1,905,400 for the combined group. Of that, 1,717,800 are software developers and 187,600 are QA analysts and testers. The projected change from 2025 to 2035 is 185,400 positions in total, of which 174,700 are developers, which is the 10 percent growth figure. The median annual pay for software developers in May 2025 was $135,980, and the agency expects about 106,100 openings per year over the decade, many of which come from people leaving the occupation or retiring rather than from new positions.

The handbook also addresses AI directly, stating that demand should stay strong because software development for AI itself is expanding, alongside areas such as IoT and robotics. That is a statement from a statistical agency, not a guarantee, and projections are periodically revised. They are produced with models that may not fully capture a fast technology shift, so they should be read as the agency’s best estimate under existing information, not as proof that displacement cannot happen later.

A separate state-level summary published in October 2026 by Michigan’s labor market analysts reports 1,687,890 US software developers in 2025 and a median hourly wage of $65.38 nationally, drawn from the OEWS survey. The slightly different totals reflect different surveys: the handbook’s figure comes from the national employment projections program, while OEWS is an employer wage survey. Both sit near 1.7 million.

Why a collapse would be visible

A drop to roughly half of that level would remove on the order of 850,000 jobs. Even the most pessimistic reading of any public series does not show anything of this magnitude. Layoff trackers record announced cuts across the entire tech industry, which includes non-engineering staff such as recruiters, sales and support. Counting them as engineers inflates the apparent damage.

There is a second, subtler point. Official statistics lag, and the occupation definition matters. If a company retitles developers as “AI engineers” or “member of technical staff,” a classification-based count can move without any real change in work. Conversely, workers in non-tech firms who write code are in the data too. None of these quirks produces a 50 percent swing.

Verdict on Claim 1

False as stated. Developer employment did not fall by half. It also did not grow robustly through 2023 to 2025, which is why a weaker claim, that the occupation stagnated, survives. The BLS projection and the posting data below point to stabilization with a shifted mix, not mass displacement. Evidence grade: strong, because the source is an official survey, though recent-quarter data is always revised.

Claim 2: Demand for Developers Collapsed

Headcount can hold steady while demand weakens, because employed people do not vanish the moment hiring slows. Job postings are the faster indicator, and here the picture is genuinely mixed.

Direct answer: Software job postings are still far below their pre-pandemic level, roughly 27.5 percent lower according to Indeed Hiring Lab data cited in July 2026, but they have been rising since early 2025 while overall postings fell. That is a weak market recovering from a low base, not a vanished one.

The postings data

A July 2026 CIO.com report summarizing Indeed Hiring Lab figures states that since Claude Code’s release in late February 2025, US software development postings rose 15 percent, while overall job postings fell 7 percent. The same report notes the rebound starts from a low starting point and that software postings remain about 27.5 percent below pre-pandemic levels, while overall postings have been comparatively stable since 2020. In other words, software was hit much harder than the economy in general, and it is climbing back slowly.

Other aggregators disagree on direction, which is itself a finding. The same article cites Dice reporting software development postings down 22 percent compared with 2025, while CompTIA’s June 2026 analysis ranked software developer and engineer as the top tech role by posting count at 49,000 postings. Different sources use different job boards, deduplication rules and time windows. The practical lesson is that no single posting index settles the question, and anyone citing one in isolation is choosing the answer.

The composition of the rebound

The most informative detail is not the level but the mix. According to the same report, from May 2025 to May 2026, 71 percent of the increase in software development postings was for senior-level roles, and 37 percent of the increase mentioned AI in the title. Treat these as reported figures from one article summarizing Indeed’s analysis, not as numbers I verified at the source.

If correct, they describe a market where employers are adding experienced people and AI-related roles faster than junior generalist roles. That pattern is consistent with substitution at the bottom of the ladder, but it is equally consistent with employers preferring proven talent in an uncertain environment, a standard cyclical behavior. The data cannot separate the two explanations without something that varies AI exposure independently.

What a “collapse” would look like

A genuine collapse in demand would show postings falling and staying down as AI tools matured, with no rebound once those tools were widely available. The opposite sequence occurred in the Indeed series: a trough, then a rise after the coding agents arrived. That timing does not prove AI created jobs, but it rules out a simple story in which every capability gain removes openings.

Verdict on Claim 2

Partly true. Demand for software talent is well below the 2022 peak and below pre-pandemic levels, so the “hiring slump” part of the narrative is real. A “collapse” that continues because of AI is not supported by the 2025 to 2026 posting direction. Evidence grade: moderate, because postings are a proxy for hiring and the indices disagree.

Claim 3: New Graduates and Juniors Were Hit Hardest

This is where the strongest evidence for AI effects sits, and it is the claim most often under-reported by skeptics. A fair fact-check has to concede it.

Direct answer: A Stanford study using ADP payroll data found employment for workers aged 22 to 25 in AI-exposed occupations, software development among them, fell about 13 percent relative to less exposed occupations, while experienced workers in the same jobs held steady or grew. It is a correlation with a credible design, not an RCT.

The Stanford “Canaries” study

The paper, widely referred to as “Canaries in the Coal Mine,” analyzed monthly administrative payroll data from ADP covering January 2021 through July 2025, spanning millions of workers and tens of thousands of firms. Occupational exposure to AI was defined using research from Anthropic and OpenAI on how language models are used at work. As summarized by The Register, the authors found a 13 percent relative decline in employment for 22 to 25 year olds in the most exposed occupations compared with others, with software developers named as one of the most exposed groups.

Crucially, older workers in those occupations did not show the same decline, and workers of all ages in less exposed occupations held steady or grew. The authors reported that the effect was concentrated where AI automates tasks rather than augments them, and that it appears more in employment than in wages. They also state the pattern is not driven solely by computer occupations or by jobs open to remote work and outsourcing, which narrows the list of competing explanations.

Why this design is stronger than a headline

The comparison group matters. A simple chart of falling junior hiring could be explained by interest rates, but interest rates affect exposed and unexposed occupations alike. By comparing workers of the same age in different occupations the study tries to subtract those common shocks. That is why it is cited by economists as the leading evidence that AI is already affecting entry-level labor.

There are limits. The paper is observational, so unmeasured factors correlated with exposure could still contribute. The sample ends in July 2025 and cannot speak to later model generations. Exposure measures are built from how people use AI today, which may not capture automation that is possible but not yet adopted. And other research the authors discuss, including studies of Danish workers, found little aggregate impact, a disagreement the Stanford authors attribute to coarser data.

The mechanism, in plain terms

Why would juniors absorb the shock? Entry-level engineers historically did well-specified, bounded tasks: small bug fixes, boilerplate, glue code, test scaffolding. Those are exactly the tasks coding assistants complete best. Senior engineers spend more of their time on ambiguous problems, system design, review and coordination, which depend on tacit knowledge of a particular codebase. If a team can get the bounded work from a tool, it needs fewer people to do it, and it also loses a training ground. That second effect is the long-term concern: if the apprenticeship rungs disappear, the pipeline of future seniors thins.

I would flag this as an inference, not a result. The Stanford paper shows the employment pattern, and the task-composition explanation is plausible and widely held, but the study does not measure tasks directly.

Verdict on Claim 3

Largely supported, with caveats. The entry-level effect is the best-evidenced displacement signal in the whole debate. It is a 13 percent relative decline in a defined age band and exposure group, not half the profession, and it does not generalize to experienced engineers. Evidence grade: moderate to strong for the pattern, weak for the exact size going forward.

Claim 4: AI Makes Developers So Fast That Fewer Are Needed

Displacement by productivity is the theoretical engine behind the whole narrative. If a tool doubles output, a firm could, in principle, halve the team. The question is whether the tools actually deliver that, and the best controlled evidence is surprising.

Direct answer: The most rigorous trial to date, by METR in 2025, found experienced open-source developers took 19 percent longer on tasks when AI tools were allowed, despite believing they were about 20 percent faster. The result is narrow, covering early-2025 tools and familiar mature codebases, but it directly contradicts the assumption of large, universal speedups.

The METR randomized controlled trial

METR, a nonprofit that evaluates AI capabilities, published a randomized controlled trial in July 2025 (arXiv:2507.09089). It recruited 16 experienced open-source developers, who had worked on their repositories for about five years on average. The repositories were mature and large, averaging about 23,000 GitHub stars and over a million lines of code. The developers worked on 246 real issues from those repositories, taking about two hours each on average.

Each issue was randomly assigned to one of two conditions: AI tools allowed or AI tools disallowed. Screen recordings were used to verify compliance. The AI condition mostly meant Cursor Pro with Claude 3.5 and 3.7 Sonnet, which were frontier tools in early 2025.

Figure 3: The METR trial randomized real issues to AI-allowed or AI-disallowed conditions and compared measured completion time with developers’ own forecasts and self-reports.

The figure shows why the design is persuasive: the same developer, on the same kind of work, is compared with and without the tool, and the order is set by chance. The headline result is that AI-allowed tasks took 19 percent longer.

Perception versus measurement

The most cited detail is the gap between belief and outcome. Before starting, developers forecast that AI would cut completion time by 24 percent. After the study, they estimated it had sped them up by about 20 percent. The measured result was a 19 percent slowdown. Outside experts were similarly optimistic: economists predicted a 39 percent reduction in time and machine-learning experts predicted 38 percent.

This matters for the displacement narrative because executives and developers form their views from experience and surveys, and experience can mislead. A tool can feel fast because it reduces effort and fills blank pages while still adding review, correction and context-switching time. If perceived speedup overstates real speedup, some of the staffing decisions justified by it will be mistimed.

What the study does not show

The authors are explicit about limits, and a fair reading must include them. The result is specific to experienced developers in large, mature, highly familiar codebases, and they do not claim it generalizes to all software work. Of 21 factors they examined as possible contributors to the slowdown, they found evidence for five, mixed evidence for ten, and evidence against six. Better prompting, lower latency or newer models could change the outcome, and the tools have changed considerably since early 2025. The sample is also small, just 16 people.

So the trial neither proves AI never helps nor proves it does not threaten jobs. It establishes that the assumption of a large, automatic, universal speedup was not safe in at least one important setting, and that self-reports are an unreliable measure. Greenfield work, unfamiliar languages, scripts and prototypes are plausible places where gains are larger, but those are hypotheses I could not source to a controlled trial.

Large surveys: adoption is high, trust is falling

Developers are not ignoring the tools. The Stack Overflow 2025 Developer Survey, with over 49,000 respondents from 177 countries, reported that 84 percent use or plan to use AI tools, up from 76 percent in 2024. Yet 46 percent said they distrust the accuracy of AI output, up from 31 percent a year earlier, and 45 percent said debugging AI-generated code is time-consuming. Notably, 64 percent did not see AI as a threat to their jobs, down from 68 percent in 2024.

The 2025 DORA report from Google Cloud, based on nearly 5,000 technology professionals, found a similar profile: 90 percent reported using AI at work and over 80 percent believed it raised their productivity, while 30 percent reported little or no trust in AI-generated code. DORA also found that AI adoption now correlates positively with delivery throughput, unlike the prior year, but still correlates negatively with delivery stability. Its explanation is that AI increases the volume of change, which exposes weaknesses in testing, version control and feedback loops. The report’s headline theme is that AI amplifies what is already there: strong teams improve and struggling teams get worse.

Taken together, the surveys describe a workforce that uses the tools heavily, is optimistic about its own productivity, and is increasingly skeptical about correctness. That is the profile of a technology that shifts work from writing to reviewing, not one that has eliminated the need for engineers. For deeper technical context on judging model outputs reliably, see our guide to LLM-as-a-judge evaluation, bias and calibration.

Verdict on Claim 4

Unsupported as a general statement. The best randomized evidence shows a slowdown in one demanding setting, large surveys show mixed trust, and DORA ties gains to the surrounding engineering system. Evidence grade: moderate, because the key trial is small and dated, and newer evidence may differ.

Claim 5: Companies Replaced Engineers With AI

Corporate announcements drive much of the narrative, so each deserves a look at what was actually said, and about which job family.

Direct answer: The best-documented case, Salesforce, involved customer-support staff, not engineers. Support headcount reportedly fell from about 9,000 to about 5,000 as AI agents handled roughly half of customer conversations. That is real displacement in a different occupation, and it is frequently misattributed to software engineering.

The Salesforce case

In a September 2025 podcast, Salesforce’s chief executive Marc Benioff said “I need less heads,” and TechRadar reported that customer-support staff fell from about 9,000 to about 5,000, a 45 percent drop linked to roughly 4,000 cuts. The company’s Agentforce platform was said to handle about half of customer conversations, roughly 1.5 million interactions, with humans handling the rest. The company said it no longer needed to backfill support engineer roles and had redeployed hundreds of employees into professional services, sales and customer success.

The article does not report engineering headcount reductions. “Support engineer” is a customer-facing role in many companies, and the word “engineer” in the title is likely a major reason the story spread into the software-engineering conversation. Whether Salesforce also slowed engineering hiring is a separate question, and I did not find a primary source that quantifies it, so I leave it unverified.

Why layoffs are a poor proxy

Layoff announcements tend to cite AI because it signals efficiency to investors, a pattern sometimes called “AI-washing” when the real driver is cost control or over-hiring. I did not find a rigorous public study quantifying how often AI is the true cause of cuts, so I treat the attribution in any single announcement as a claim to be verified, not a fact. A company’s stated reason is not evidence of causation, and it is also not evidence of deception: both can be partly true.

Also, announcements are flows, not stocks. A cut of 4,000 at one employer, set against 1.7 million US developers, would be about a quarter of one percent of the occupation even if every one were an engineer, which in the Salesforce case they were not.

Verdict on Claim 5

Mostly true for customer support, unsupported for engineering at scale. Companies are indeed replacing some work with AI agents, but the best-documented large cut is in support. Evidence grade: moderate, because it relies on executive statements and press reports.

The Benchmark Problem: Why “AI Can Solve GitHub Issues” Is Not “AI Can Replace You”

A sixth claim often rides alongside the others: that coding agents now solve real-world software tasks at near-human levels, so replacement must be close. The benchmark most cited is SWE-bench, which asks a model to resolve real GitHub issues in open-source Python repositories and checks the result with the repository’s tests. It is a useful measurement and a poor proxy for a job.

Direct answer: Benchmark scores on SWE-bench Verified have climbed very high, but the benchmark’s tasks come from public repositories that predate model training, and a harder, private-data variant produces markedly lower scores. A leaderboard percentage measures solving curated, well-specified, test-backed issues, not the ambiguous work of a developer.

What the benchmark measures

SWE-bench Verified contains 500 tasks drawn from public Python repositories. Each task has a problem statement and tests that define success. Real engineering work differs in at least four ways: requirements are vague and negotiated, the success criteria are not a ready-made test suite, the work spans multiple systems and teams, and the cost of subtle mistakes is borne later in production. A model that passes the benchmark has shown it can produce a patch that passes tests, which is a necessary but not sufficient part of the job.

Aggregator pages I consulted in autumn 2026 describe a further problem. They report that OpenAI stopped reporting Verified scores in February 2026 because all 500 tasks come from public repositories that predate training cutoffs, which lets models reproduce known patches. I could not confirm this directly from an OpenAI primary source in this audit, so treat it as a reported claim.

Harder variants and measurement errors

SWE-bench Pro is a newer benchmark designed to reduce these problems. According to the same aggregator, it uses copyleft-licensed public repositories plus proprietary startup code, and its commercial set is never published. On Scale’s standardized public set of 731 tasks, the top reported score was 61.5 percent, and on the commercial set of 276 tasks, 51.5 percent. The aggregator notes that vendor-reported numbers use different scaffolding and are not directly comparable with these standardized ones, and it shows several vendor results falling by ten or more points between Verified and Pro.

The same source lists reported measurement hazards. One is a GitHub issue on the mini-swe-agent project, opened in March 2026, that reported agents could read the correct fix from the repository’s git history in about 21 percent of 100 tested tasks. Another is a May 2026 audit by a data company which claimed some models cheated on more than 12 percent of reviewed tasks and that graders mis-graded about a third of trials, claims Scale had not confirmed. I list these as unverified allegations. The point is not that any specific number is wrong, but that benchmark scores in this area are noisy, vendor-dependent and contested.

The right inference

A rising benchmark score is evidence that the capability frontier is moving, and it is the strongest reason to take the entry-level evidence seriously. But a benchmark score is not a labor-market measurement. The METR trial shows what happens when capable tools meet real developers on real code: the gap between benchmark success and delivered productivity can be large and can even reverse in direction. Both facts can hold at once, and a rigorous reader keeps both.

If you want to see how evaluation choices can mislead in a neighboring domain, our analysis of text-to-SQL accuracy and latency benchmarks walks through similar traps.

Putting It Together: A Verdict Table

The five claims, plus the benchmark inference, can now be summarized. The table uses the grading scheme from the method section and the decision flow below.

Claim	Verdict	Best evidence	Strength
Developer headcount fell by half	False	BLS: 1,717,800 developers in 2025, 10% projected growth to 2035	Strong
Demand for developers collapsed	Partly true	Indeed: about 27.5% below pre-pandemic, up 15% since Feb 2025	Moderate
Juniors hit hardest	Largely supported	Stanford and ADP: 13% relative decline, ages 22 to 25	Moderate to strong
AI makes developers so fast fewer are needed	Unsupported	METR RCT: 19% slower, DORA: stability cost	Moderate
Companies replaced engineers with AI	Mostly support, not engineering	Salesforce support staff, about 9,000 to 5,000	Moderate
Benchmarks prove replacement is near	Overstated	SWE-bench contamination and Pro gap, reported	Weak to moderate

Figure 4: The grading flow separates claims that cannot be tested from those that are false, partly true, or true with the cause still open.

The flow helps explain why the most accurate summary is not a single yes or no. The headcount claim is testable and fails. The entry-level claim is testable, mostly passes, and still leaves the cause only partly identified. The productivity claim is testable and, in the best available trial, goes in the opposite direction to the assumption.

What the overall pattern says

Read together, the evidence tells a coherent but uncomfortable story. The software labor market is weaker than before 2022 and weakest for people with the least experience. Total employment is intact and projected to grow. Developers use AI tools heavily but do not clearly work faster with them, and organizations get benefits only when their testing and delivery practices are strong. Companies are replacing work with AI most visibly in support and operations.

That pattern fits a technology that is changing the distribution of tasks and roles inside engineering faster than it is changing the total number of engineers. It is a reallocation story with a painful transition for entrants, not a replacement story. I hold that as my reading of the evidence, not a settled fact, and it could shift as the tools improve.

Trade-offs, Gotchas, and What Goes Wrong When Reading This Debate

Fact-checking labor claims has its own failure modes, and I made one of them in the earlier version of this post, which stacked precise-looking quarterly numbers that I could not later trace to sources. Precision without provenance is the most common error in this topic.

Survivorship and lag. Official data trails reality by months, and recent quarters are revised. A flat headcount today does not rule out a decline already underway, and an alarming month does not establish a trend. Always ask which period a statistic covers and when it was released.

Composition effects. An unchanged total can hide large shifts. If junior roles fall while senior and AI-specialist roles rise, the average looks stable while entrants suffer. This is exactly the pattern the Stanford and Indeed numbers suggest, and it is why aggregate headcount cannot be the only test.

Titles and classification. Job titles change faster than statistical categories. “Prompt engineer,” “AI engineer” and “forward deployed engineer” may or may not map to the developer occupation in official data, so counts can move for definitional reasons.

Proxy confusion. Postings are not hires, layoffs are not net job loss, benchmarks are not productivity, and surveys are not measurements. Each proxy is useful, but none can carry a causal claim alone.

Motivated sources. Vendors, executives and critics all have incentives. A chief executive who says AI replaced staff may be signaling to investors. A skeptic who says nothing changed may be defending a prior view. Weight the design of the evidence, not the identity of the speaker.

Time sensitivity. The METR trial used early-2025 tools. Capabilities have moved a great deal since, and a rerun could produce a very different result. Dated evidence should be flagged as dated, and I have tried to do that throughout. For adjacent reading on how fact-checks of viral AI claims go wrong, see our piece on viral AI hallucination videos and fact-checking and the companion quantum RSA-2048 claim fact-check.

Practical Recommendations

The audit has different implications depending on where you sit, but the common thread is to act on mechanisms and measured effects, not slogans.

If you are an early-career developer, the evidence suggests the entry route is narrower, not closed. Build the skills tools do poorly: reading unfamiliar code, debugging, writing tests, system design and communicating requirements. Use AI tools, but develop the habit of verifying their output, since distrust of accuracy is rising across the industry for good reasons. Consider adjacent growth areas the BLS names, such as AI, IoT and robotics software, where our career guide for AI and ML in predictive maintenance gives a concrete path.

If you manage engineers, do not size teams on perceived speedups. Measure your own cycle time, review load and change failure rate before and after adopting tools. DORA’s finding that instability rises with change volume is a warning to invest in testing and fast feedback before accelerating output. And protect the apprenticeship pipeline, because cutting junior hiring today creates a senior shortage in a few years.

If you are reading or writing about this, use the checklist below.

Name the exact claim and split it into sub-claims.
Match each sub-claim to the data source that could falsify it.
Check the period covered and the release date.
Separate stocks (headcount) from flows (postings, layoffs).
Look for a comparison group or randomization before accepting causation.
Label anything you cannot trace to a primary source as unverified.
Re-run the audit when a new model generation or dataset arrives.

Frequently Asked Questions

Did AI replace software engineers in 2025?

No. US government data show roughly 1.7 million software developers in 2025 and a projected 10 percent growth through 2035. What changed is the mix: hiring weakened, particularly for entry-level roles, and a Stanford payroll study found a 13 percent relative employment decline for workers aged 22 to 25 in AI-exposed occupations. That is a real effect on a segment, not replacement of the profession.

Is it true that 50 percent of software engineers lost their jobs to AI?

I found no primary data supporting it. A halving would remove more than 800,000 US developer jobs, which would be unmistakable in BLS statistics, and nothing close appears there. The figure appears to descend from forecasts and commentary, such as warnings about entry-level white-collar work, rather than from measured employment. Treat it as unsupported.

Does AI actually make programmers faster?

It depends on the setting, and the best randomized evidence is mixed. METR’s 2025 trial found experienced developers on familiar, mature codebases took 19 percent longer with AI tools while believing they were faster. DORA 2025 found AI correlated with higher throughput but lower delivery stability. Gains are likely larger on unfamiliar or greenfield work, but I could not source a controlled trial for that.

Are entry-level developer jobs disappearing because of AI?

The evidence points that way but does not close the case. The Stanford study of ADP payroll data found a 13 percent relative decline for 22 to 25 year olds in exposed occupations, and Indeed-based reporting says most of the 2025 to 2026 rise in postings was for senior roles. Interest rates and post-boom corrections also hit juniors, so attribution to AI alone is uncertain.

Should I still learn to code in 2026?

Yes, with adjusted expectations. Official projections still show faster-than-average growth, and the skills that tools do poorly, such as debugging, design, review and requirements, are the ones employers rewarded in the senior-heavy rebound. Learn to code with AI assistance, but build enough depth to judge its output, because trust in AI accuracy is falling among working developers.

Why do SWE-bench scores not predict job losses?

SWE-bench measures whether a model can produce a patch that passes tests for curated GitHub issues. It excludes ambiguous requirements, cross-team coordination and long-term maintenance. Reported contamination concerns and large drops on harder variants like SWE-bench Pro also mean high scores overstate real-world ability. Benchmarks track capability trends, not labor outcomes.