Why AI Hasn't Replaced Software Engineers, and Never Will

Shen Translation is a translation team under 36Kr, focusing on technology, business, workplace, life and other fields, with an emphasis on introducing new foreign technologies, perspectives, and trends.

Editor's Note: Are AI-driven layoffs just a "fantasy facade" for executives? This article breaks down the "sandwich model" of knowledge work to reveal the underlying irreplaceable truths of software engineers. It is translated from an original piece.

Anxiety and uncertainty about AI replacing jobs are spreading widely. How can we move past vague warnings and exaggerated predictions to examine this issue with objective data? An excellent approach is to look at the industry at the cutting edge of AI capability development, where adoption has exploded at an extraordinary pace: software engineering.

In this article, we present substantial evidence to refute the narrative that AI will trigger mass layoffs once it reaches a critical capability threshold. Given that this dynamic holds even in the software industry, which has virtually no regulatory barriers, most other sectors are likely to have far stronger buffers protecting their workforces.

We also have a clear understanding of the root causes behind this phenomenon. Many knowledge-intensive jobs, including software development, can be viewed as a "Decide-Execute-Deliver Sandwich". AI has compressed the middle "Execute" layer of this sandwich, but the two outer layers remain highly resistant to automation—something that cannot be overcome by technological advancement alone.

We maintain a cautiously optimistic stance on the future demand for software engineering talent. This is the first article in our series. The next installment will explore why individual software engineers may still face career turbulence even as overall industry demand remains robust. This series draws on published research in economics and software engineering, our hands-on evaluations and observations of AI agents, and reflections from numerous software engineers on the current and future impact of AI on their field—both from publicly published articles and our direct interactions with the community.

Stories of AI causing mass layoffs in the software industry appear to be a textbook case of "AI washing"

Consider these three headline-grabbing news stories, and their stark contrast with harsh reality:

1. In February this year, fintech company Block (developer of apps including Cash App, Square, and Afterpay) announced 4,000 layoffs. According to its founder Jack Dorsey, AI has "enabled entirely new ways of working" that allow for "smaller, flatter teams", with specific references to projected model capability leaps in late 2025.

Subsequent follow-up reports revealed a far different reality. After tripling its headcount during the pandemic, the company was under severe financial strain. Naoko Takeda, a data scientist on the Cash App team, wrote that Block "force-fed AI to everyone", but she observed "extremely limited productivity gains". She rejected a 75% retention bonus and left the company. Other interviewed employees expressed sharply conflicting views on AI's actual capabilities at Block, and Dorsey's personal understanding of these technical matters.

As Aaron Levie pointed out, CEOs are uniquely prone to hallucinations about AI's practical utility, because they can quickly build prototypes while remaining blind to the remaining 90% of grueling work required to turn those prototypes into production-ready products. Dorsey's public statements about AI fit this pattern perfectly.

2. In April this year, Snap laid off roughly 1,000 employees. CEO Evan Spiegel largely blamed AI for the cuts in his internal layoff memo, also claiming that 65% of the company's new code was AI-generated. In reality, the layoffs were the result of a campaign by activist investors pushing for cost reductions. (Since going public in 2017, Snap has posted net losses every year, and its stock price dropped more than 30% in 2026.) Tellingly, the structural nature of the layoffs—such as the elimination of 150 roles spanning multiple job categories in the augmented reality division—had no correlation with the patterns we would expect from AI-driven displacement (which would manifest as widespread cuts to programming and other "AI-vulnerable" roles across the entire company, rather than being concentrated in a single department).

3. In May this year, Intuit announced 3,000 layoffs alongside partnerships with Anthropic and OpenAI. Media outlets quickly linked the two events, framing the layoffs as an AI-powered transformation. On this occasion, however, the CEO pushed back against that superficial narrative, explicitly stating "This has nothing to do with AI" and clarifying that the cuts targeted roles with high coordination overhead and redundant management layers.

These examples are not cherry-picked. Every report we investigated that claimed AI was causing software engineering layoffs revealed facts that contradicted the surface-level narrative. It turns out that framing layoffs with "AI" is a widespread phenomenon across the entire economy, corroborated by numerous surveys:

• 59% of U.S. hiring managers admitted they intentionally emphasized AI when explaining hiring freezes or layoffs, because this framing plays better with stakeholders than admitting financial struggles.

• J.P. Gownder, principal analyst at Forrester, noted of companies planning so-called AI layoffs: "When we asked if they had mature, proven AI applications ready to take over those roles, nine times out of ten the answer was no—they hadn't even started building them."

• In a Harvard Business Review survey of over 1,000 global executives, 21% had carried out large-scale layoffs out of "anticipation" of AI, while another 39% had made mild or moderate anticipatory cuts. By contrast, only 2% had implemented large-scale layoffs driven by actual AI deployments. This tenfold gap shows that executives, just like ordinary people, are easily swept up in misleading narratives about AI replacing jobs.

Another revealing data point comes from the U.S. Worker Adjustment and Retraining Notification (WARN) Act, which requires mandatory disclosures for plant closures and mass layoffs affecting more than 100 workers. In March 2025, New York became the first U.S. state to add an AI disclosure checkbox to its WARN filings. Over the full first year, more than 160 companies submitted WARN notices. Not a single one checked the AI box. When we reached out to the New York State Department of Labor, they confirmed that as of late May, only one company (Nespresso) had marked that option. If these figures are accurate, out of roughly 25,000 laid-off workers in New York during that period, only 46 were affected by AI—a rate of approximately 0.2%.

Even more devastating to the "AI causes mass layoffs" narrative: layoffs themselves are the wrong metric for evaluating AI's potential productivity benefits! Research clearly demonstrates that this impact primarily manifests through "slower hiring rather than increased firings". Terminating existing employees directly robs companies of the tacit knowledge and organizational assets that enable their workforce to use AI effectively. Furthermore, layoffs carry enormous costs in severance pay, damaged morale, and rehiring risks. Given these costs, layoffs are unnecessary—normal employee attrition can achieve the same headcount reduction over a few years.

So when we shift focus away from layoffs and look at overall employment trends, what does the data tell us? A landmark paper from Federal Reserve economists compiled evidence from the U.S. context. Employment for software engineers is still growing, but they found that after ChatGPT's launch, the annual growth rate slowed by roughly 3 percentage points compared to a no-AI counterfactual. A key limitation of this study is that its methodology cannot capture self-employed individuals, meaning part of that slowdown may have been absorbed by an entrepreneurial boom. Other research does confirm that AI has made starting new businesses easier. So the real industry picture is likely healthier than the Fed's report suggests.

Finally, it is important to acknowledge that two types of AI-related unemployment do exist in software engineering, but they are fundamentally different from AI directly replacing software engineers. The first scenario occurs when AI completely erases market demand for certain products—such as at Chegg (homework help) or Stack Overflow (technical Q&A), both of which laid off employees. AI did not directly perform these workers' jobs; it eliminated market demand for that type of work. This has strong historical parallels: out of 270 occupations counted in the 1950 U.S. Census, only one was entirely eliminated by automation—the elevator operator. Many other roles became obsolete due to new technologies, like telegraph operators.

The other apparent AI layoff narrative plays out at companies selling AI rather than buying it. So when firms like IBM or SAP announce layoffs tied to AI, a more accurate framing is: "We are reallocating headcount from traditional functions to our fastest-growing business lines." This is normal corporate restructuring around monetization opportunities, not technology displacing labor.

Why AI coding agents won't cause job displacement: the "Decide-Execute-Deliver Sandwich" model

Many tech executives (like Snap's CEO referenced earlier) love to cite the percentage of code written by AI when announcing layoffs or predicting future job losses. This fuels a simplistic mindset: once AI writes all the code, programmers will be out of work. Fortunately, that mindset is wrong. The metric of "percentage of code written by AI" is almost entirely disconnected from the core factors that actually determine labor displacement. Here's why.

Writing code itself is not, and has never been, the bottleneck in the process. A 2019 paper summarizing existing research concluded: "Developers spend surprisingly little time writing code—anywhere from 9% to 61% depending on the study." This finding aligned with the paper's own data from 6,000 Microsoft developers. As coding agents became mainstream, a wave of technical blogs in late 2025 pointed out that writing code is not the bottleneck, as developers realized that even when agents handle the vast majority of code generation, the overall productivity lift remains marginal.

If writing code isn't the bottleneck, what is? Task breakdown surveys point to activities like meetings or debugging. This raises further questions: what exactly are developers doing in those meetings, and why can't AI do it? Won't debugging be automated as technical capabilities improve? To identify the real bottlenecks, we need qualitative analysis that digs into software engineers' own deep understanding of which parts of their work cannot be automated.

When we conduct this analysis, we find the real bottlenecks fall into three categories: (1) deciding and defining what to build; (2) validating and taking accountability for delivered outputs; (3) the deep human understanding of codebases, business logic, and broader context required to do the first two activities.

In other words, a software engineer's work forms a "Decide-Execute-Deliver" sandwich (with comprehension as a prerequisite for all three). AI has drastically compressed the middle "Execute" layer, but the two ends remain largely untouched. As long as software development teams retain decision-making authority and final accountability for deliverables, engineers will still need to invest significant time building deep system understanding. These are the three core bottlenecks.

Figure: Software development consists of three layers: (1) Decide—problem definition, requirements specification, planning; (2) Execute—design and implementation; (3) Deliver—testing, validation, integration, maintenance, etc. Note that these are conceptual logical layers, not sequential phases. It is common to move back and forth between them as projects progress.

The "sandwich model" of AI productivity effects is validated in a recent paper titled Writing Code vs. Delivering Code. By observing 100,000 developers on GitHub, researchers found that AI agents increased lines of code written by a factor of eight—confirming that AI has nearly maximized compression of the "Execute" layer of the sandwich. However, this only translated to a 30% increase in production releases, offering strong evidence that the human bottlenecks (the "Decide" and "Deliver" layers) remain robust.

Can this sandwich be compressed further? We argue no. At one end of the workflow, development teams must decide what to build. One of the most critical lessons junior software engineers learn is that requirements specification—the industry term for this layer—takes an unexpectedly long time, and forcing shortcuts here leads to endless downstream pain. This layer is hard to automate because it requires balancing user needs, market signals, organizational priorities, and in some cases legal compliance constraints.

As AI capabilities evolve over time, the types of decisions that can be delegated to AI will indeed increase. But this won't make the "Decide" layer thinner—because once a decision can be handled by AI, it no longer serves as a source of competitive advantage, and the human decision-making value proposition shifts to higher ground. Software complexity grows over time, so this evolutionary process has no upper limit.

At the other end of the sandwich, human teams must take full accountability for what gets delivered. Perhaps one day teams will ship mission-critical code without fully testing or understanding it, but for now, AI's unreliability makes that kind of reckless behavior catastrophic for software teams and their customers.

Even if future technical barriers disappear, we don't have to cede control to AI. The core insight of "treating AI as just another technology" is that we can collectively choose to assign final accountability to humans through shared norms, laws, and policies. This is a far more resilient approach to managing AI's adoption speed and improving safety than trying to suppress technological development. These "speed bumps" already largely exist through tort liability laws and industry-specific regulations, and they can be strengthened further in the future.

In this vision, as more execution-layer work is offloaded to AI, the future role of software engineers will resemble that of crane operators. AI agents will handle most of the heavy cognitive lifting, while the core human job becomes overseeing the agents and ensuring they stay under control.

Some critics argue that a future where humans retain control is unlikely, because hiring people to do this work will be too expensive. A few widely circulated absurd stories have already emerged online about coding agents deleting production databases or causing other damage due to lack of oversight. But we see these as "man bites dog" anecdotes, not an emerging industry norm. They go viral precisely because their extreme irresponsibility and rarity create shock value, serving as wake-up calls that help the technical community guard against over-reliance on AI. As the old saying goes: "If it's news, you don't need to panic about it." Still, one of the most critical missing datasets today is tracking whether unregulated, high-stakes AI usage across the broader economy (not just in software engineering) is on the rise.

As an aside, the compression of this sandwich is not a new trend, nor is it unique to AI. Over two decades ago, the U.S. Bureau of Labor Statistics began separately tracking "programming" and "software engineering". The distinction essentially framed programmers as execution-focused workers, while software engineers owned a much larger portion of the sandwich. This not only caused pure programming roles to shrink, but also drove down their compensation, as they were seen as commodity labor. AI has only accelerated this pre-existing trend, further devaluing purely technical skills.

Software engineering vs. programmer employment trends. Chart produced by The Washington Post.

The pattern where humans remain deeply involved at both ends of the "Decide-Execute-Deliver" sandwich even as the middle layer gets automated by AI appears to apply broadly to most knowledge-intensive work, even if it has advanced furthest in software. After all, complex decision-making and accountability are shared across nearly every industry. Failure to recognize this dynamic has led to many overconfident claims of imminent mass unemployment, such as predictions that AI would replace radiologists.

Vibe coding is not equivalent to agentic engineering

One source of confusion about the scale of transformation in software engineering is the loose, broad application of the term "vibe coding" to wildly different engineering practices—two modes that are conceptually distinct and far apart on the spectrum.

In true "vibe coding", users simply give instructions to agents, run them unsupervised, do not review the generated code (and may not even have the technical ability to do so), and do not evaluate final outputs unless there is an obvious, catastrophic failure.

This stands in stark contrast to how most software engineers actually use agents: as tools, with humans retaining core control and accountability for outputs. Encouragingly, the term "agentic engineering" is gaining traction to accurately describe this practice.

As agentic engineering becomes the norm, engineers are discovering that overseeing coding agents is surprisingly mentally draining. For example, prominent developer and AI transition chronicler Simon Willison has noted that he is exhausted by 11 a.m. from constant agent oversight. This aligns closely with our own hands-on experiences.

More quantitative evidence comes from SWE-chat, a dataset tracking interactions between open-source developers (who voluntarily opted into logging tools) and coding agents. The study found that only 44% of agent-generated code ultimately survived in users' commits; code submitted via vibe coding was nine times more likely to introduce security vulnerabilities than purely human-written