Chapter 12. The Normative Base¶
I’m writing this book with an agent. In Chapter 2 it wrote upravlinnia — a Russian-flavored word for “control” — and I changed it to keruvannia, the Ukrainian one. In Chapter 6 I changed it again. After the third time it became a line in the book’s style guide, and the word never showed up again.
In Chapter 13 I counted how many times the word “green” appeared in the text: twenty-four. Each one made sense on its own — “a green run,” “a green checkmark.” Together — twenty-four mentions of green in a single chapter. Another line in the style guide: “green” only where it’s specific.
There was no style guide before the first chapter. It grew out of edits: ran into it — changed it; ran into it again — changed it; the third time, wrote it down. Today it’s three hundred lines long, and I didn’t come up with a single one of them in advance. Each is a remark of mine that kept repeating.
What separates a lucky find from a norm? In Chapter 2 I called the normative base an amplifier — variety preserved in text — and promised it a chapter of its own. Here it is.
Twice is a coincidence, three times is a class¶
A norm doesn’t come from a single situation, but from repetition.
One good result is still just one result, and it carries the imprint of everything around it: your phrasing, the time of day, how much you’d managed to read beforehand. As an instrument, a human is unstable: same task, same person, morning and evening — different answers. So from a single result you can’t see what in it is your decision and what is a coincidence of circumstances. Compare three — and whatever survived in all three is the decision. The rest is noise.
Hence the definition. A norm is a written-down response, with instructions, to a class of situations that keeps repeating for you. The key word is class. Once is an accident. Twice is a coincidence. Three times is a class, and the response to it is worth writing down, because there will be a fourth.
Until there’s a norm, “good” in a review is an opinion, and everyone has their own: three reviewers on one pull request will give three verdicts, all three well argued. A written norm turns a verdict into a comparison: here’s what we measure against, here’s the deviation. The next chapter, on control, will build its tolerance zone on exactly this: the norm says what’s right, the loop checks whether the process has strayed outside it.
And one more thing: a norm flows back into practice. Practice is your settled way of working with an agent: prompts, checks, team habits. Practice creates norms, and norms carry practice further. It’s a closed loop.
The kitchen¶
Picture a restaurant kitchen at six in the evening.
A line cook puts a steak in the pan. He doesn’t taste, doesn’t eyeball, doesn’t ask anyone: there’s a card on the wall. Steak, two hundred fifty grams; pan heated to the first wisp of smoke; two minutes a side; then five minutes resting under foil, so the juice doesn’t run out onto the board; done — dark crust, fifty-four degrees inside by the thermometer. The chef isn’t in the kitchen, but the steak tastes as if the chef had cooked it himself.
That card wasn’t written on opening day. The chef made this steak hundreds of times — on this stove, with meat from this supplier — and that’s how he separated what in the process is stable and can be formalized from what is just emotional background. That’s how the instruction card came about. It has four blocks: the name of the dish; what to do, step by step; why — “rest it so the juice doesn’t run out”; and how to check it came out right — a thermometer, not “by eye.” The chef pulled all of this out of an endless variety of ways to cook, and now it works every time without him. A new location of the chain opens with a folder of cards, not with the chef.
Now a scene at home.
We buy a thick book by a famous chef — six hundred pages, hardcover — and imagine becoming great cooks. We cook one recipe from it. More likely — none. The book sits on the shelf, and every now and then our eyes brush over it with a warm feeling. I know this from my own shelf.
What did we buy? Not norms — a desired state. The recipe in the book and the card in the kitchen look the same: the same four blocks, the same grams and minutes. The difference isn’t in the text. Behind the card are a hundred evenings in this kitchen. Behind the recipe — a hundred evenings in someone else’s. The book promises that someone else’s repeats will stand in for ours.
And one more detail from the kitchen. The card was written for that stove. They put in a new one, an induction one — and “two minutes a side” gives a different steak. Same card, different kitchen.
Why a norm works without you¶
Now for how a norm actually works — three parts.
The first is the arithmetic of Chapter 2. A norm is a distinction taken out of your head and put outside it. While it’s in your head, it works as long as you’re paying attention and as long as you remember. In a file, it works when you’re tired, on vacation, when a colleague is at the keyboard or an agent is doing the work. Every written norm is one more state that’s no longer told apart by your attention but by the written text. You wrote it once, and it fires in every session — and in every session of everyone on the team.
The second part is about understanding. Chapter 10 showed that the “understand” component of activity can’t be handed to AI. A norm with a “why” block carries a piece of understanding across the session boundary: next time it gets read, not rebuilt from scratch. “We don’t write a down method in migrations, because our rollbacks are done from a database snapshot” — and someone seeing that line for the first time knows not just what the norm is but why it exists. A norm without a “why” carries only the order. People can go on following it after the reason is gone — and nobody will notice it no longer applies.
The third part is about the agent. A colleague reads the style guide once, during onboarding, and a week later remembers three lines of it. That’s fine: the colleague has a head and will reconstruct the rest from context. An agent reads the normative base at the start of every session and follows it to the letter — just as literally as “fix the test” in Chapter 6. So a norm multiplies everything written in it for the agent: the decisions and the mistakes alike. A “this, not that” example that would sound pedantic to a human is the only form that works for an agent: it won’t guess what you meant.
There’s one condition without which the three parts don’t work. The norm has to be in the session. This is the context boundary: what’s in the session is what’s in play, and the agent sees only what it’s been shown — open files, pasted text, the instruction at the start. A style guide on a wiki that nobody linked to doesn’t exist for the agent — a norm that isn’t in the session controls nothing.
What turns a note into a norm¶
Four blocks — the same as on the kitchen card. I’ll show them on one norm from a real project memory file.
Situation. When this applies — the class, named explicitly: “in database migrations.” A norm without a “when” either applies everywhere, and then it’s noise, or nowhere, and then it’s a wish.
Decision. What to do, specifically and for a literal reader: “no down method; every index gets an explicit name following the pattern idx_<table>_<columns>.” One “this” example, one “not that.”
Why. In one line: “we roll back from a database snapshot, so the down method never runs, and auto-generated index names differed between two environments and broke a deploy.” This block lets you check, six months on, whether the norm is still needed: the reason is gone — drop the norm; the reason has changed — rewrite it.
Check. How to know it’s been done: “the migration linter in CI fails on a down method and on an index in the wrong format.” Here the norm moves from words into structure — the same cure for the megaprompt as in Chapter 2, only now it’s clear where the lines to move into structure come from.
Every line in this book’s style guide is written the same way: what it was, what it became, why. Without the “why,” two chapters later I myself wouldn’t remember why I’d banned a word.
Where a norm lives¶
One and the same norm can live in four places, and the place decides whether it gets followed without you. The test for every level is the same: what happens to the norm if you don’t come in tomorrow?
In your head. You know how it should be done and explain it to the agent every time. The norm exists, but it’s you. From scratch every time: the version where the chef tastes every dish before it goes out to the guest. Tomorrow without you — no norm.
In the prompt. You copied a good instruction into your notes and paste it in at the start of a session. It’s reproducible now — but only by you, and only when you remember. The chef’s notebook in his pocket. Tomorrow without you there’s still no norm, but at least there’s a text someone can find.
In the project. A project memory file, a system prompt in a chat, a skill in an agent, a README you’re told to read first — all of these are forms of the same thing: a text the agent reads before it starts work. Here every session and every colleague reads the norm — and this is the first level where the norm is followed without you. The folder of cards in the kitchen.
In the structure. A linter, a test, a template, a CI check. The norm is no longer a text you can read and ignore — the unacceptable state physically doesn’t pass. A probe in the steak that beeps at fifty-four degrees. These are the attenuators from Chapter 2, and now you can see where they come from: every one of them started out as a norm in somebody’s head.
Does every norm have to make it into the structure? No. A norm in the structure costs flexibility — that’s the control budget from Chapter 2: clamp down one dimension and another stretches. The harder the rule, the more it costs to change. What goes into the structure is where a mistake is expensive and irreversible: data, access, public interfaces. Here the “three times” threshold drops too: if a mistake broke a deploy once, nobody waits for the second time. Norms of taste — naming, comment style, import order — can stay as text. Hard at the bottom, soft at the top.
How do you measure where your practice sits on this scale right now? Take the last ten remarks you made to the agent in review and ask three questions. How many of them were you making not for the first time? How many are written down so that every session reads them? How many get checked without you? Three numbers — and that’s the profile of your normative base. The first time I counted mine, it came out: seven, zero, zero.
The story of one norms file¶
The team took over maintenance of a legacy billing service — the one everybody is afraid to touch.
Month one. Reviewing the code the agent writes turns into repetition. In a week I wrote down thirty remarks, and twenty-two of them were repeats of five classes: an extra dependency instead of the project’s own utility, a migration with an unnamed index, a test that mocks the database, print instead of the logger, a list endpoint without pagination. We couldn’t have picked these out in advance — they’d have been lost among rules written “just in case.” We write five norms into the project memory file.
Month two. Six remarks a week instead of thirty, and three of them are new classes that had time to repeat over the month: a payment gateway call without a timeout, a secret in the config instead of an environment variable, a new feature without a feature flag. We wrote those down too — the file now has eight norms. We dropped one: the “why” block showed that after the move to Kubernetes, where the log collector picks up everything the service prints to the console, the reason for the print norm was gone. Seven left. Two of them moved into the structure — the migration linter and a dependency check in CI — and five stay as text and get followed, because the agent reads the file at the start of every session.
Month three. A new engineer, on his first day, opened a pull request without a single one of the seven remarks. He hadn’t had time to read the memory file yet — but the agent had.
This is what “norms are followed without me” means: seven distinctions moved out of my head into the process in the form of norms, and now they’re present in every session of anyone who opens this repository.
The big cookbook¶
This chapter’s anti-pattern looks like speeding up.
The team grabs “the best skill pack” from GitHub — four hundred lines, thousands of stars. Or copies a big company’s style guide. Or — the flip side of the same thing — sits down before starting and writes the norms in advance, “the way it should be”: twenty rules for repeats nobody has seen yet. The file is ready on day one. It looks like professionalism.
Behind not one of those four hundred lines is a road actually traveled: no “ran into it,” no “changed it,” no “changed it again.” A norm is a response to your class of situations, one that has repeated; without real repeats it’s not a norm but a wish, or even a guess.
What happens next is predictable. The agent follows someone else’s lines to the letter: it doesn’t know they aren’t yours. Along with someone else’s norms come someone else’s defects — the rule “always use library X,” from a project that had a reason for it, drags into yours a dependency you’d never have chosen. And your own repeats stay unwritten, because “we already have a style guide.” The sign is simple: ask the team which case any given line of the file protects against. If nobody remembers — it’s a line from someone else’s book.
Systems theory has a regularity that explains why this happens: a person in their activity is guided by values that their own practice created. Practice gives birth to norms, and norms carry practice further. It’s the same closed loop the chapter started with.
However much discipline a team pours into following someone else’s lines, it won’t add a single repeat of its own.
The cure isn’t deleting the file. First, count your own repeats, as in the “Where a norm lives” section: take your last ten remarks to the agent and find out how many of them repeated, how many are already written down, and how many get checked without you. Then the borrowed file reads as a list of candidates: a line stays if it answers a repeat you’ve actually had; the rest moves to “hasn’t come up yet” or goes away. Someone else’s book is fine to read, and worth reading — as a source of ideas, each of which still has to earn its place by repeating in your own kitchen. What exactly carries over between projects and what doesn’t is the subject of Chapter 16.
The normative base scales¶
An agent reads the normative base before it starts, and that’s its only “understand” before the work. How to build an agent on norms, criteria and a control loop — Chapter 14.
A team is the next level. Onboarding is reading the normative base, and a team norm differs from a personal one in a single way: it stays when the person who found it has left. That’s Chapter 17.
The mechanics are the same at every level: a distinction that has repeated moves out of your head into the process — and from then on works without you.
In your craft¶
Norms don’t know what code is. Every craft has its kitchen card.
Text. An editor keeps fixing upravlinnia to keruvannia in the agent’s text by hand. As long as that’s the case, the norm lives in the editor’s head. Once the replacement is written into a style guide that the agent reads before it starts, the norm is in the project. And when a script runs the finished text against a list of banned words on its own, upravlinnia won’t get through even if the editor is on vacation. That’s exactly how this book’s style guide grew.
Analytics. What’s an “active user”? Until the definition is written down, three analysts will give three different numbers, and each will be right. A written metric definition is a norm in the project: the agent counts by it instead of inventing its own. And when there’s a data test next to it that fails the moment someone counts differently, the norm fires on its own, even if nobody has opened the definition.
Design. A designer keeps telling the agent: “use only our buttons, and spacing in multiples of eight.” As long as that’s the case, the norm lives in the designer’s head. Once those rules are written into a guideline the agent reads before every mockup, the norm is in the project. And when there’s a design system with ready-made components, the agent simply can’t pick another button, even if nobody mentioned the rule.
To close — three questions for your practice.
— Take the last ten remarks you made to the agent: how many of them were you making not for the first time?
— Which norm in your project will be followed tomorrow if you don’t come in — and which won’t?
— And deeper: is there a line in your project memory file that nobody remembers the reason for — which case it protects against?