Max Kanat-Alexander of Capital One gives AI Engineer a 16-minute framework for deciding how much engineering rigor AI-built software needs.

Quality makes change understandable

  • Engineers need to understand what a system actually does and how to change that behavior safely.
  • Components make a large system comprehensible: Chromium’s URL parser can be explained even when the whole browser cannot.
  • Every change risks an immediate problem and can also make later changes harder, compounding the cost of misunderstanding.

Assess how disposable the software really is

  • Check four factors: failure consequences, replacement cost, dependencies and maintenance cost.
  • A personal calculator or one-party planner can be cheap to discard when all four are low.
  • Long-lived, widely depended-on systems still need rigorous engineering, even when agents generate their code.
  • Treat disposability as a spectrum; Kanat-Alexander advises assuming more durability than you first expect.

Design for a smaller failure radius

  • Isolate experimental tools from customer data and personally identifiable information.
  • Prevent production systems from becoming dependent on disposable tools.
  • Keep a durable fallback behind an experimental front end, and constrain each tool’s scope.

Make rigor inexpensive

  • Standardize languages, frameworks and service protocols to reduce the number of cases your tooling must support.
  • Run fast, reliable checks automatically inside the development workflow.
  • Invest in deterministic tests and reusable in-memory service substitutes; agents can help build that infrastructure.
  • Enable strict checks early, while keeping false positives low, to avoid an expensive codebase-wide cleanup later.

Caveat: cheap code generation alone does not make a system disposable. Its data access, users and downstream dependencies determine the consequences.

“You can make software more disposable.” — Max Kanat-Alexander, 10:00