Software engineer layoffs blamed on AI? Almost entirely theatre. A new essay from Normal Tech compiles the data — and the picture is clearer than most pundits want to admit.
"59% of U.S. hiring managers admitted they emphasise AI when explaining hiring freezes or layoffs because it plays better with stakeholders than citing financial constraints."
Block, Snap, Intuit — all recently cited AI as a reason for cuts. All turned out to have more ordinary explanations: pandemic-era hiring excess, activist investor pressure, management layer trimming. The Intuit CEO literally pushed back on the framing himself, saying the cuts "had nothing to do with AI."
What the data actually shows
- WARN Act disclosures — New York added an AI checkbox to layoff filings in 2025. After a full year and 160+ filings, just one company checked it. Out of ~25,000 laid-off workers, 46 (0.2%) were flagged as AI-related.
- Federal Reserve research finds software engineer employment is still growing post-ChatGPT — just ~3 percentage points per year slower than the no-AI counterfactual.
- Layoffs are the wrong signal anyway. AI's productivity effect comes through slower hiring, not firing. Laying off experienced engineers destroys the tacit knowledge that makes AI effective in the first place.
The sandwich model
Here's the key framework. Software development has three layers:
- Decide — Problem framing, requirements, planning
- Execute — Writing and designing code
- Deliver — Testing, verification, integration, maintenance
AI has compressed the middle. Writing code was 9–61% of a developer's time (Microsoft research, 6,000 devs). Agents compress that dramatically.
Here's the number that makes it concrete: across 100,000 GitHub developers, AI agents produced an 8× increase in lines of code written — and only a 30% increase in releases.
The two ends of the sandwich — deciding what to build and being accountable for what ships — resist automation. Not because of capability limits, but because requirements specification and delivery accountability are structurally human-in-the-loop: user needs, business context, regulatory constraints, liability.
Why the bottleneck migrates, not disappears
As more decisions get delegated to AI, the value of human judgment moves upward. Software complexity keeps growing, so there's no ceiling. The comparison in the essay is apt: the engineer's role becomes more like a crane operator — supervising AI doing the heavy lifting, responsible for what lands where.
"Vibe coding" has muddied this picture. A solo dev shipping a toy app with LLM autopilot is very different from an engineering team accountable for production systems. The word covers both, which is why the discourse is so sloppy.
This isn't unique to software. The essay notes the same sandwich applies broadly to knowledge work — radiologists, lawyers, analysts. Software is just the furthest-along test case.
What to do
- If you're an engineer: The execute layer is being automated. Invest in the ends — better requirements skills, stronger delivery practices, accountability at scale.
- If you're hiring: Don't mistake AI productivity gains for headcount savings. The bottleneck moved, it didn't disappear.
- If you're reading AI layoff headlines: Check whether the company had pandemic hiring excess, investor pressure, or consecutive net losses before crediting AI.
Source: Normal Tech — Why AI hasn't replaced software engineers
✏️ Drafted with KewBot (AI), edited and approved by Drew.
Top comments (2)
This is a really useful framing.
The “AI replaces engineers” narrative keeps missing the part where software work is not just code production. If agents compress the execute layer, the hard problems do not disappear. They move into deciding what should change, preserving system intent, verifying what actually changed, and being accountable for what ships.
That is the part I keep seeing in AI-assisted development: the agent can move incredibly fast, but speed does not automatically preserve repo truth.
A system can still build.
A test can still pass.
A patch can still look plausible.
And yet the repo can quietly drift around the wrong assumption.
So I think the sandwich model is right, but I would add one more pressure point: as execution gets automated, the delivery/accountability layer needs stronger diagnostic support. Humans are still responsible for what lands, but they need better ways to inspect whether the agent preserved the system’s actual boundaries.
That is where I think the next serious tooling layer has to emerge: not just agents that write more code, but repo-side diagnostics that can ask what the system is obligated to preserve and whether the agent stayed inside that truth.
AI does not remove engineering judgment.
It makes engineering judgment more structural.
What are the three skills that a future software engineer should develop today to remain indispensable?****