There are many like it, but this one is mine.

“Software Factories” have become all the rage recently. I saw one HN comment compare them to the Cambrian explosion of JS frameworks back in simpler times and that’s pretty accurate.
Before we go further, let’s (attempt) to define “Software Factory”. At its most basic, I think it means a tool that manages multiple agents to accomplish a goal while moving tasks through the workflow, involving humans in decisions without requiring them to manually coordinate agents. The ability to go from idea -> PR, if not “deployed”, without needing to babysit agents. For me this is powerful because there is a cap on how many agents I can directly manage and keep track of. I want a list of things that need my attention or approval, and tasks only I can do, while the agentic loops run in the background. Another important concept is a system of checks or an enforced “pipeline” that tasks should go through (Example: Plan -> Review -> Human Gate -> Execute -> Review -> Fix issues (loop till done) -> Human Gate). And accomplishing all of that without just shuffling text between agents yourself.
I know at the company I work at something like 30% of the developers have some kind of software factory they are working on in their free time. What I wanted to explore is “why”? Why are so many people trying to build effectively the same thing?
I think the answer to that is that our own workflows for how to develop software are inherently personal. Yes, at the end of the day many of these projects are trying to be a “harness of agent harnesses” (in no small part because API billing is unsustainable for many of us so wrapping things like Claude Code to use the subscription is the path that a lot of people have picked), but they all have slightly different approaches and I’ve yet to see much effort coalesce around one “factory”.
While I can’t speak for other people, I know that personally LLMs have changed the way I think about things, things like “build vs buy” and also just what is possible, or rather practical. In the past I was acutely aware of what was “possible” but without unlimited time/energy/funds it was effectively out of reach. Now that has changed. I’ve been frustrated with MyFitnessPal’s locked-down nature for the 10 years or so I’ve used it, so I built my own version of the parts I cared about. It has an app I enjoy using and is more accessible to me (MCP/API). Whenever I hit a sharp edge, I can file it down instead of just dealing with it.
I give that example because I feel similarly about software factories. I’ve tried many versions of them that have been posted to HN or I’ve found online. They all have bright spots and also plenty of LLM “jank”. In a world where you can build anything, some of those attempts will fall flat and the ability to prune becomes paramount. Too many software factories try to be everything to everyone. Any feedback from users is implemented (or strongly considered) where in the past the economics to build all those ideas/features wouldn’t work out. You would be forced to prioritize, filter, and turn down ideas. Today you can go from Discord message to working feature in record time. In a crowded space like software factories, building what people are asking for, especially when it’s so cheap/easy, can be appealing. However I think it leads to less than stellar outcomes the same way that implementing any feature a client comes to you with is a bad idea (even if parts of the development cost have fallen sharply).
I don’t know what the future looks like. Heck, I thought Gas Town was a fever dream, that it could not possibly work, and it was an example of AI psychosis. I was wrong. Today I’m building my own version of Gas Town and getting real work done with it. Stop for a second, when did you first hear about Gas Town? Or can you guess about when the blog post was written? 6mo, 1 year, 2 years? Without checking, I almost gave the time range of 1.5-2 years ago… It was 9 months ago. In 9 months I went from “this is crazy” to “I have one of my own”. So given that, I don’t feel at all qualified to speculate on what the future looks like but I will anyways, because it’s fun and I’d love to hear from other people on what they think will happen.
So what is the future of software factories? Will they always be niche to specific use-cases? Will we converge on a handful of them like we did on IDEs? Will there be “source available” tools that everyone modifies to do what they need? Will every company have its own bespoke, made-just-for-their-process factory? And beyond factories, will software as a whole become more source available? “We provide the core and you can augment it”? Will software factories disappear in 6 months or less as LLMs get better and we move further “up the stack”? Do they have about as much staying power as “prompt engineer”? Just a product of this exact moment in time which we will look back on and laugh?
Currently every software factory I’ve tried is incredibly opinionated which has pros and cons. It’s nice to have an established workflow but if it doesn’t fit with how you do things it can be a non-starter. That’s why I have my own version. Mine builds on Claude Code and Herdr for reasons that aren’t super interesting to talk about. It doesn’t abstract to support Codex/Pi/OpenCode, and it doesn’t support tmux or any other multiplexer. It’s for me. While I’ve shared the source with some coworkers/friends, it’s not at all my intention to release it to a wider audience. I’ve encouraged people with access to copy ideas from it instead of trying to get it running and use it directly. To mine it for the “good ideas” to build their own.
We, as programmers, have largely spent our careers automating our jobs. We’ve made building software easier and easier, and somehow there’s still more software we want to build. Once you’ve automated one piece to a level you’re happy with, you start looking for the next bottleneck. Or at least this is how my mind works. Software factories are the natural extension of this idea. I think that writing code is now a mostly solved problem with LLMs. That’s probably the most controversial statement of this blog post but it explains why my attention has shifted to the rest of the process: deciding what to build, fleshing out ideas before starting on the code, and reviewing the results more thoroughly. For the first few months of 2026 that consisted of a lot of copy/pasting data between agents. “Code is written, now spin up a fresh agent to review the code, now spin up an agent to address the feedback from the first, and so on”. Software factories are a way to try to address that inefficient process.
Using your software factory to improve the software factory itself feels pretty magical. Noticing an issue or realizing you could benefit from a new feature, passing it into the factory, and then seeing the factory refresh/rebuild/restart/whatever with your change is so freaking cool. It has completely changed my view on so much software and I feel more constrained in “traditional” software. I want to be able to extend it just as easily as I can my own code.
Follow-up topics that I’d like to explore but this is already long enough:
- Are we at the edge of a wave that will reach the “general population” in time? Will they be re-evaluating build-vs-buy the same way I am?
- Will we see software that is more extendable going forward? Unreal/Unity but for business tools?
- Will the old adage about how people have kitchens and the ability to cook but many still choose to go out to eat or pay someone else hold for software?
- Could we see a move towards smaller single-purpose tools (with API/MCP hooks), possibly even largely open source?
If you haven’t tried building software just for yourself, with no plans to sell or monetize it, I suggest you give it a shot. It’s incredibly freeing to build for an audience of 1 (or even a small group) without worrying about whether it will make money or how you will market it to others. In the last year or so, building to scratch your own itch has become a lot cheaper and a lot more achievable.
This is my Software Factory. There are many like it, but this one is mine.