No Human Will Ever Write Code Better Than LLMs? Better at What?

A tweet went around saying: "No human will ever write code better than LLMs. Accept this fact, stop pretending, and move on."

Here is my reply.

That's a lot of implicit "better" in that question. LLMs are trained to be plausible, not right. You can get as elegant/idiomatic/smooth-sounding as you want, and still miss the real constraints that matter (existing systems, team patterns, business considerations, failure modes, not-yet-real features).

Senior-level engineering is not just about "writing" code. It's knowing when not to. It's about recognizing real edge cases and not-baked-yet abstractions, knowing when a problem could be more simply solved, or not solved at all. That kind of judgment is hard to quantify, hard to prompt, and often non-obvious in a generated solution.

So yes, LLMs can be a handy tool, but not even close to the level of a real human expert.

The word that bothers me most in that tweet is "better". So I wrote down what it means.

"Better" is a word that we treat like a scalar value. In other words, there is one value that defines better. However, when you ask "better" at what are you measuring it? Lines per minute? Correctness? Maintainability? The courage to not build it? You quickly realize "better" means different things depending on the dimension you are measuring it along.

The productivity metric is lines per minute. It's a nice, simple metric, and it's easy to measure. There's a lot of momentum in this metric because it feels like improvement. However, it is only a measure of typing. It doesn't mean the resulting program is better.

A thousand lines of wrong code is worse than no code at all. A thousand lines of code that crumbles the second you look at it are even worse than that. So, instead we look at correctness. We want our code to be better because it's correct. It has the correct functionality, and it meets the spec. It passes the test. This is an improvement. But, that's not enough.

The real nightmare is that the LLM-generated code works until it doesn't, and it doesn't make sense to you. You'll get reasonable-looking code that somehow finds its way to production, and your payment pipeline will suddenly start silently discarding transactions because the model just decided to add a retry_on_timeout decorator to your transaction handler function that will catch the exception, log a WARNING, and return None. The code down the line will take the None and read it as a zero-dollar successful charge, so now your customers are getting the things they ordered for free.

Gramli tested a case like this in To Retry or Not to Retry. In one scenario, a payment request returned a 503 with a Retry-After header and no idempotency key. Most of the 8 models followed the header and said to retry. Only two said no.

Dex from HumanLayer explains why this happens in his talk "Harness Engineering Is Not Enough and Why Software Factories Fail". Many coding benchmarks give the model a pass or fail reward. The model wins when the tests pass, and nothing penalizes it for bad design. So it learns to add a try/catch or a type cast, because those make the test pass.

We can have a perfectly good piece of software that's unchangeable. This is the opposite of what we want. This is legacy code, and it is bad. We need to be able to make changes without pain.

So we improve it by making it maintainable. Maintainable code is readable, simple code, it's code that doesn't make anyone else want to burn down the office. It doesn't break as time goes on. Maintainable software just works. It meets new requirements and changes without breaking.

The last option is the best of all. It's the metric of wisdom. The "better" that allows us to say "no we shouldn't do that". It's better because it's less, but necessary.

In other words, code is a liability, it is something that we should keep at a minimum. This "better" is the most difficult to practice. It requires saying no to pressure, to budget, to a stakeholder who thinks they have a great idea. It is a less is more metric. However, the compounding interest it pays by not building something keeps growing.

So, "better" is not one thing. It's multiple things. It's a hierarchy, and it changes as we gain experience. We go from lines per minute to correctness to maintainability to not building.