Ashby's Law (Requisite Variety)
Ross Ashby's cybernetic law that a regulator must have at least as much variety as the system it governs — invoked in this corpus to argue for harnesses and controls rich enough for agent behaviour, for self-managing (DP2) organisations in turbulent environments, and (contestedly) for distilled measurement systems.
Also known as: Ashby's Law, Ashby's law of requisite variety, requisite variety, law of requisite variety
How authors use it
Oldest first (extraction date when no publication date is known).
| Author | Their term | Their meaning |
|---|---|---|
| DORA Community Discussion - DX Core 4 DORA · 2025-03-13 | Ashby's Law (requisite variety) | Invoked to argue that a measurement/control system capable of reliably governing a complex engineering organization must itself carry at least as much variety (complexity) as that organization — used here as the warrant for building a multi-framework synthesis rather than a single metric. |
Documents (4)
- GitHub - Doorman11991/smallcode: AI coding agent optimized for small LLMs. 87% benchmark with 4B-active model. https://github.com/Doorman11991/ · 2026-05-21 source ↗ Reader 🖥️
A well-engineered harness — context budgeting, forgiving tool-call parsing, patch-first editing, two-stage tool routing, decomposed planning, and per-model profiles — can extract production-grade agentic coding work from small (7B-20B), locally-hosted LLMs that would otherwise be considered too weak for the task, making local, private, frontier-free coding agents viable. - Harness engineering for coding agent users Birgitta Böckeler · 2026-04-20 source ↗ Reader 🖥️
Coding agent users should engineer an outer harness of feedforward guides and feedback sensors — distributed across computational and inferential execution types and across the change lifecycle — to reduce review toil and increase system quality, but the behavioural harness (ensuring functional correctness) remains the hardest unsolved problem. - DORA Community Discussion - DX Core 4 DORA · 2025-03-13 source ↗ Reader 🖥️
A software organization's performance multiplier lives at the organizational/cultural level, not in individual '10x engineers', and is best captured not by any single metric framework but by a blended quantitative-plus-qualitative system — DORA, then SPACE, now distilled into DX Core 4's four dimensions (speed, effectiveness, quality, impact) anchored by a composite Developer Experience Index — that treats flow state and cognitive load as the proximate mechanism linking developer experience to delivery outcomes. - Thriving with complexity using open sociotechnical systems design Trond Hjorteland · 2022-01-05 source ↗ Reader 🖥️
Software organizations should undergo a radical, participatively-designed structural transition from DP1 (bureaucratic, redundancy-of-parts, externally-coordinated) to DP2 (self-managing, redundancy-of-functions, internally-coordinated) sociotechnical design — the empirically-grounded Open Systems Theory tradition that agile, product, and 'team-first' movements have been independently and incompletely rediscovering — because only DP2 generates the variety needed to thrive in today's turbulent technical and social environment, and because that change must be structural and self-designed, not a culture or values campaign layered on top of unchanged structure.
Propositions touching this concept (2)
By publication month, oldest first (extraction month when no publication date is known).
2025-03
- explicitAshby's Law (requisite variety) implies that any system capable of reliably controlling a complex engineering platform must itself carry at least as much complexity/variety as that platform.
2026-04
- explicitcorroboratedCommitting to pre-defined service topologies is a variety-reduction move (per Ashby's Law) that makes comprehensive harnessing more achievable.
Tensions
Can harness engineering actually solve the AI code quality problem?
from: What is the right approach to building harnesses around AI coding agents, and where are the limits?
- Agent Harness Engineering (Osmani): Yes — harness engineering is the primary solution. A decent model with a great harness beats a great model with a bad harness.
- Harness engineering for coding agent users (Böckeler): Partially — harnesses can solve maintainability and architecture fitness, but the behavioral harness remains fundamentally unsolved.
- Genie Tarpit (Beck): Unknown — genies naturally produce degraded code and nobody knows how to fix this. Harnesses are listed as one possible remedy among several, without endorsement.
Assessment: This is the central divergence in the literature. Osmani is most optimistic, operating from benchmark evidence that harness changes produce dramatic improvements on coding tasks. Böckeler occupies the middle ground, distinguishing solvable from unsolved harness domains. Beck is most skeptical, questioning whether harnesses address the root cause at all. The disagreement is partly empirical (what do the benchmarks actually measure?) and partly about scope (Osmani focuses on task completion; Beck focuses on long-term code value including flexibility). They may not be contradicting each other so much as talking about different time horizons: harnesses help with immediate task success, but the tarpit emerges over accumulated changes.
What is the right metaphor for the human-AI relationship in coding?
from: What is the right approach to building harnesses around AI coding agents, and where are the limits?
- Patterns for Reducing Friction in AI-Assisted Development (Garg): AI is a teammate — treat it like a junior pair programmer who needs onboarding, context, and rituals.
- Harness engineering for coding agent users (Böckeler): AI is a system to be governed — the cybernetic governor model with feedforward and feedback controls.
- Agent Harness Engineering (Osmani): AI is a runtime to be engineered — the harness is an engineering artifact, not a social relationship.
- Looking back at the Future of Software Engineering unconference (Thoughtworks): AI is a new organizational participant — Conway's Law applies, and agent topologies must be designed.
Assessment: These metaphors are not mutually exclusive but they lead to different design decisions. Garg's teammate metaphor emphasizes collaboration rituals and may underplay the need for hard constraints (you don't sandbox a teammate). Böckeler's governor metaphor is the most theoretically rigorous but may overclaim the applicability of control theory to creative work. Osmani's engineering metaphor is the most actionable but may miss the social and organizational dimensions. Thoughtworks' organizational metaphor captures the broadest scope but is the hardest to operationalize.
Open gaps (13)
- incompleteThe behavioural harness is acknowledged as 'the elephant in the room' but no concrete framework or methodology is proposed for solving it beyond mentioning approved fixtures as a partial pattern.Harness engineering for coding agent users — read next: Read the approved fixtures pattern (lexler.github.io/augmented-coding-patterns) and explore specification-based testing approaches (property-based testing, contract testing) as potential behavioural harness components.
- incompleteThe article does not address how to evaluate harness quality or coverage — it raises the question ('If sensors never fire, is that high quality or inadequate detection?') but offers no answer.Harness engineering for coding agent users — read next: Explore meta-testing approaches: mutation testing for harnesses, harness coverage metrics, or adversarial testing of the harness itself.
- incompleteThe cybernetic framing (feedforward/feedback, Ashby's Law) is adopted as the organizing metaphor but not critically examined. Control theory assumes a well-defined desired state and measurable error signal — software development often has neither.Harness engineering for coding agent users — read next: Read Stafford Beer's work on viable systems and cybernetic management to assess how well control-theory concepts transfer to inherently creative/ambiguous engineering tasks.
- incompleteNo discussion of the cost-benefit analysis of harness engineering itself — when is the investment in building and maintaining a harness worthwhile vs. simply relying on human review?Harness engineering for coding agent users — read next: Look for empirical studies or experience reports quantifying harness ROI in agent-assisted development.
- incompleteThe interaction between guides and sensors — coherence, contradiction, priority resolution — is raised as an open question but not explored.Harness engineering for coding agent users — read next: Explore policy conflict resolution in cybernetic and multi-agent systems literature.
- illogicalThe talk invokes Ashby's Law (requisite variety) to argue that a measurement system governing a complex organization must itself be at least as complex as that organization — then immediately uses this as the warrant for 'distilling' three frameworks down into a single, simpler four-dimension composite index. These two moves are in tension: requisite variety is an argument for irreducible complexity, not for safe simplification, and the talk never reconciles why distillation doesn't lose the very variety Ashby's Law says is required.DORA Community Discussion - DX Core 4 — read next: extract-bockeler-harness-engineering (which separately flags Ashby's Law/cybernetic framing as adopted uncritically) is a direct companion critique worth reading alongside this.
- incompleteThe headline '87% benchmark with 4B-active model' is the entire credibility hook and is completely unspecified in the body. No benchmark name (SWE-Bench? Aider polyglot? HumanEval? a custom suite?), no subset, no scoring methodology, no comparison baseline (what does a frontier model score on this same eval? what does the same 4B model score without SmallCode?), no link to results. For a rigorous adopter this is the single most disqualifying gap.GitHub - Doorman11991/smallcode: AI coding agent optimized for small LLMs. 87% benchmark with 4B-active model. — read next: Check the GitHub repo itself for an evals/ or results/ directory; check the project's `/eval` command output; check whether any third party has reproduced. Compare against published SWE-Bench / Aider / HumanEval+ leaderboards for similar-sized models. Look for the actual model named in the example (gemma-4-e4b) and find its baseline scores.
- incompleteNo comparison to other small-model-aware agentic coding tools — Aider (with local models), Cline + Ollama, Continue, OpenHands with local backends, Roo. The only named comparator is OpenCode, which is set up as a strawman ('assumes frontier models').GitHub - Doorman11991/smallcode: AI coding agent optimized for small LLMs. 87% benchmark with 4B-active model. — read next: Read Aider's local-model documentation and benchmark notes (Paul Gauthier publishes Aider polyglot scores for many models). Compare with Cline's local-model guidance and OpenHands' SWE-Bench results with open models.
- incompleteOne-author ecosystem risk: SmallCode depends on BoneScript, MarrowScript, and budget-aware-mcp — all by the same GitHub user. If the author stops maintaining, four projects rot together. This single-maintainer concentration is not flagged anywhere.GitHub - Doorman11991/smallcode: AI coding agent optimized for small LLMs. 87% benchmark with 4B-active model. — read next: Check commit history and contributor counts on all four repos; check npm download stats for smallcode and budget-aware-mcp; check whether MarrowScript / BoneScript have any external adopters.
- misinformedThe escalation target list cites 'Claude Sonnet 4.5 / 4.6, Haiku 4.5' and 'GPT-5.4 Mini / Nano' and 'DeepSeek V4 / V4 Pro / V4 Flash'. As of the document's apparent date, these specific named version numbers may be aspirational, outdated, or fabricated. The presence of confidently-named future/non-existent model versions weakens credibility on other un-checkable claims.GitHub - Doorman11991/smallcode: AI coding agent optimized for small LLMs. 87% benchmark with 4B-active model. — read next: Cross-check the named model versions against vendor product pages; if they are not real, treat the rest of the README's confident numbers (87%, '8-15 → 1-2 tool calls', '1400+ lines from 50 lines') with proportional skepticism.
- illogicalThe marketing claim ('87% with 4B-active model') and the body text ('7B-20B local models') are inconsistent. The title advertises a 4B-active model; the body describes the project as targeting 7B-20B. If 4B-active means MoE active params with a larger total, both can be true — but the README never reconciles them, leaving the reader to guess.GitHub - Doorman11991/smallcode: AI coding agent optimized for small LLMs. 87% benchmark with 4B-active model. — read next: Identify the actual model used to produce the headline number; if it is MoE (e.g. gemma-4-e4b with ~4B active), check whether 7B-20B framing in the body is meant as total-parameter range, active-parameter range, or both — the project's positioning depends on which.
- incompleteNo discussion of how the harness itself is engineered, tested, or evaluated. The Observability section mentions traces and `/eval` but provides no example evaluation results, no harness-coverage metrics, no failure-mode regression tests beyond 'trace-to-test'. The harness is presented as fait accompli, not as something the reader could audit.GitHub - Doorman11991/smallcode: AI coding agent optimized for small LLMs. 87% benchmark with 4B-active model. — read next: Connect to Birgitta Böckeler's harness-engineering article (already in the user's library): her steering-loop concept asks how a team iterates the harness based on observed failures. Apply that lens here — what is SmallCode's own steering loop?
- incompleteThe cybernetic / control-theory framing latent in the design (variety reduction via BoneScript topologies, feedback via early-stop detection, model profiles as adaptive control) is never made explicit. Connecting this project to the broader harness-engineering conversation (Anthropic's effective harness paper, Böckeler's framework) would let it argue from theory rather than just engineering instinct.GitHub - Doorman11991/smallcode: AI coding agent optimized for small LLMs. 87% benchmark with 4B-active model. — read next: Read SmallCode against Böckeler's 'Harness engineering for coding agent users' (in this batch) — map SmallCode's components to her feedforward/feedback and computational/inferential axes. Read against the Anthropic harness-design materials the user is also tracking.