“Software Factory” vs. “Software Garden”
October 28, 2026 · Ryan X. Charles
This week I wrote two posts about software factories: the state of the art and our own design. Factories are the big idea of 2026. Stripe, Uber, StrongDM and many others say that they run one.
But a metaphor is not only a name. It tells you what to build, what to measure and what to worry about. And “factory” is not the only metaphor for software. There is an older one, and I think that it is about to come back: the garden.
So this post asks a simple question. If we want to turn astrohacker.com into the place where software gets made by super intelligent (SI) agents, should we build a software factory or a software garden?
Two very old ideas
The factory idea is almost as old as software. Bob Bemer used the term “software factory” in 1968. In the 1980s, Hitachi, Toshiba, NEC and Fujitsu built real ones: big organizations that applied the discipline of a production line to code, with standard processes, quality control and reusable parts. Michael Cusumano wrote the history in Japan’s Software Factories (1991).
The garden idea came from people who did not like the factory. In The Pragmatic Programmer (1999), Andy Hunt and Dave Thomas wrote that software is not like a building. In a 2003 interview, Hunt said it directly: “software is much more like gardening.” Thomas explained why: “you typically don’t change the shape of a building.” But you change the shape of software every day. They wanted people to see software as “far more organic, far more malleable”.
The musician Brian Eno gave the cleanest version of the split in a 2011 talk. An architect is “someone who carries a full picture of the work before it is made.” A gardener is “someone who plants seeds and waits to see exactly what will come up.” The gardener is not lazy. The gardener “carefully planted some rather well-selected seeds,” and then let the system do some of the work.
For fifty years, the two camps argued about how people should write software. Now the argument has a new meaning, because people are not the ones who write it.
The factory view
The factory view goes like this. Work comes in as issues. Each issue moves through stations: classify, implement, review, merge, deploy. Each station has a job and a check. Defects stop at their station. The output is a stream of deployed changes, and you measure it like a production line: throughput, cost per item, defect rate.
Jim Grey gives a good version of this in The factory floor metaphor for AI coding agents. He sees agents as “specialized stations positioned in sequence, each with a specific job and a team that operates it.” An agent is “custom tooling for one job in one factory.”
The factory view has real power:
- It ends things. Every work item ends as deployed or as “human required”. Nothing loops forever.
- It scales. A good line can process a thousand items a week.
- It makes cost visible. You know what each item cost and which station wasted the most.
- It has a century of theory. Toyota, jidoka, the andon cord, lean manufacturing. We do not have to invent quality control from nothing.
Where the factory breaks
Then Grey says the most interesting thing in his post: “software factories make one copy, not thousands.” A car factory stamps the same hood ten thousand times. A software factory never makes the same thing twice.
He also notes that “the metaphor breaks if we imagine the factory floor as stable.” In a car plant, the machines stay the same and the cars change. In software, the thing that you build is also the floor that you stand on. Each change that the factory ships changes the codebase, and the codebase is where the next change must go.
Igor Ostrovsky, in his survey of software factories in September 2026, finds the same limit from another side. Factories work best “when a standardized process makes agents more autonomous”: alerts, simple tickets, backports. They do not help much with open work, such as brainstorming a new feature.
And there is a quiet failure that a factory cannot see. Each item can pass every check, and the codebase can still get worse: one more helper that copies another helper, one more pattern that is a bit different, one more test that is a bit slow. Addy Osmani calls the result comprehension debt. No station is responsible for it, because it is not in any one item. It is in the sum.
The garden view
The garden view starts from the other end. The main thing is not the stream of changes. The main thing is the codebase, and the codebase is alive. It grows. It gets weeds. Some parts get too big and need pruning. Some parts die. You do not finish a garden. You keep it healthy.
Nikola Balić came to this view in January, after he watched agents work in real projects. In AI Agents Are a Stress Test for Your Dev Stack, he writes: “The best metaphor I’ve found isn’t ‘factory operator.’ It’s ecosystem gardener.” His point is that agents do not fix weak engineering; they expose it. A flaky test that a person learned to ignore will stop an agent every time. The goal is not maximum throughput. The goal is a system that stays healthy while it moves fast.
Other people are building gardeners now. A pull request from yesterday adds a “gardener” agent to one developer’s setup. Its job is to keep the codebase safe for other agents to copy. Its rules are very garden-like: “one weed per PR”, and when a weed is found, first stop the spread, then remove the existing copies, then leave a good example behind.
That last rule shows why the garden matters more with agents than it did with people. Agents copy what they see. A person who finds a bad pattern may ignore it. An agent will repeat it, faithfully, in the next ten changes. In a codebase where SI writes most of the code, weeds spread faster than ever.
The deeper difference: machines or living things
Here is the part that I find most interesting.
A factory assumes that its workers are machines. Toyota’s line works because each station does one simple job in a known way. The intelligence is in the design of the line, not in the stations.
A garden assumes that the things in it are alive. The gardener does not build a tomato. The tomato grows itself. The gardener chooses the seeds, prepares the soil, gives water and light, pulls the weeds and decides what to cut. The intelligence is split between the gardener and the plants.
Agents in 2026 are somewhere in between, and they are moving toward the garden end. Each year, a single agent can do a bigger piece of work alone. In a factory, that means that the stations get bigger, until one station is “build the feature”. At that point the factory diagram has one box, and the interesting question is not how the line works. It is what to plant, and how to keep the ground healthy.
Eno, quoting the cybernetician Stafford Beer, said: “instead of trying to organize it in full detail, you organize it only somewhat.” That sounds like very good advice for working with super intelligence.
Side by side
| Software factory | Software garden | |
|---|---|---|
| The main thing | The stream of changes | The codebase itself |
| Unit of work | A work item | The whole system |
| Input | Issues | Intent, and the current state of the code |
| Done when | The item is deployed | Never; you keep it healthy |
| You measure | Throughput, cost, defects | Health: speed of change, test trust, clarity |
| Agents are | Stations that do one job | Growers and gardeners |
| People do | Design the line, take stopped items | Choose what to plant, prune, decide what dies |
| Typical failure | Ships the wrong thing fast; rot in the sum | Never ships; endless tending |
| Design | Planned up front, then tuned | Emerges, then shaped |
| Old wisdom | Toyota, lean, jidoka | Hunt and Thomas, Eno, Gall’s law |
Gall’s law is the garden’s best argument, from John Gall’s Systemantics (1975): a complex system that works always grew from a simple system that worked. You cannot draw a complex working system and then build it. You can only grow one.
What would each product look like?
Suppose we build each one as a product. What would you see when you open it?
The software factory is a control room. Its main screen is a board of work items, each at its node in the graph. You see throughput per day, cost per item and the items that stopped at “human required”, with the reason. You edit the graph: add a branch for dependency updates, change the review node, add a check. Agents connect from anywhere and ask for work. Its input is an issue, and its output is a deployment. This is close to the design that we published yesterday.
The software garden is a map. Its main screen is the codebase itself: each module, colored by health. Which parts change often and break often? Which tests do people (and agents) no longer trust? Where do two patterns compete for the same job? Where does the code no longer match its docs?
In the garden, agents do not wait for issues. They walk the garden all the time, without being asked. One agent looks for weeds: dead code, slow tests, copied helpers. One agent prunes: it splits a file that grew too big. One agent handles the seasons: dependency upgrades, new language versions, security patches. Each one makes small changes, one weed at a time.
And the person in the garden does a different job. They plant: “I want a search page.” They decide what to cut: “this feature does not earn its place.” They set the rules of the soil: the conventions, the tests that define health, the examples that agents copy.
The garden has a second, wilder form. Robin Sloan wrote in 2020 that an app can be a home-cooked meal: he built a messaging app for his family, and nobody else will ever use it. Maggie Appleton took the idea further in Home-Cooked Software and Barefoot Developers, and Ink & Switch argued for malleable software that users can shape themselves. With SI agents, every user can be a gardener of their own software. A factory makes products for many people. A garden can grow something for one person.
Each one fails without the other
When I think it through, I do not believe that we have to choose. Each metaphor fails in a way that the other one fixes.
A factory with no gardener ships every item on time, and the codebase slowly fills with weeds. The agents copy the weeds. After a year, every change costs more, and nobody can say why, because every item passed its review.
A garden with no factory is beautiful and does nothing. The gardeners prune forever, and nothing ships. Nobody knows what anything cost, and a weed “fix” can run all night with no stop.
So my current answer is this: the factory is how changes move, and the garden is where they land.
- The factory gives every change a path, a limit and an end.
- The garden gives the codebase an owner that is not any one change.
- The gardener agents are one more source of work for the factory. A weed that a gardener finds becomes a small work item. It goes through the same graph, with the same reviews, and ends as deployed or human required.
- The factory’s review nodes check the garden’s rules. A change that adds a weed fails review, even if it works.
The factory makes the garden safe to change. The garden makes the factory’s work worth doing.
So which is Astrohacker?
We have not decided the name. We call it a software factory today, because that is the word that the industry uses, and because our issue and experiment records already work like a production line: each change has a design, a result and a record.
But the more I think about it, the more I believe that the factory is the part that people will see first, and the garden is the part that will matter most. The fastest factory in the world only makes the codebase bigger. Only a gardener makes it better.
Which metaphor do you use for your own work with agents? Are you running a factory, tending a garden, or something else? I want to hear from you. Get in touch.