Does Code Quality Still Matter? It Depends on This — Max Kanat-Alexander, Capital One
Max Kanat-Alexander reframes the familiar "it depends" answer around two factors that govern all software work: understanding a system and safely changing it. He explains why code quality matters for durable software but not for a new, rapidly growing category of disposable software created by AI, and shows how to make systems more disposable and make rigor cheap through standardization, inward-flow tooling, easier testing, and maximum strictness.
Why code quality exists
The speaker opens with the familiar senior engineer answer, “it depends,” and argues that the useful question is what it depends on. His answer is that every software outcome, whether aligning a model, scaling a system, or driving adoption, rests on two factors: understanding the system and executing on that understanding. Debuggers, observability, evals, and tests all exist to improve one of those two things. He argues that everything the field has called code quality serves only these purposes, not abstract correctness or aesthetics.
Two understandings matter most to a software engineer. The first is the actual behavior of the system, as opposed to what the documentation claims it does. The second is how to modify that behavior correctly and safely. On a tiny program that prints Hello World, understanding is trivial. Real systems are different. Chromium’s component map implies effectively unbounded interaction behaviors, so no one can describe the whole system’s behavior in words. What remains tractable is describing individual components, such as the URL parser that splits a URL into its parts.
Structure is the point
He makes the case that the reason code exists at all is structure. Two Hello World programs produce identical output, but one has a recognizable identity, a component you can name and reason about, while the other is a flat list of instructions. At small scale the difference is cosmetic. At millions of lines it decides whether anyone can grok the system. Concepts like readability and testability matter insofar as they serve an understandable structure, and structure matters most when someone needs to change the system.
The two risks of every change
Every modification carries two risks. The first is that the change introduces a problem, and he defines problem broadly: a bug, but also a project running over schedule, behaving wrongly for users, or exceeding budget. The second is that the change makes future changes harder, which raises the likelihood of future problems. Both trace back to failures of understanding. Difficulty understanding a system and the difficulty created by changing it feed each other in a cycle that compounds non-linearly rather than growing steadily. He argues that nearly every incident postmortem reduces to these two factors, whether the production configuration was too hard to understand or emergent properties were invisible. Eventually every system reaches a point where every change is a problem. He points to giant mainframe codebases as examples and notes that this shows up in organizational issues and timelines, not just in code. He sets aside the argument that future models will tame complexity, pointing instead to a more interesting shift already underway.
Disposable and durable software
AI is making common a category of software that has always existed: disposable software. He defines it by four factors: low consequences of failure, few dependents, low cost of replacement (hours or days), and near-zero maintenance cost. In that world code quality does not matter, because the compounding risks he described never accumulate. Durable software lives for years, serves millions of people, carries business-critical failure consequences, and demands heavy maintenance. It is where most engineers spend their time. He expects durable software to remain the most important and to grow in absolute amount, since AI coding tools make it easier to produce. The most numerous software, however, will be disposable: a personal calculator, or a party planner written for a single event and thrown away.
He describes a spectrum rather than a binary, with engineering rigor scaled to the degree of disposability. Because all four factors are hard to predict, he advises erring toward durability and assuming each factor will be higher than expected.
Making software more disposable
He also describes deliberate ways to increase disposability. These include isolated environments that hold only non-sensitive data, with no customer or personally identifiable information; enforced independence, such as forbidding inbound API calls from other production systems; keeping an old, clunky but durable backup so that vibe-coded replacements can fail without consequence; and limiting scope to a single user or a single purpose. He suggests this forms a discipline of its own, focused less on rigor for durable systems than on designing systems that people can safely throw away.
Lowering the cost of rigor
The second lever is reducing the cost of rigor itself, which makes it cheap to change your mind about where a system sits on the spectrum. Standardization is the first tool. Eliminating alternatives, such as PHP in a stack, multiple front-end frameworks, or a variety of RPC protocols, removes the linters, security practices, and tooling choices that would otherwise be evaluated and repeated for every project, including agent-generated tooling.
Inward-flow tooling runs without anyone choosing to invoke it. To feel free, it must be fast, reliable, and low in false positives. Making testing easier means building test infrastructure so that every test is fast and deterministic without requiring deep testing expertise. He notes a long-held wish of test owners: in-memory fake versions of every service. Coding agents can now produce these, but they still have to be made available to everyone.
Finally, maximum strictness means setting lint rules to their highest level from the start. Occasional false positives are acceptable if they are rare and not catastrophic. Enabling strict rules on a new codebase is far cheaper than retrofitting them into a million-line one later.
Answering the question
Does code quality matter? For disposable software, no. For durable software, yes. Does it have to be expensive? No.