Disposable Code Is Here to Stay, but Durable Code Is What Runs the World

Every day I seem to run into yet another post with someone solemnly opining that “writing code has never been the hardest part of software engineering.

And hey, that’s smashing. As an engineer from the ops/infra/SRE side of the house, I feel like I’ve been saying this my whole career. (Is there anything more satisfying than being proven right in public? Not in my book.)

So, which is it? Is writing code a valuable skill that people should practice and build up, or on the way to becoming obsolete; maybe even a skill set that dates you, like cursive writing?

The answer, I think, is “both.”

The software domain is splitting in two

Software development is in the process of bifurcating into two very different domains: disposable code and durable code.

At the moment, engineers are bringing largely the same skill sets and tools to both domains, but this won’t last. The skill sets, tool chains, and definitions of success have already begun to diverge, and they are likely to split into different disciplines entirely.

Some people seem to be carrying around a lot of anxiety about whether the days of durable code are numbered, but I think this is nuts. Both types of software are here to stay, at least for the foreseeable future.

Disposable code vs. durable code

The uses for disposable code have exploded since ChatGPT was released: design mocks, experiments, data processing scripts, exploration, prototypes, hobby apps, and more. You generate some code to do a thing, you do the thing, you throw it away. Generate ten thousand variants and let them fight it out, if you feel like it. It’s so cheap and easy, it feels like magic.

And then there’s the code that we rely on for bank transactions, package deliveries, medical results, satellite launches, airline flight paths, self-driving cars, mortgage payments, and nuclear power plants. This is durable code, and it’s going to stay that way.

Durable code is used when the stakes are high, the losses are material, the ripple effects of failure or performance changes throughout the system are complex and unpredictable. Highly regulated industries require durable software. From a risk management perspective, people need to be able to read the code and understand the system, so they can follow the money or respond to customer complaints, hundreds or thousands of times a day.

Here’s one (unscientific) rule of thumb: the lower on the stack you go, the closer you get to laying bits down on disk, the more dependable and predictable our software has to be. Databases and operating systems will be durable code til the stars die out.

The cost of software is defined by its maintenance

The difference between disposable code and durable code is not about whether the code was generated by AI or written by a human, or even how difficult it was to write. The cost is defined by the standards you are building to, and the rest of the software development lifecycle: how well you expect to maintain it, extend it, migrate it, understand its behavior, or fix it when it breaks. This is the expensive part of software development, the type that requires deep expertise and familiarity with your language and environment. Disposable code is cheap because you don’t even try to maintain it.

Because everything we know about durable software development—or what we used to just call “software development”—tells us that the cheapest, easiest way to build good software is by investing in the sociotechnical systems that unlock fast feedback loops. You frontload tests and CI/CD, so you know when something breaks or regresses. You frontload observability, so you can understand what’s happening and why. The time you spend on testing and observability might feel like overhead, but it’s not. It’s actually the thing that lets you go fast forever.

As Laura Tacho and others have noted, the only companies currently able to reap efficiency gains from their AI investments are the ones who have already invested in reliability and observability. In other words no, AI has not eliminated the need for fast feedback loops and software guardrails—it’s made them more important than ever.

The fact that code generation doesn’t dramatically upend the cost model of durable software development doesn’t mean it’s not useful, of course. It can absolutely make the development process faster and easier. But you still need to understand the code you’re committing and roll changes out in a controlled and considered way. If you introduce uncontrolled chaos into your durable software environment via unreliable, unmaintainable, un-understandable code, your cost goes 👆and speed goes 👇. That doesn’t help anyone.

Durable software is about trust

Call me old fashioned, but there is no test suite on earth that could make me trust a new chunk of code more than I trust the code that’s been running in production for two years. That’s how trust works; it takes time.

The only way to build confidence in your code is by exposing it to reality in a controlled manner, then iterating on what is known and stable. Smaller, more frequent diffs are the most dependable and cost-effective way to introduce changes into a massively complex web of software interdependencies. If the requirements for your code include reliability, stability, predictability, or performance, the durable model is the way to go.

There is no point in over-engineering software to be any more reliable or performant than it needs to be. Reliability is especially expensive to design and maintain. Alex Ewerlof calls this the 10x/9 rule: “For every 9 you add to your SLO, you’re making the system 10x more reliable but also 10x more expensive.” It makes sense to replace expensive, durable code with cheap, disposable code wherever it will satisfice.

But I suspect (just a guess) most of the growth in disposable code will come from inventing new uses, rather than taking over large chunks of the existing software domain. I think reliability and maintainability matter more than most people realize, and are harder than people expect.

Disposable vs. durable modalities

Disposable and durable code are modalities that can and do coexist in the same product, codebase, or project. These are complementary skill sets, especially for software engineers who have already invested in the skills for developing durable code.

Some of the most interesting use cases for disposable code that I’ve seen have been used in the process of making code that is ultimately durable.

A new product or feature might start out as a disposable prototype, then be converted into durable code once its shape comes into focus. The ease of turning out ancillary code like tests and docs should ultimately mean that more tests and docs get written.

I think some of the most interesting places to watch in years to come will be the boundaries between disposable and durable software, and how, or when, or why projects move fluidly between one state and the other.

AI has a role to play in both domains

This isn’t about “using AI” vs. “not using AI,” or even about generating code vs. not generating code. It’s about understanding the cost model and the risk profile of the type of development you’re engaged in.

There’s a lot of energy right now in the AI devtools sector around getting better at generating specifications, operating parameters, and functional descriptions. This is awesome, and it’s really fun to watch. I expect disposable code will not be code that humans can read or understand, for the most part; or rather you could say the spec is the code, and implementation details are below the fold.

If it’s easy to achieve proficiency with disposable code generation tools, it probably won’t be thought of as software development (and the pay scale will drop accordingly). If I had to guess, I suspect it won’t be a profession at all so much as a skill set, much like typing or spreadsheets, that any tech-literate modern worker is expected to pick up in order to perform the functions of their job in marketing, sales, product, design, etc.

For durable code bases, AI tools can help us generate code, sure; more importantly, it can help with the parts that are actually expensive. One of the most exciting things to me personally has been seeing rewrites that might have taken years to execute in the past (or just wouldn’t have been done), but can now be done in weeks or months using LLMs. AI can help with instrumentation and incidents, analyzing anomalous data, looking for outliers, or helping us understand our code and create that shared meaning.

The first wave of AI-assisted development was all about code generation, but I actually think that’s the least interesting part. The world is already awash in shitty code, so I can’t get too excited about astronomically more shitty code being unleashed upon us. But the code that runs the world, that’s exciting to me. The coordination tax on large groups is enormous; if AI can help a smaller number of engineers own more product surface and move faster with more confidence, that’s exciting.

Don’t freak out <3

The distance between a junior engineer and a senior engineer can often be measured in humility. A senior engineer knows better than to trust their code. Even if you’re an expert in your entire stack, and you intimately understand the change you are rolling out, you don’t know what’s going to happen. If you think you do, you really don’t. So you roll it out safely, progressively, incrementally, with tools. You accept the limitations of your control. Trust but verify.

Look, I won’t even try to guess what’s going to happen more than five years out. But inside that time frame, I can’t see a world where we move away from the durable software model. If it ever does happen, it won’t be overnight. We’re going to see it coming, because confidence takes time.

Anything that can be done with disposable code probably will be, because as we all know, durable software is expensive and hard. But disposable software is a skill set; durable code is a profession.

But when it comes to the code we have a lot riding on, the code that runs the world, I don’t see a path to a world where there is any substitute for production. Where we don’t verify that it works BY putting it in production and letting it bake, where we don’t gain confidence in the code the longer it runs. Where that confidence is not fucking precious.

In one sense, this new ability of ours to generate an endless supply of cheap, disposable code is an illusion, because in order to generate that code, you silently rely on millions of components, running billions of lines of durable code in a predictable, reliable, precise way, from your Apple laptop to the python interpreter to the device drivers, ethernet packets, routers and bridges and switches and hubs, transcontinental fiber optic cables, wifi and SaaS and databases, caches, microservices and web servers. It’s turtles all the way down.