Patterns Were the Map in the Search for Beauty

Christopher Alexander told the patterns community they missed the point. Thirty years later, agents finally let us listen.

In October 1996, Christopher Alexander gave the keynote at OOPSLA — the conference where object-oriented programmers gathered every year to argue about software design. He had been invited as the patron saint of the patterns movement. His 1977 book A Pattern Language was the conceptual foundation the Gang of Four had drawn on for Design Patterns a few years earlier. The whole field was, in a real sense, his.

He used the keynote to tell them they had missed the point.

The form of the pattern — name, context, problem, solution — was something software had borrowed cleanly. What had been left behind was the purpose. Patterns weren’t taxonomies. They were instruments for generating a quality Alexander was by then comfortable calling beauty: the thing that makes a courtyard feel inevitable, or a doorway feel right at five in the morning.

He told the room he hoped they would eventually get there. They mostly didn’t. The community kept refining the form — anti-patterns, pattern catalogs, books and books of templates — and Alexander spent the next decade writing The Nature of Order, four volumes on the structure of beauty in built systems. The two camps never really reconnected.

The thing patterns can’t capture

Engineers spent two decades cataloguing every shape they could find: Singleton, Observer, Strategy, Chain of Responsibility. Enterprise software followed the same logic at the next level up. ERP. CRM. Document management. Workflow engine. Identity provider. Each one a discrete category with its own pattern language and its own vendor.

Then ask any senior engineer to describe a real production system. You get something stranger.

A claims-processing system at a regional health insurer is, on inspection, maybe 30% ERP — it tracks line items, holds money, runs against an accounting period. 40% CRM — it tracks individuals, decisions about them, communications history. 30% document management — every claim has scanned attachments, every appeal has a paper trail. The categories vendors use to sell software don’t describe the categories work operates in.

Every senior engineer I know has lived this. The vendor sells you the ERP. You implement it. Six months in, the shape of the work isn’t ERP-shaped — it’s something else the vendor’s data model can’t quite hold — and the spreadsheets and Slack channels start filling in the rest.

A partition is not a whole

It’s tempting to stop there and say: real systems are blends of categories, and patterns don’t catch blends. That framing concedes too much. A blend implies a partition — that the system can be cleanly carved up into 30% of this and 40% of that, summing to 100%. It still gives the categories the dignity of being the right axes.

That’s not what’s actually happening. The ERP-ness of the claims system is not separate from the CRM-ness. The line items only make sense alongside the individual whose decision created them. The communications history hangs on the document trail. And the document trail is paper stapled to nothing without the line items it justifies. The categories don’t slice a pie. They are codependent centers, and the codependence is the system.

Alexander had a name for this. In The Nature of Order he describes fifteen fundamental properties that he claims contribute to the wholeness of a built artifact — strong centers, deep interlock and ambiguity, not-separateness, among others. Wholeness, in his framework, is what happens when the parts of a system strengthen each other rather than tile. A beautiful courtyard is not a sum of wall and bench and tree. It’s a configuration where the wall makes the bench feel like a place to sit, the tree makes the wall feel like shelter — and somehow, the bench makes the tree feel placed rather than planted.

A claims-processing system is the same kind of thing, when it works. When it doesn’t, you bought three vendors and integrated them, and you got something that diagrams cleanly and operates badly. The seams show. The work happens in spreadsheets.

This is why patterns were a dead end. A pattern is, by construction, a separable unit. It can be named, lifted out of context, and reused. That’s the entire point. But the property Alexander cared about — wholeness, beauty, deep interlock — is exactly the property that does not survive separation.

Map and terrain

There’s a phrase from general semantics — the map is not the territory — that captures the same point operationally. A pattern is a map. The named, separable thing the catalog points at. The terrain is the system that has to actually run, with all its interpenetrating centers and codependencies and exceptions.

Workflow software is where this gets expensive. A workflow encodes a map: this step, then that step, then this branch, then that approval. It assumes the work decomposes into known stages in a known order. Where the work fits the map, that’s industrial-strength leverage. Where it doesn’t — where the operation is interpenetrating rather than sequential — the workflow forces the terrain into the shape of the map. That’s where you get the joke at every enterprise: there’s the system everyone officially uses, and the spreadsheet where the work actually gets done.

Workflow software didn’t create that gap. It industrialized it. It encoded the map into the system itself, which made a bad map cheaper to enforce and harder to bend.

Jason Stanley writes about this in governance terms. He sorts work governance into four modes — procedural (verify the steps), credentialing (verify the actor), gatekeeping (verify the output), reputational (trust accumulated over time). Alexander’s own practice was reputational: clients on the Eishin School trusted him because he’d built things they recognized as alive. That mode doesn’t transfer to a non-human builder. When an agent walks onto the site, governance has to fall back to gatekeeping — verifying the output instead of trusting the actor.

Planting flags

Alexander’s practice on his bigger projects — the Eishin School outside Tokyo, the Mexicali housing — was not to draw a blueprint and hand it to builders. He walked the site. He planted flags where buildings would go. The plan came out of the topology, not the other way around. He was, in his own vocabulary, finding the centers — the places the site wanted a building — and letting the buildings emerge from there.

This is the move I think agents finally make available on the software side.

The way you hand an agent a task whose right answer depends on the specific terrain of your data, your customers, your existing systems is not by writing a workflow. It’s by giving it a runbook — a quality bar in markdown — and a rubric that measures the gap between output and bar, then letting it figure out the procedure. The procedural details — step order, retries, routing — stop being something a human has to specify in advance. You plant flags. The agent fills in the building. This is the bet I’ve been making with Jetty.

A journalist isn’t measured on her first draft. A designer isn’t graded on her sketches. They’re judged on what comes out the other side, against a standard their editor or art director can articulate. We’ve governed knowledge work this way for a hundred years. We’ve never been able to govern software systems this way, because the systems couldn’t read the standard. Now they can.

What’s a beautiful system, then?

I don’t have a clean answer. I keep running into it without recognizing it. A workflow that handles the easy 80% and falls back to a runbook for the rest. An evaluation pipeline whose rubric makes the codependence of the centers visible. An agent that produces a pull request that fits the codebase as if it had always been there. None specified by category. All specified by outcome.

Markdown rubrics work for a single task. The honest open question is what the outcome specification looks like at the level of a whole system. A whole organization.

I suspect Alexander would say it’s some version of beauty, and that we’d recognize it when we saw it. The patterns weren’t going to get us there. We’ve had thirty years to find out.