The last essay I published, on coding agents and codebase rot, had a footnote that made a promise. It said that if you like Stafford Beer, the situation is simple to state: System 1 just got a massive variety amplifier. The metasystem didn't. It also said that this was a longer argument than the essay wanted to make, and that I'd make it here.
This is that argument. It involves some counting, and it ends in the same place the essay did, with the claim that the agent isn't the risk; the missing model is. But it gets there by a route that explains why that's true, and the route is sixty years old.
Counting what a thing can be
In 1956 W. Ross Ashby needed a word for "the number of distinguishable states something can be in," and chose variety.1 A light switch has a variety of two. A traffic light has three. The word deliberately says nothing about what the states mean. It only counts them, which is why it works the same way for nervous systems, factories and, as it turns out, data models.
Go back to the Deployment from the last essay. On day one it had a status enum with four values:
PENDING ──> RUNNING ──┬──> SUCCEEDED
└──> FAILEDVariety: four. Then ordinary requirements arrived, and each one was cheapest to implement as a field beside the enum rather than a change to it:
representable intended
status 4 4
+ cancel_requested 8 5
+ awaiting_approval 16 6
+ rolled_back_at (set / unset) 32 7
+ manual_override 64 8And that's before counting retry_count, which is an integer and therefore, for practical purposes, unbounded.
Varieties are usually counted in bits, because then independent parts add instead of multiply.2 In bits the story is shorter: the design has three bits of intended variety and the implementation has six. Every boolean added one bit. Every bit doubled the space.
The three extra bits are the important part. They are the 56 combinations that are representable but that nobody intended: is a SUCCEEDED deployment with rolled_back_at set a success? They aren't errors, exactly. They are variety that the system has and that nothing regulates. Each call site that reads status makes its own private decision about them, and the decisions don't have to agree.
Only variety can absorb variety
Ashby's best-known result is the Law of Requisite Variety. In its usual form, with varieties counted in bits:
V(outcomes) ≥ V(disturbances) − V(regulator)Read it as a constraint on anything that tries to keep something else within bounds. The world throws disturbances at the system. The regulator responds. The outcomes are what's left. To hold outcomes to an acceptable set, the regulator needs at least as many distinct responses as there are distinct disturbances, and it needs to be able to tell the disturbances apart. Ashby's five-word version: only variety can absorb variety.
Now put a software team inside that inequality.
The disturbances are the stream of changes arriving at the codebase: every diff, every new field, every "small refactor while I was in there." The regulator is whatever decides whether a change keeps the system coherent. In most teams that's code review plus the head of whoever holds the architecture. The outcome we care about is the one Perry and Wolf named in 1992: whether the system keeps a coherence and clarity of form, or drifts.
For most of the history of the profession, those two sides were roughly balanced. Not because reviewers were brilliant, but because typing was a rate limit. A team could only produce so many structural changes a week. That ceiling held the variety of the disturbances down to something a few people's attention could absorb.
Agents removed the ceiling. The variety of the change stream went up by an order of magnitude. The variety of the regulator — a handful of reviewers, the same hours in the day — did not change at all. The inequality doesn't care how good your engineers are. If the right-hand side grows and the regulator doesn't, the outcomes spread out. That spreading is what drift looks like from the inside.
The balance happens anyway
Stafford Beer took Ashby's law and turned it into a design method. His observation was that when the environment's variety vastly exceeds management's, you can't balance the equation by making management bigger. You have to work both sides of it. You attenuate the variety that reaches the regulator: filter it, summarize it, constrain it at the source. And you amplify the regulator's responses, so that one decision acts many times.
Then he stated a principle that I think is the most useful single sentence for anyone running agents on a real codebase. Paraphrasing: the varieties on either side of a channel tend to equalize, whether or not anyone designs the mechanisms that equalize them.3
The balance happens anyway. The only question is whether you chose how.
Here is how it happens on a team whose review process has been outrun. Nobody decides to stop reading diffs. The diffs just get skimmed. The approval comes after the summary and the green checks, not after the code. Each reviewer quietly develops a filter for what they look at closely and what they wave through. That's attenuation: the incoming variety is cut down to what a person can absorb. It wasn't designed and it isn't written down, and it cuts in the wrong places, because what it filters out is precisely the change that looks small and local and is actually an ontology change.
"LGTM" is an attenuator nobody designed.
The solo builder's version is the same with fewer people. Your own attention is the regulator, and the filter is whatever you happen to remember about last Tuesday.
What exactly got amplified
Beer's Viable System Model gives a slightly finer vocabulary for where the imbalance sits.4 It splits any system that stays viable into the operations that do the primary work (System 1) and a metasystem of functions that keep those operations a coherent whole:
S5 identity what the system is, and isn't allowed to become
S4 intelligence the outside world, and the future
S3 control what happens next, inside, now
S3* audit checks the work without trusting the worker's account of it
S2 coordination keeps operations from colliding
─────────────────────────────────────────────────────────────
S1 operations the units that actually change the worldMap a software team onto it and the picture is uncomfortable. The people and agents writing changes are S1. Merge order, conventions, and CI scheduling are S2. Planning and prioritization are S3. Review and testing are S3*. Watching dependencies, platforms and users is S4. And S5, identity, is the domain model and the architectural intent: the thing that says a Deployment is in exactly one state, and these are the states.
Coding agents are an enormous amplifier attached to S1. They did very little for the metasystem, and in one respect they made it weaker: the same people who used to hold the model now spend much of their attention writing prompts and reading summaries.
That's the precise form of the footnote's claim. It isn't that agents write bad code. It's that the amplification landed entirely below the line.
Every good regulator is a model
There's one more result worth having, from Roger Conant and Ashby in 1970. The title of the paper is the result: Every good regulator of a system must be a model of that system.5
A regulator that keeps something within bounds has to carry, somewhere, a representation of how that thing behaves: which disturbances exist and which response answers each. If the representation is missing or wrong, any regulation you get is luck.
Apply that to an agent session. Before it changes anything, the agent builds a model of your system from whatever code is in front of it. It has to; if the code is the only source of truth, the code is what it reads. Then the next session builds its own, slightly different one, because the code underdetermines the model. Nullable field, or genuine optionality? Two concepts, or one concept with a flag?
So the regulator's model of the system, the thing Conant and Ashby say good regulation depends on, is being reconstructed dozens of times a day, by processes that never compare notes. That's why the last essay ended where it did. "The agent isn't the risk; the missing model is" is the good-regulator theorem in plain clothes.
Restoring the balance on purpose
The cybernetic reading doesn't produce exotic advice. What it produces is a reason for advice you've probably heard, and a way to tell which side of the equation a given practice works on.
Attenuate at the source. The cheapest way to absorb variety is to stop it existing. A real sum type for the deployment's state cuts the representable space from 64 back to the 8 states someone intended. Now cancel_requested can't be quietly added beside the enum. The change has to go through the model, and someone has to decide, on the record, what cancelling a running deployment means. Types, schemas that reject instead of coerce, and module boundaries the build enforces are all attenuators. They're the designed version of what skimming does by accident.
Amplify the regulator with things that act without attention. A test that encodes an invariant is a decision made once that responds to every future change of its class. That's what amplification means: one response, multiplied. The same goes for an architectural rule the linter enforces, a schema check in CI, and a gate that refuses a merge without fresh evidence. None of them needs a reviewer to remember anything.
Make the model external, so every regulator regulates against the same one. Give S5 a home outside any one session's reconstruction: a domain model, written down, versioned, read by every agent and checked by the build. This is the part most teams skip, and it's the part the theorem says matters most.
Then design what reaches people. Some judgments stay human, and should. But what a reviewer sees should be a designed attenuation (the diff that touched the model, the invariant that changed, the check that was weakened), not whatever survived a skim.
Where the analogy fails
House rule for this series: every translation has to say where it breaks. This one breaks in at least three places.
Variety is crisp for enums and fuzzy for architecture. You can count the states of a Deployment. You can't count the states of "the design," and anyone who claims to put a number on a codebase's architectural variety is doing rhetoric. The law is still useful as a direction: more distinct disturbances need more distinct responses. As arithmetic, it only goes as far as the things you can actually enumerate.
Requisite variety is necessary, not sufficient. A regulator with many responses can still pick the wrong one, and a regulator with too many responses can be its own problem. A check that refuses correct work is variety too, pointed the wrong way. Over-regulation is a failure mode with its own issue later in this series.
Agents can amplify the regulator side as well. They write tests and reviews too. But a producer that also generates its own evaluation is mostly reporting on itself, and two models in different boxes can share every blind spot. Whether agents can legitimately supply metasystem variety, and under what conditions, is the subject of issue 4.
And a smaller caveat: the Conant–Ashby theorem is narrower and more contested than its title. It says the simplest optimal regulator must be a homomorphic model of the system it regulates, under specific assumptions. I'm using the title, as most people do, as a design principle rather than a proof.
One exercise for this week
Pick the entity in your system that matters most: the order, the account, the deployment. Write down two numbers. The first is how many states its fields can represent. The second is how many states someone actually designed. The gap between them is unregulated variety, and every call site that reads the entity is making its own decision about it.
Then list what currently stands between a change and your main branch, and mark each item: is it an attenuator, an amplifier, or a person? Is it designed, or did it just happen? Most teams I've done this with find several accidental attenuators and exactly one amplifier, which is whoever is still reading the diffs carefully.
Next week: if a prompt is one response played in advance to every disturbance a run will meet, how much variety does it absorb? Prompts advise, types describe, gates enforce.
Lab note. I'm building an open-source agent harness called regulator that takes this argument literally. It runs Beer's model as explicit functions, typed channels and gates, not as five chatbot personas, and every gate in it carries a registry record that says what it fails to catch. It's my running test of the claims in this series, including where they fail.
Notes
- W. Ross Ashby, An Introduction to Cybernetics (Chapman & Hall, 1956). Variety is introduced in chapter 7 and the Law of Requisite Variety in chapter 11. A free PDF is hosted by Principia Cybernetica, and the book is far more readable than its reputation. ↩
- Strictly, Ashby counts variety either as the number of distinct states or as its logarithm. The logarithmic form is what makes the law's minus sign work. Four states is two bits; sixty-four is six. ↩
- Beer states this as the first of his principles of organization in The Heart of Enterprise (Wiley, 1979). The attenuator/amplifier vocabulary runs through Brain of the Firm (Allen Lane, 1972; 2nd ed. Wiley, 1981). ↩
- Beer develops the Viable System Model across Brain of the Firm, The Heart of Enterprise and Diagnosing the System for Organizations (Wiley, 1985). The S3* audit channel is part of the model, if easy to miss in the usual five-box diagrams. ↩
- Roger C. Conant and W. Ross Ashby, "Every Good Regulator of a System Must Be a Model of That System," International Journal of Systems Science 1(2), 1970, pp. 89–97. ↩