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 polished, nobody notices the gap as quickly. In the past, a weak engineer was often rate-limited by their own speed or amount of stack overflow copy/pastes. Now, bad taste can be expressed at machine speed, wrapped in decent formatting, and sent to review as if we should all be grateful.
Do Not Hurt The Next Person’s Brain
This is why code that does not hurt other people’s brains still feels important to me. It sounds casual, but it is actually a pretty serious standard. Most systems are not destroyed by one big mistake. They become painful through hundreds of small decisions that make the next person think harder than necessary. A vague name here. A duplicated condition there. A service that knows too much. A helper that is not really a helper. A test that locks in implementation instead of behavior. None of these things looks catastrophic in isolation, but together they create the kind of codebase where every change feels like a lost cause.
LLMs do not save us from that. If anything, they can accelerate it. The better version of AI-assisted engineering is not letting the model write whatever and clean it up later because later is where tech debt goes to become culture. The better version is much more boring: give the model a smaller box, keep the diff small, make the boundaries explicit, ask for simple and stupid code, ask for tests that prove behavior, and reject anything you cannot or author cannot explain. Treat the model like a fast assistant, not like the owner of the system.
In practice, you do not ask the model to design a feature; you ask it to implement a constrained change inside existing patterns, with the relevant context already encoded in repo instructions, skills, examples, tests, tool permissions, and task-specific success criteria. You prompt for the math, not the architecture. This is also why the most impressive AI coding stories usually have rails around them. Ports, migrations, mechanical rewrites, equivalence checks, strong tests, typed contracts, narrow diffs, reproducible commands, review checkpoints, and clear constraints. The model is not being asked to discover the shape of the system from thin air. It is being asked to move inside a shape someone else already understands.
A model can generate a function. It cannot take the pager. It cannot sit in a postmortem and explain why a simple feature now touches seven files that should never have known about each other. It cannot carry the operational shame of breaking something obvious in hindsight. That part is still on us. And I am not going to let myself, or my teams, get paged for code we do not understand just because it arrived quickly and looked clean enough to merge.
The New Quality Bar Is Ownership
Velocity is a vanity metric if it results in an unreviewable block of black-box logic. If you can't refactor it without a total rewrite, you don't own it and you're just renting it from a statistical model. Ownership is the new quality bar. Can the generated code be deleted without fear? If the answer is no, I do not care how cheap it was to generate, it is already expensive.
Quality matters because code is becoming abundant, and when something becomes abundant, the scarce thing becomes more valuable. The scarce thing is judgment and taste. It is the ability to look at something that works and still say, this will hurt us later.
The producing code got cheaper but the ownership did not.