# Does Code Quality Still Matter? It Depends on This — Max Kanat-Alexander, Capital One

Max Kanat-Alexander, Capital One

[Talk page](https://ai.engineer/talks/bU5gDVyu_28-does-code-quality-still-matter-it-depends) · [Video](https://www.youtube.com/watch?v=bU5gDVyu_28)

## Does Code Quality Still Matter? It Depends on This

Failure consequences, replacement cost, dependencies and maintenance help determine how much engineering rigor software deserves. Making that rigor cheaper is a separate opportunity—and makes it easier to recover when a supposedly disposable program becomes a lasting system.

![Recording frame at 16:03: Does Code Quality Still Matter? It Depends on This](https://ai.engineer/api/talk-essay-media/75199ff90f8363b5de9279237de6ac34bef9ee83aff99e9546734f3e5efc9a25)

Does Code Quality Still Matter? It Depends on This — recording at 16:03

### What code quality buys

[0:12](https://www.youtube.com/watch?v=bU5gDVyu_28&t=12s)

“It depends” is the senior engineer’s ready answer to whether code quality still matters. Max Kanat-Alexander of Capital One starts by asking what that answer depends on. Before deciding how much engineering effort to spend, we need a reason code quality mattered in the first place. Feeling good about the code is too weak a justification.

![Recording frame at 2:29: What code quality buys](https://ai.engineer/api/talk-essay-media/f9c3f3ec097c8af37b5d709e7a87f902c65844987bd1f62810a46de005d4fe40)

What code quality buys — recording at 2:29

His framework starts with two requirements for accomplishing anything with software: understanding, and executing on that understanding. Debuggers, observability, evaluations and tests help us learn what a system does or act on what we have learned. The same model covers work as different as aligning a model, scaling a system and driving adoption. Code quality earns its place by supporting those two requirements.

For a software engineer, two kinds of understanding matter most:

- **Actual behavior:** What the system really does, including behavior its documentation may not capture.
- **Safe modification:** How to change that behavior correctly and safely.

### Structure gives a large system understandable parts

[2:12](https://www.youtube.com/watch?v=bU5gDVyu_28&t=132s)

For a program that prints `Hello, World`, understanding and execution fit in a tiny example. Its behavior is the printed text. Change the requirement to `Hi, World`, and the intended modification is equally easy to describe. There is little else to understand before making it.

The codebase map of Chromium, the open source project behind Chrome, introduces a different problem. Its components can interact in too many ways for a useful description to enumerate the whole system’s behavior. A component provides a smaller unit of understanding: Chromium’s URL parser identifies the different parts of a URL. That behavior can be described even when the behavior of the browser as a whole is too complex to hold at once.

The next Hello, World comparison asks what structure contributes when output stays the same. Both versions would print `Hello World` on Linux. In one, `print("Hello World")` makes the program’s purpose apparent. In the assembly version, the reader has to work through register assignments and system calls to recognize the same operation.

![Recording frame at 4:41: Structure gives a large system understandable parts](https://ai.engineer/api/talk-essay-media/68d0f9ac230cfab08ad25bc5eed1e9c114a75652e1a96846f0870eb403f0d6c2)

Structure gives a large system understandable parts — recording at 4:41

At this small scale, a reader can still work through the instructions. Across millions or billions of lines, the missing structure becomes much more consequential. Readability and testability are ways of talking about the underlying need for an understandable system. Identifiable components let us reason about behavior without repeatedly reconstructing their purpose from individual operations.

### Two risks compound across changes

[4:42](https://www.youtube.com/watch?v=bU5gDVyu_28&t=282s)

Changing a system creates two kinds of risk:

- **A problem with the current change:** The code might behave incorrectly for users, but the project can also run late, exceed its budget or fail. A bug is only one kind of bad outcome.
- **More difficulty on future changes:** The modification can make the system harder to understand and alter, increasing the likelihood of problems later.

![Recording frame at 5:47: Two risks compound across changes](https://ai.engineer/api/talk-essay-media/fb186a5ad2719ca4fb593d0e712042d00b03049926aa31401682e7f2ec9e8b23)

Two risks compound across changes — recording at 5:47

These risks connect to understanding in different ways. Existing difficulty makes it harder to perform today’s change safely. New difficulty introduced by the change makes tomorrow’s work riskier. A confusing production configuration or behavior that emerges from complicated interactions can make the current system difficult to understand; a modification that obscures the system adds to that difficulty.

A change can cause immediate trouble, and it can also leave a less understandable system as the starting point for the next change. Kanat-Alexander describes this as a nonlinear compounding effect. At the extreme, almost every modification creates a problem. His giant mainframe example illustrates the result: a system becomes difficult to change at all, with costs appearing in timelines and organizational problems as well as software failures.

How a change can increase the risk of later changes
The two outgoing branches represent separate risks of the same modification. The return path carries added difficulty into the starting conditions for later work.
- Current system — Existing behavior, configuration or interactions may already be difficult to understand.
- Attempt a change — Reason about the system and modify its behavior.
- Problems in this change — Unexpected behavior, delays, budget overruns or project failure.
- Less understandable system — The modification can make future changes harder and riskier.
- Current system → Attempt a change (Existing difficulty raises the risk of changing it)
- Attempt a change → Problems in this change (May introduce)
- Attempt a change → Less understandable system (May leave behind)
- Less understandable system → Current system (Becomes starting difficulty for the next change)

### When software can be thrown away

[6:22](https://www.youtube.com/watch?v=bU5gDVyu_28&t=382s)

Future models might become better at handling complex systems. Kanat-Alexander sets that possibility aside to examine another change: the expansion of disposable software. This category has existed for a long time. He expects it to become dramatically more common as models make software easier to create and replace.

![Recording frame at 8:40: When software can be thrown away](https://ai.engineer/api/talk-essay-media/22e274a6899abdf608b2cb6599bbede3c95666b816cb8ef8dcee200612792614)

When software can be thrown away — recording at 8:40

Imagine a program with minimal or nonexistent consequences of failure, few users and almost no other systems depending on it. There is little need to coordinate changes with others. The whole thing can be replaced in hours or days, and maintenance costs nearly nothing. Under those conditions, preserving code quality has little value in this framework: the compounding risks it was meant to prevent no longer justify the effort of preserving the implementation.

Durable software carries a different set of obligations. It lives for years, serves thousands or millions of people, can fail in ways that threaten the business, and demands continuing maintenance. Kanat-Alexander expects these systems to remain among the most important software even if disposable programs become the most numerous. Their continuing need for changes keeps the value of understanding and safe modification high.

Two small examples make the difference tangible:

- **A personal calculator:** If the calculator supplied with the operating system is unsuitable, make another one. In the imagined world of cheap replacement, the few people using such a tool can have agents make their own versions instead of preserving one implementation indefinitely.
- **A planner for one party:** Build software to organize a party for the kids, use it for that event, then throw it away. The task ends with the party; the software does not need a continuing life as a maintained product.

### Four factors set the level of rigor

[9:00](https://www.youtube.com/watch?v=bU5gDVyu_28&t=540s)

To decide how much engineering rigor a system needs, compare four factors together. The endpoints of the spectrum are:

| Factor | Disposable end | Durable end |
| --- | --- | --- |
| Consequences of failure | Minimal or nonexistent | Potentially catastrophic for the business |
| Cost of replacement | Near zero; replaceable in hours or days | High |
| People and systems depending on it | Few people; almost no other systems | Many dependents |
| Cost of maintenance | Nearly zero | Substantial continuing work |

![Recording frame at 9:33: Four factors set the level of rigor](https://ai.engineer/api/talk-essay-media/7ec90b0d5b4dfac9811592156a178e50be24a9eb455756625a3596d59b51522d)

Four factors set the level of rigor — recording at 9:33

When all four are low, the system is disposable; when all four are high, it is durable. Cheap replacement addresses only one row of the table. These factors provide qualitative guidance, so mixed cases still require judgment about how much rigor to apply. The practical bias is conservative: err toward treating the software as durable, and assume each factor may be higher than it first appears.

### Design software to be more disposable

[10:00](https://www.youtube.com/watch?v=bU5gDVyu_28&t=600s)

Disposability is something engineering can increase. Four independent choices reduce the consequences or obligations that make software expensive to abandon:

![Recording frame at 10:50: Design software to be more disposable](https://ai.engineer/api/talk-essay-media/b947d83fb50d1ab2bd144ba672485063b160b4a9ddea1da589b8e6b5e93abc96)

Design software to be more disposable — recording at 10:50

- **Isolate data access.** Limit deployment to an environment with constrained access to the builder’s data, excluding customer data and personally identifiable information. The environment limits what the software can affect when something goes wrong.
- **Prevent production dependents.** Disallow inbound API calls from other production systems. Keeping those systems from relying on this one makes its deletion or replacement easier to tolerate.
- **Keep a durable fallback.** An old, clunky system can remain available while people generate more efficient front ends. When one of those front ends fails, its users can return to the old system. The new interface is easier to discard because the important work still has another route.
- **Limit scope.** Keep the calculator for one person or the planner for one party. Fewer users and a shorter useful life leave fewer commitments for future changes.

The fallback example makes the relationship especially clear: a durable backup and disposable front ends can coexist. The backup is what makes a front end’s failure tolerable. Kanat-Alexander proposes designing for this kind of disposability as an additional discipline of software engineering. He also expects AI coding tools to increase the absolute amount of durable software, because they make that software easier to create too.

Disposable and durable therefore describe a spectrum. What changes across it is the amount of effort worth putting into engineering rigor. A team can change a system’s position by reducing its consequences and dependencies, while still preserving durable systems where their responsibilities require them.

### Make rigor cheap enough to use by default

[11:59](https://www.youtube.com/watch?v=bU5gDVyu_28&t=719s)

A second design choice changes the cost of rigor itself, both immediately and over time. A program initially treated as disposable may later need to be durable. The cheaper it is to strengthen that software, the less painful the mistaken estimate becomes. This creates a separate engineering task: reducing the effort required to apply good practices.

![Recording frame at 13:37: Make rigor cheap enough to use by default](https://ai.engineer/api/talk-essay-media/652853c6b904e712a26acd1e155176c023c5cc0e2ca048a371742ba07a54fd82)

Make rigor cheap enough to use by default — recording at 13:37

Several practices attack that cost in different ways:

- **Standardize the choices that multiply support work.** A system with no PHP has no PHP-specific linters, practices or security issues to manage. Fewer frontend and backend frameworks mean fewer sets of supporting tools to build. Shared remote procedure call (RPC) protocols serve the same purpose. An agent may be able to generate tools for every stack, but each additional stack creates that work again. Standardization reduces the number of possibilities rigor must cover.
- **Put reliable tools in the workflow.** Checks should happen automatically, without programmers deciding to run them or understanding their implementation. They also need to be fast and produce few false positives. Automatic but noisy tooling still costs attention; automatic, reliable tooling can feel almost free. At that point it can be reasonable to use it for disposable software too.
- **Make fast, deterministic testing easy to obtain.** The goal is for test authors to get these properties without becoming testing experts. That requires substantial work on shared test infrastructure. The concrete proposal is to provide in-memory fake versions of services, so tests can use those substitutes for their dependencies. Coding agents can help create the fakes, but someone must choose to provide them and make them available to everyone. Shared infrastructure lowers the effort each programmer must spend figuring out how to test.

### Turn strictness on before the cleanup grows

[14:59](https://www.youtube.com/watch?v=bU5gDVyu_28&t=899s)

The final recommendation is “maximum strictness”: turn lint rules up from the start and apply them consistently. Like standardization, this removes recurring choices and arguments. The tradeoff is accepting some incorrect warnings when the false-positive rate stays relatively low and their consequences are tolerable.

The cost becomes obvious when a large codebase adopts linting late. In Kanat-Alexander’s illustrative example, turning on a linter in a codebase with a million lines creates a cleanup touching a hundred thousand lines. Keeping the checks enabled for everyone from the beginning avoids accumulating that particular backlog. Fixing violations as code is written makes enforcement part of ordinary changes, rather than a large later migration.

Code quality matters for durable software and can cease to matter at the truly disposable end of the spectrum. Its cost is a separate engineering problem. Making rigor inexpensive to apply gives teams more room to change their minds about how durable a system needs to be—and gives a concrete answer beyond “it depends.”

## Key takeaways

- Code quality supports understanding actual system behavior and changing it safely. A modification can cause trouble now or make later changes harder, allowing risk to compound across successive changes.
- Judge disposability by failure consequences, replacement cost, people and systems depending on the software, and maintenance cost. Cheap replacement alone does not settle the decision; uncertain estimates should lean toward durability.
- Make software easier to discard by isolating its data access, blocking production dependents, retaining a durable fallback and limiting its scope. The fallback example shows how durable and disposable software can coexist.
- Lower the cost of rigor through standard stacks and protocols, automatic reliable checks, and shared infrastructure for fast, deterministic tests. Coding agents can help create in-memory service fakes, but those fakes still need to be made available to test authors.
- Apply strict linting early while keeping false positives low and their consequences tolerable. Avoiding a large later cleanup is one way to make rigor cheaper—and cheaper rigor makes it easier to recover when supposedly disposable software becomes durable.

## Related talks

- [Stop Prompting — Greg Pstrucha, Sentry](https://ai.engineer/talks/E3KbFLAGD6A-stop-prompting-greg-pstrucha-sentry) — 
- [In the Land of AI Agents, the Verifiers Are King](https://ai.engineer/talks/VrpEyglYgeU-in-land-ai-agents-verifiers-are-king) — 

## Slides

### Does code quality matter?

[0:19](https://www.youtube.com/watch?v=bU5gDVyu_28&t=19s) [The opening slide splits the screen between two opposite answers in black and white.](https://assets.ai.engineer/sites/aiecode2025/sha256/d2a2c87d90eca8d9a8af813ad7408e50406e17924504f9faa19db61e651638fb.webp)

Absolutely no · Absolutely yes

### The two parts of a change

[1:15](https://www.youtube.com/watch?v=bU5gDVyu_28&t=75s) [A numbered list separates understanding the software from acting on that understanding.](https://assets.ai.engineer/sites/aiecode2025/sha256/263206d49e22c3bbfccdbb8fdc745f3567537cf4ac6fa224e878e7a3e1835917.webp)

Understanding · Executing on that understanding

### What a maintainer needs to know

[2:00](https://www.youtube.com/watch?v=bU5gDVyu_28&t=120s) [Two bullets distinguish the behavior of a system from how to change it correctly.](https://assets.ai.engineer/sites/aiecode2025/sha256/ed3981c339a9c8e8b01a08fd0ce8fcc32246a77162abccb87eee7dcfbbb17030.webp)

Behavior · How to correctly modify it

### Changing a greeting

[2:29](https://www.youtube.com/watch?v=bU5gDVyu_28&t=149s) [A one-line code example changes the printed greeting from Hello World to Hi World.](https://assets.ai.engineer/sites/aiecode2025/sha256/9ce2b6cf4cc7a277cf9c05c2a7c0fe1912c341a770df4e2e9cc8f719c88b09d3.webp)

print(“Hello World”) → print(“Hi World”)

### The call tree for parsing a URL

[3:18](https://www.youtube.com/watch?v=bU5gDVyu_28&t=198s) [A sample URL points to a tree of functions that parse its scheme, authority, path and query.](https://assets.ai.engineer/sites/aiecode2025/sha256/2885b858bafebff9062f455363fbba413ed9ba6df1aa118e0fae9540b61208d4.webp)

ParseStandardUrl · ParsePath · FindQueryAndRefParts

### Two ways a change can cause harm

[5:26](https://www.youtube.com/watch?v=bU5gDVyu_28&t=326s) [The slide separates the immediate risk of introducing a problem from the longer-term effect on future changes.](https://assets.ai.engineer/sites/aiecode2025/sha256/cb214783dac71310a9ba1970836100ef10da86074bf3570af3422f1e5600405d.webp)

Probability of introducing a problem · Making it more likely to have future problems

### What makes software durable?

[7:16](https://www.youtube.com/watch?v=bU5gDVyu_28&t=436s) [Four bullets weigh failure, dependencies, replacement and maintenance.](https://assets.ai.engineer/sites/aiecode2025/sha256/2bf7ee727226af52890f94d9f77fdd3a916b4619bfdf1b90c616ecef2e18f3c7.webp)

Consequences of failure · People/systems that depend on it · Cost of replacement · Cost of maintenance

### Durable and disposable software

[8:39](https://www.youtube.com/watch?v=bU5gDVyu_28&t=519s) [Two columns compare software that lives for years with software that can be replaced in hours.](https://assets.ai.engineer/sites/aiecode2025/sha256/3f8bc61975d8719a8aa9e13340aaafd8c9109993d2a2e3d978855a1d85155fbc.webp)

Durable Software · Disposable Software

### Where software sits on the spectrum

[9:32](https://www.youtube.com/watch?v=bU5gDVyu_28&t=572s) [A two-ended arrow places disposable and durable software above four factors used to decide between them.](https://assets.ai.engineer/sites/aiecode2025/sha256/8d7a285ad3a280ac7c36b56eebd435c049020002cd2902a5c207e6bd1de6d7f8.webp)

Consequences · Dependencies · Cost of replacement · Cost of maintenance

### Increasing disposability

[9:58](https://www.youtube.com/watch?v=bU5gDVyu_28&t=598s) [Four ways to limit the harm from replacing a piece of software appear as a checklist.](https://assets.ai.engineer/sites/aiecode2025/sha256/f28ada289ae7ef5ecac7d3d1d7b78feacec09a9813b327ad6a8367c2231c15a8.webp)

Isolation · Independence · Redundancy · Limiting scope

### The cost of stronger foundations

[11:49](https://www.youtube.com/watch?v=bU5gDVyu_28&t=709s) [Two curves diverge as the horizontal axis moves from more disposable to more durable software.](https://assets.ai.engineer/sites/aiecode2025/sha256/2a5a8b221985b0842d1ae9b2e7686175c85e8da333b33eb68c8e3ec7d6f16877.webp)

With better foundations · Without better foundations

### Making durability easier

[12:49](https://www.youtube.com/watch?v=bU5gDVyu_28&t=769s) [A checklist names four ways to make high-quality work part of a developer’s workflow.](https://assets.ai.engineer/sites/aiecode2025/sha256/8ca85cc528de2f863208751dc15a21b4a71e4c3b50243d12123ef587bd82b24f.webp)

Standardization · In-Workflow Tooling · Make Testing Easier · Be Super Strict

### Different standards for different lifetimes

[16:12](https://www.youtube.com/watch?v=bU5gDVyu_28&t=972s) [The final slide gives a separate answer for disposable and durable software and asks whether quality must be expensive.](https://assets.ai.engineer/sites/aiecode2025/sha256/a007c7e0b77d3cd4d08e595ff5103b9699d3d6b1d3785260fdfa9ba2c350e61e.webp)

For disposable software? No · For durable software? Yes · Does it have to be expensive? No

## Full transcript

[0:12](https://www.youtube.com/watch?v=bU5gDVyu_28&t=12s) So today, I figured I'd just pick a nice, uncontroversial topic that nobody has any opinions about, right? Nobody, nobody's said anything on th- about-- on this about social media, you know. And of course, every take about this on social media is, like, really deeply nuanced, you know. Like, people have lots of, like, depth and, like, you know, really big thoughts. You know, maybe there's a little bit more to it than, like, yes or no. And, you know, of course, if you ever ask a senior engineer a question, we always have the same answer to every question,

[0:42](https://www.youtube.com/watch?v=bU5gDVyu_28&t=42s) every senior engineer's favorite answer to every question, which is, "It depends." Now, that's not a very helpful answer though, frankly, because what does it depend on? So let's start with this. Why did code quality ever matter in the first place? Like, I see a lot of people be like, "Well, it made me feel good." That's not really a sufficient justification. So let's see if we can inject some nuance into this conversation and help everybody at least be able to have a basis for reasoning about it while

[1:12](https://www.youtube.com/watch?v=bU5gDVyu_28&t=72s) we're discussing it. So let's see if we can make a framework here, and that's what we're gonna try to do with this talk. Okay, so we're gonna start off with everything you want to ever accomplish with a piece of software, uh, depends on two factors and two factors alone, and that is understanding and executing on that understanding, whether that's aligning a model, scaling a system, driving adoption, anything. All software success is determined by these two factors. This is why we have things like debuggers and observability and evals, and even tests. All those things actually are there to improve

[1:42](https://www.youtube.com/watch?v=bU5gDVyu_28&t=102s) your understanding or ability to execute on that understanding. People think that they're there for other reasons, but fundamentally, they're there for that reason. Everything we have ever done in the field of code quality is exclusively and only for these two things. It's not for anything else. And that doesn't have something to do with correctness or something else. It has to do only with these two things. Now, there's two understandings that are the most important to have if you're going to be a software engineer. There are other understandings to have about software if you're gonna be in product, if you're gonna be in sales. But if you're a software

[2:12](https://www.youtube.com/watch?v=bU5gDVyu_28&t=132s) engineer, there's the two that are the most important. And the first is, what is the behavior of the system? Like con-- concretely, not what does a doc say the behavior of the system is, but what is the actual behavior of the system? And the second one is, how do I correctly and safely modify that behavior, okay? On a very small system, if you wanna understand what the system does, I just tell you what it does. It prints, "Hello, World." You say, "I want it to say, 'Hi, World.'" I say, "Okay, I will make it say, 'Hi, World' now."

[2:42](https://www.youtube.com/watch?v=bU5gDVyu_28&t=162s) There's very little to understand about it other than purely what it does, and that's all of the understanding that you need. However, any real software system is enormously complex. This is a real map of the codebase of Chromium, which is the open source project behind Chrome. And if you think about all of the different ways that these components can interact, they have essentially infinite possible behaviors. Like, I could not describe to you in

[3:11](https://www.youtube.com/watch?v=bU5gDVyu_28&t=191s) words the behavior of Chromium as a whole, as a system. However, what I can describe to you, and as we all know, everybody's been a software engineer for a while, I can describe to you components of the system. I can successfully describe to you how a component of the system behaves. So this is the URL parser, the actual functions and stuff for the URL parser of Chromium. It figures out all the different parts of the URL. And this is the whole

[3:41](https://www.youtube.com/watch?v=bU5gDVyu_28&t=221s) reason that code exists. The whole reason that we have code at all in the first place is for structure. It-- Because it-- What do I mean by that? Okay, so both of these two things on the left and on the right will print, "Hello, World," if run on a Linux machine. However, on the left, you can see that it is Hello, World. It has the identity and structure of Hello, World. On the right, you just see a

[4:11](https://www.youtube.com/watch?v=bU5gDVyu_28&t=251s) series of instructions with no particular identity, recognizable or understandable identity. It's not a component, it's just a bunch of instructions. While that's understandable there, if that was millions or billions of lines of that, it would be much harder to grok. In the past, we've talked about things like readability or testability or things that seemed like human concepts about code. But what actually mattered the most always was that the system had some sort of understandable structure. So it's the structure that actually matters.

[4:42](https://www.youtube.com/watch?v=bU5gDVyu_28&t=282s) And when this modifies-- when this matters the most is when you want to modify the system, the second, uh, understanding that we talked about. All modifications to a system carry two categories of risk. The first is that you will introduce some sort of problem. And a problem isn't just a bug, it's anything bad that could happen. Like, your project could take much longer than you expect. Uh, it could not behave in the way that you wanted it to for your users. The project could fail because you have budget overruns. Any kind of problem could happen from just you

[5:12](https://www.youtube.com/watch?v=bU5gDVyu_28&t=312s) trying to go through the process of making this change. And the second is you could make it harder to make future changes. In particular, what that means is you could make it more likely to have future problems. You could increase future risk of the system. These two things are caused by under-- problems with understanding. So the first has to do with the difficulty of understanding the system in the first place, and the second is you make the system harder to understand. I can reduce every postmortem I have

[5:42](https://www.youtube.com/watch?v=bU5gDVyu_28&t=342s) ever read for any incident to these two factors in one way or another. The, the, the production configuration was too hard to understand, somebody made something impossible to understand, there were emergent properties of the system that were impossible to understand, whatever. Point two feeds into point one in a vicious cycle that compounds in a non-linear fashion. So the difficulty of understanding does not grow linearly. It compounds over time. You will

[6:12](https://www.youtube.com/watch?v=bU5gDVyu_28&t=372s) eventually reach a point, and all systems eventually tend to reach this point, where every modification involves some sort of problem.

[6:22](https://www.youtube.com/watch?v=bU5gDVyu_28&t=382s) Uh, and you know, some, some systems get to the point where, like, you can't modify them at... Like, if you think of like, you know, some of like your giant hundred million, five hundred million line mainframe codebases and the, uh, everything, every change is some sort of problem. You know, you'll see it in organizational issues, you'll see it all over the place. You'll see it in timelines, whatever. And look, there's a lot of arguments about maybe future models will fix this. Look, maybe they will. Maybe future models will have infinite ability to deal with complexity somehow. Uh, but we don't have to discuss that today because

[6:52](https://www.youtube.com/watch?v=bU5gDVyu_28&t=412s) I think models are doing something else really interesting right now. They are creating a new kind of software, a new category of software. This category has always existed, but it's about to become a hundred thousand times more common than any other form of software, and that is disposable software. So what is that? Okay, so imagine a world in which the consequences of failure for your

[7:21](https://www.youtube.com/watch?v=bU5gDVyu_28&t=441s) system are very minimal or nonexistent. Imagine that there's very few people that depend on it or, and almost no other systems depend on that piece of software. Change management, very minimal, nonexistent. Imagine the cost of replacement went to near zero. You could re-replace the whole thing in hours or days, and it had basically no cost of maintenance. In that world, code quality does not matter because

[7:51](https://www.youtube.com/watch?v=bU5gDVyu_28&t=471s) it-- all of those things we were trying to prevent about the compounding risks over time don't exist.

[8:00](https://www.youtube.com/watch?v=bU5gDVyu_28&t=480s) Traditionally, we've always built durable software. You know, it lives for years. It's depended on by millions or thousands of people. There's huge consequences of failure, potentially business catastrophic consequences of failure, and it requires enormous maintenance. Most of the software engineers in the world spend most of their time maintaining these giant, durable systems. I expect this to continue to exist, so this is one of the areas where I think sometimes the conversation goes a little astray, okay? Durable

[8:30](https://www.youtube.com/watch?v=bU5gDVyu_28&t=510s) systems will continue to probably be the most important systems in the world, and there will be probably more of them. But the most numerous systems will be disposable software. They will be replaceable in hours. They will be depended on by a few, or change management just won't matter. And look, if it doesn't work, you will give everybody agents. They'll make a version of it themselves, you know. Maintenance will be unimportant or nearly free. Don't like the calculator on your

[9:00](https://www.youtube.com/watch?v=bU5gDVyu_28&t=540s) OS? Make your own. Wanna plan a party for your kids? Write a party planner software just for that one party. Throw it away. Code quality doesn't matter. Nobody cares. In the future, we will apply engineering rigor to the degree of disposability of the software. On the left, nothing. None of our practices of engineering rigor matter at all. On the right, all the practices of engineering that we have built up over the last many

[9:29](https://www.youtube.com/watch?v=bU5gDVyu_28&t=569s) decades matter d- greatly. We can determine where you are on this scale by those four factors that I have been talking about: consequences, cost of replacement, dependencies, and cost of maintenance. If they're all low, it's disposable software. If they're all high, it's durable software. And look, any person who's written software for a long time knows you should err on the side of it being durable. You should err on these all being higher than you expect them to be. But there's also a new thing you can do in the world.

[10:00](https://www.youtube.com/watch?v=bU5gDVyu_28&t=600s) You can make software more disposable. So, like, what d- what does that involve? Well, come up with better isolated environments, right? So, hey, you can only deploy to this environment that has access to only your data. No customer data, no personally identifiable information, whatever. You can enforce independence. You can say, "Okay, no inbound API calls from other production systems are allowed to this system in this environment," right? And so everything deployed to that environment is disposable.

[10:29](https://www.youtube.com/watch?v=bU5gDVyu_28&t=629s) Redundancy. You can have an old clunky backup system that is, like, hard to use and then, like, look, if people wanna vibe code their own, like, more efficient front ends, you let them vibe code their more own more efficient front ends because there is an old, durable, clunky backup system that they can use if their, you know, crappy little vibe coded thing fails, which, which it will fail, right? That's fine, but it doesn't matter if it fails. Uh, and you can limit scope, just like I talked about, right? It's just a calculator for this one person. It just plans this one party. There's so much

[10:59](https://www.youtube.com/watch?v=bU5gDVyu_28&t=659s) more we could do here and talk about ways of increasing disposability. In fact, I think this is a whole new discipline of software engineering. Not to think about how we improve the rigor of durable systems, but how do we take our systems and how do we encourage disposability or allow more disposability, allow people to just throw these things away? Interesting thought. Now, I wanna reemphasize that durable software engineering is not going away because this is

[11:29](https://www.youtube.com/watch?v=bU5gDVyu_28&t=689s) the biggest confusion that I see on social media today. In fact, I believe the absolute amount of durable software in the world will increase because AI coding tools make it easier and easier to make more durable software. And another important thing to understand is that disposable and durable are not black and white. There's a spectrum, like I showed before. But that spectrum, what changes across the spectrum is how much effort you're going to put into engineering rigor, okay?

[11:59](https://www.youtube.com/watch?v=bU5gDVyu_28&t=719s) And that's both immediate effort and effort over time, just like we've always talked about for software. However, what you wanna do, and I think what you wanna care about the most, is reducing the cost of effort, reducing the cost of rigor. Like, if rigor is cheaper, if it's-- the, the, the easier and easier you make it to be rigor, the less you have to worry about where you are on the scale. So this is another approach you can take. If you change your mind, it's much easier

[12:29](https://www.youtube.com/watch?v=bU5gDVyu_28&t=749s) to-- like, you're like, "Oh, I thought this was gonna be disposable, and now it needs to be durable." The cheaper you make it to make it durable, the easier it is to change your mind or to be wrong, because you're never going to be a hundred percent right all the time on that estimate. So that involves a different set of practices that are not engineering rigor themselves, but that are about how to decrease the cost of engineering rigor. Now, I could talk about this for hours. I have spent a tremendous amount of my career doing this. Uh, I don't have ten hours. I have about

[12:59](https://www.youtube.com/watch?v=bU5gDVyu_28&t=779s) five minutes left on that timer. So I'll talk, I'll talk about what I can, okay? Let's talk about standardization. Why do we do standardization? People are like, "Well, I don't know, because the boss said so." Well,  no. We do standardization because it removes possibilities. If you don't have any PHP in your system, you don't have to figure out what are all the linters for PHP, what are all the practices, what are all the security holes I have to fix. You just eliminate possibilities through standardization, and it just

[13:29](https://www.youtube.com/watch?v=bU5gDVyu_28&t=809s) reduces the cost of rigor. Uh, same thing with, like, frameworks. Like, why don't you wanna have every front-end framework or every back-end framework in e- in existence? Because it makes rigor more expensive. Like, yes, rigor is still possible. Yes, you could still have the agent code up all your tools, but you have to do it every single time. Uh, you know, pro- protocols, why do you wanna have standardized RPC protocols? All the same thing. Standards are all for this reason, okay? Uh, what I call in-workflow tooling. So in-workflow tooling is tooling that just occurs. The programmer doesn't have to choose to run it. They don't have to

[13:59](https://www.youtube.com/watch?v=bU5gDVyu_28&t=839s) understand how it runs. It just happens. If it's there, it, it feels and seems free, and it is reliable. Reliability is very, very important. Like, it doesn't have a ton of false positives. It's fast. It just happens. And the more that's true, look, you can apply it to your disposable software too. If it's free and fast, who cares? Uh, making testing easier. So this is not just about like, "Hey, how do we do better testing?" Look, how do you make it so that nobody has to think about how to do better testing? How do you make it so

[14:29](https://www.youtube.com/watch?v=bU5gDVyu_28&t=869s) that every test is fast and deterministic without anybody having to be a deep expert in testing? There's a ton of work that you have to put into test infrastructure to make that possible. For example, you know, one of the great dreams that I've always had as a, as a test owner is that everybody would provide in-memory fake versions of their services, and I could just run those in-memory fake versions of their services. Guess what? The coding agent can do that, so you can just do that now, right? But you have to choose to do it and make it available to everybody. And

[14:59](https://www.youtube.com/watch?v=bU5gDVyu_28&t=899s) another thing is, look, maximum strictness. You just turn the strictness up everywhere. You turn-- You set all your lint rules to maximum. You, you never compromise on anything, and it just eliminates... It's very similar to standardization. It eliminates a ton of conversations. Sometimes the linter's wrong. Like, as long as the false positive rate is relatively low and doesn't have catastrophic consequences, it doesn't matter because all of a sudden there's a bunch of future lint errors or future issues that you don't have to deal with. Like, ask anybody who's been like, "Oh, I suddenly wanna turn on my linter in this million-line code base," and they're like, "Oh, wow,

[15:29](https://www.youtube.com/watch?v=bU5gDVyu_28&t=929s) now here's my hundred thousand line change that I need to make," right? Much easier to just do that up front and have it on for everybody. Now, look, like I said, I could literally stand here and talk to you about this straight for ten hours. There is much, much more you can do here. This is just a few areas, but also a whole area of software engineering discipline that you can apply on the other axis. So this lets us now answer our question, not just it depends, but yes or no. So does code quality even matter?

[15:59](https://www.youtube.com/watch?v=bU5gDVyu_28&t=959s) For disposable software, no. For durable software, yes. And we get to answer a third and even more interesting question, which is, does it have to be expensive? No. Thank you very much.