Parallels between a software factory and a laundry failure
AI + Simple Core
Is this title clickbait?
Not at all. For context, I have been building an agentic software factory. There are many of them out there. This one is mine. When I am not working, I’m keeping my household (as a father of 4) running. A month ago, my clothes washer failed. Last week, its pair (the dryer) also failed. These failures led to enormous backlogs of laundry very quickly. For the past couple of days, my working day was intermittently interrupted every 70ish minutes with the need to start loads, move from the washer to the dryer, and the dryer to my pool table (which serves as my holding area for clean clothes).
Naturally, while doing all of these clothes, I thought about some parallels between the at-home-laundromat I was running and the software factory I have been building. Here are the principles that I found most important.
Keep the core simple
AI handles feeding and draining the core
When running a factory, the key metric is throughput
Make failure easy to deal with
Eliminate bottlenecks one at a time
Keep the core simple
I am a lifelong ‘tech guy’. People often make the assumption that, because I’m a tech enthusiast, I want everything in my house to be “SMART”. Bluetooth enabled, cloud-connected, etc etc. This is actually quite un-true. Or at least, there is some nuance to it. Samsung is currently advertising AI OptiWash, which senses fabric type and soil levels, adjusting wash time and detergent levels, wi-fi connectivity, etc. LG is advertising “ThinQ AI Washer”, with big-data-driven AI to pick wash settings automatically.
The washing machine that I got is a Speed Queen TC5. It is mechanical, and is controlled by three knobs and two buttons. It is a top-loading agitator design, which has the advantage of not leaking. It is driven by gears rather than belts, adding to its strength. There is no cloud, API, big data, or anything like that. It is a tried and tested design that will hopefully survive a household of multiple teenagers and a large dog. Its new companion is a Speed Queen DR7, also bare bones and mostly mechanical. These machines have a reputation for being bare bones, reliable, and having a long service life.
These machines are the Millennium Falcon of laundry appliances - ugly but they’ve got it where it counts. My software factory is, in some sense, similar. The core ‘runner’ takes a well specified issue, unleashes a coding harness on it, and produces a commit on a branch. The task is very simple and well defined. Any coding harness can do this. Depending on the complexity of the task, it may do a better or worse job, but it should basically always work.
Lesson: The core workhorse needs to be as sipmle and reliable as possible.
AI handles feeding and draining the core
In the 48 hours after I installed my new washing machine, I did 18 loads of laundry. It’s amazing how quickly a backlog can build up in a household of this size. With a simple, reliable core, the ‘intelligence’ comes in how you feed it. Given a giant pile of laundry, it needs to be sorted: towels, bedding, whites, darks, ones which need pet hair removal. One of my kids walks outside with white socks on - this particular load needs to be soaked in OxyClean for a few hours, maybe for the duration of 3 other loads. The ‘intelligence’ in this case is me, planning the order of the loads, doing the prep work, finding that hidden pile at the foot of kid 3’s bed, and getting the pipeline all lined up.
In my Yesod software factory, I have AI agents that are responsible for feeding the factory. The agents set the job queue, make sure that the feature requests and bug reports are planned, and that the tasks will be implemented in a reasonable order.
On the other end, AI agents are looking at the merge queue, choosing a sensible merge queue, doing tests, and making sure that it all works out. The merge queue is like my pool table with a giant pile of freshly laundered clothing, and those agents are responsible for getting everything set and nicely integrated, into dressers and linen cabinets, etc.
Lesson: Have AI managing how to best use the simple, rock-solid core.
When running a factory, the key metric is throughput
If you’re doing just one or two loads of laundry per day, you’re just thinking about timing. “Load A goes in at 11. Move A from washer to dryer at lunch, and start load B. Switch over load B after my 2pm meeting. Done.” That’s easy, and we are thinking about individual loads. When you have a backlog the size of a mountain, the only question that matters is
Is the washer doing a load right now? If not, why?
This is the bottleneck to the factory. There’s lots of other things you can look at. Are the piles sorted? Is the folding done? Is the linen-closet right? Those are all good indicators, but the key thing to look at is is the washer running right now? Without that, no-matter what you do on the front end or the back end, you’re not really getting any closer to the destination. The merges can be done later. The work sequence will never be perfect. But, if you’re not writing code, you’re not getting things done.
In the software factory, my key metric is the same. Are the runners, the workers which pull an issue and write code, are they running? If not, why? I have a large backlog of issues, and that backlog only grows as I get more ideas. This backlog is not just for the factory, but for all of the other tools and projects that I am building with it.
There is a ton of AI all over the factory. Checking the merge queue, the eval queue, making sure issues are planned and sequenced properly. But, all of this doesn’t matter if code isn’t getting written. And, when this metric goes to zero, investigating it reveals the problem. Sometimes it is a database failure, or getting rate-limited on a coding plan, or the mail-system failing, etc, etc. This key metric (are the runners writing code) is what needs to be focused on, and all triage needs to work on fixing this.
Lesson: Identify the key metric. When this metric falls over, investigating it will reveal the issue you need to fix.
Make failure easy to deal with
I think that this would stretch my laundry analogy a bit. But, here is my attempt. There’s all kinds of ways to ‘optimize’ things. My laundry algorithm is pretty simple:
If it’s white, soak it in the tub with some OxyClean, then use a hot cycle and normal detergent.
If it’s dark, use Woolite Dark detergent on warm.
If it’s bedding, use the bedding cycle.
Else: normal cycle, warm water, normal detergent.
If, for whatever reason, something happens that shouldn’t. My ‘failure algorithm’ for laundry is going to be ‘soak in Oxyclean, then use the heavy cycle.’
For my software factory, I have an extensive set of tests. My default runner models are GLM 5.2, Deepseek V4 Pro, and Kimi K2.7 Coding. It tries to have some intelligence about complexity vs cost of the models. When something fails, I can go back and try to figure it out, but a good solution to failure is to try throwing Opus or GPT 5.5 at it. This is the heavy cycle of models. Not terribly efficient, but it gets the job done and we can move on to a more interesting problem.
Eliminate bottlenecks one at a time
Building a software factory, or doing anything at scale, exposes bottlenecks. Sometimes it’s the merge queue. Sometimes it’s the database. I tried implementing an inter-agent mail system with Beads/dolt and it was way too heavy. When you hit a bottleneck, you need to deal with it immediately. At a factory scale, bottlenecks quickly blow up. As a former Operations Management specialist, I really enjoy thinking about this stuff. Little’s law is a useful tool here. There are three related parameters in a factory:
Arrival of jobs
Speed of processing the job
Queue length
In a bottleneck, the speed of processing plummets, meaning the queue length blows up. This is well represented in one of my favorite TV scenes, the Chocolate Factory scene in I Love Lucy:
In my next post, I’ll introduce the Yesod Software Factory.
Upcoming Articles
I accidentally wrote a cost-aware code factory, and it’s awesome
How to effectively use Beads + Dolt at Scale
Give your AI access to Infrastructure - an Experiment with Proxmox
Yesod Factory - A Software Factory Architecture
When an AI System Reaches Critical Mass
The Factory Received Critical Mass when I saw it hit a bug, file a bug report against itself, fix the bug report, and redeploy itself
Agentic Roles in a Software Factory
Decoupled Agents in a Software Factory
Yesod Processes - Making your AI Processes Repeatable
Yesod Mail - Easy-to-use Messaging Between Agents
Yesod Toolbox - What happens when your tools know about each other?
Yesod Distillations - Capturing Best Practices in a Changing System
Making your factory cost-aware