essay #code-craft #ai #essays
Code learned craft from architecture. Now it's learning the assembly line. We already know how it ends.
Software borrowed 'design patterns' from a building architect. Architecture's next chapter was industrialization — and it tells us what AI is doing to code.
~ $ ./lineage --trace craft ────────────────────────────────────────────────────────────── architecture master-builder → Bauhaus → Int'l Style → Levittown → parametric software hand-rolled ───→ structured → patterns ───→ frameworks → AI-gen ◀ you are here # borrowed the patterns. it's inheriting the whole century.
Every developer who reaches for a design pattern is quoting a building architect, whether they know it or not. The Singleton, the Factory, the Observer — the whole vocabulary of Design Patterns, the 1994 book four engineers wrote that every senior still has on a shelf — was lifted, deliberately and with credit, from a man who designed houses and campuses. His name was Christopher Alexander, and what software borrowed from him was not a metaphor. It was a method.
That detail usually gets told as trivia and dropped. I want to do the opposite and take it literally. If code imported architecture’s theory of craft, then architecture’s next chapter — what happened to the master builder after the patterns — isn’t a coincidence to admire. It’s a forecast. And we already know how it ends.
The Gang of Four had a fifth member — and he designed buildings
Alexander’s A Pattern Language (1977) and The Timeless Way of Building (1979) argued that good design could be captured as named, reusable patterns — a problem, its context, and a solution that recurs — and assembled like a grammar. In the late 1980s Kent Beck and Ward Cunningham took that idea and pointed it at software. In 1994 Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides — the “Gang of Four” — published Design Patterns and turned Alexander’s move into the common tongue of object-oriented programming. The loop closed in 1996, when Alexander gave a keynote at OOPSLA, mildly bewildered that programmers had run further with his idea than architects had.
So the parallel isn’t poetic license. It’s a citation trail. Which is exactly why the rest of architecture’s history is worth reading as if it were our own — because the patterns weren’t the end of that story. They were the artisan phase, right before it industrialized.
Architecture’s industrial century
For most of history a building was made by a master builder who held the whole thing in his head — structure, ornament, the local stone, the client. Then, across roughly one century, that craft was taken apart and rebuilt as an industry. The Bauhaus opened in 1919 under Walter Gropius to marry design to mass production. Le Corbusier, in 1923, called the house “a machine for living in” — four words that are really a thesis: a building is a product, optimizable, repeatable. By 1932 the look had a name, when curators Henry-Russell Hitchcock and Philip Johnson mounted a show at New York’s MoMA and called it the “International Style” — the same glass-and-steel grammar, deployable in any city on earth. After the war it scaled: Levittown (1947) stamped out 17,447 near-identical houses on Long Island; the curtain wall turned skylines into repeated modules. The endpoint is parametric design — Patrik Schumacher’s “parametricism,” around 2008 — where you no longer draw a building, you write the rules, vary the parameters, and let the forms generate themselves.
Read that progression with software eyes and the rhyme is almost too on the nose. Hand-rolled code gave way to structured programming, then to design patterns, then to frameworks and package managers that ship whole rooms pre-built, and now to a tool that generates the forms from a prompt. Same arc: craft → standard → component → generation. The image up top is just those two tracks laid over each other.
The honest part — standardization mostly worked
Here is where the nostalgia piece starts mourning, and where it goes wrong. Architecture’s industrialization was, on balance, a triumph. Standardized methods and mass production are what housed the exploded postwar population — quickly, safely, affordably. Building codes made buildings stop falling down. The “boring” glass box is also the legible, efficient, anywhere-deployable box. Nobody actually wants the world where every structure is a bespoke artisanal miracle and most people therefore can’t afford one.
The software version is just as clearly good, and you use it every day. Design
patterns gave teams a shared vocabulary. Frameworks and package managers are the
shipping container of code — the stack you npm install without reading. They are
how a small team ships what used to take an army, and how an engineer in São Paulo
or Lagos or Kraków builds on exactly the same foundation as one in San Francisco:
the International Style of software, and, like its namesake, a form of access as
much as a flattening of local character. Refuse the easy lament here.
Standardization earned its place.
So if it isn’t craft we’re losing, what is it?
So what’s actually lost? (the turn)
The thing worth worrying about was never beauty. It’s understanding. And the sharpest statement of it is forty years old.
In 1985 the Danish computer scientist Peter Naur — the “N” in BNF, a Turing Award winner — wrote a short paper called “Programming as Theory Building”. Its claim cuts against everything our tools quietly imply: the real product of programming is not the source code. It’s the theory in the programmers’ heads — the model that maps the problem onto the program, that knows why the code is shaped the way it is, what it assumes, where it would break, which changes are safe. Naur put it without hedging:
A main claim of the Theory Building View of programming is that an essential part of any program, the theory of it, is something that could not conceivably be expressed, but is inextricably bound to human beings.
— Peter Naur, Programming as Theory Building (1985)
The text is a lossy projection of that theory. A program is not its source code; the source is the residue, and the understanding that produced it lived in someone’s head. Lose the people who hold it and you don’t have a maintainable program — you have an artifact nobody fully understands, with the source sitting right there in front of you.
Architecture ran this exact split a century ago. The master builder — one head holding the whole theory — was broken into pieces: an architect who draws, a structural engineer who calculates, a contractor who builds, and a catalog of standard parts nobody on site fully understands. The theory didn’t vanish; it was distributed across specialists, codes, and components. That distribution is what made scale possible — and it’s also why no single person on a modern site holds the whole building in their head the way a master builder once did.
Code is now doing something one notch more extreme. With patterns and frameworks, the theory was distributed across a team and its libraries. With AI generation it can dissolve entirely. This is what Andrej Karpathy named “vibe coding” in early 2025 — building by prompting and accepting, where the code works and ships and nobody, human or model, holds the theory of why. The program runs; the understanding was never built. That’s not the loss of artisanship. It’s the loss of the thing artisanship was a way of producing.
And it has a cruel second-order effect, the part I keep coming back to: the theory used to get built by doing the grunt work. You became the person who holds the model of the system by writing its boring functions, chasing its bugs, sitting in its code reviews. That on-ramp is exactly what AI eats first — the same fracture I wrote about as the breaking junior pipeline. Distribute the theory and you still have specialists who each hold a piece. Dissolve it and you risk a generation of software nobody ever understood in the first place.
How this story actually ends
Stop architecture’s story at the glass box and you get a tragedy. But it doesn’t stop there — and this is the genuinely useful part, because the backlash already happened and we get to read it.
The International Style didn’t win forever. In 1961 Jane Jacobs published The Death and Life of Great American Cities and dismantled the top-down, machine-for-living orthodoxy — most famously against Robert Moses and his plan to run an expressway through lower Manhattan. In 1966 Robert Venturi answered “less is more” with “less is a bore,” and postmodernism was off. New Urbanism brought back the street and the square. Parametric tools — the supposed endpoint of standardization — turned out to be how you get variation cheaply again: place and difference, generated. The real arc wasn’t craft → standardization → the end. It was craft → standardization → backlash → synthesis.
That’s the forecast for code, and it isn’t a doom one. The synthesis won’t be a retreat from AI generation any more than architecture retreated from steel. It’ll be a re-valuing of the one thing standardization and generation can’t supply on their own: someone who holds the theory. The engineer who matters in five years isn’t the one who refuses the model or the one who rubber-stamps it. It’s the one who still understands the system well enough to catch the generated answer that’s plausible and wrong — the last twenty percent, where the judgment and the cost both live.
The machine can produce the building. It still can’t hold the theory of why the building stands. That part didn’t get automated. It got more valuable.
Architecture took a century to learn that lesson and is still arguing about it. Code is running the same loop in about a decade. We have one advantage the architects didn’t: their century is already written down. We can skip ahead to the part where we remember what standardization was about to make us forget — and decide, on purpose, to keep holding the theory.