Does code quality even matter anymore?

Everything you want to accomplish with a piece of software depends on only two things:

1. Understanding
2. Executing on that understanding

When I say everything you want to accomplish, I mean everything. Whether that’s aligning a model, improving system performance, getting more users, implementing some refactoring, everything.

This is fundamentally why we have observability platforms, debuggers, style guides, and even tests. (Yes, tests are there primarily to improve understanding, believe it or not.)

Everything we’ve ever done in the field of code quality is simply to enable understanding. The real output, the thing that really matters, is understanding.

The primary barrier to understanding is the difficulty of understanding. The harder you make something to understand, the longer it takes to understand it, the more likely you are to make a mistake with it due to a misunderstanding, the fewer people or AI models will be able to work with it, etc.

The Key Understandings

The most important understandings to have about a system are two:

1. What is the behavior of that system?
2. How do I correctly modify the behavior of that system?

Whether you’re a human or an AI model, these are the most important understandings you need about a software system.

In a very small system, I can describe to you simply what the system does, and you can correctly modify it by saying it should do something else. We start off with “it prints Hello World,”  you tell me “make it say ‘hi’ instead,” and I make it say “Hi World.” All I needed to understand was the initial, simple behavior, and I modified it correctly.

However, a system of sufficient complexity has nearly infinite possible behaviors. How many combinations of input does a C compiler have to deal with? How many possible ways could a web browser have to behave? Some of these systems have a set of possible behaviors that is infinite or close to infinite.

The only way for a human or an AI model to understand such systems is as component parts.

This is the most important part of code: the structure that it provides. For example, these two programs do the same thing:

On the left, you can see that this is Hello World, on the right you can only see a set of instructions. 

We have long discussed “readability” or “testability” as supreme, but what is truly supreme is understandable structure of the actual behavior. (Not just a separate proof or specification of the behavior, though those can be helpful. What matters most is the understandability of the thing that represents the behavior itself, which today is code.)

Modification Over Time

All of this matters for our immediate desires with our software (intending “move that button over there” and accomplishing that successfully), but it is most important when we think about having to continually modify software through many changes over time.

Every change has two probabilities associated with it:

1. The probability of the change itself being problematic (introducing a bug, being unable to be accomplished, having extreme timelines)
2. The probability of the change making future changes more likely to be problematic.

The first one is determined entirely by our two factors of success in software: understanding and executing on it. The most important factor, then, is the difficulty of understanding the system. And the second point is about how much harder this change makes it to understand the system. So you can reframe these as two factors about the system:

1. How hard is the system to understand?
2. Are you making the system harder to understand?

The two points feed into each other. The harder it is to understand the system in present time (point 1), the more likely it is that you will have to do something that makes the system harder to understand (point 2) in order to simply accomplish what you’re presently trying to do. Thus, complexity doesn’t grow linearly, but compounds over time.

The worst part about this is that there is a limit. There is a limit beyond which any given human can no longer successfully modify the system correctly in any reasonable period of time. We see the same limit over and over with AI models today—there is a limit of structural complexity beyond which any given AI model starts to flail.

Disposable Software

We can guess about the capabilities of future models and how they will change some of this, but mostly, I think we don’t have to, because there’s something else new that’s happening in the world with the rise of AI coding agents. There is a new kind of software rising up in the world. It has always existed to some degree, but it is about to become the most popular type of software in the world by many, many orders of magnitude: Disposable Software.

Imagine a world in which all of these things are true:

• The consequences of failure in a piece of software are minimal
• The number of people or other systems that depend on that software are minimal
• The cost of fully rewriting the software from scratch is minimal
• The cost of maintaining the software is minimal

In that world, code quality does not matter. There is no risk to incorrect changes. There is no compounding complexity over time. When you need it to do something different, you throw it away and start over.

Traditionally, we have always built durable software—codebases that live for years, depended on by millions of people, worked on by hundreds or thousands of developers, where the consequences of failure are dramatic. I expect this process to continue to exist in the world. I expect the most important systems in the world to always be durable software. In these systems, code quality and all the deep practices of software engineering matter deeply.

But far, far more software will be disposable software. Don’t like how the calculator on your OS looks? Have a new one in five seconds. Need to organize a party for your kids? Get a custom party planner, just for you, in minutes.

Degree of Durability

Between these two extremes of Disposable and Durable there is a spectrum, determined by the four factors I listed above:

• Consequences
• Dependencies
• Cost of Replacement
• Cost of Maintenance

Where all of those are high (and you should always err on the side of them being higher than you expect) all of the rigor of software engineering and code quality must be in play. Whether that’s done by humans or AI isn’t the point I’m making—I’m just pointing out that it must happen, and ultimately some person is going to have to be responsible for making sure that it’s happening.

What’s interesting in this new world is that there’s also an opportunity for some software to make it more disposable. What if you can put guardrails around a system so the consequences of failure become minimal? (For example, it doesn’t have access to any personally-identifiable information about your customers, there’s some other backup system that can function if it fails, it can’t access most of your internal network, etc.) What if you forbid other systems from depending on it? What if you stand up just a backend and let everybody vibe code their own frontend whenever they need it? There’s a whole new world of engineering practices we will build around how to have safe disposable software.

So no, I don’t believe that durable software engineering is going away. In fact, the total amount of durable software seems likely to expand enormously in the future, thanks to the incredible capabilities we have with AI. But there’s also a whole new world of Disposable Software, and we have to learn to support it, embrace it, and differentiate it from our durable systems.

-Max