It's 2020. You're the most senior person on your team, in charge of code quality and architecture. You've set up good engineering practices, you thoroughly review PRs from people who are less experienced than you and work hard to maintain a healthy codebase.
Then at some point, you go on holiday. When you come back, the codebase is a mess. Everyone merged each other's PRs without really paying much attention, someone added a bunch of new tables to the database to denormalise it because it was easier and they added serverless or Kafka to the stack without any solid evidence that they needed either.
It's okay. You can fix this.
Fast forward to 2026. You haven't been on holiday. It's just a normal
Monday morning. You make yourself a nice coffee, open your computer and
find yourself with 7 PRs to review. You open the first one:
+24506
-3938
lines, accompanied by some AI-generated description of what they're
supposed to do. Somehow, your team has made more changes since Friday
than they used to make while you were away for a few weeks.
AI removed the speed limit
AI makes projects with weak engineering culture fail much faster.
There used to be a time when people sat down and talked about how they'd do something. Now they can just prompt an agent for a few hours and open a PR.
The most tragic aspect of this way of working is that, to the untrained eye, it works.
If you pull the branch and test it, you'll probably get something somewhat functional. So what do they do? They keep going. Again and again. Until the project reaches a point where no one knows how anything works.
Just like someone buying a new luxury car on a credit card. You don't see the debt. You just see the car that looks great.
But then users start to report a weird bug. It's the 4th time your team has been trying to fix it. I mean... asking AI to fix it. Unfortunately, it seems like not even Fable can figure it out.
You go talk to the person who worked on this feature.
- "So where does the data come from?"
- "Hmm... actually I don't know. Let me ask Claude."
You sit next to each other watching an endless wall of text appear on the screen. Neither of you has any idea whether any of it is true but Claude seems very confident.
"Let's just turn on ultracode and ask it to double-check?"
This one will take a while. You start talking about the latest drama on X.
You finally get an answer back.
- "Does this make any sense to you?"
- "I'm not sure."
- "Didn't you build this like... last week?"
Silence.
This project has become so convoluted, with so many layers and services, that no one on your team could possibly start to understand what's going on.
So, what do you do?
Fixing it would require such a colossal amount of work that it would be impossible to even start justifying it to anyone in management.
And what are you even thinking about? It would end up in the exact same state again in just a few months anyway.
- "Let's just ask Claude to fix it."
- "Okay. I'll create a loop and goal so it doesn't stop until it's checked that everything works."
- "Sounds good"
- "Actually, I ran out of Fable usage for today so I'll run it tomorrow"
You grab another coffee and walk back to your computer. You now have 13 PRs left to review. You see something you don't quite understand, so you message the person who wrote it.
- "Why are we doing this here?"
They send you a link. It's a Claude conversation.
Somewhere in that conversation, buried between Claude confidently recommending one architecture, apologising, changing its mind, your coworker asking it to reconsider again and another 15 rounds of changes, is apparently the design decision behind this code.
- "Which part should I read?"
- "Probably all of it."
Does this sound familiar?
Whenever I talk about this, someone eventually tells me that nobody ever fully understood large systems anyway. It's true.
You were never expected to understand every service and every database. But at least someone did and would explain it to you.
Now they ask an LLM because they don't actually know themselves.
You can't afford bad engineers anymore
In every team, there are competent people who make the project possible. There are also people who essentially make it harder for everyone else. And now anyone can produce more code in a day than they used to in a year.
In the story above, everyone is failing:
- The engineer opening a 25,000-line PR should have stopped the agent long before it got there. They should have understood what it was doing, broken the work into smaller pieces and questioned every new abstraction it introduced.
- The person reviewing it should have refused to review something that large instead of giving in.
- The person adding Kafka should have been able to explain exactly why it was needed.
- The person who built the feature should have been able to explain where the data came from without sending a link to a Claude conversation.
But what's the problem then? Just use AI to fix it. Well, it's not that easy...
Before anyone jumps on this, none of this means technical debt is always bad. The important part is that you know it's a shortcut.
Anyway, reverting a bad decision is hard. Very hard.
For example, how long would it take an LLM to add a bunch of tables and columns to the database? 10 minutes?
But once you start storing data there, you can't just remove them. You have to come up with a migration plan, make sure you don't disrupt the system because people are paying to use this every day. You have to think about what you'll do if the migration fails. Make sure you don't end up with orphaned foreign keys. It's just so much harder to fix. Even with the best model you can get.
And while you're fixing it, more PRs keep coming in. More code, more abstractions, more decisions. A person can generate 20,000 lines of code in an afternoon, but you still have to sit there and understand what those lines actually do.
By the time you've untangled one bad decision, five more have been merged.
The new AI economy
Of course, bad engineers were always a liability.
It has been like this for decades, well before OpenAI or Anthropic existed. Bad decisions compounded, unnecessary complexity accumulated and teams ended up maintaining systems nobody really understood.
The difference is that there used to be a limit to how fast you could do it.
Today, implementation is cheap. You are paid to make good decisions. To build software that will scale while managing complexity.
Ask yourself why companies are paying six-figure salaries for engineers in London or San Francisco in the first place.
If all they needed was someone who could turn a specification into working code, why were they paying that much when they could already get it done cheaply elsewhere?
Why are the tech companies claiming that "software is solved" still paying top salaries to attract the best people they can?
My bet is that AI pushes salaries further apart. To be employable, there's a bar you have to clear and that bar is whatever the current best model du jour can do.
Good engineers have become more valuable because AI lets them move much faster. They don't need as many people around them just to do the implementation work anymore.
At the same time, bad engineers have become much more expensive to hire.
I wrote about this before when I said the vibe coder career path is doomed.
You need to contribute beyond what everyone already gets by giving an agent a prompt.
If you lack the judgment required to evaluate the LLM's recommendation, asking for more judgment doesn't solve the problem.
At some point, someone still has to know what is going on. And that's the most valuable person on the team.
The people who don't will become much cheaper to hire or get replaced entirely while the money gets funnelled towards an increasingly smaller number of people who can actually be trusted.
I don't think this is going to be limited to software engineering either. I believe the same thing is going to happen across most knowledge work. AI will make the best people much more productive and the bad ones almost impossible to hire. Before, there was a good chance someone would catch their bad decisions before they went too far. Now they can make changes faster than anyone around them can realistically review or understand them.
Answers to the most common objections
"Bad engineers always existed"
The difference is the speed.
It is the difference between crashing at 30 km/h and crashing at 200 km/h. Before AI, a bad engineer would struggle to produce code that even compiled. When they did produce something, it took them a long time and the blast radius was limited. The damage was bounded by how fast a human could type.
Now a bad engineer can produce 10,000 lines of working code before lunch. The damage we can do in an afternoon used to take them months. The speed at which bad decisions compound has changed completely while the speed at which you can fix them has not.
"Just fix your process"
Several people argued that the real problem is lack of process. If you had proper tests, CI, code review and architectural reviews, AI-generated slop wouldn't get through.
We had all of those things. None of them disappeared.
The problem is that they were designed for a world where producing a massive amount of change was impossible. Code review don't work anymore when someone opens 10 PRs a day with an AI-generated description. Tests work when they cover the behaviours you thought to test. They do not catch the behaviours nobody thought to test.
How many times have you had a completely green CI with full coverage and still shipped a bug?
The difficulty of producing code was by itself one of the limiting factors.
If the people trying to understand changes and guard quality are now the bottleneck, you have three options. Generate less, find a genuinely better way to validate or accept lower quality.
"You are just anti-AI"
Everytime I critisise AI someone says I'm a Luddism. I'm refusing to adapt to the new world, clinging to the old ways.
I use AI heavily. I have said this repeatedly. I use it every day and I have no interest in going back to writing everything by hand.
The point is that we have made producing large changes extremely cheap and fast while understanding those changes is still slow, difficult work. We have no shortcut for building a correct mental model of what a change does.
Maybe one day we will find one. As of today, I do not think we have one.
You can be a heavy AI user and still recognise that there are serious problems with how it is being used.
"More output means more productive"
Someone generates 10 PRs in a day, the numbers look incredible, surely this person is ten times more productive.
Not necessarily. The supposed 10x engineer may simply be someone stealing productivity from everyone around them.
If I generate 10 PRs in a day but three engineers now have to spend the next two days reviewing them, figuring out what I changed, correcting bad assumptions, debugging regressions and explaining why half of it needs to be redone, I have not become 10x more productive. I have just moved the work onto other people.
Worse, I am consuming the time of the people who are usually the hardest to replace and whose attention is already scarce.
PR count, lines changed and features "completed" are terrible measures of productivity. You can make your own numbers look incredible while reducing the throughput of the entire team.
Some people pushed back on this by saying the real problem is bad organisations with broken incentives. It's true. If your company rewards ticket count over quality, the careful engineer looks like the bad employee and the sloppy one gets promoted.
"Pushing back just makes you're the toxic one"
Someone pointed out that trying to hold the line on quality can get you labelled as toxic. Everyone else is shipping fast and you are the person saying "wait".
I would much rather have someone on my team who ships less but whose work I can trust than someone much faster whose changes leave me wondering what problems we're going to discover later.
You need to be flexible and compromise when the business trade-off makes sense. But you also need a backbone. If you think something is going to cause real problems, bringing it up is part of the job.
And when production breaks, and it will, I need the person who made the change to actually understand it well enough to help fix it. Not show up with no idea what is going on.
"Just AI output is like assembly from a compiler"
We already trust compilers to produce machine code we do not read. Why is this different?
A compiler takes code and translates it into another representation while preserving its semantics. The compiler is not deciding what your system should do. It is deterministic.
An LLM is making decisions. It is choosing architectures, picking abstractions, deciding where to put things. When you ask Claude to build a feature, it is not translating your intent into code. It is making dozens of design decisions on your behalf.
If in five years I can give an agent a complete specification and reliably verify the resulting code against it, then sure, reviewing code may become obsolete and I would happily stop doing it. We are not there yet.
If you genuinely understand the resulting system, that is fine. That is not the behaviour I am criticising. But for the vast majority of very large PRs, especially AI-generated ones, I would bet money that the person opening it does not actually understand all of it.
"We ship 99% AI-generated code and it works"
I do the same. Most of the code I produce comes from AI.
You still have to put in the work to understand the result. If you are shipping AI code and you genuinely understand the system, you are doing it right. The article is not about you.
"AI can write the code" ≠ "I do not need to understand it anymore."
You can use AI heavily and still take responsibility for what it produces.
"Users don't care. It's just a CRUD app. Ship it and get paid"
I tend to find that this perspective comes from people working on relatively small or isolated projects.
On a large system, the customer being happy today is not enough. You need other engineers to be able to understand the system. Have you ever been on call and been woken up in the middle of the night to fix a production incident in a system you did not write?
If everything you build is small, isolated and easy to replace, then sure. Ship the ugly thing, get paid and move on. If you are going to be working on something for the next five years or more, you should probably spend some time thinking about what you are doing.
Nobody is getting paid significant money just to build a simple CRUD app. Even before AI. Companies pay experienced engineers because the supposedly simple CRUD sits inside a messy real system with years of business rules, constraints and integrations where bad decisions have consequences.
"What about junior developers?"
I have worked with two junior developers recently who are very good precisely because they are trying to understand what they are doing rather than just producing code. They use AI to explore things they do not understand, ask questions to clarify their reasoning and double-check assumptions. They use the tools to increase their understanding.
I have also worked with senior developers who basically gave up and stopped trying to understand the code. They became much worse engineers as a result. At this point I would much rather work with those two juniors.
The problem is not AI. The problem is using AI as a substitute for understanding instead of a tool for building it.
Related to this, some people argued that we should not teach skills that AI can do better. The fact that a machine can do something better than humans does not automatically make learning it pointless.
We still teach arithmetic and algebra despite computers being vastly better at calculation. We teach spelling, grammar and essay writing. We even teach history and geography while everyone permanently has a device in their pocket that can look up almost any fact in seconds.
How else would you be developing the mental models required to understand, question and verify anything?
"Using AI is just delegation, like a manager"
A manager is not normally the person deciding how the software should be architected or implemented. Their job is largely priorities, people, coordination and resource allocation.
You are still an engineer. But you have delegated your technical judgement to an LLM. You just stopped doing the most important part of your job.
"Not all technical debt is bad"
Agreed. Debt is debt. Some of it is absolutely worth taking on.
I do not have any issue with intentional debt when you understand the trade-off and have a clear payoff plan.
"How do we make more senior devs if we don't hire juniors anymore?"
By reducing the number of entry-level engineering roles, the industry is sabotaging its own future. Fewer people learning means fewer people capable of maintaining systems down the line.
It's true. But the industry does not really owe people opportunities. Even if you think it should, that is not how companies are going to behave.
That said, maintenance is the essence of the software industry. LLMs cannot modify projects spanning hundreds of thousands of lines. The skill required to partition architectures is still entirely human. Learn that.
That is exactly why experienced engineers are becoming more valuable, not less.
"Will anyone actually care?"
They will care when nothing works, nobody seems able to fix it, building new features takes forever and every change breaks something somewhere else.
This was already happening before AI. But now, a lot more companies that previously might have taken many years to reach an unmaintainable state can get there in just a few months.