Complexity is the limit: software design during the era of AI programming.

      AI has significantly accelerated the code-writing process. However, the greater challenge lies in comprehending a system and making modifications without causing errors. This aspect has not become less expensive, and it fundamentally influences the extent to which tasks can be entrusted to machines.

      **Introduction**

      In 1987, Fred Brooks, in his essay “No Silver Bullet,” anticipated that no tool or technique would achieve a tenfold increase in software productivity in the following decade. The years following have largely validated his prediction, primarily because his argument transcended the technology of his time. Brooks categorized the challenges of software development into two types: accidental complexity, which refers to the unnecessary burden imposed by tools—like syntax, boilerplate, and infrastructure—and essential complexity, which pertains to the inherent requirements of the problem itself, such as determining what the system needs to accomplish and creating an adaptable design. He contended that tools tend to only mitigate accidental complexity, leaving the essential complexities intact, which constitute the majority of the work.

      AI coding assistants represent the most significant advancement in tackling accidental complexity. They can generate a function or create an entire test suite in a matter of seconds, effectively reducing the cost related to the mechanical aspects of programming. This has led to the commonly accepted notion that code is now inexpensive, suggesting that the code itself is of little consequence. You can describe your needs, let the model create the code, and if issues arise, merely alter the description to regenerate the code.

      Software educator Matt Pocock recently articulated a counterargument in a conference talk, which resonates with my own experiences. As the leader of AI engineering at a legal-research company, I utilize these tools regularly, and I find that in a practical codebase, the "code is cheap" assertion does not hold true. While writing code may be inexpensive, understanding and amending it without causing further issues remains costly, and any model must comprehend a codebase sufficiently to modify it safely. Therefore, the complexity of a system sets the limit on how much can be delegated to a machine. Far from making software design optional, AI raises the stakes of neglecting it.

      **The Cost that Remains**

      When people claim that code is now inexpensive, they refer to the reduced cost of writing it. However, the real expenses lie beyond the initial draft: it’s about making sense of the code later and modifying it without accidentally introducing new problems. John Ousterhout precisely identifies this cost as complexity. According to his definition, complexity encompasses aspects of a system's structure that complicate understanding or modification. It manifests through change amplification, where a minor modification necessitates numerous alterations, cognitive load, which refers to what developers must remember to manipulate the code safely, and unknown unknowns, which highlight the uncertainties surrounding which other areas a change might influence. None of these factors are related to typing speed; they are purely about comprehension, and generating code more quickly does not equate to enhanced comprehension.

      AI shifts this dynamic unfavorably. A model produces considerably more code than an individual, and does so at greater speed. This results in a larger volume of code requiring understanding, as well as amplifying the potential impact of any single change across the codebase, all competing for the same cognitive resources. The comprehension challenge also increases, given that the model must understand the system well enough to alter it correctly, while the human needs to grasp the system and any modifications made by the model sufficiently to trust them. Hence, the statement "code is cheap" is partly true, and it is the perilous aspect.

      **AI as a Tactical Programmer**

      Ousterhout delineates a clear distinction between tactical and strategic programming. Tactical programmers focus on getting the immediate task completed, while strategic programmers invest extra effort to maintain a clean structure for the system, making future modifications cheaper and safer. Today, tactical programming is more expedient but grows more costly with every subsequent day.

      By default, a language model functions as a predominantly tactical programmer. Its training and prompts are aimed at producing operational code rather than code that a colleague would appreciate inheriting. Consequently, it tends to replicate blocks of code rather than abstracting shared concepts, add parameters instead of reconsidering interfaces, and opt for localized fixes that, while functional in isolation, degrade the overall integrity of the system. The Pragmatic Programmer refers to this phenomenon as software entropy, where each change that disregards system design contributes to increased disorder.

      Evidence of this entropy is beginning to emerge. A study conducted in 2026 analyzed over 300,000 AI-generated commits across more than 6,000 public repositories, using static analysis before and after each change to determine what the model introduced. More than fifteen percent of those commits introduced at least one new issue, and of all identified issues, nearly ninety percent were categorized as code smells—structural flaws that compile and pass tests yet make understanding and modifying the code more challenging. The code may function, but the design deteriorates silently. This is accidental complexity accumulating with each commit