AI is removing the middle class of software engineering

It's 2020. You're the most senior person on your team, in charge of code<br>quality and architecture. You've set up good engineering practices, you<br>thoroughly review PRs from people who are less experienced than you and<br>work hard to maintain a healthy codebase.

Then at some point, you go on holiday. When you come back, the codebase<br>is a mess. Everyone merged each other's PRs without really paying much<br>attention, someone added a bunch of new tables to the database to<br>denormalise it because it was easier and they added serverless or Kafka<br>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<br>Monday morning. You make yourself a nice coffee, open your computer and<br>find yourself with 7 PRs to review. You open the first one:<br>+24506<br>-3938<br>lines, accompanied by some AI-generated description of what they're<br>supposed to do. Somehow, your team has made more changes since Friday<br>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<br>do something. Now they can just prompt an agent for a few hours and open<br>a PR.

The most tragic aspect of this way of working is that, to the untrained<br>eye, it works.

If you pull the branch and test it, you'll probably get something<br>somewhat functional. So what do they do? They keep going. Again and<br>again. Until the project reaches a point where no one knows how anything<br>works.

Just like someone buying a new luxury car on a credit card. You don't<br>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<br>has been trying to fix it. I mean... asking AI to fix it. Unfortunately,<br>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<br>the screen. Neither of you has any idea whether any of it is true but<br>Claude seems very confident.

"Let's just turn on ultracode and ask it to<br>double-check?"

This one will take a while. You start talking about the latest drama on<br>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,<br>that no one on your team could possibly start to understand what's going<br>on.

So, what do you do?

Fixing it would require such a colossal amount of work that it would be<br>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<br>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<br>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<br>PRs left to review. You see something you don't quite understand, so you<br>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<br>recommending one architecture, apologising, changing its mind, your<br>coworker asking it to reconsider again and another 15 rounds of changes,<br>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<br>fully understood large systems anyway. It's true.

You were never expected to understand every service and every database.<br>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.<br>There are also incompetent people who essentially make it harder for<br>everyone else. And now anyone can produce more code in a day than they<br>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<br>long before it got there. They should have understood what it was<br>doing, broken the work into smaller pieces and questioned every new<br>abstraction it introduced.

The person reviewing it should have refused to review something that<br>large instead of giving in.

The person adding Kafka should have been able to explain exactly why<br>it was needed.

The person who built the feature should have been able to explain<br>where the data came from without sending a link to a...