Clean Code Was Never The Point

The only thing worth anything in your software is what happens when the CPU runs it. The source code has never had value to the end user. AI just made that impossible to keep ignoring.

I learned this the expensive way, with a startup I built with a former colleague. We had a vision we believed in, and when the early signals told us people did not care, we kept telling ourselves the pitch just was not sharp enough yet. It was not the pitch. Nobody was buying the beautiful thing we had in our heads, and nobody was buying our code either. It is a little obvious, but the obvious is worth saying out loud: no end user cares whether you followed SOLID or any of the other Uncle Bob principles. The only question that matters, and ever has, is whether that pile of code (the one you or your favorite AI agent wrote) solves a problem for someone who pays you for it.

The same blind spot shows up in the way developers talk about code. I have sat next to colleagues who treated a framework or a list of best practices like a religion, reciting rules they could not justify. Ask them why they are using a given pattern or framework and the answer is either “because it is the industry standard” or “because it is the correct pattern.” Honestly, that one hurts my soul. The problem is not wanting a clean, well-organized codebase. The problem is copy-pasting a stack of rules with no idea what decision they came from, and never noticing the plain circular logic or appeal to authority holding the whole justification up.

The user runs the program, not the repository

Nobody who pays for software ever opens the source. They run the program. The value shows up the instant the CPU executes the instructions and a problem someone had stops being a problem. Software is intangible in a way hardware is not. A chair has value in the wood and in the comfort it gives you. A program has value only in what it does when it runs. The elegance of the source is invisible to the person whose problem it solves. Hand someone two programs that solve the same problem the same way, and they cannot tell you which one is spaghetti code and which one is not. The customer, for that matter, has no reason to care.

Quality is a means, and it has a job

This is the point where people expect me to say quality does not matter. It matters a lot. It just does not matter for the reason most people use to defend it. Obsessing over code quality is a mistake, because polishing the source produces nothing for the user. Ignoring quality is a mistake too, and an expensive one. Code that grows fast and careless costs you adaptability later, and delivery keeps getting slower, exponentially so. When that happens, value stops flowing. Quality is what keeps software cheap to change, and that is its whole job. It is there to protect your delivery pace over the long haul, not to sit on a shelf as a trophy. The moment you treat clean code as the goal, you have confused the tool with the result.

AI made the bill come due

For years you could hide that confusion, because writing decent code was slow and expensive, so it looked valuable in its own right. AI stripped the disguise off. A machine now turns out correct, simple, working code faster than any of us writes pretty code by hand. If a tool ships the running result faster than you ship your handcraft, you have to ask what you were actually optimizing for. I hope the answer is the user’s problem, and not your own taste for elegance.

Once you accept that code is a means, the question changes shape. It stops being “is this code good?” and turns into “does this code let me keep delivering value cheaply and consistently?” You can argue the first question forever inside a pull request. The second one is far more concrete, and it pulls your attention back to what actually matters: delivering value to the end user.