What Happend to Good Code ?

Note: This article is handwritten with AI enhanced.

What is bad code?

Is it code that has bugs? Noo. Is it code that doesn’t have unit tests? No.

Bad code is code that someone else can’t understand. Everything else is secondary.

If code is readable, it solves most of the problems. You find a bug, read through the code, understand what is happening, and fix it. Maybe it takes a few minutes.

But what happens when you can’t understand the code? A simple bug can suddenly become a two-hour investigation.

And this is where I think we have a problem with the current AI coding trend.

AI Slop

With all the AI-generated code being dumped into codebases, it can sometimes take hours to read a simple implementation.

Why is everything so complicated?

AI models are heavily trained to write code. And when someone uses AI or “vibes” their way through building something, the result can very easily become technically over-engineered.

There have been many times where I’ve stumbled across a piece of code and thought:

Why do you need all of this?

Especially when we’re building a prototype.

A simple problem gets five abstractions, three interfaces, a factory, a service layer, a utility layer and God knows what else.

The code works.

But can you understand it?

Where Did Readable Code Go?

As someone who genuinely loves coding, I find this recent change in the trend worrying.

A lot of the good, readable code is disappearing.

AI-generated code often creates layers upon layers of abstraction. The code might follow every “best practice” imaginable, but it becomes difficult for a human to understand without spending a significant amount of time tracing through it.

And that’s a problem.

Because code is written for computers, but maintained by humans.

I have always had a habit of keeping things simple and minimal. I think before writing code. I start with the simplest thing that solves the problem. Once that works, I build around it when there is an actual need.

Not because I can.

Not because some design pattern exists.

Because there is a reason for it.

Code Reviews Suck Now

Code reviews used to be one of my favourite parts of development.

Now, sometimes, they suck.

You open a pull request and see a bunch of extremely complicated code.

You start reading one function. It calls another function. That calls a service. The service calls a factory. The factory creates another abstraction.

And somewhere down the rabbit hole, there is a simple if statement that could have solved the original problem.

Maybe I’m exaggerating.

But you know exactly what I’m talking about.

The scary part is that the code often looks professional.

There are types everywhere. There are interfaces. There are abstractions. There are tests. There are comments. There are patterns.

Everything looks correct.

But you still can’t understand what the hell is happening.

Started to Doubt Yourself?

Nah.

This isn’t about imposter syndrome.

Although it definitely felt like it for a moment.

I realised this after spending a very long time trying to understand some code written by someone else.

I’m pretty sure the developer took somewhere between 10 and 30 minutes to write it.

It took me two hours to understand what the code was actually doing.

And then the imposter syndrome kicked in.

“Am I actually a fool?”

Maybe I’m just not good enough to understand this.

So I did what any developer in 2026 would do.

I asked Claude to evaluate the code.

And Claude basically confirmed what I was thinking:

“The code is not written for humans to read.”

And that sentence stuck with me.

Because maybe that’s the actual problem we’re creating.

We’re getting really good at generating code.

But we’re getting worse at writing code that humans can understand.

And if the person who has to maintain your code needs an AI to explain your AI-generated code…

Maybe the code wasn’t that good in the first place.