Harvard Business Review published a piece in early 2026 with a title that should've set off alarm bells across every engineering org on the planet: "Companies Are Laying Off Workers Because of AI's Potential — Not Its Performance."
Not performance. Potential.
That's the corporate equivalent of demolishing a profitable restaurant because someone heard a rumor about a self-cooking kitchen. Except 52,050 real people lost real jobs in Q1 2026 over this particular rumor.
The Q1 2026 Scoreboard
Before anyone dismisses this as doomerism, here are the actual numbers:
| Metric | Q1 2025 | Q1 2026 | Change |
|---|---|---|---|
| Total tech layoffs | ~37,000 | 52,050 | +40% YoY |
| Companies citing "AI efficiency" | 12 | 31 | +158% |
| Measurable AI productivity data shared | 0 | 0 | No change |
That last row is the important one. Thirty-one companies told Wall Street that AI-driven efficiency justified cutting engineering headcount. Zero of them published internal data showing those efficiency gains actually existed.
Meta, Google, Amazon, Block, Atlassian, Pinterest, Salesforce. All of them used some variant of "AI productivity" or "automation dividend" on their earnings calls. None of them showed the receipts.
The 55% Productivity Claim vs. Reality
A number keeps showing up in executive presentations: teams using AI coding assistants produce 40-55% more code per sprint. Sounds great on a slide. It's also the wrong metric, and everybody who's actually shipped software knows it.
Here's what the engineering workload breakdown looks like in practice:
| Activity | % of Engineer Time | AI Capability |
|---|---|---|
| Writing new code | ~20% | Strong (boilerplate, CRUD, tests) |
| Reading/understanding existing code | ~25% | Moderate (summaries, not deep context) |
| System design & architecture | ~15% | Weak |
| Debugging & incident response | ~15% | Very weak |
| Code review & collaboration | ~10% | Superficial |
| Cross-team coordination | ~10% | None |
| Requirements & stakeholder work | ~5% | None |
AI tools are good at roughly 20% of the job. They're passable at another 25%. They're useless at the remaining 55%. Firing 15-20% of an engineering org because tools got better at the easiest fifth of the work isn't strategy. It's innumeracy.
Code AI Actually Can't Write
The "55% more productive" claim falls apart the second anyone looks at what AI-generated code actually looks like in production systems. Here's a real-world example that illustrates the gap.
Ask any AI assistant to design a retry mechanism for a distributed payment processing system. Something like this:
# What AI generates (and what juniors accept):
async def process_payment(payment_id: str):
for attempt in range(3):
try:
result = await payment_gateway.charge(payment_id)
return result
except Exception:
await asyncio.sleep(2 ** attempt)
raise PaymentFailedError(f"Payment {payment_id} failed after 3 attempts")
Looks clean. Passes linting. Even has exponential backoff. Ship it, right?
Wrong. A senior engineer would immediately spot what's missing:
# What production actually needs:
async def process_payment(payment_id: str):
# Idempotency key prevents double-charging on retry
idempotency_key = await get_or_create_idempotency_key(payment_id)
# Check if payment already succeeded (another instance might've
# completed it while we were retrying)
existing = await payment_ledger.get_status(payment_id)
if existing == PaymentStatus.COMPLETED:
logger.info(f"Payment {payment_id} already completed, skipping")
return existing
for attempt in range(3):
try:
result = await payment_gateway.charge(
payment_id,
idempotency_key=idempotency_key,
# Gateway timeout must be LESS than our consumer's
# visibility timeout, or we'll get duplicate processing
timeout=GATEWAY_TIMEOUT_SECONDS,
)
await payment_ledger.record(payment_id, result)
await dead_letter_queue.remove_if_present(payment_id)
return result
except GatewayTimeoutError:
# DON'T retry timeouts - the charge might have gone through.
# Route to manual review queue instead.
await manual_review_queue.enqueue(payment_id, reason="timeout")
raise
except RateLimitError as e:
# Respect the gateway's retry-after header, not our own backoff
await asyncio.sleep(e.retry_after)
except TransientError:
backoff = min(2 ** attempt + random.uniform(0, 1), MAX_BACKOFF)
await asyncio.sleep(backoff)
if attempt == 2:
await dead_letter_queue.enqueue(
payment_id,
last_error=traceback.format_exc(),
retry_count=attempt + 1
)
raise PaymentFailedError(
f"Payment {payment_id} failed after 3 attempts",
alert_oncall=True, # Page someone. Money is involved.
)
The difference between those two blocks is about six production incidents, a possible double-charge, and an angry call from the payments team at 3 AM. AI generated the first version. Only a human who's been burned before writes the second.
Another example. Try asking an AI to debug this:
// "It works fine locally but times out in production 2% of the time"
func GetUserProfile(ctx context.Context, userID string) (*Profile, error) {
profile, err := cache.Get(ctx, userID)
if err == nil {
return profile, nil
}
profile, err = db.QueryProfile(ctx, userID)
if err != nil {
return nil, err
}
cache.Set(ctx, userID, profile, 1*time.Hour)
return profile, nil
}
AI will suggest adding timeouts, retries, circuit breakers. All wrong. The actual bug? In production, the cache cluster runs across three availability zones. 2% of requests hit a node in a different AZ where a recent network policy change added 800ms of latency. The cache Get call doesn't fail — it just takes long enough to eat the request's timeout budget before the database call even starts.
No AI tool figures that out, because it requires knowing the infrastructure topology, the recent change history, and the operational context. That knowledge lived in the heads of the people who just got walked out with a cardboard box.
The Incident Rate Nobody Mentions on Earnings Calls
Here's the metric that should be on every board slide but mysteriously isn't. These numbers are composited from publicly shared engineering metrics and postmortem trends across mid-to-large tech companies in late 2025 and early 2026:
| Metric | Pre-AI Tooling | Post-AI Tooling | Change |
|---|---|---|---|
| PRs merged per sprint | 34 | 51 | +50% |
| Incidents per PR | 0.034 | 0.042 | +23.5% |
| Total incidents per sprint | 1.16 | 2.14 | +85% |
| Mean time to resolve | 2.1 hrs | 3.4 hrs | +62% |
Read that bottom row. Incidents aren't just happening more often. They're taking longer to fix. Because the people who understood the systems well enough to fix them quickly are gone.
The math tells a brutal story. A team that shipped 34 PRs and handled ~1.2 incidents per sprint now ships 51 PRs and handles ~2.1 incidents. If each incident consumes an average of 3.4 engineer-hours (up from 2.1), that's 7.1 hours per sprint burned on incidents instead of 2.4.
The "productivity gain" of 17 extra PRs costs 4.7 extra hours of firefighting per sprint — and that's before accounting for the reduced team size. Fewer engineers splitting more incident load means each person carries a heavier on-call burden. Burnout follows. Then attrition. Then more hiring, often at premium rates, because the company now needs to backfill institutional knowledge it threw away for free.
The Stock Price Play
There's a less charitable explanation for what's happening, and it involves looking at who benefits from the "AI efficiency" story.
When a company announces AI-driven layoffs, its stock typically jumps 3-7% within 48 hours. The productivity gains don't need to be real. The market reaction is real enough.
This creates a perverse incentive loop:
- CEO announces layoffs, cites AI efficiency
- Stock jumps
- Executive compensation (tied to stock price) increases
- Board sees stock performance, approves more of the same
- Actual engineering output degrades quietly over 12-18 months
- By the time the damage shows, the narrative has shifted
It's not conspiracy thinking. It's just recognizing that the people making layoff decisions are financially rewarded for making them, regardless of the engineering outcome.
There's also the uncomfortable overlap between companies selling AI products and companies citing AI as the reason for layoffs. When a cloud provider says "AI makes developers 55% more productive," that provider is also selling AI developer tools at $19-40/seat/month. The incentive to produce honest productivity assessments is... limited.
The Skill Paradox That Makes It Worse
Here's the part that would be funny if it weren't so destructive.
Senior engineers get the most value out of AI tools. They know what good code looks like, so they can evaluate AI output critically. Architectural context lets them integrate generated code without breaking existing systems. Years of production failures give them the instinct to reject AI suggestions that will cause problems downstream.
Junior engineers, by contrast, tend to accept AI suggestions at face value. Without that scar tissue, a clean-looking retry loop reads as correct code rather than a double-charge waiting to happen.
So the layoffs that disproportionately hit experienced engineers are removing exactly the people who make AI tools safe to use. The remaining team is less equipped to evaluate AI output, which means more bad code ships, which means more incidents, which means more pressure on an already-thinned team.
It's a doom loop with a nice PowerPoint attached.
The Historical Rhyme
This pattern isn't new. The technology changes. The corporate behavior doesn't.
| Hype Cycle | Promise | Premature Workforce Action | Outcome |
|---|---|---|---|
| Blockchain (2017-2019) | Decentralize everything | Restructured teams for "Web3" | Most projects dead by 2022 |
| RPA (2015-2020) | Automate all back-office work | Cut operations staff | Rehired 60-70% within 2 years |
| Cloud migration (2012-2016) | Zero ops engineers needed | Cut infrastructure teams | Created "DevOps" role at 2x salary |
| Offshoring (2003-2008) | Same quality, 1/4 the cost | Cut domestic engineering | Brought much of it back within 3-5 years |
| AI coding tools (2024-now) | Replace junior/mid engineers | Cutting 15-20% of eng orgs | TBD (but early data isn't encouraging) |
All of them followed the same arc: real technology gets overhyped, executives make premature workforce decisions, reality bites, and the company quietly rebuilds — usually at higher cost and with less institutional context.
The difference this time is that AI coding tools are useful -- more useful than blockchain was for most businesses, more practical than early RPA. That kernel of real value makes the hype harder to separate from reality. But "useful tool" and "replacement for human judgment" aren't even in the same category.
What Smart Companies Are Actually Doing
Not every company is sleepwalking into this trap. The ones getting it right aren't cutting engineers. They're redeploying them.
The rational approach looks like this: use AI to automate the boring parts (boilerplate, test scaffolding, documentation drafts), then redirect human time toward the work AI can't do (system design, cross-team architecture, security auditing, the kind of deep debugging that requires knowing why the system is built the way it is).
A team of 10 using AI well can operate like a team of 14. That's real and valuable. But cutting the team to 7 and hoping AI makes up the difference isn't the same math. One approach builds on proven capability. The other is a coin flip with people's livelihoods.
The problem is optics. "We're redeploying our workforce to focus on higher-value work alongside AI tools" doesn't pop on an earnings call the way "we cut 20% of engineering and invested in AI" does. Wall Street rewards the dramatic narrative. The sensible one gets polite nods and no stock bump.
The 18-Month Prediction
This story has a predictable ending because it's the same ending every time.
Within 18-24 months, some of the companies making the deepest AI-motivated cuts will be hiring again. The job titles will be different. "AI Systems Engineer" instead of "Software Engineer." "Human-in-the-Loop Architect" instead of "Senior Developer." The LinkedIn posts will celebrate the exciting new roles without mentioning they're doing the same work the laid-off engineers did, minus three years of institutional knowledge.
The 52,050 people affected in Q1 2026 will mostly land on their feet. Good engineers always do. But the disruption, the uprooted families, the abandoned projects — all of it happened because of a speculative thesis, not empirical evidence.
Companies are firing developers today based on tools they hope to have tomorrow. The HBR piece named it precisely. These layoffs aren't a response to demonstrated AI capability. They're a response to a story about AI capability. And unlike software, stories don't need to compile to be believed.
The data says one thing. The earnings calls say another. Somewhere between those two realities, 52,050 engineers are updating their resumes because a slide deck full of projections was more persuasive than their actual output.
That's not strategy. That's a very expensive way to learn a lesson the industry has already learned four times before.
Has your team been affected by AI-justified layoffs or restructuring? Are you seeing the productivity gains that leadership claims, or is the gap between the narrative and reality as wide as the data suggests? I'd like to hear what it looks like from the inside.
- My project: Hermes IDE | GitHub
- Me: gabrielanhaia
Top comments (0)