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

Code quality matters only to the degree that software is 'durable' rather than 'disposable'; AI coding tools are creating a massive new category of disposabl...

Does Code Quality Still Matter? A Framework for Conditional Engineering Rigor

Abstract

This synthesis examines a framework, originating from Max Kanat-Alexander's analysis at Capital One, for reasoning about software quality in the era of generative coding tools. The central claim is that code quality is not an intrinsic virtue but a conditional investment whose value depends on whether a given artifact is durable or disposable. Software success is modeled as a function of two factors - understanding and execution - from which the risks of modification are derived: introducing a defect, or degrading future comprehensibility. Because these risks compound non-linearly, durable systems warrant full engineering rigor, while a rapidly expanding class of AI-generated disposable software, characterized by negligible failure consequences and near-zero replacement cost, does not. A four-factor disposability assessment is proposed, alongside mechanisms - standardization, inward-flow tooling, and agent-generated test infrastructure - for lowering the cost of rigor where it remains necessary. The framework offers engineering organizations a principled basis for allocating quality effort rather than applying it uniformly.

1. Introduction

The question "does code quality matter?" is typically treated as rhetorical within professional software engineering, with an assumed affirmative answer by default. The framework presented here argues that the question is genuinely open, and that its answer is contingent on a property of the artifact rather than a property of the discipline itself. This reframing has gained urgency as AI coding tools dramatically lower the cost of producing software, raising the question of whether traditional engineering rigor still applies universally.

Two terms anchor the analysis. Durable software is software that persists, accumulates dependents, must be maintained, and whose failure carries consequence. Disposable software is software that is used and discarded, has few or no dependents, can be regenerated at trivial cost, and incurs no maintenance burden. The thesis holds that quality practices - tests, review, observability, static analysis - derive their entire justification from the dynamics of durability. Where durability is absent, so is the justification for rigor.

A secondary thesis addresses cost: for genuinely durable software, rigor remains mandatory, but its price is not fixed. Standardization and tooling design can substantially reduce the per-change cost of rigorous engineering. The analysis proceeds by establishing an understanding-execution model, developing the mechanics of modification risk and disposability, and presenting technical mechanisms for reducing the cost of rigor.

2. Background and Related Work

The framework rests on a minimal model of software outcomes, termed the Two-Factor Software Success Model: "Everything you want to ever accomplish with a piece of software depends on two factors and two factors alone: understanding and executing on that understanding." This model reinterprets debuggers, observability platforms, evaluation harnesses, and automated test suites as instruments that either improve understanding of a system or improve the ability to execute reliably against that understanding.

Two specific understandings are identified as critical: behavioral understanding (what the system actually does) and modification understanding (how behavior can be changed correctly and safely). The difficulty of attaining these understandings scales with system size - a trivial script demands almost none, while a production codebase such as Chromium exhibits a near-infinite space of possible behaviors, since behavior emerges from combinatorial interactions among components rather than from any single component in isolation. This motivates the claim that "the whole reason that we have code at all in the first place is for structure," illustrated by a comparison of two functionally identical "Hello World" snippets - one with clear structural identity, one without - demonstrating that correctness of output alone does not satisfy the purpose of code.

3. Core Analysis

3.1 The Mechanics of Modification Risk

Every modification to a system carries two risks: introducing a problem, or making future changes harder, thereby increasing future risk. Both risks trace back to understanding problems - either the system was too difficult to understand in the first place, or the modification made it harder to understand going forward. Critically, "point two feeds into point one in a vicious cycle that compounds in a non-linear fashion." This non-linearity explains why large legacy systems, such as giant mainframe codebases, can reach a state where virtually every modification introduces a problem: accumulated comprehension debt has compounded past a threshold where safe change becomes effectively impossible. Postmortem analyses, the framework suggests, reduce cleanly to these same two factors, offering a parsimonious diagnostic lens for incident review.

3.2 The Emergence of Disposable Software

AI coding tools are producing a new and soon-to-be-dominant category of software: disposable software, defined by minimal consequences of failure, few dependents, near-zero cost of replacement, and no maintenance cost. Examples include a personal calculator application or a one-time party-planning tool. In this context, code quality does not matter, because the compounding risk dynamics described in Section 3.1 simply do not apply - there is no future state in which accumulated difficulty of understanding imposes cost, since the artifact is discarded before such compounding can occur. Notably, the framework does not predict the disappearance of durable software; it anticipates that "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," implying a bifurcation of the software landscape rather than a uniform decline in rigor.

3.3 The Disposability Spectrum

Software position is determined by four measurable factors: consequences of failure, cost of replacement, dependencies, and cost of maintenance. This yields a spectrum rather than a binary classification, with the practical guidance that "engineers should err on the side of treating software as more durable than expected" given the asymmetric cost of misjudgment. The framework also identifies a new discipline - intentionally engineering disposability - through techniques such as isolated execution environments, enforced independence between components, redundancy paired with durable backups, and deliberately limited scope. This represents an inversion of traditional engineering instinct, which optimizes for durability by default; here, disposability itself becomes a design target to be actively constructed.

4. Technical Insights

Several concrete mechanisms are proposed for reducing the cost of rigor in durable systems, rather than eliminating rigor itself:

• Standardization as risk elimination: Reducing the space of supported technologies (e.g., not supporting PHP) removes entire categories of required expertise, such as language-specific security review or linting knowledge, lowering the cost of applying rigor without lowering its standard.
• Frameworks and protocols: These serve the same function as standardization - reducing the marginal cost of applying rigor consistently across a codebase by encoding best practices structurally rather than relying on individual judgment.
• Inward flow tooling: Tooling that operates automatically without requiring programmer choice "feels free" to the engineer and must meet strict operational requirements - speed, reliability, and few false positives - to be adopted without friction. This represents a design constraint on tooling architecture: rigor-enforcing systems succeed only when they impose negligible perceived cost.
• Agent-generated test infrastructure: The automatic generation of in-memory fake service versions for testing, previously a manual aspiration of test infrastructure owners, is now feasible via coding agents. This lowers the historically high cost of comprehensive test coverage.
• Maximum strictness upfront: Applying maximum lint or rule strictness at the outset eliminates future negotiation and technical debt by universally enforcing standards before exceptions can accumulate, rather than retrofitting strictness after a codebase has matured.

A key trade-off is that these mechanisms reduce the cost of rigor without reducing its necessity for durable software - they do not substitute for understanding, but they make achieving and maintaining understanding cheaper to sustain.

5. Discussion

The framework's central contribution is reframing code quality from an unconditional professional norm into a conditional engineering decision, parameterized by measurable properties of the artifact. This has direct implications for organizations adopting AI coding tools at scale: applying durable-software rigor to disposable artifacts wastes engineering capacity, while applying disposable-software laxity to durable artifacts reintroduces the compounding risks the framework warns against. The four-factor disposability assessment offers a practical triage mechanism, though its application in ambiguous cases - software that begins disposable but accumulates dependents over time - remains an open area requiring further operational guidance.

A broader industry implication concerns tooling investment. As AI tools generate increasing volumes of code, the inward-flow tooling concept suggests that quality enforcement must shift toward frictionless, automatic mechanisms rather than manual review processes, since the volume of disposable-adjacent code may overwhelm traditional human-gated quality gates. This connects to current industry discourse on AI-assisted development, where the bottleneck shifts from code generation to code evaluation and classification.

6. Conclusion

The framework answers its namesake question with precision rather than reflexive affirmation: code quality does not matter for disposable software, because the compounding risk dynamics that justify rigor are absent; it continues to matter fully for durable software. Furthermore, achieving necessary rigor need not be expensive - standardization, protocol design, and inward-flow tooling can substantially reduce its cost. Practically, engineering organizations are encouraged to classify software explicitly along the disposability spectrum before determining the level of quality investment warranted, treating disposability itself as an engineerable property rather than an accidental byproduct of AI-assisted development.

Sources

• Does Code Quality Still Matter? It Depends on This - Max Kanat-Alexander, Capital One - Original Creator (YouTube)
• Analysis and summary by Sean Weldon using AI-assisted research tools

About the Author

Sean Weldon is an AI engineer and systems architect specializing in autonomous systems, agentic workflows, and applied machine learning. He builds production AI systems that automate complex business operations.

LinkedIn | Website | GitHub