Does Code Quality Still Matter in the Age of AI? It Depends on One Thing
Ask any senior software engineer a question, and you are almost guaranteed to get their favorite two-word answer: "It depends."
In the era of AI coding tools and "vibe coding," the debate over whether code quality still matters has reached a fever pitch on social media. In a presentation for the AI Engineer channel, Max Kanat-Alexander (Capital One) moves past the binary "yes or no" arguments to offer a concrete framework for when engineering rigor is critical—and when you can throw it out the window.
The Foundation: Why Code Exists at All
Before deciding if code quality matters, we have to establish what software engineering practices are actually trying to achieve. According to Kanat-Alexander, everything you want to accomplish with a piece of software—whether aligning a model, scaling a system, or driving adoption—boils down to two factors:
- Understanding the system.
- Executing on that understanding.
Debuggers, observability tools, evals, and tests don't exist in a vacuum; they exist exclusively to improve our understanding of a system and our ability to act on it. For a software engineer, this comes down to two critical questions:
- What is the actual, concrete behavior of the system? (Not just what the documentation claims it does.)
- How do I correctly and safely modify that behavior?
While a simple "Hello World" program is easy to grasp in its entirety, real-world systems—like the massive open-source Chromium codebase—have essentially infinite possible interactions. No human can hold the entire behavior of Chromium in their head. Instead, we rely on understanding specific components, like a URL parser.
This is why code exists: for structure. In the past, engineers talked about concepts like "readability" and "testability," which sound like purely human concerns. What always mattered most underneath was recognizable, understandable structure.
The Vicious Cycle of Modification Risk
Structure matters most when you need to modify a system. Every modification carries two risks:
- Introducing an immediate problem: This isn't just a bug—it could be a missed deadline, budget overrun, or misaligned user behavior caused by the difficulty of understanding the system.
- Making future changes harder: By degrading the structure, you make the system harder to understand next time.
Risk #2 feeds directly back into Risk #1 in a compounding, non-linear cycle. Over time, giant codebases can reach a state where every single change triggers organizational friction, timeline delays, or production incidents.
The Great Divide: Durable vs. Disposable Software
While people debate whether future AI models will eventually have an infinite capacity to untangle massive complexity, AI is already doing something else right now: making disposable software 100,000 times more common.
Historically, engineers have spent most of their time building and maintaining durable software—systems that live for years, serve thousands or millions of users, and carry catastrophic business consequences if they fail. Durable software isn't going away; in fact, AI tools will likely lead to more durable software being built.
However, AI agents also allow us to spin up software where:
- The consequences of failure are minimal or non-existent.
- Few people (and no other production systems) depend on it.
- The cost of replacement is near zero (it can be rebuilt in hours).
- The cost of maintenance is basically nothing.
Don't like your OS calculator? Have an agent build a custom one. Planning a kid's birthday party? Spin up a one-off party planner app and throw it away on Monday. In the world of disposable software, code quality does not matter at all because the compounding risks of future modifications simply don't exist.
| Evaluation Factor | Disposable Software | Durable Software |
|---|---|---|
| Consequences of Failure | Minimal to none | High / Business-critical |
| Dependencies | Isolated; used by one or a few people | Depended on by thousands/millions or other systems |
| Cost of Replacement | Near zero (replaceable in hours/days) | Extremely high |
| Cost of Maintenance | Unimportant or nearly free | Enormous ongoing investment |
| Engineering Rigor Needed | None | Maximum |
Two New Disciplines for Modern Engineering
Because disposability and durability exist on a spectrum, modern software teams have two strategic levers they can pull.
1. Engineer for Disposability
Instead of applying heavy processes to everything, organizations can architect environments that intentionally make software safe to throw away:
- Isolated Environments: Create sandboxes that only access an individual user's data, with zero access to customer data or PII.
- Enforced Independence: Block inbound API calls from other production systems so nothing can accidentally depend on a disposable tool.
- Durable Redundancy: Keep a reliable, "clunky" legacy system as a backup, while letting employees "vibe code" fast, custom front-ends for their own workflows. If their custom front-end breaks, they just fall back to the durable system.
- Strict Scope Limits: Keep tools hyper-focused on a single user or a single event.
2. Drive Down the Cost of Rigor
Experienced engineers know that "temporary" prototypes have a habit of becoming permanent production systems. If you misjudge where a project sits on the spectrum—or change your mind later—you want the transition from disposable to durable to be as painless as possible. You achieve this by making engineering rigor cheap and effortless:
- Ruthless Standardization: Standardizing languages, frameworks, and RPC protocols isn't about bureaucracy; it's about eliminating possibilities. Fewer frameworks mean fewer linters, security patches, and bespoke agent tools you have to maintain.
- In-Workflow Tooling: Build quality checks that run automatically in the background. When tooling is fast, reliable, low on false positives, and requires zero conscious effort from the developer, it feels free—meaning you can apply it even to disposable projects.
- Frictionless Testing Infrastructure: Don't require every developer to be a testing expert. Invest in infrastructure that makes tests fast and deterministic out of the box—for example, using coding agents to automatically generate and maintain in-memory fake versions of services.
- Maximum Strictness Up Front: Turn all lint rules and strictness settings to the maximum from day one. It eliminates endless team debates and prevents the nightmare of trying to retroactively enable a linter on a million-line codebase.
The Verdict
So, does code quality still matter? Kanat-Alexander leaves us with three clear answers:
- For disposable software? No.
- For durable software? Yes.
- Does rigor have to be expensive? No.