Separation of concerns

In software, a concern is any aspect of a system that has to be got right: what it stores, how it looks, how it behaves, who’s allowed to change it. Separating concerns gives each of these its own place, so the code that fetches an event’s date needn’t know which font will display it, and a change to one part doesn’t ripple unpredictably through the rest. On the web, the familiar version is the division of labour between HTML for structure and meaning, CSS for presentation and JavaScript for behaviour.

Edsger Dijkstra coined the phrase in a 1974 essay, where it described a habit of mind as much as a technique: thinking hard about one aspect of a problem at a time while remembering that the others are still there. He conceded that the separation can never be complete. That caveat matters, because separation is a question of where the boundaries sit and which way the dependencies run. It doesn’t promise that the parts never touch.

Why it matters for content

Content people mostly meet the principle as the separation of content from presentation. When the words, facts and structure of a piece are stored apart from the templates that display them, a redesign doesn’t mean rewriting, and the same material can appear as a web page, an app screen and a newsletter item. The CSS Zen Garden, launched by Dave Shea in 2003, made the case memorably: hundreds of designers restyled one page without touching its HTML. Structured content, headless CMSs and create once, publish everywhere all depend on the same split. So does a piece of writing’s ability to travel, since copy that leans on its layout (“see the panel on the right”, a heading that only makes sense beside its photo) breaks as soon as it moves.

The principle reaches well beyond templates. An organisation separates concerns when it keeps editorial rules in a style guide and visual patterns in a design system, or gives a fact one owner and one source of truth. Each boundary decides who can change what without consulting everyone else.

Overdone, it creates problems of its own: writers working blind to the space their words will fill, designers drawing boxes for content nobody has written yet, and a CMS divided so finely that authors can no longer see what they’re making. Adam Wathan’s essay on utility CSS argued that the textbook web split often moves the coupling between markup and styles rather than removing it. Content and presentation shape each other whatever the architecture says, so good separation makes that dependency deliberate and visible.

How AI changes the picture

Large language models undo one of computing’s oldest separations. A conventional program keeps its instructions apart from the data it works on, whereas a model receives both as text in a single stream: the system prompt, the user’s request, a retrieved policy document and the email it’s been asked to summarise. If that email contains a line telling the assistant to disregard its instructions, the model may obey it. Simon Willison named this prompt injection in 2022, comparing it to SQL injection, where the fix was to pass the query and the user’s input to the database separately.

Language models have no equivalent fix yet. Any text an AI system reads, from published pages to supplier documents and customer messages, can therefore carry instructions as well as information, and permissions, validation and approval steps have to supply the separation the model can’t guarantee.

Separation also decides how well AI-assisted content work holds together. When research, drafting and checking are distinct steps with their own instructions and criteria, a poor result can be traced to the step that produced it. Keeping verified source content apart from generated versions means a correction can be made once and flow outwards, instead of being chased through every summary. Even a system prompt benefits: one that mixes voice, policy, product facts and formatting rules in a single block is hard to maintain, while separate sections can each be updated by whoever owns them.