When Code Is Cheap, Does Quality Still Matter? | Yusuf Aytas

The other day we were having a casual conversation on quality and looking at a few code examples. If you want serious engineering, you want your code to use a few principles like SOLID. You want to see that the code does not hurt other people's brains for no good reason. This has been the case for a very long time. People grew their gut feeling over the years by reading code, breaking code, fixing code, reviewing code. Sometimes you win the lottery by being the person who had to understand a clever decision made by someone who had already left the company. Now the question becomes whether that really matters anymore. When code becomes so cheap with LLMs, do we still care about it?

I think we do, but maybe not in the same way we used to.

The Old Smell Test

The easiest way to spot a serious engineer used to be reading their code. Following every pattern from a book was never really the point. Good engineers break rules all the time, and sometimes they break them for very good reasons. The real signal was different. You could see whether the person understood what they were doing, whether they had some respect for the next person, whether they created a small boundary where a small boundary was enough, or whether they created a beautiful cathedral to solve a garden shed problem.

That is the taste. Taste as in knowing when a function is doing too much, when an abstraction is hiding the wrong thing, when a dependency is about to leak everywhere, when a name is vague because the author did not understand the domain well enough to name it properly. Taste as in looking at a piece of code and feeling the future cost before the future arrives.

Just Vibe Code It

The Cost Moved

LLMs make this whole thing uncomfortable because they attack the old cost model. If code takes less time to produce, the pressure to care about the first version naturally drops. Why spend twenty minutes cleaning up something the model generated in ten seconds? Why argue about structure if the same model can rewrite the structure tomorrow? Why care whether the code is elegant if it works and the tests pass?

The argument sounds reasonable until you actually look at where engineering time goes. Nobody's calendar is full of typing meetings. Time goes into figuring out why the system behaves differently from the original design, into tracing a bug through three services before realising the assumption was wrong on day one, into the conversation before the code where someone has to understand the problem well enough to know what they're even building. The code at the end of that process is almost a receipt. Proof that the thinking happened. LLMs can produce the receipt without thinking, which is not a shortcut so much as a forgery.

LLMs made the output cheaper but they did not make understanding cheaper. The real quality was never about aesthetics. A clean function makes the next change cheaper. A good boundary is there so that when something breaks, you have fewer places to look and fewer things to hold in your head at once. A good abstraction means one concept lives in one place. When it changes, the change stays there.

In the LLM era, quality is less about protecting the act of writing code and more about protecting the act of changing code.

The Dangerous Code Looks Good

In some ways, LLMs make pain easier to create because they remove the natural brake that used to slow bad code down. Before, writing a lot of messy code still took effort, and that effort at least created some friction. You could still do damage, of course, and many people did, but there was a physical limit to how much nonsense one person could type in an afternoon. Now the nonsense can arrive fully formatted, with comments, with tests, with confident naming, and with enough surface polish to make a tired reviewer think it is probably fine.

That is the dangerous part. Bad code used to smell bad more often. AI-generated bad code can smell like lavender for the first few minutes. AI generated code can put the wrong concept in the wrong place, duplicate logic that already exists somewhere else, invent a new pattern because it did not notice the old one, or create a branch of behavior nobody understands well enough to safely remove later. This is why the old engineering gut feeling still matters.

A serious engineer with an LLM is dangerous in a good way. They can move faster because they already know what shape the solution should roughly have. They know when to ask the model for a small function, when to ask for tests, when to reject an abstraction, when to stop prompting and write the damn thing themselves. They can look at generated code and feel that something is off, even before they have fully explained why. That feeling is years of scars presenting themselves as magic.

A weak engineer with an LLM is dangerous in the other way. They can now produce more code than they understand, and because it looks...