The AI Layoff Story Keeps Falling Apart When You Check the Receipts

Every few months a new headline announces that artificial intelligence has started eating software engineering jobs. A CEO cites model improvements in a layoff memo. A company reports that 65% of its code is now machine-generated. The narrative writes itself: capabilities crossed a threshold, and the coders became redundant.

Arvind Narayanan and Sayash Kapoor, the Princeton researchers behind the AI as Normal Technology project, decided to check whether the receipts matched the rhetoric. Their conclusion, laid out in a new essay, is blunt: not only has AI failed to trigger mass layoffs in the one profession where adoption has been fastest and regulatory friction lowest, but the structure of the work suggests it won't, even as the models keep improving.

That is a contrarian position in a discourse dominated by countdown clocks. It is also, on the evidence they assemble, harder to dismiss than the usual optimism.

The layoffs that weren't about AI

The authors examined the marquee examples one by one. In February, Block announced 4,000 cuts, with founder Jack Dorsey attributing the move to AI "enabling a new way of working" with smaller, flatter teams. Subsequent reporting told a different story. The company had tripled its headcount during the pandemic and was under heavy financial pressure. One data scientist on the Cash App team, Naoko Takeda, posted that Block "shoved AI down everyone's throats" while she saw "very limited gains in productivity," then turned down a 75% retention raise and quit.

Snap laid off roughly 1,000 people in April, with CEO Evan Spiegel naming AI in the memo and citing that 65% code-generation figure. The cuts followed an activist investor campaign demanding cost reductions at a company that has posted a net loss every full year since its 2017 IPO. The detail that gives it away: 150 of the cuts hit the augmented reality division, spread across roles. If AI were really displacing programmers, you would expect the losses concentrated in coding and other automatable work, not scattered through a hardware unit.

Intuit announced 3,000 cuts in May alongside deals with Anthropic and OpenAI, and the press duly connected them. This time the CEO pushed back, saying "none of it had to do with AI" and that the cuts targeted "coordination-heavy roles" and excess management layers.

The authors are careful to say they did not cherry-pick. In every layoff story they examined, the same gap opened up between the public framing and the underlying cause. There is even a name for it now: "AI washing." A survey found that 59% of U.S. hiring managers admit they emphasize AI when explaining freezes and cuts because it plays better with stakeholders than admitting the money ran short. Forrester analyst J.P. Gownder describes companies preparing supposedly AI-driven layoffs: "When we ask if they have a mature, vetted AI app ready to fill in those jobs, nine out of 10 times, the answer is no, and they haven't even started."

The single most striking data point comes from New York. In March 2025 the state became the first to add an AI disclosure checkbox to its WARN Act filings, which large employers must submit before mass layoffs. Over the first full year, more than 160 companies filed notices. As of late May, exactly one had checked the AI box: Nespresso. By that accounting, around 46 of roughly 25,000 laid-off workers in the state, about two-tenths of one percent, were affected by AI.

Why layoffs are the wrong thing to watch anyway

The essay makes a point that cuts against both the doomers and the boosters: firing people is a poor signal of AI's productivity effects in either direction. Research on technology adoption shows the labor impact tends to operate through slower hiring rather than increased separations. Laying off existing staff destroys exactly the tacit knowledge and organizational context that lets a workforce use new tools well, and it carries real costs in severance, morale, and rehiring risk. Natural turnover accomplishes the same headcount reduction over a few years without any of that.

The more honest signal is hiring, and there the picture is mixed but not catastrophic. A paper from Federal Reserve economists finds U.S. employment still growing, but growing slower post-ChatGPT than a no-AI counterfactual would predict, by about three percentage points a year. The authors note the study can't capture self-employment, and other research suggests AI is making entrepreneurship easier, so some of that slowdown may be migrating into new firm formation rather than vanishing.

They also concede the cases where AI-adjacent job loss is real. Chegg and Stack Overflow have cut staff not because AI does their employees' jobs but because chatbots obviated demand for their products. And when IBM or SAP announce AI-related cuts, the accurate framing is usually that they reallocated headcount toward a fast-growing product line, which is ordinary corporate restructuring around a revenue opportunity, not displacement.

The sandwich that resists compression

The theoretical core of the argument is a model the authors call the "decide-execute-deliver sandwich." Software work, they say, breaks into three layers: deciding and specifying what to build, executing the design and implementation, and delivering through testing, verification, integration, and maintenance. Underneath all three sits the deep human understanding of the codebase, the business, and the environment.

AI has compressed the middle layer almost completely. It has barely touched the other two.

This is where the widely cited "percentage of code written by AI" metric falls apart as a predictor of job loss. Writing code was never the bottleneck. A 2019 paper summarizing prior studies, consistent with its own data from 6,000 Microsoft developers, found that developers spend somewhere between 9% and 61% of their time actually coding depending on the study. The rest goes to meetings, debugging, figuring out what to build, and confirming that what shipped actually works. Through late 2025, a wave of developer blog posts made the same discovery from the inside: handing most of the code to agents produced surprisingly little change in overall output.

The quantitative backstop is a recent paper titled "Writing Code vs. Shipping Code." Across 100,000 GitHub developers, AI agents drove an eight-fold increase in lines of code written but only 30% more releases. The execute layer collapsed; the human bottlenecks at either end held.

The authors argue these bottlenecks aren't waiting to be cleared by better models. The decide layer resists automation because specifying correct behavior requires reasoning about user needs, market signals, organizational priorities, and regulatory constraints. As models improve and more decisions become delegable, the value of human judgment simply migrates upward; once a decision can be handed to AI, it stops being a source of competitive advantage. Since software grows more complex over time, there is no ceiling to that process.

The deliver layer resists automation because someone has to be accountable. Today's models are too unreliable to ship mission-critical code unexamined. And even if that changes technically, the authors make a normative argument that runs through their whole project: society can choose to keep humans accountable through norms, law, and liability, which is a more durable safety lever than trying to slow capability research. The future software engineer, in their framing, looks less like a typist and more like a crane operator, supervising machinery that does the heavy lifting while staying responsible for where it sets things down.

Vibe coding is not the same thing as engineering

Much of the confusion, the authors contend, comes from sloppy use of the term "vibe coding." In its pure form, the user tells an agent what to do, doesn't supervise it, doesn't review the output, and might lack the skills to do either. That is genuinely different from how most engineers use agents, as tools, with a human in control and on the hook for the result. The community has started calling the latter "agentic engineering," and the distinction matters.

Evidence from SWE-chat, a dataset of opted-in coding-agent interactions, sharpens the contrast. Only 44% of agent-produced code survived into user commits. Vibe-coded commits introduced vulnerabilities at nine times the human-only rate. And the most common reason developers reached for an agent was to understand existing code, not to generate new code. Even Simon Willison, among the most prolific chroniclers of the AI coding transition, has described being mentally exhausted by 11am from supervising agents. The work didn't disappear. It changed shape and, by several accounts, got more tiring.

The case for more engineers, not fewer

Here the essay turns genuinely optimistic, and it leans on economics to do so. When something gets cheaper to produce, people buy far more of it, provided demand is price elastic. Software is about as elastic as goods get. Programmer employment in the United States grew from near zero around 1950 to millions today precisely because falling costs unlocked enormous new demand. That is the opposite of agriculture, where mechanization gutted labor demand because the amount of food people can eat is roughly fixed. There is no comparable ceiling on software. A modern car runs something like a hundred million lines of code. As coding gets cheaper, people are spinning up one-off utilities that never justified the effort before.

This is the territory where commentators reach for "Jevons' paradox," the idea that efficiency gains increase total consumption. The authors note the term gets thrown around loosely, but the underlying dynamic fits.

They are careful not to oversell it. More software and more engineers does not mean the big platforms grow without limit; most engineers already work in-house at non-software firms, and that share may rise. The much-hyped idea of "AI rollups," where investors buy ordinary businesses and rebuild them as AI-native operations, might amount to nothing. And they explicitly bet against the democratization thesis, the claim that domain experts will simply write their own software and crowd out professionals. Every prior generation made that prediction. FORTRAN, COBOL, and SQL all arrived wrapped in the same hope. It never happened, because the barrier was never syntax. It was the skilled judgment to make good decisions and remain accountable for them.

The counterweight to all this optimism is the authors' own promised follow-up. Healthy aggregate demand, they acknowledge, says nothing about whether individual engineers come out ahead. The next essay in the series argues AI will drive large structural shifts in how software gets made, with winners and losers sorted by firm type, geography, seniority, and adaptability. Forty years ago Fred Brooks, in No Silver Bullet, distinguished the essential complexity of software from the accidental kind, arguing that better tools only ever attack the accidental part. The decide-execute-deliver sandwich is a modern restatement of that old observation. The pattern has held through every prior tool that promised to make programmers obsolete. The honest question is not whether this time the optimists are right, but whether anyone betting against Brooks has won before.