I was thinking about a couple of ideas. They were too good not to put them here. Have fun this weekend. Happy Friday to everyone.
Software Architecture Is Fractal
And That Is Why Your AI Keeps Breaking It
A small heresy, before we rename the problem again.
We have a tradition in this field. Every year or so we rediscover that the work is hard, panic quietly, and give the hard part a new name so it feels solved. Prompt engineering was a name. Context engineering was a name. Workflow orchestration is the fashionable one now, and I can already hear the next one warming up backstage, something like intent expression, and the one after that will be grander still, maybe self-assembling agent philosophy, sold by someone in a very good jacket. Each name promises the same thing. Learn it, and the work disappears.
I want to talk about the one part nobody has managed to rename into submission, the part that outlives every rebrand because it will not hold still long enough to be packaged and sold. The architecture itself. Not the prompts that feed it or the context you pour into it, but the shape underneath them: the boundaries, the rules, the reason a thing is built the way it is. The part you are quietly supposed to be in charge of, and the part that stops being anyone’s job the moment the project starts moving fast.
Here is the scene every one of you knows. You start a project clean. You draw the boundaries, you write the rules, you feel briefly like a competent adult. Then the thing grows. People add features, the deadline arrives, and lately a very confident machine writes half the code while you sleep. Six months later (or six hours, if your agents are working hard enough and your account allows it) the shape you designed is a corpse, and there was no murder, only a thousand small reasonable decisions, each one fine on its own, none of them flagged, because who flags a reasonable decision. We call the corpse drift, and we agree to deal with it later, which is to say never.
I used to think this was a tooling problem, the kind a better linter or a stricter pipeline would eventually catch. I have changed my mind. I think it is a language problem, and I think it has been one since long before the machines arrived to make it loud.
Watch what happens when you try to be precise. Ask five engineers what a “component” is. You will get five answers, delivered with total confidence, none of them wrong, none of them the same. Now do it again with “service,” “module,” “layer,” “unit.” We have built an entire discipline on words that mean something different to every person holding them, and then we act surprised when a machine, or a new hire, or an agent, cannot protect a structure we were never able to say out loud. You cannot guard a shape you cannot name.
So here is the idea. I will say it plainly and keep a mostly straight face, because it is simpler than the apparatus we have bolted on top of it.
Software architecture is fractal.
The same shape repeats all the way up and all the way down.
A function has a boundary, a reason to exist, and things it talks to. A service has a boundary, a reason to exist, and things it talks to. A whole system, the same. There is no floor where architecture quietly turns into something that is not architecture. It is one pattern, repeating, zoomed in or zoomed out. The thing you are looking at on every level is the same thing, and the only reason it feels like five different disciplines is that we gave each floor its own vocabulary and then forgot they were all describing the same building.
Which is why I stopped saying “component” and started using one word for the whole stack of it. A unit. And a unit is defined by exactly one thing, the only honest thing you can say about all of them at once.
A unit is anything that is different from its surroundings.
That is the entire definition, and I mean entire. Not its size, not its language, not whether it is a function or a container or a team or a whole company. If you can tell it apart from what sits around it, it is a unit. The function is a unit. The service is a unit. The subsystem is a unit. The system is a unit. They are the same animal in different coats, and once you see that, two stubborn problems get quietly smaller.
The first is description. If everything is the same kind of thing, you can describe it with the same handful of questions, written once, asked at every level. What is this. What does it talk to. What does it need in order to live. Why is it shaped this way. A machine can hold that, because the shape never moves on it. A tired human at two in the morning can hold it. So can an agent, which is the entire point of saying any of this out loud.
The second is drift, which finally gets a definition instead of a mood. Drift is a unit becoming harder to tell apart from its surroundings, or starting to touch things it was never meant to touch. And because the pattern repeats, you do not have to keep the whole system in your head at once like some party trick that gets harder every quarter. You check one unit, at one level, and move on. The impossible audit becomes a stack of small boring ones, and small boring things are exactly what we already know how to automate.
There is one piece left, and it is the one experienced people lose without noticing. The reason a unit is shaped the way it is has to travel with the unit. Right now that reason lives in the architect’s head, because after enough years it stops feeling like knowledge and starts feeling like the obvious, and nobody writes down the obvious. Then someone arrives who does not share the feeling, meets a silence where the reason should be, fills it with a perfectly sensible guess, and the guess is the drift. The knowledge was never missing to the person who had it. It simply never got attached to anything a stranger could read, and an agent is the most literal stranger you will ever hire. Put the reason next to the unit, in plain words, and the machine has something to respect instead of a blank to improvise into.
And now the part that makes me think this is buildable this year and not in some keynote future. We do not have to invent the machinery. Graph databases, policy engines, conformance checkers, observability, type systems, the formal methods people who have been quietly correct for decades. The tools to check all of this already exist. They are just scattered across a dozen research fields that have never been in the same room, and until recently nothing could speak all of their dialects at once. The dull practical move is to write your units in something plain, YAML will do, so that people and models and tools can all read it without a fight, and then pour that into a graph you can actually reason over. The genuinely new ingredient is the one thing that can walk between all those rooms and translate. That is what the machine is for here. Not the magician. The glue.
Which brings me to an old joke that has slowly stopped amusing me. Science began as one thing, philosophy, and then it shattered into physics and logic and linguistics and computer science, each of them off in its own building, proud and partial. And now there is something that can move between all of them, and the walls are coming down without anyone deciding to demolish them, and it is sliding back toward one thing again. Philosophy, with better tooling. Whether architecture is structure, or language, or logic, stops being three arguments and goes back to being one question, which is roughly where it started.
So no, fractal is not the next magic word, and a unit is not a framework with a clever acronym and a TODO list. That is the opposite of what I am offering, and I am not offering. The magic words all promise the work vanishes. This one only points at why the work was never going to vanish, and gives it a shape you can finally hand to someone who is not you.
Two questions, and I would honestly rather have your answers than your approval.
For the ones who like to argue: is software architecture more linguistic than we admit, fractal all the way down, and have we been making it hard on ourselves by inventing a brand new vocabulary at every floor?
For the ones shipping real things on real deadlines: when you build on a large codebase with a machine in the loop, how do you actually keep the architecture from drifting? What works, what did you try and bury, and where does it still hurt? That is the part I want, because I do not believe anyone has truly solved it, and I would rather learn from your scars than guess at mine.
What part of your architecture only lives in your own head, and what becomes of it the day you are not in the room?
(Rewritten by a machine, from my swearing and my pushbacks. I brought the idea and the cursing; it brought the patience to survive both.)
) version of where I’m today:
