I've been thinking a lot about code quality lately. Partially because it's my job, but largely because it's so clear that LLM-written code is here to stay in at least some capacity. I've seen good and bad LLM code, mostly bad, with its presence justified with a statement along the lines of "I built it faster like this and it's providing value." But... is this code an asset? Or is it a liability that we will inevitably have to fix in the not-so-distant future?
The accepted answer seems to be that code is a liability: [1] [2] [3]. But if that were the case, why would anyone write code? Why would software engineers demand such high salaries? The reality is that code is both an asset and a liability. Code is a bet that the value it provides is worth the time spent writing and maintaining it, and the system around it. That's a lot of factors to consider.
Code is an asset
Software you develop is an asset. The end result should be a meaningful improvement to your business. And since software is made up almost entirely of code, you might assume that code is an asset, just like the fully formed software would be. Case closed.
Code is a liability
Every line of code is something that must be maintained. Any one could potentially break an entire business. Existing code has an active maintenance cost; that's clearly a liability! The code itself must be separated from the business product; that software is made up of code but it isn't itself code.
Code value is nuanced
High-quality, battle- and unit-tested code that's been running in production environments for years without incident seems like it should clearly be an asset. That provides obvious business value, and its maintenance burden is near 0.
But even something like this has a cost. The abstractions used may lock the rest of your system into a specific type of thinking or force operation ordering that is less than ideal. The system as a whole might suffer because this code has been around for too long. And if you want to change it to adapt to incoming business requirements? Those tests are there to play defense against changing functionality; this is usually a good thing since it prevents accidental changes, but in this case they will slow you down immensely. Every comment in the codebase may need to be reexamined. Suddenly it's not so obvious how valuable that "perfect" code is.
On the flip side, there is vibe-coded AI "slop" code; chunks of LLM-generated code thrown at the wall to make something work, regardless of the system design or best practices. These are rarely tested, and when they are the LLMs regularly fail to test key portions of the functionality. It's nearly impossible to make changes to this code without accidentally breaking something. Clearly, this code is a liability.
But... what if it's not? What if that mess of spaghetti helped the business forward? What if it was thrown together on a tight timeline to prove if a feature was valuable or not, and the conclusion had been that it wasn't worth removing or pursuing further; the thing worked just well enough. You may have heard about indie video game developers shipping laughable code quality but still producing exceptional experiences. How much can you really separate the code from the software it produces? Surely there's at least a correlation between the two.
In fact, sometimes code quality is explicitly ignored in an effort to push features out to customers faster. It's become normal to hear engineers talking about "making tradeoffs" to be able to "move fast" and bring things to market. While I generally (and strongly) disagree with their philosophy, it does make sense.
Code is a gamble
My conclusion is probably unsatisfactory: every line of code written is a gamble.
Every line of code is a bet that it will provide more business value than it will cause maintenance burden and cognitive load on future engineers. You're betting that the problem that code solves will exist long enough to justify the time spent writing it. You're betting that any time you save by not writing tests or thinking through edge cases or even thinking about the system design around that code... you're betting that your time spent and saved was worth it.
The best engineers I know aren't the ones who write the most elegant code. Actually, that's a lie. They can write the most elegant code. But they also know how to make tradeoffs with their time - how much to test, how much to work out the perfect abstraction, how much to spend writing the most perfect version of the code they're trying to write. They're the ones who know when elegant code is worth it and when a quick hack will do just fine. They're the ones who can look at terrible code that's delivering value and resist the urge to rewrite it just because it offends their sensibilities. They're usually the ones who work best with others, adapting patterns from the codebases they are working in and pushing slight improvements where they can. They're the ones who understand that code is just a tool, not an end in itself, but that poorly written or understood code is an enormous liability.