Designing for Inherited Judgment

This week I was writing with an AI and at some point it handed me back a paragraph that said almost exactly what I wanted to say. I read it and knew instantly it wasn't mine. What I managed to articulate was fairly useless: the idea is good, but I wouldn't put it that way. I had no rule to offer, I couldn't name which principle had been violated. I only knew, with a certainty that allowed no argument, that this was not my voice. And yet, two exchanges later, the text had arrived somewhere that was mine. Something had been transmitted. The strange part is that I never managed to say it.

I tell this because it describes, with some precision, the problem the design industry is trying to solve right now—and one that runs deeper than it appears. It's called design.md, or context file, or agent guidelines, and the premise is always the same: write your judgment into a file so the machine can use it. Put down what you know. Bottle your judgment. It's a reasonable idea and probably an inevitable one, because agents work without us beside them and need something to replace the conversation they're never going to have.

The question almost no one asks is whether judgment is the kind of thing that can be written down.

We know more than we can tell

Michael Polanyi formulated the problem we now have to manage sixty years ago, in a sentence that hasn't aged at all: we can know more than we can tell. His favourite example was riding a bicycle. Anyone who can do it does it without thinking, but almost no one can state the physical rule that keeps them upright, and whoever can state it doesn't use it to pedal. Recognizing a face among thousands works the same way: we recognize it instantly and cannot describe how. Polanyi called this tacit knowledge, and his point wasn't that it was mysterious but that it was structural: there are kinds of knowing that exist in practice and not in propositions.

Design judgment lives almost entirely there. We know an interface is wrong before we can say why. We know a piece of writing doesn't sound right without having the rule at hand. An experienced designer looks at a screen and spots the problem in two seconds, then needs twenty minutes to construct the explanation—which is a later reconstruction, not the mechanism they actually used. Our whole craft was transmitted this way for decades: by proximity, by repeated correction, by watching someone say "no, not like that" without being able to fully explain why.

What's new is that we're now being asked to turn that into text. Not because we've come to understand our own judgment any better, but because who needs to read it has changed.

The compliance officer

The clearest evidence of what happens when we try was documented by Yesenia Perez-Cruz, and it is specific and devastating. Building a prototype with an agent on top of a minimal design system, she noticed the agent filling every gap with the same pattern: a large icon inside a gray container, over and over. Her diagnosis wasn't the one you'd expect. It wasn't a taste problem: the agent didn't understand what it was building.

So she tried what any of us would try, which is to give it a principle. Something like: a color must carry meaning, and if it doesn't, it's decoration. The agent applied it like a compliance officer, flagging everything that technically violated the rule, with no sense of when the rule mattered. It's the most instructive possible failure, because it shows that an abstract principle does not transport judgment: it transports an instruction that can be followed to the letter until it becomes absurd.

What did work was something else. Classifying each surface by the job the person would be doing there—orienting, comparing, bulk editing, reading a record—and, above all, giving canonical examples. The examples outweighed any written principle. And that is no longer a technical detail: it's a claim about the nature of judgment. What can be bottled is not the rule, it's the case and its reasoning. Judgment doesn't travel as a proposition; it travels as an example with the thinking attached.

One detail from her account stayed with me more than any other: the agent has no colleague to ask whether someone has already solved this. We learned nearly everything that way, by asking the person next to us. What we're trying to write into a file is, in large part, the very conversation that file is meant to replace.

What is preserved and what atrophies

Here is the tension that genuinely interests me, and I won't fully resolve it, because I think both halves are true.

Writing judgment down can preserve it. Articulating forces understanding: when I have to explain why something works, I discover the times I don't know, and I'm forced to think it through. A team that sits down to write its design principles almost always leaves that meeting knowing more than when it walked in—not because of the document, but because of the argument required to write it. In that sense, externalizing judgment is a way of exercising it, and a fairly demanding one.

But it can also atrophy it, through a quieter mechanism. Once the conclusion is in the file, no one derives it again. The team that argued for weeks to arrive at that line understands perfectly where it came from; whoever joins next year reads it as a fact. They inherit the conclusion without the reasoning, which is exactly what my previous essay described as delegating without participating. The rule survives and the judgment that produced it is lost—and the worst part is that from the outside nothing looks different, because the document is just as tidy as ever.

It's the same question I've been chasing for two essays now, at another scale. There it was how much friction to preserve for one person. Here it's what gets transmitted between generations of a team: whether what passes from hand to hand is the answers or the capacity to find them.

A file with enough variety

Stafford Beer, who thought about these problems long before agents existed, offers the most useful criterion I know for deciding when a document like this has become dangerous. His central idea is variety: the measure of change an environment produces, which a system must be able to absorb in order to remain viable. A system with less variety than its environment cannot respond to what happens to it; it becomes rigid and, sooner or later, irrelevant.

A static file has zero variety. It was written at one moment, facing certain problems, with the knowledge available then. The environment keeps moving and the document doesn't. At first the gap is imperceptible and everything works; later it starts producing decisions no one would make today but which are backed up in writing. That's where a guideline turns into dogma—not through a drafting error, but through a structural property of anything that freezes.

Beer also left a line worth applying to our own documents: the purpose of a system is what it does. Not what it declares, not what its authors intended. If our design.md is producing mechanical consistency and decisions nobody would defend, that is its real purpose, whatever the header says.

Inheritance

Perhaps that's why we should change what we ask of these files. A design.md is not a team's judgment: it's the residue, the mark left by judgment that was exercised somewhere else. It's useful, genuinely useful, but mistaking the residue for the thing is exactly what turns a guideline into dogma. A living file differs from a dead one in a single way, and it isn't the content: it's whether anyone still argues with what it says. The day a team stops asking its own document why, the document is still there, immaculate, and the judgment has already left.

And there's something about the scene at the beginning that keeps circling back. When I said I wouldn't put it that way, I didn't transmit a rule, because I didn't have one. I transmitted a case, and then another, and at some point the text began to sound like me. What travelled wasn't the principle: it was the repeated correction, the friction of going over the same thing until something clicked into place. That's how we learned to design too, watching someone say "no, not like that" without being able to fully explain why. Maybe what we're trying to fit into a file is precisely the one thing that was never transmitted in writing. And then the question isn't how to document our judgment better, but what we're going to leave to whoever comes next: a set of conclusions, or the practice that produced them.