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

      AI has accelerated the process of writing code to unprecedented levels. However, the challenging aspect now lies in comprehending a system and making modifications without introducing errors. This remains a significant cost, ultimately influencing how much work can be assigned to automated tools.

      **Introduction**

      In 1987, Fred Brooks, in his essay “No Silver Bullet,” forecasted that no single tool or method would yield a tenfold increase in software productivity within a decade. The years that followed have largely validated this view, as his argument was not based on the technology available at the time. Brooks categorized the challenges of software development into two types: accidental complexity, which refers to the extra effort imposed by tools—such as syntax and boilerplate—and essential complexity, which pertains to the intrinsic demands of the problem itself, including system requirements and design structures that can scale. He posited that tools primarily address accidental complexity while leaving essential complexity largely unchallenged, as it constitutes the majority of the workload.

      AI coding tools represent the most significant breakthrough against accidental complexity to date. They can produce functions or assemble entire test suites in mere seconds, significantly reducing the effort associated with the mechanical aspects of programming. This has led to the widely-held belief that because code is now inexpensive, its quality is less crucial. The approach becomes: describe what is needed, let the AI generate it, and if issues arise, simply adjust the description and regenerate the code.

      However, Matt Pocock, a software educator, presented a counterargument at a conference that aligns with my experiences. In my role leading AI engineering at a legal research firm, I work with these tools daily, and in a tangible codebase, the idea that “code is cheap” does not hold true. While generating code might be inexpensive, understanding it and modifying it without inadvertently causing additional problems remains costly. For an AI model to make safe modifications, it must first comprehend the codebase. Consequently, the complexity of a system limits the extent to which tasks can be delegated to machines. AI does not render software design optional; instead, it raises the stakes of neglecting it.

      **The Unresolved Costs**

      When people assert that writing code is cheap today, they are referring to the ease of creation. However, the real costs of software lie in what occurs after the initial version runs: the need to comprehend the code later and to modify it without inadvertently impacting other components.

      John Ousterhout precisely terms this expense as complexity, which he defines as the aspects of a system’s structure that complicate understanding or modification. The manifestations of complexity can include change amplification, where minor alterations necessitate multiple edits across the system; cognitive load, referring to the vast amount of information a developer must retain to make code changes safely; and unknown unknowns, where it's unclear which sections a change could influence. None of these complexities relate to typing speed; they hinge on understanding, and faster code generation does not inherently lead to better comprehension.

      AI exacerbates this issue. A model can generate much more code at a significantly faster rate than a human, which results in a greater surface area to comprehend and increases the potential impact of a single change across the codebase. This creates a compounded cognitive burden since now both the model and the developer need to understand the system: the model must gain enough insight to modify it correctly, while the developer has to understand both the system and the changes proposed by the model to have confidence in them. Thus, the assertion that “code is cheap” is only partially accurate and potentially misleading.

      **The Role of AI as a Tactical Coder**

      Ousterhout distinguishes between tactical and strategic programming. The tactical programmer focuses on quickly getting current tasks completed and promptly moving on, while the strategic programmer invests extra effort to maintain a clean system structure, making future changes safer and less costly. Tactical tasks may be faster now, but they incur higher costs down the line.

      By default, a language model acts as a tactical programmer. It is designed to generate functioning code rather than well-structured code that would be beneficial for colleagues in the future. Consequently, it may replicate code blocks instead of abstracting shared logic, add parameters rather than reevaluating interfaces, and implement local fixes that work in isolation but jeopardize overall system integrity. The Pragmatic Programmer describes this as software entropy: each modification made without consideration for system design further pushes it toward disorder.

      Evidence of this drift is beginning to surface. A study in 2026 examined over 300,000 AI-generated commits across more than 6,000 public repositories, analyzing what changes were introduced. The results revealed that over fifteen percent of these commits introduced at least one new issue, with nearly ninety percent of those issues classified as code smells—structural problems that compile and pass tests but complicate future understanding and modifications. Although the code functions, the underlying design continues to degrade, illustrating the accumulation of accidental complexity one commit at a time. This expense does not factor into the model's optimization