Contents
Why
The model, where humans fit in it, and the risks it balances.
-
From Dark Factory to Software Garden
Why we stopped calling it a dark factory. The metaphor that set the ambition, why it leaves people in the dark, and the garden that fits better: agents grow the code, humans tend the structure as growth wears it down.
-
The role of humans
Humans move to the edges: vision and validation, with agents implementing in the middle. And the answer to “how will I know the code is any good?”
-
The organisation of agents
Zoom from a colony of agents, through the processes they follow, into a codebase garden. Watch it run wild, then partly structured, then refactored into a structure that holds up at agentic speed.
-
Two ways to lose
Too careful loses the market; too careless loses trust. It's not the agentic part, it's the engineering part.
Quality
How you know it's any good, at agentic speed.
-
Agentic Loop Engineering
TDD is the template: a hard correctness condition lets an agent climb to correctness. Then loops inside loops, escaped defects, trade-offs, and why it's engineering all the way down.
-
All software fails somewhere
All software fails somewhere. Keep the signal non-negotiable, reason at compiler speed instead of human speed, stack integration and scenario tests to find the failure conditions, and feed them back so the defect rate falls as throughput rises.
-
There are no flaky tests
An intermittent failure is a real defect, in the test or in the product. Why noisy signals break agent loops, how to control time, and why every fix should cover the whole class of defect.
-
Zero-eyes PR approval
Agents review and fix each other's pull requests until the review is clean. Humans stop reading every PR and start engineering the loop: what escapes it, and how to make it stronger.
Structure
Know where the model is reliable, and harden the edges at compiler speed.
-
Every model has an envelope
Models aren't good or bad, or interchangeable. Map where yours is reliable, and harden the edges with structure.
-
Rules that enforce themselves
A rule in a document is advice; a rule in the build is a fact. The enforcement ladder, ratchets, narrow exceptions, an always-green baseline, and turning review comments into checks.
-
Derivation over duplication
Write each fact once and generate the rest: seven SDKs from one spec, docs and help from compiled sources, a generator you fix instead of its output, and CI that proves nothing drifted.
System
The tools agents use, and the gates they pass through.
-
Designing for agent users
Agents use our tools too. Data rather than prose, one job per output channel, respecting the context budget, dry runs, self-describing help, and SDKs whose types and errors tell the truth.
-
The merge button is part of the system
Auto-merge is only as safe as what the branch refuses. Required checks that can actually fail, stable branches, settings drift across a fleet, a vulnerability-to-release loop with no human in it, and handing admin changes to humans.
Organisation
Rolling it out: people, teams, tools and bottlenecks.
-
The bottleneck moved
The Theory of Constraints for agentic engineering: find where work waits, fix it, find the next one.
-
The constraint is mindset, not the model
Same model, opposite results. The beliefs, incentives and learning curve that decide which.
-
You are the skill
Tools churn. Your judgement, encoded as skills, rules and checks, is what scales.
-
Conway's Law still holds
Features cross teams. Every repository declares what it owns, and a planning skill places each capability with its owner.
-
Start with one garden
Choose one codebase, prepare it, prove it, and let it seed the next.