Separation of Concerns (Dijkstra)

In the AI Story

The principle was introduced in Dijkstra's 1974 paper "On the Role of Scientific Thought," in a passage that made clear the separation was first a property of mind and only derivatively a property of code. The programmer separates concerns because she cannot reason about many concerns at once; the human skull is strictly limited in capacity. Managing complexity that exceeds that capacity requires addressing one concern in isolation from all others, verifying that it has been correctly handled, and moving to the next. The modular organization of code that mirrors this discipline is a consequence of the discipline, not a substitute for it.

The distinction between discipline and organization matters enormously when the source of the code shifts. A codebase can be perfectly modular — clean interfaces, well-separated responsibilities — and still be intellectually unmanageable if the person responsible for it did not create the separation and does not understand the reasoning that produced it. Modularity in the artifact provides organizational convenience but not epistemic assurance. The separation has to exist in the mind that builds, or it exists only on paper.

AI code generation destroys the discipline at the generation layer. When a builder describes a desired outcome and receives a complete implementation, every concern has been addressed simultaneously by a statistical process she does not control and cannot inspect. The AI did not address correctness separately from efficiency. It did not define interfaces before implementing functions. It generated code that appears to satisfy the described outcome, optimizing for plausibility rather than for the structured, layered, independently verifiable construction that separation of concerns demands. The output may be organized into modules; the modules were not arrived at by separation in the builder's mind.

A related problem, subtler and more corrosive, concerns the interactions between concerns. When the programmer separates concerns herself, she develops an understanding of how they interact — where correctness and efficiency trade off, where interface design constrains implementation. This understanding is perhaps the most valuable form of engineering knowledge, and it is the knowledge Segal's senior engineer was drawing on when he made architectural decisions with confidence. AI-generated code does not produce this understanding, because the interactions were handled internally by a process the builder cannot reconstruct.

Origin

The phrase "separation of concerns" appears for the first time in Dijkstra's 1974 paper "On the Role of Scientific Thought" (EWD447), though the underlying practice had been central to his thinking at least since the late 1960s work on structured programming. The paper framed the principle as a general scientific method — an argument that deep understanding requires the discipline of restricting attention — and only secondarily as a technique for software.

The term was absorbed into the software engineering vocabulary over the subsequent decade and has since become a commonplace, routinely invoked in architectural discussions without any reference to Dijkstra's broader epistemological claim. The flattening of the concept from discipline to organizational maxim is itself a case study in what happens to powerful ideas that become popular.

Key Ideas

Discipline of attention, not filing scheme. The separation lives in what the programmer is thinking about at any moment; the code structure follows, but the code structure alone is not the principle.

Skull-limited. The human mind cannot hold a complex system in view all at once. Separation of concerns is the concession to that limit — and the technique that turns the limit into a source of reliability rather than a cause of failure.

Verifications compose. If each concern is addressed in isolation and verified, and the interfaces between concerns are specified precisely, the composed system inherits the correctness of its parts. This is the modular structure of mathematical proof applied to computational systems.

Modularity in artifact is not separation in mind. AI-generated code can be modular without having been produced by a separation of concerns. The builder sees the organization; she does not see the reasoning that produced it, and therefore cannot independently verify it.

Interaction knowledge is lost first. When the generation process handles concerns internally, the trade-offs between concerns become invisible. This is the knowledge that erodes first when implementation is delegated, because it was never deposited in the builder's mind in the first place.

Debates & Critiques

The operational question raised by the principle in the AI era is whether separation of concerns can be preserved as a discipline when the generation layer does not observe it. One response is to require that builders decompose requirements into independently specified concerns before prompting the AI, and evaluate each generated concern separately; this preserves the discipline at the specification layer while accepting that the generation layer does not. Another response, more pessimistic, is that the decomposition only works if the builder understands the domain well enough to recognize what concerns exist — which is the expertise the natural language interface was supposed to make unnecessary.