Chapter 2. The Law of Requisite Variety¶
What do we do after the model answers? We read it, assess it, ask for a redo; we find something else — patch it by hand; then again. Every step is a reaction to the generated output.
Picture a shepherd trying to control a flock on his own: he runs after one sheep, turns it back — and while he was turning it, five others have already wandered off. He isn’t lazy, he just can’t cope. He simply has one pair of legs against a hundred. The flock generates variety faster, and more of it, than the shepherd has responses for. He will always be the one catching up.
Back from the flock to a session with the model. Who controls whom in this pair — you and the model? The question seems rhetorical — the human writes the prompts, so the human is in control. But let’s look closer. In the previous chapter I proposed taking as the unit of analysis not the model but the pair: human + model + context + tools. This chapter is about the law of control itself — the one that decides who controls whom. And curiously, at its core control is a question of arithmetic, not of effort or skill.
Only Variety Absorbs Variety¶
In 1956 W. Ross Ashby formulated a law that cyberneticians consider their counterpart to the conservation of energy. It goes like this: a regulator can hold a system in its target state only if the regulator’s own variety is no less than the variety of the disturbances it has to deal with. The short form: only variety absorbs variety.
Variety is the number of states a system can take. And here’s a subtlety that usually gets skipped: what counts isn’t every state, only the ones you can tell apart. Variety is always measured relative to the observer.
A thermostat controls the boiler: the boiler has an internal temperature, and for every value of it the thermostat has a numeric response, to a certain precision. Could you hand that same thermostat the job of monitoring the heating system of the whole house? That system has more states: a pipe that might freeze, an air lock in a radiator, a leak at a joint. Controlling such a system takes distinguishing more states than temperature alone — and temperature is all the thermostat sees. It is physically incapable of the job: all it can do is react to one particular slice of the disturbances, namely temperature.
Now back to our pair. The model can hand back thousands of substantially different answers to the same request — different in the architecture of the solution, in hidden assumptions, in facts it made up, in what it decided “not to see.” How many of those differences do you distinguish? And for how many of the ones you do distinguish do you have a separate response ready in advance?
That’s the whole arithmetic. If the machine’s variety aimed at you is greater than your variety aimed at it, the machine is in control. Not because it has intent. It’s just that your activity starts being structured by its outputs: you fix what it decided to write, in the order it wrote it.
The Four Roles¶
This arithmetic unfolds neatly into a scale. Depending on the ratio of your variety to the variety of the process, at any given moment you’re playing one of four roles.
Captain. Your reserve of variety substantially exceeds the complexity of the task. Any fragment of the generated output you can assess, rework, or throw away — and you know what to replace it with. You’re in control all the way up to rebuilding the whole solution.
Helmsman. Your reserve roughly equals the complexity of the process. Review barely keeps up with generation. One unexpected turn and you’re already chasing.
Deckhand. You accept most of what’s generated, fix small things, and can no longer always explain why the solution is the way it is. The direction of travel isn’t set by you.
Passenger. You accept without reading anymore. The system you’re nominally building dictates the course of its own development, and your resources are just enough to keep servicing it.
Every session where you accepted a decision you hadn’t examined shrinks your variety with respect to your codebase a little — and grows, a little, the variety of the thing you’re trying to control. Fixing this is harder than preventing it: a process that has picked up speed acquires momentum of its own, and the correction that cost ten minutes at the start can now cost days.
Sounds hopeless? No! Because Ashby’s law isn’t a verdict — it’s the problem statement for control. It doesn’t say “the human loses.” It says: to control, match the variety. And you can match it from two sides.
The Raft and the Yacht¶
You can see this best on the water.
Wind has colossal variety: gusts, lulls, shifts in direction, squalls. A human against the wind is nothing: you physically can’t blow back. A raft with a rag for a sail drifts wherever the wind pushes — that’s a chat session with no system behind it, and its passenger sincerely believes he’s a captain because he’s holding on to the mast.
A yacht, though, holds its set course regardless of where the wind blows. Not because the sailor guesses the wind or can change it at will. Because between him and the wind there’s a built system. The keel absorbs the sideways drift — it takes away from the wind the part of its variety that pushes off course. The sail, set at an angle, catches and amplifies the part that does useful work. And the sailor himself holds in his hands not the wind — he holds the course, the sheet, and the tiller: three controls with distinguishable states, for each of which he has ready reactions, drilled to the point of reflex.
The sailor doesn’t try to persuade the wind. He doesn’t write the wind a longer instruction. He changed his own position in the system so that the wind’s excess variety is absorbed by the structure, and its useful variety works for the course.
This is variety engineering — the name Stafford Beer gave it when he carried Ashby’s law from thermostats over to firms. It has exactly two levers.
Two Levers¶
Lever one: amplify your own variety. Everything that increases the number of states you distinguish and the responses you keep ready. The sheepdog at the shepherd’s side is an amplifier: his own variety, running faster than he can.
Decomposition. Split the task into smaller parts — and for each piece you suddenly have a ready assessment: this one’s trivial, this one’s risky, this one don’t touch. A piece has less variety than the whole, and yours hasn’t gone anywhere. You’ve just improved the ratio without adding any variety of your own — by lowering the complexity of the task. The model’s own variety we haven’t touched yet: that’s the second lever’s job.
Criteria. “Something’s off here” is a feeling, not a criterion: you can’t lean on it. A written criterion turns the feeling into a visible state: “if the code retries a request that must not be retried — that’s unacceptable.” Once it’s written down as text, you check it every time, and before long a test does the checking for you. Every written criterion is one more state you distinguish.
Normative base. A style guide, a checklist, a project memory file — that’s your variety preserved in text: an answer, found once, to a whole class of situations. You wrote it once, and it fires in every session. There’s a separate chapter on this.
Variants. Ask for three implementations instead of one — and the model’s sensitivity to phrasing, which used to plague you as instability, suddenly works for you: you compare, and comparison is the cheapest way to distinguish. Selecting from variants is an act of control available only to someone who has criteria.
Lever two: attenuate the machine’s. Everything that reduces the number of states the machine can hand you. The fence around the pasture is an attenuator: the chance that the sheep wander off on their own drops to a minimum.
Context boundary. What’s in the session is what’s in play: the model sees only what you gave it — the open files, the pasted code, the document, the instruction. Everything else doesn’t exist for it, and you can use that: give it the one service file instead of the whole repository, and the class of solutions called “rewrite the neighboring modules” disappears on its own, because in its world those modules don’t exist. The boundary isn’t what you forbade — it’s what you didn’t show. One more addition to this lever: periodically clearing the agent’s context.
Response format. A schema, a template, “first the plan, then the code.”
Tests and automated checks. Tests that a fabrication can’t get through. CI checks — a linter, a config schema, and where the language allows it, strict type validation.
Permissions. An agent with no access to the production database has its variety reduced by exactly one production database — and none of its “initiative” will ever reach you there.
The second lever comes with a rule: an attenuator works when it’s structural. A test is an attenuator: the unacceptable state physically doesn’t pass. The phrase “please don’t add dependencies” in a prompt is not an attenuator but a wish: the unacceptable state was possible before and remains possible. It’s the same difference as between a keel and asking the wind to blow more evenly.
The Dependency Between Freedom and Control¶
Clamp one dimension and you release another. Lock in a rigid output format — you’ve lost the unexpected solutions that don’t fit into it. Fence generation in with so many constraints that error is impossible — you’ve got an executor that will never propose anything you didn’t already know. Cover everything with tests down to the last detail — now any change of architecture costs rewriting a thousand tests, and the system sets like concrete.
It’s not a conservation law — there’s no formula here. It’s a regularity from practice.
The inverse dependency between freedom and control is no reason to give up on constraints. They’re worth setting deliberately: decide in which dimension unexpected results are unacceptable — add control there — and in which variety is the value — leave room there. Control is a resource with a finite budget, not a metric where more is always better.
One Week, Two Sessions¶
Let’s watch this mechanics in a real task: add retries to the HTTP client in an old project.
Session one, Monday. I opened Claude Code and typed: “add retries to such-and-such service.” Whoa, how many ways there are to do that: an external library, a hand-rolled decorator, retries on a POST that shouldn’t be repeated. An identical pause between attempts for everyone — so when the server goes down, a thousand clients knock again second for second, never letting it get back up. Out of that space of solutions the model picked one plausible one — plausible, because that’s what its internal pull is toward; chapter six is about that. I spent time on review, caught a retry of a non-idempotent request, asked for a redo — and got a new solution with a new problem. Second lap. Third.
Session two, Thursday. Same service, another retry task. Ten minutes went into constructing the prompt: boundary, criteria, format, tests. The boundary: the client file, the environment config, the line “no new dependencies.” The criteria, as a list: retry only idempotent methods; the pause between attempts grows and carries a random offset; three attempts maximum. The format: first the plan, then the code. I read the plan in a minute and cut the excess with one line — while it was still a plan and not code.
What happened to the space of possible results? On Monday it contained everything plausible. On Thursday — a few acceptable implementations whose differences come down to taste. Note: same model, same task, same hands. What changed is the structure the model works inside. My ten minutes of preparation are amplifiers of my own complexity: with the criteria I cut off the model’s room to invent solutions, and with the minute over the plan I neutralized a false assumption before it grew into code. The boundary, the format, and the tests are attenuators: the boundary took the extra files and dependencies out of the context, the format kept code from appearing before the plan, the tests won’t let through a retry in the wrong place. Whole strata of unacceptable solutions no longer pass in my system.
The result: two hours of flailing on Monday against ten minutes of a systematic approach on Thursday. And those ten minutes are an investment: the criteria have already moved into a checklist; the next task gets them for free.
The Megaprompt Is a Surrender¶
Now the typical mistake — framed as a violation of this law, not as “bad practice.”
It looks like this. The model reads a system prompt in a chat, a CLAUDE.md file or a skill in an agent, sometimes just a README. After a failure repeats, this instruction grows: “don’t use library X,” “always write tests,” “never change signatures,” “don’t add config fields”… A month later it’s four hundred lines, and the engineer sincerely believes he’s on top of things: look how many rules I’ve written.
But as the number of instructions grows, a zone of extra variety grows with it: the longer the system prompt, the larger the space of ways to read it. Rules start to overlap and conflict, the model follows them selectively — and you now have two poorly controlled systems: the generation and the instruction itself. It’s an attempt to absorb the machine’s variety with your weakest channel — words, which block nothing structurally. In the raft analogy: the raft has grown banners addressed to the wind, but that hasn’t made it a yacht.
The diagnosis under Ashby’s law is precise: the human is growing not their variety but the volume of their wishes, and attenuating nothing — not one of the four hundred lines physically forbids anything. The position in the system hasn’t changed.
The cure is moving rules into structure, not simply shortening the text. Walk through the megaprompt with one question: what here can become structure? “Always write tests” becomes a CI step. “Don’t change signatures” — an automated check of the public interface in the pipeline. “Don’t invent fields” — a config schema. The response format — a template. After that extraction, four hundred lines leave a single page — the part that genuinely should be text: the task’s context and the criteria. The result: the prompt gets shorter, control grows.
The Law Works at Every Level¶
Beer spent his life demonstrating that Ashby’s law applies to organizations just the same. A firm survives while its governing structures keep up with absorbing the environment’s variety; it degrades when a range of three possible decisions (“cut costs,” “hire,” “wait”) is steering a market with thousands of states. An executive dashboard is an attenuator: thousands of events compressed into three numbers. A conversation with the team is an amplifier: you gain distinctions. Confusing these two instruments is the occupational disease of management, and we’ll come back to it in Part V.
Here I want to pin down one thing: the law scales. A session, an agent, a team, a company — at every level, control belongs to whoever’s resolution and number of responses cover the variety of the process. So nothing you build for your own sessions in the coming chapters will go to waste: it’s the same method that later unfolds onto working with fleets of agents and running teams.
In Your Craft¶
The law doesn’t know what code is. Substitute your own craft — the arithmetic is the same.
Text. An editor who writes “make the text livelier” is sitting on the raft: that request has not a single distinguishable state. A set of samples to measure against and a list of banned turns of phrase are attenuators: we deliberately pick a slice of the distribution instead of hoping to land by chance not on the gray middle of the results but on its peaks. A style pinned down in a guide, examples of “this, not that,” a separate editing skill with its own checklist are amplifiers: the text gains more states that you control.
Analytics. An analyst with a template for the findings and a mandatory list of source checks is in control of the research. An analyst with the prompt “analyze the market” gets the most plausible report in the world — and no way to tell it from a correct one. The template and the list of checks are your distinctions, moved onto paper.
Design. “Make it beautiful” loses on variety even to the raft. A direction, three references, and a stack of constraints — grid, palette, banned moves — are attenuators. An extra selection stage over three variants is an amplifier: only someone with criteria can choose.
To close — three questions for your own practice.
— Think back to your last working session: how many states did you actually distinguish in the model’s answer — and how many were most likely there?
— What one structural attenuator could you put in place tomorrow — one that works without your attention?
— In which of the four roles did you spend more of your time last week?