Why Companies Are Quietly Rehiring Software Engineers...

[00:00:00]There's a story going around at the moment that companies fired their developers, replaced them with AI, and are now quietly hiring them all back.

[00:00:08]It's a great story. It's comforting if you write software for a living, and it's satisfying if you're skeptical about all of the AI hype. And it's mostly not true, at least not in the way that it's usually told. But underneath that too good to check headline, there is something real going on. And that thing is really very interesting. It tells us something important about what software engineering actually is and why the part of it that AI is good at was never really the hard part in the first place.

[00:00:43][music] Hi and welcome to the modern software engineering channel. My name is Dave Farley and if you haven't been here before, please do hit like and if you enjoy the content today, hit subscribe as well. I want to talk today about the idea that companies are rehiring the developers that they tried to replace with AI. And I want to be careful and honest about the evidence because this is a topic where it's very easy to tell ourselves a rather self-fulfilling flattering story and switch our brains off in the process. So, I'm going to do two things. First, I'm going to tell you what the evidence actually supports and where the popular version falls apart.

[00:01:26]And second, and more importantly, I want to use this to get to a much deeper point that writing code and engineering software are not the same thing. And I think that the confusion between those two is at the very heart of why some of these AI bets have gone the way that they have. So let's start with the honest version because I don't want to sell you a myth in the process of trying to bust one. The famous examples people reach for, Cler and IBM, are the two at the top of my mind, are real, but they're not what they're often claimed to be. Cler is the one that everybody sites. And yes, Cler leaned very hard into AI. They reduced its overall headcount substantially over a couple of years and said its AI was doing the work of something like 700 customer service agents. Then in 2025, they rode back and made a point of guaranteeing that customers could always reach a human being. Their CEO said something I find rather telling. He admitted that in optimizing for cost, cost had become, in his words, a too predominant factor. And the result was lower quality. Now, that's a fascinating admission, isn't it? But notice what it is not. Cler was talking about customer service, not software development. IBM's example is about HR. So if anybody tells you that there's a great wave of companies rehiring the software developers they replace with AI, be careful because the documented version of that story that developers are being replaced by AI is a lot thinner than headlines suggest. I'm not going to stand here and overclaim it. But here's the thing. We really don't need the anecdotes because the developer specific evidence when measured is far more interesting and points in a very consistent direction.

[00:03:17]In July of 2025, a group called MER meta ran a proper randomized controlled trial, not a survey, not a vendor case study, an actual controlled experiment.

[00:03:30]They took 16 experienced open-source developers working on their own repositories, code that they knew well, and gave them 246 real tasks, and then they measured what happened when those developers were allowed to use modern AI tools versus when they weren't. The developers were 19% slower when they used AI. Even more interesting, though, is that before the experiment, those developers expected the AI to speed them up by about 20%. And even after being measured being slower, they still believed that it had sped them up by about 20%. So that's a roughly 40% gap between perception and reality. They were confidently, measurably wrong about their own productivity. This reminds me of something Fred Brooks wrote back in 1986 in his famous article, No Silver Bullet. This is the most important sentence in our whole industry, and nearly everyone ignores it. The hard part of building software is the specification, design, and testing of this conceptual construct, not the labor of representing it and testing the fidelity of the representation. In plain English, what Fred was really saying is that the hard part was never the typing.

[00:04:44]It's the understanding the problem and shaping a solution that actually holds together that is difficult. But typing is exactly the part that we've optimized with AI. There's a lovely story about a hyperproductive team, a high-erforming team. They'd optimized their development process and were doing everything well, improving the amount of features they were producing dramatically and up to eight times improvement in productivity.

[00:05:10]The only problem was that this was the MySpace team just before Facebook took over the world and ate their lunch. So, they were doing lots of the right things, but they were creating the wrong features very fast. They had misunderstood the problem and were pleased with being busy but weren't making progress. My point is not to suggest that the MySpace team were dumb.

[00:05:31]They weren't. But rather that it's always important to keep your head in the game and your eyes on the ball.

[00:05:38]However great we are at building software, it's irrelevant if no one wants it. So understanding and tracking the impact of our work is a lot more important than how fast we can type code. Looking busy and making progress are not the same thing. This episode is brought to you by sponsors Equal Experts, Transfic, and Octopus Deploy, and through the support of our Patreon members. We'd like to thank all of them for their ongoing support. Our sponsors offer product and services that are extremely well aligned with the topics that we discuss here every week. So, if you're looking for excellence in continuous delivery and software engineering in general, please do check out their links in the description below to this video. So, if the AI is writing lots of code, but the developers aren't actually going faster or in the right direction, where is all that effort going? And this is where it really gets interesting because the measurements are surprisingly consistent about the answer. The effort is going into the invisible parts of the work. reviewing, debugging, structuring solutions, untangling, securing, and scaling systems to match the problem. The engineering, let me give you some numbers. A company called Git Clear looked at 211 million changed lines of code across four years. They found that 2024 was the first year on record where the amount of copied and pasted code overtook the amount of moved code. moved code being their proxy for refactoring, for consolidating, for tidying up as you go. Duplicated code climbed from around 8% to over 12, so 50% worse. So the pattern is more code, more duplication, and less of the careful restructuring that keeps a system soft enough to change. If you've watched this channel for any length of time, you'll know that this is precisely the wrong direction.

[00:07:36]That's the signature of a system accumulating the kind of coupling and mess that slows down every feature change, AI written or not. A similar problem shows up in security, too. One peer-reviewed study looked at over 700 real snippets of AI generated code and found that more than a quarter of them, 27% contained a security weakness of some kind. And then there's another result that I find almost poetic.

[00:08:04]Researchers took some verified secure code and then asked an AI to iteratively improve it again and again. After just five iterations of the AI refining its own work, the number of critical vulnerabilities had gone up by nearly 40%. The researcher's conclusion was blunt. You need human expertise in the loop. The machine left to polish its own work made it worse. Now, this is the counterpoint because I don't want to be unfair to the tools. None of this means that AI coding assistants are useless.

[00:08:36]They're not. I use them myself for real things most days. For the right task in the right hands with the right review, they are genuinely helpful and can improve productivity and quality. The point isn't that the tool is bad. The point is what's the tool good at? It's very good at producing plausible code quickly. And there's some good evidence for these things, too. The best case for AI is that developers using it completed 26% more tasks 55% faster. Juniors leveled up more quickly when working with AI. And here's why everyone of those results properly read still points to the same conclusion that I'm trying to point you at today. In the words of Dora, the source of these findings, AI is an amplifier. It makes teams with strong engineering practices do better and teams with weak engineering do worse. AI is not on this evidence good at the judgment that decides whether code should exist, whether it's correct, whether it's secure, and whether the next person will be able to live with it. It can't infer the context of how scalable, how resilient, how secure something should be. Someone has to tell it those things. And that kind of judgment is really the whole job of software development. There's a broader confusion though underneath all of this that I think is worth calling out.

[00:09:59]There's an assumption baked into the replace all replace the developers bet that some firms have taken. The assumption that a developer is a person who converts tickets into code. The job's just typing. If that were true, then yes, a machine that types very quickly would be a very straightforward replacement. But this is never really true and never was. The typing was always only the tip of the iceberg. I talk more about this in this episode.

[00:10:28]This lesson shouldn't come as any surprise. I'm sure that lots of people watching have had the experience of working with or in a codebase that they didn't create. We even have a name for systems like that. We call them legacy systems. And if you've ever worked in a big company, my bet is that you've seen some truly awful code in some of those legacy systems. Tactical crap that no one would add on purpose to a new system. In one trading system that I worked on for a major bank, a system that we were tasked with speeding up. It had seven different cues separating eight different processes to simply get a message from an MQ series message bus to an a web-based UI. So perhaps that's actually eight different cues and nine different processes. There was no good reason for any of this. And it was a horrible mess that took me and my team several weeks to understand and untangle before we realized that all this complexity served no useful purpose at all and only served to make the software slower and more complicated than it needed to be. But this system had been maintained by people without any real mental model of what's going on. And that seemed like a pretty good analogy for AI coding assistance to me. The system had grown to be unmanageable over several years and so had devolved into chaos. The result was so slow in execution that there were literally no users left to use it. And it was so expensive and slow to change that they hired me and my team to come and fix it.

[00:11:58]Now I want to be scrupulously fair and deal with the strongest counterargument to all of this because there is one.

[00:12:05]Someone will say, "But Dave, the developer job market has contracted. So clearly AI is replacing people." And that's certainly true. Getting a new job has been tougher lately. But when you look at the actual figures, they tell a more precise, more nuance story. In the US data, the narrow category of programmer, and hold on to that word, has fallen sharply by something like a quarter over the last two years. But the broader category of software developer has grown and is projected to keep growing over the next decade. So the market isn't eliminating the work. It's repricing it. And it's paying less and less for pure programming, the typing bit, the ro production of code, the bit that the machine can now do more cheaply. That's certainly true. But it's paying more and more for engineering.

[00:12:58]the understanding, the design, the judgment, the responsibility, the line between those two words is turning out to be one of the most important distinctions in our industry. And I would say that's the theme for this channel to a large extent. And it reframes the whole of this debate. The story was never really AI replaces developer and then companies rehire them. The more interesting, more accurate story is that some organizations placed a bet that coding was the job and so automated their coding and then they discovered that the engineering bill still had to be paid in review, in debugging, in security, in maintenance and so on. You don't get to skip that bill. You can move it around perhaps you can even defer it a bit but it always comes due and the people who pay it are called engineers. So, let me come back to where we started. Are companies rehiring the developers that they replace with AI? Honestly, based on the data, that's more of a meme than a fact. And I'd rather tell you that than sell you a comfortable story. But the deeper change underneath is real. And I think it's more useful. The evidence, the measured, controlled, peer-reviewed evidence is telling us something that we should have known all along. AI is genuinely good at writing code these days. And writing code was never really the hard part. The hard part is the understanding the problem, designing something that fits it and keeping it working and changeable over time and across many many people and many many years. That's the engineering. That's the part that doesn't really fit on one screen. And it's this fact of the reality of our profession that is the part that the market is quietly learning to value a little more, not less. So here's the takeaway I'd leave you with.

[00:14:43]If you want to be valuable in a world full of machines that can type code, don't compete with them at typing. Get better at the things that the typing was always hiding. Understanding design, testing, judgment, and taking responsibility for the result. If you'd like to learn about that, we have some great training courses which you can check on our training site. The machines produce plausible code in seconds. They don't reduce the need for engineering though, in my view. that increase it.

[00:15:13]Thank you for watching and if you enjoy our stuff here on the Modern Software Engineering channel, please consider supporting our work by joining our Patreon community and supporting our sponsors. Thank you and bye-bye.

[00:15:28]>> [music]