Don't roll agents out across the whole organisation at once. Pick one codebase, prepare it, run it at agentic speed, prove it, and let it seed the next one.
Hand every team agents on the same day and every codebase becomes a jungle at the same time. Every review queue floods, every flaky suite gets hammered, and the organisation concludes that “agents don't work here”.
One garden lets you meet the constraints one at a time, fix each of them properly, and write down how. The second garden starts with everything the first one learned.
The first garden has to be hard enough that success means something, and contained enough that failure is cheap. Above all it needs owners who want to do this: people who will treat every problem as a constraint to fix, not a reason to stop.
Agents amplify whatever the codebase already is. Point them at a messy one and you get a messier one, faster. So the first phase is structural, done by humans directing agents: the refactor-for-speed phase from the garden.
And record a baseline before anything changes. Without one, you can't show the defect rate held while throughput rose, and that's the result the rest of the organisation will want to see.
Start with eyes on the code, and take them off as the loops prove themselves. Each phase ends when its constraint is gone, not on a date.
Expect the dip. The team is learning a new skill while it changes how the codebase is built. Protect them while that happens.
Agents implement, humans review everythingCalibrate: learn what agents get wrong in this codebase.
Turn review comments into skills and checksEvery repeated comment moves down the encoding ladder.
Zero eyes for proven change classesDependency bumps, generated code, well-tested modules first.
Find the next constraintRelease, validation, deciding what to build. Keep going.
The first garden exists to answer one question for the organisation: can throughput go up while the defect rate per change holds or falls? Answer it with the baseline you recorded, not with an impressive demo.
Publish the failures too: the escapes, the loops that leaked, the constraints that took longest. They're what the next team most needs to know, and showing them is what makes the numbers credible.
The people who tended the first garden are the best way to start the next ones. They carry the skill, and they bring the encoded parts with them: shared skills, architecture rules, merge-gate settings, scenario harnesses.
Each garden starts further ahead than the last, and each one finds a constraint the others haven't hit yet, which goes back into the shared playbook. That's how the method spreads without a big bang.
Choose a codebase that matters with owners who want it. Refactor it for speed and record a baseline. Earn autonomy as the loops prove themselves, show the rate, publish the failures, and let the people and the playbook seed the next garden.