Posted on Jun 6

They fired the devs. The AI broke production. Now they’re begging them back.

#ai #softwaredevelopment #programming #webdev

The AI replacement experiment ran at scale. The results are in. Nobody’s writing a press release about what they found.

Nobody announced the plan out loud. But somewhere in 2024, the same decision got made at a hundred companies simultaneously. Developers were expensive. AI coding tools were getting genuinely impressive. The math looked obvious on a slide deck.

Cut headcount. Ship with AI. Protect margins. Simple.

Around 124,000 software developers got laid off across the industry that year. Amazon, Microsoft, Meta, Salesforce the list was long and the announcements came fast. The narrative was confident. AI would write the code. Humans were the bottleneck.

That narrative is now quietly, awkwardly falling apart.

Gartner recently estimated that 50% of companies that laid off workers because of AI will rehire for the exact same roles by 2027. Around 40% of new hires at some companies are already former employees who were shown the door after the AI pivot. Google rehired roughly 20% of its 2025 engineering intake from people it had previously cut.

Nobody’s throwing a party about this. There are no press releases celebrating the return of the developers. No LinkedIn post from a CTO saying “we were wrong.” But the hiring data tells the story that the PR team won’t.

TL;DR: AI replaced the code-writers. It couldn’t replace the context-holders the people who know why the system works the way it does, where the bodies are buried, and which part of the codebase you absolutely do not touch on a Friday. Now those people are getting their calls returned.

The theory was clean. The codebase was not.

The logic behind the layoffs was reasonable on the surface. AI tools generate code fast. If you reduce the humans writing code and increase the AI writing it, output stays roughly the same and the salary line goes down. Clean arbitrage.

The theory had one flaw that took about eighteen months to become undeniable.

Writing code and developing software are not the same thing.

AI can produce code. It produces it fast and it produces a lot of it. What it produced in practice was code that worked in isolation and quietly detonated when it touched a real system. IBM research found that four out of ten development teams reported compatibility issues when integrating AI-generated code into existing infrastructure. Not “it threw a warning.” Integration failures. The kind that take down services.

The syntax was fine. Gartner found that more than 50% of errors in AI-generated code were related to missing business context not algorithm bugs, not type errors, not off-by-one mistakes. The code was technically correct in a vacuum and wrong in the actual system it was dropped into.

The AI didn’t know why the payment service uses polling instead of webhooks. It didn’t know that decision came from a vendor bug years ago that cost the company a full weekend of downtime. It didn’t know that two services share a cache, that a certain table gets locked during batch jobs, or that the “legacy” module nobody touches is legacy for a reason.

It read the codebase. It did not understand the history of the codebase. Those are completely different things.

Think of it like hiring a contractor who builds exactly to spec, fast and cheap, but has no idea the building has a load-bearing wall that’s not on any blueprint. The wall exists because a structural engineer made a call in 2019 and never wrote it down. The contractor removes it. The building does not fall immediately. It falls six months later when someone adds weight to the second floor.

The developers who got laid off were the ones who knew about the wall. The AI read the blueprints and had no idea the wall existed.

The productivity math that nobody checked twice

The ROI case for replacing developers with AI was built on a specific assumption: that AI tools would make the remaining engineers dramatically faster, or eliminate the need for as many of them entirely. Either way, output goes up and costs go down.

Neither half held up.

A study found that seasoned engineers were actually 19% slower when using AI tools compared to working without them. Not junior devs getting overwhelmed. Senior engineers the exact people you’d expect to extract the most value from AI tooling moving slower because of it. The tools generated suggestions that looked plausible on the surface and required time-consuming verification underneath. Reading AI output carefully enough to trust it turns out to take longer than just writing the thing yourself.

The error rate compounded the problem.

AI-generated code contained up to 1.7x more errors than human-written code. Not slightly more. Nearly double. And those errors weren’t always obvious. They were the kind that pass a code review, survive testing, and surface in production three weeks later when a specific edge case finally triggers them.
Teams that adopted AI tools heavily ended up maintaining 38% more code than before. The AI shipped fast. The humans then spent months cleaning up what shipped.

The intern analogy is almost too accurate here. You hired someone who types extremely fast, never gets tired, and produces a lot of output. The problem is that a senior engineer is now spending the majority of their day reviewing that output instead of building anything. You didn’t reduce the senior engineering workload. You redirected it toward something less valuable and more exhausting.

Congrats. You now have 40% more code, zero new features, and one very tired staff engineer.

A GitHub study found that 49% of teams reported a decrease in real productivity after leaning heavily into AI code generation. Not a slowdown in growth. An actual decrease. The companies that moved fastest on the AI-first bet were the ones watching their best engineers burn out on review work while the backlog stayed exactly where it was.

The cost calculation didn’t just fail to improve. It inverted. More code to maintain, more errors to catch, more senior attention consumed by supervision work that hadn’t existed before. The salary savings from the layoffs got eaten by the hidden cost of running a permanent AI audit operation inside the engineering org.

The self-correction problem nobody talks about

Here’s the detail that changes the entire calculation. The one that didn’t make the headlines because it’s less dramatic than a layoff announcement but more important than anything else in this conversation.

Princeton researchers found that AI models failed to self-correct in more than 60% of cases even when explicitly asked to review their own code.

Let that sit for a second.

You can tell the AI “check your work.” It will check its work. It will tell you the work looks fine. And in 60% of cases where the work is not fine, it will still tell you the work looks fine. Confidently. With no visible uncertainty. The same energy it uses when it’s actually right.

This is not a minor limitation. It’s a structural characteristic of how these tools work.

Human engineers accumulate judgment from failure.

The feedback loop is: write code → run it → watch it break → understand why → update your mental model → write better code next time.

That loop is uncomfortable and slow and it’s also exactly how engineers develop the instincts that make them valuable. Every production incident a developer survives makes them slightly harder to fool the next time.

AI doesn’t have that loop. It generates output at the same confidence level regardless of whether the output is correct. The mistakes it makes on day one of a project are structurally identical to the mistakes it makes on day ninety. It doesn’t accumulate experience from failures because it doesn’t experience failure. It just generates the next token.

Think about the senior dev who’s been on your team for four years. Ask them why the auth service has that weird retry logic and they’ll tell you a story about a cascade failure, a 3am incident call, a decision made under pressure that turned out to be right, and three things they’d do differently now. That story is not in the codebase. It’s not in the docs. It exists entirely in their head and it shapes every decision they make.

The AI read the README. It did not survive the incidents.

This means AI-generated code requires permanent human supervision. Not as a transitional phase while the tools mature. Not something that gets better as the models improve. A fundamental characteristic of a system that generates confident output without closing the feedback loop that produces judgment.

Someone has to close that loop. That someone is a developer.

The companies that laid off their developers didn’t eliminate the need for loop-closing. They just left the loop open and hoped nobody would notice until the quarterly numbers came in.

What the rehiring actually reveals

Nobody is issuing a correction. That’s not how large organizations handle being wrong about a strategy that made headlines. What they’re doing instead is more revealing than any admission would be they’re showing it in job postings.

The boomerang is already moving. Around 40% of new hires at some companies are former employees who were let go after the AI pivot. Google rehired roughly 20% of its 2025 engineering intake from people it had previously cut. No announcement. No acknowledgment. Just a recruiter email and a slightly awkward first week back.

But here’s what’s actually interesting about who is getting rehired.

Not junior engineers to ship new features. Senior engineers who understand existing systems, can supervise AI output intelligently, and can catch the class of errors that AI produces reliably but cannot catch itself.
Not warm bodies to fill seats. More than 54% of companies indicated they plan to specifically increase senior developer hiring while reducing junior positions.

The structure of engineering teams is changing but in the opposite direction from what the original thesis predicted. AI isn’t replacing experienced engineers. It’s replacing the entry-level work that used to build the pipeline of future experienced engineers. Which sounds like a solved problem until you realize you’ve stopped planting trees and are now surprised there’s no shade.

The boomerang hires succeed for one specific reason. They already know the context the AI cannot learn from reading the codebase. They know why certain architectural decisions were made, what the system was designed to handle at scale, where the dangerous assumptions live, and which services will silently misbehave if you change the wrong config value. That knowledge doesn’t exist in any file the AI can access. It exists in the heads of the people who were present for the history of the system.

Institutional memory turns out to be an actual competitive asset. Who knew.

The companies that moved fastest to replace developers with AI are now the ones moving fastest to hire them back. Not because AI coding tools don’t work. They work. They generate code quickly and handle repetitive tasks well and genuinely accelerate certain parts of the development workflow. But they work as a layer on top of human judgment, not as a replacement for it.

The experiment ran at scale with real consequences. The results are visible in the hiring data even if they’re nowhere in the press releases.

So what do you actually do with this?

The “90% replacement” thesis that was making the rounds a few years ago was wrong in a specific and instructive way. It assumed that writing code was the core value engineers provided. Turns out the core value was something harder to name and much harder to replicate.

Understanding systems. Maintaining context over time. Catching the errors that confident tools produce invisibly. Making judgment calls that require knowing things that aren’t written down anywhere. Closing the feedback loop that turns failure into instinct.

None of that is replaceable by current AI tools. It may not be replaceable by near-future AI tools either, because it depends on the kind of accumulated, context-specific knowledge that only comes from being present for the history of a system. You can’t fine-tune your way into knowing why the checkout flow has that bizarre edge case handling you had to be in the room when the decision got made.

The real slow-burn crisis isn’t senior developers getting replaced. It’s the junior pipeline collapsing. AI is doing the entry-level work that used to teach people how systems break, how production behaves differently from staging, and how to develop the instincts that eventually make someone a senior engineer worth rehiring. That pipeline doesn’t disappear overnight. It disappears over five years, quietly, and then suddenly every company is competing for the same shrinking pool of experienced engineers who survived the transition.

That’s the uncomfortable part of the story nobody’s writing the press release about either.

For the developers reading this the ones who kept learning during the uncertainty, kept building context, kept sharpening the skills that don’t show up in a GitHub commit you’re the ones getting the calls now. The recruiters reaching back out aren’t doing you a favor. They’re correcting a calculation error.

The question worth sitting with: what does the knowledge you have about your current system look like if you tried to write it down, and how much of it exists nowhere except in your own head?

That’s not a liability. That’s the job.

Drop a comment with your take are companies actually learning from this, or are we six months away from the next round of “AI will replace developers” headlines?