Petri Dishes, Not Factories
Against software that ships fast and matters to no one
The factory assumes execution is hard.
In software, understanding is hard.
Currently, in software, it’s factory-building-season. Agent orchestration frameworks with mayors and workers. Delegation hierarchies. Merge agents resolving conflicts. The machinery is getting sophisticated.
However, our mental models are lagging behind our enthusiasm. The pieces of the puzzle are there but we’re held back by a monolithic definition of what ‘work’ is. Looking around, most software engineers are fervidly vibe-coding every idea they have and looking for tools to build more, faster. So where’s the problem..? Well, most ideas are bad. In practice building the thing is not nearly as much work as designing it.
In fact, with a good plan, building is pretty easy! For months, I have been paying close attention to Ralph1. It turns out, with some knowhow, you can basically 3D Print Software. Ralph’s continued virality points to the power of self-modifying loops but it is not some silver bullet, it’s almost nothing. Ralph is simply a feedback loop. Fast iteration with feedback is how work compounds… and a strange enough loop can become almost anything.
The problem isn’t the loops, loops are good, it’s what we’re doing with them. When engineers encounter a new primitive, they reach for familiar mental models: assembly lines, org charts, throughput optimization. The loop becomes a factory. Agents become workers. The question becomes “how do we ship faster?”
But should we ship faster? If so, what should we ship?
The Factory Assumes the Hard Work is Done
Factory thinking is seductive because it maps onto familiar territory. We know how to think about workers, managers, delegation, quality control. We can measure commits, track velocity, celebrate shipping.
But the factory assumes the hard work is execution. In software—especially in novel software—the hard work is understanding: figuring out what problem you’re actually solving, discovering what users actually need, developing taste for what deserves to exist versus what merely can exist.
When implementation becomes cheap, this bottleneck gets exposed. You can build anything. The question becomes whether you should.
Factory techniques applied to exploration problems produce a predictable failure mode: software that ships fast and matters to no one. Technically functional, aesthetically bland, strategically pointless.
The code exists. But nobody asked whether it should.
Optimized Loops Leave No Room to Listen
Jumping straight from idea to fabrication can squeeze out the emergence that creative work actually requires. There’s an opportunity cost to building as-fast-as-possible.
Having a background in creative work makes this especially clear. Music production is mostly listening and comparison, not playing or composing. A producer’s ear develops through A/B tests, through sitting with a mix and letting it reveal its flaws. The instrument is secondary2. The feedback is primary.
Creators run many intersecting feedback loops in their process, ultimately designing their life in the process. It’s almost never a clear set of requirements that proceeds to implementation. More often, it’s making small, instinctive adjustments and checking the outcome without any overarching ‘plan’. The ability to surprise yourself, to intentionally not know what you are doing, is key. You run experiments to learn what you want to make.
Open-ended ecosystems are where value is created. The value comes from the system surprising itself.
When you optimize loops for throughput, the opportunity cost is subtle. You miss emergence. You miss inspiration. You miss the unexpected discovery that redirects the entire project. You optimize a path you chose before you understood the territory.
This is worth noticing: building your own orchestrator may be prerequisite to seeing what orchestration really is: feedback-loop architecture. Adopting someone else’s process means inheriting their assumptions about what matters.
Maybe that’s fine. But you should know you’re doing it.
What If the Loop Explored Instead?
The glaring omission from the agentic coding discussion is ideation. Where do the ideas for what to build come from? How do we use AI to help us strategize?
Here’s the largely unexplored opportunity: apply the loop to ideation and design, not just implementation. Loops can explore the design space rather than collapsing to a solution.
What if your loop selected for continuous inspiration? Or meaningful experiences for the end user? What if you generated three different approaches to the same project, compared them, then threw it all away?
What if your metric wasn’t “how fast did we ship” but “what did we learn about what’s worth building?”
Same primitive. Different application. Radically different outcomes.
Iteration toward a fixed target is factory work. Iteration that expands understanding is exploration.
Cultivate, Don’t Manufacture
Are you building a factory or cultivating a petri dish?
Factory: Known process, predictable outputs. Optimize the assembly line. Measure yield. Converge on a predetermined target.
Petri dish: Unknown territory, emergent outcomes. Design conditions for growth. Observe what develops. Learn from the dynamics. Discover.
Factories are appropriate when you understand exactly what you want—when the hard work of figuring out what to build is already complete. Then yes, optimize for speed3. Churn through implementation. Ship.
But most interesting problems aren’t like this. They require exploration before execution. Probing the space to understand its shape. Trying approaches to learn their tradeoffs. Building things to discover what you actually want. Using factory techniques on exploration problems produces fast, bland outcomes. You converge quickly on something mediocre because you never explored the space where interesting solutions live.
Geoffrey Huntley’s self-modifying loop that feeds prompts to agents, observes results, rewrites the prompt, and iterates
In game development it’s 50% playtesting, 40% design and 10% implementation. In visual art? Most of the work ends up in the bin!
And correctness