Coding Fast, Flying Blind

LLMs can generate code fast. Almost instant. That’s why you hear code is cheap now.

But was writing code ever the main problem?

Writing code is one of many parts when building a reliable system. In fact, it was never the bottleneck. The cost lies elsewhere.

You mistake writing code for shipping software. Lines of code is not the same as getting a reliable working system into users’ hands.

The Speed Trap

You keep hearing LLMs make you 10x faster. The question is, how stable is that speed? It doesn’t make sense if you ship 10x more bugs to your users.

LLM generated code often ignores the complexity of a system. It picks what’s popular, not what fits. The code works alone, but breaks when it meets the rest of your system.

All of this speed doesn’t save time in the long run. Instead, it pushes the cost for later.

Technical debt grows with interest. The faster you pile it up, the sooner it catches up.

The New Bottleneck

Shipping doesn’t stop at writing code. You need to make sure it works in production reliably. You need to review it, test it, integrate it, deploy it. None of that gets faster just because the writing part got faster.

What happens instead is more code flows into review. Reviewers get overwhelmed. Bigger changes arrive faster than anyone can reason about.

Bugs slip through. The PR sits for three days, someone merges it to unblock the sprint. No one actually reviewed it.

Or worse, the reviewer throws the diff at an LLM and copy-pastes whatever it says back into the PR. No thinking, no judgment. The author could have done the same thing. Nothing of value was added.

Speeding up one part of a process doesn’t speed up the whole thing. It just creates a pile-up at the next step. If code review was already the bottleneck, making code generation 10x faster only makes the pile-up 10x bigger.

What’s the point of writing 10x faster if everything stalls at review?

Understanding Can’t Be Delegated

We can hand off the writing to an LLM. We can even ask it to explain what the code does. But the thinking behind why the code was written that way? That’s gone the moment no one on the team went through it themselves.

You can outsource your coding, but you can’t outsource your understanding.

Maintaining code you don’t understand is draining. Sometimes almost impossible.

You end up letting the LLM handle everything blindly. Each time you do, you understand less. The longer it goes, the more debt you stack up with no way to pay it back.

LLM generated code ages the opposite of wine. A bad codebase gets worse faster when you throw AI at it. Bad patterns multiply. Problems stack. 10x faster to build. 10x harder to fix.

If you look at LLM generated code next to human-written code, the AI version is harder to follow. It compiles. It looks right. But something is off. The structure doesn’t reflect anyone’s intent, because no one had an intent.

Debugging this kind of code is worse. You didn’t write it, so you don’t have a mental model to fall back on. If a person wrote it, you can at least ask them why. With LLM code, there’s no one to ask.

You hand it back to the LLM, which gives you different code. Not better code. Different code. A loop with no exit.

Design is Still Human

LLMs can’t make sane judgment calls for five years down the road. They pick what looks right, right now, based on training data. Not the one that fits your limits, your team, your users.

Architecture is about tradeoffs that show up over years. It requires understanding the business, what the team can handle, and the cost of change. An LLM has no stake in any of that. It doesn’t care if the system is still standing in two years. It doesn’t even know.

Engineering is not about writing code. It never was. It’s about choosing the right approach given the limits. Making sure the system is reliable for the user and easy to work on for the team that comes after.

LLMs made writing code cheaper. But writing code was always the cheap part. Understanding, designing, reviewing, maintaining, operating. That’s where the cost lives.

The hard parts were never about typing speed.