CONCEPT

Dijkstrian Elegance

Not an aesthetic preference but an epistemic property: a solution is elegant when its correctness is visible. Elegance is the precondition of trust.

Dijkstra used the word elegance in a sense most readers misheard as aesthetic. He meant something far more severe. An elegant program is one you can look at and see why it works. An inelegant program is one that works but conceals its own logic. The first is correct for reasons that can be stated; the second is correct by accident — it works because its bugs happen not to be triggered by the inputs it has received. Elegance is therefore not a matter of taste but of epistemic status: the elegant solution is trustworthy because its correctness is demonstrable at a glance; the inelegant solution is a bet. Dijkstra's lifelong insistence on elegance was engineering judgment, not aesthetic preference. He believed — and the failure histories of complex systems have borne him out — that the only reliable code is code simple enough to be understood, and the only way to achieve such simplicity is to demand it, relentlessly, against the constant pressure of a culture that rewards output over clarity.

The Maintenance Imperative — Contrarian ^ Opus

There is a parallel reading that begins not with the moment of code creation but with its lifetime of maintenance. From this vantage, Dijkstrian elegance becomes a luxury afforded only to systems that can be built once and left alone. The overwhelming majority of production code exists in a state of continuous modification — patches applied to patches, features grafted onto architectures never designed to support them, teams rotating through with varying levels of understanding. In this environment, the elegant solution often becomes the first casualty of the next urgent requirement. What survives is not the most elegant but the most legible to the rotating cast of maintainers, which means the most conventional, the most pattern-following, the most similar to what they've seen before.

This is where AI-generated code may paradoxically serve maintenance better than elegance ever could. The median practice that Dijkstra scorned is also the lingua franca of the profession — the shared set of patterns that any competent programmer can recognize and modify. An elegant solution that requires deep understanding to appreciate becomes, in the hands of a junior developer at 2 AM fixing a production issue, more dangerous than a verbose but obvious one. The AI's tendency to produce conventional, even redundant code may be a feature, not a bug: it produces code that the next developer, and the one after that, can understand without needing to grasp the deep structure of the problem. The real engineering judgment may lie not in achieving elegance but in recognizing that most code will be maintained by people who weren't there for its inception and don't have time to appreciate its beauty.

— Contrarian ^ Opus

In the AI Story

Hedcut illustration for Dijkstrian Elegance — Dijkstrian Elegance

The key formulation is characteristically compressed: "Simplicity is a great virtue but it requires hard work to achieve it and education to appreciate it. And to make matters worse: complexity sells better." The observation cuts in two directions. Simplicity is difficult because it requires the programmer to understand the problem deeply enough to find its essential structure — to strip away everything that is not necessary and keep only what is. And the market does not reward this difficulty, because the market cannot distinguish between a simple solution that is correct by construction and a complex solution that appears to work. The complex solution may look more impressive, because complexity is often confused with sophistication.

AI-generated code elevates this confusion to a structural principle. Large language models are trained on vast corpora of existing code, and existing code is overwhelmingly complex — not because the problems are inherently complex but because most programmers, working under time pressure without the discipline Dijkstra advocated, produced solutions that were adequate rather than elegant. The training data encodes the profession's median practice, not its best. When an AI generates code, it generates code that resembles the code it was trained on — competent, conventional, almost never elegant. This is not a failure of the AI. It is a faithful reflection of the data.

The consequence is a subtle but pervasive degradation of the standard against which code is judged. When the AI generates a function that is correct but complex, the builder has two options: accept it because it works, or reject it and ask for something simpler — which requires her to know what simpler would look like, which requires understanding the problem at a level the AI was supposed to make unnecessary. The structural incentive points overwhelmingly toward acceptance. The code works. The deadline is real. The effort required to demand and evaluate a simpler solution produces no visible output.

The result is the progressive erosion of elegance as a standard. The smooth aesthetic that Byung-Chul Han diagnoses in contemporary culture is the same aesthetic AI-generated code embodies: smooth on the surface, opaque beneath. Code that reads well, that follows conventions, that passes linting — and that conceals, within its conventional surface, a logic no one has examined for correctness. The smoothness is not evidence of quality. It is the mechanism by which the absence of quality is concealed.

Origin

The relevant Dijkstra essay is "On the Role of Scientific Thought" (EWD447, 1974) and the various manuscripts collected in Selected Writings on Computing. The aphorism about complexity selling better appears in several EWDs from the 1970s and 1980s and reflects a concern that deepened throughout his career as the profession grew and the incentives for careful work weakened.

The argument has a surprising convergence with Dieter Rams's Weniger, aber besser in design and Christopher Alexander's quality without a name in architecture — three thinkers in three domains converging on the claim that restraint is not a limitation but the precondition of reliability.

Key Ideas

Elegance is visibility of correctness. The elegant program makes its own reasoning inspectable; the inelegant one hides its logic behind conventional surfaces.

Correct by construction vs. correct by coincidence. Dijkstra's two categories correspond to programs whose correctness was derived and programs whose correctness is a fortunate property of the inputs they happened to receive.

Complexity sells. The market cannot distinguish correct-by-construction from appears-to-work, so the market rewards output volume over understanding.

AI outputs median practice. Language models trained on the corpus of existing code reproduce the profession's habits, including the habits Dijkstra spent a career arguing against.

Regeneration compounds. Each AI-generated fix adds complexity without adding understanding. The system grows more complex with each iteration, and the complexity is of the worst kind: generated rather than designed, with no architect who can simplify it.

Debates & Critiques

The counter-position — that elegance is an aesthetic preference of a temperamentally fastidious minority — persists inside the profession, particularly among practitioners who point to the enormous volume of production code that is ugly and yet functions for decades. The Dijkstrian reply is that "functions for decades" is a statement about the narrow envelope of inputs the code has encountered, not about its correctness in the logical sense — and that when the inputs finally drift outside the envelope, the ugly code's failure will be both invisible in its onset and catastrophic in its consequences. Which account the next decade's failure histories vindicate is an empirical question the profession is actively running.

Appears in the Orange Pill Cycle

Edsger Dijkstra — On AI

The Context-Dependent Standard — Arbitrator ^ Opus

The tension between elegance and maintenance reveals that we're asking different questions at different moments in a system's lifecycle. When we ask "what makes code trustworthy at inception?", Dijkstra's view dominates completely (95%) — elegance as visible correctness is indeed the only reliable foundation. But when we ask "what makes code maintainable across team changes?", the contrarian position gains significant ground (70%) — conventional patterns, even if inelegant, provide a shared language that enables collaboration across skill levels and time.

The critical insight is that both views are describing different phases of the same system's evolution. A system benefits from Dijkstrian elegance most powerfully at its architectural level (90% weight to elegance) — the deep structures that rarely change need to be correct by construction. But at the implementation level, especially in peripheral features that will be modified frequently (60% weight to conventionality), the comprehensibility to median practitioners may matter more than mathematical beauty. This suggests AI's proper role might be inverted from current practice: AI should not generate the architectural decisions where elegance is paramount, but might reasonably generate the conventional glue code where familiarity aids maintenance.

The synthesis points toward a disciplined division: preserve Dijkstrian standards for the load-bearing structures — the core algorithms, the central abstractions, the security boundaries — where correctness by construction is non-negotiable. Accept conventional solutions for the periphery — the UI handlers, the data transformations, the logging infrastructure — where the cost of elegance exceeds its benefit. The challenge is maintaining this discipline when AI makes it effortless to generate everything, core and periphery alike, in the same conventional style.

— Arbitrator ^ Opus