A barely lit factory in blue moonlight looking through a high window — “Dark software factory” by Ed Lyons via prompting Midjourney

This is the first of a two-part essay on the mysterious topic of software factories. It is a deep dive into what they are, how they work, and what providers are out there. It also explains how you can start using factory techniques in your own software development workflows.

Part two is about how factories will significantly alter the software development methodologies so many organizations use, as the extraordinary momentum and cost savings of factory techniques will force changes.

There has been a lot of talk this year about agent-driven software factories. It started with laughter. But that soon turned to fear among developers when they were imagined as powerful “dark factories” - with huge numbers of agents building software without human supervision in unlit facilities.

Then two large factories appeared, backed by hundreds of millions of dollars of investment. And in their shadows, many smaller ones started rising. Most recently, new platforms have appeared which let you build your own custom factory.

But… what are they?

Software factories, like industrial factories, are capable of producing a large volume of products at lower cost than doing so by hand. Using a factory, a software project that previously required months or years could be completed in days or weeks.

Developers are right to be skeptical of such huge automations. After all, aren’t the agents we’re prompting right now making mistakes creating small features? How could you possibly scale what we are seeing every day?

To see how this is possible, let’s take a familiar process to automate: turning your project’s tickets into finished features. Without a factory, you’d load that ticket content into your agent, have it generate the code, perhaps try it out yourself, run tests, run reviews, have the agent fix problems, put it through your CI pipeline, fix any errors that it found, run tests and reviews again, resubmit the PR to your pipeline, and once it passes, have someone else review it, and then merge it.

Now imagine you decided your agent should do all of these steps on its own. We all know that usually wouldn’t work. There are too many places where something could go wrong. It might not correctly interpret what the ticket means. It might not do the reviews properly. It might get good feedback from the reviews but mess up the implementation. Or it might fix a bug in the wrong way. Or it might get stuck in endless loops between reviews and fixes. Or an agent could just get stuck or shut down.

And imagine creating a sequence of 50 features in this way. The problems across PRs would multiply, and the entire project would be shaky and error-ridden. It would be unusable.

A factory is designed to address all of these problems. It has stages where work can be checked for accuracy, it has specialized agents for different tasks, it has loops to fix problems and handle flakiness, it has ways to escalate serious problems to a person, and it has methods of evaluating and improving its operations.

Let’s look at one!

Jim Bennett from Microsoft built a delightful, open source factory that demonstrates the core principles. It turns GitHub issues into shipped features for a fun little project. It is the best simple project I have seen to learn how a factory works, and its documentation is excellent. If you already have, or can set up inexpensive accounts for Claude Code, Codex, and Arize AX - you can get it all working in a couple of hours to start building the sample application.

As you can see from the diagram above, it is a workflow with defined phases and specialized Claude Code agents working at each one. (Codex is used in the evaluation and improvement of prompts outside the flow of this diagram.)

After the pipeline stage, three reviews happen in parallel and are sent to the “Risk router.” If the router decides the code is good and low-risk, it merges. Otherwise it goes to the “Human” gate, with the command to ship it (meaning no problems found but high-risk) or to make changes, which means it goes back to the Babysit gate for code fixes, unless it has been there a few times already. Then a person must fix it.

The factory also grades itself based on how well it does based on evaluations and reports using the Arize AX tool. It takes that information and changes the coding agent prompts that are present in each of the gates. The prompt improvements also go through loops and evaluations, which a person can monitor.

That’s it. You understand what a simple software factory is.

We still need to cover a really important topic: what powers factories. It’s two things — neither of them tokens — though you certainly need those!

To find out about the first one, we will go all the way back to the first light of 2026. To a silly group of cartoon animals working in a software factory called Gastown and a maverick software developer named Steve Yegge.

In late December 2025, developers who were good with coding agents knew that to get better agent product quality, you should ask for an execution plan before generating code. There were even a few open source projects that enhanced the planning and execution phases to allow larger amounts of work to be performed in this way. Yet I did not hear anyone describe these first efforts as factories.

On January 1, Steve Yegge released the first software factory that lots of people noticed. To the surprise of everyone, he claimed he had read none of the generated code, which was considered sacrilege at that time. His project was accompanied by silly AI-generated images of animals working in an industrial factory town.

Gastown went viral immediately and the entire coding agent world could not stop talking about what it meant. (It even briefly spawned a memecoin, $GASTOWN).

Yegge believed we could feed a factory all of our specifications, and a variety of specialized agents using clever task management would play all of the roles in a factory to produce a finished product. This kind of software development process seemed ridiculous. Many people scoffed or made fun of it. Yet, for a few weeks, no one could look away.

There was a broad consensus that Gastown could not be used for serious applications. The results were not good enough.

The main reason why Gastown existed was Yegge’s ambition, which is the most important driver of factories.

He saw the unreliability of agents as a problem that could eventually be solved. If you had the right processes and correction loops, some agents could catch the many errors and failures of others, and assign those errors to other agents. It didn’t work well, but he did it anyway.

Ambition is the most important trait for technical people using coding agents. Skilled developers who are motivated to try really hard things despite fear of failure, and fight their way through problems are the ones who make great progress. This is why company training classes and show-and-tell sessions about AI will not create broad changes in organization behavior all by themselves. Without broader transformation and a change in incentives, a small group of people with ambition keep moving forward, but most others will be satisfied with small improvements.

Ambition is especially important in agent automation because it is not easy to set up, and there are a lot of less sophisticated alternatives with great benefits. Back in January, tens of thousands of developers were doing amazing things driving individual agents when Gastown came out. Why would they bother trying to build something like that?

There is one more thing driving factories: increasingly powerful coding agent technologies.

If Yegge had the models and agent tooling we have today, Gastown would have worked. The frontier models are vastly better at coding than several months ago; the harnesses are better and can handle longer-running tasks; we write better prompts; and lots of new techniques have been created.

Yet, while things continue to improve rapidly, we now hear that a lot of developers are no longer using the latest models and techniques. Many are quite happy with what they set up a few months ago. And besides, the bosses are worried about token costs, aren’t they?

That means many software developers are simply not aware of what can be done right now, and therefore do not appreciate that factory techniques can be used to create software if you make a big enough up-front investment.

The last thing I will say about Gastown is that not everyone laughed at it. Some ambitious people grabbed the baton and ran.

Let’s now look at the factory space, which is quite hot and drawing a huge amount of investment. We will start with the big players.

Of course, Open AI famously uses a software factory internally for all their software, and you can read in The Pragmatic Engineer how it works. (Anthropic has something similar.) But you can’t use their internal factories.

Fortunately, there are other factories out there for hire.

Blitzy and Opsera are large factory offerings, and offer a new frontier of large application offshoring. They are focused on legacy application modernization. That is because it is a huge market, and these are applications where the requirements are often known ahead of time — crucial for large-scale factory work.

For a very high price, they are quite capable of rapidly churning out many types of applications. I’ll focus on Blitzy as they have a much bigger public profile and advertising campaign. They boldly claim on their website that their factory can “transform six-month software projects into six-day turnarounds.” I have been on a tour of the factory floor at Blitzy, and I would not dismiss that claim out of hand.

Like everyone else who has looked at legacy applications, Blitzy decided that agents were a game-changer for modernization. They built a huge architecture where many thousands of agents could collectively digest millions of lines of code in order to get all of the requirements. Then they created lots of new processes to guide the agents to translate that old code to new code that did the same thing, and a web interface for humans to track and manage the process.

It’s important to note that no factory claims it can do 100% of the coding for you, due to missing requirements or mistakes by the agents. The claims are usually that they will complete 80 to 90% of the work.

This is still very compelling, even though these methods will not be appropriate for all modernization projects. Many are complex journeys involving risks, architectural changes, and new features.

Blitzy also reveals an important flaw in the “factory” analogy. When we think of real-world factories, we imagine huge investments in heavy equipment and factory worker training that provide sustained value and are very difficult to replicate. But in the world of coding agents, the technology is cheap, mostly open, and advances at extraordinary speed. It is hard to imagine that the current frontier models would require the extraordinary processes and resources that Blitzy’s agents needed several months ago. What legacy application would now require “thousands” of Blitzy agents to understand it?

Therefore it seems possible that many applications today might be built with newer factories that will not cost millions of dollars to use.

Blitzy is taking its case to market, even engaging skeptical and spicy technology YouTubers to try out its tools, including some quant guy named “Coding Jesus” who posted his review here.

Another influencer posted a 16-minute video comparing a $20/month Cursor agent to using Blitzy, which he said “costs up to $5 million a year.” That review was a surprisingly good, side-by-side comparison of both platforms attacking a very difficult feature request on a 3-million line open source project. It made it clear what you get out of factory techniques that you don’t get with developer-driven agents.

The unexpected result of this comparison was that both were successful. But Blitzy delivered a more robust solution with better testing and error-handling. I could see how, over many features in a huge build, such a quality difference would really add up and be worth paying for.

Yet I could not help but think, “Uh… surely we could do something useful to augment the $20/month solution to avoid paying the $5 million, right?”

The answer is yes… sometimes. And that’s where we’re going next.

Ona and Factory are far less expensive platforms that let you create your own software factory with autonomous agents. As a sign of their success, Ona was recently acquired by OpenAI and Factory raised $200 million several weeks ago. I have recently seen huge Factory digital billboards along the interstate highway in Boston and in Times Square of New York City, and wondered why such specialized software was being advertised like a Disney movie.

Digital billboard pictures in NYC and Boston by Ed Lyons

Factory is a far smaller product than Blitzy that has been around for several months. It offers a platform for you to set up your own factory with autonomous agents called droids.

Using Factory, I created a few small applications that I had a lot of requirements for, and I was impressed with the results. You can use it in more than one way. You can use it like a typical coding agent harness, and even in that mode, it is good at figuring out how to get things done on its own, in the same way that Devin AI does. The next step is to set up your droids to do larger and longer-running tasks without your supervision, which is how you’d set up factory-style processes. Or you can sign up for their new pre-configured factory that offers sophisticated management and analytics.

Another offering is from Ona, which specializes in cloud-based “background agents.” That’s what led them to factory work, and is probably why they got acquired by Open AI.

A few months ago, Ona’s engineers did a two week project where they built a factory, using their background agents and tools, and then let it build a new application. In several hours of great videos, they showed what they were doing each day to create it, and then released all code to the public for scrutiny. It made it clear what the differences were between typical developer-driven agents and the factory approach. The project and videos are outstanding, and if you want to understand the journey to build a sophisticated factory, it is the best thing I have found.

Their videos demonstrated that factory work is all about well-defined processes. As part of their two week project, they made a great interactive diagram about their automated SDLC. On their website, you can hover over each piece to see the flows. It’s a useful way to get a feel for the kinds of automations you could set up yourself without their platform.

The green boxes describe the Ona “automations” - which are simply steps in the process that are needed for the agents to move through the workflows, detect problems, and direct fixes. These are somewhat like skills in typical agentic development, such as the ones that the Superpowers framework uses for similar lifecycle processes. But they are more robust, they exist independently in a cloud-based environment, and they are reliably triggered according to process rules.

At the end, they said that 88% of the final application was written by the factory, and not their prompts. So their factory isn’t totally dark either, which they had no problem admitting. Still, that’s an incredible outcome. Their pride resulted in one of their engineers saying that developer-driven agents were “so last year.” He was half-joking. But only half. (I wanted to laugh, but couldn’t quite do it.)

If you find this intriguing, you might wonder, “Why haven’t I heard of anyone doing this?”

It is for three reasons. First, most software development projects do not start with all of the requirements known. You cannot gain the benefits of a factory if you aren’t sure what you want. Second, it is not easy to build your own factory and the offerings can be expensive. Developers driving agents more effectively is a much better short-term investment than trying to build or lease a factory. Third, many people do not believe the factories can deliver what they are promising.

Yet you do not need to make a “go/no-go” decision about using software factories. Perhaps you should take inspiration from some of the automations I have described. Watching the Ona videos should provide examples of what you can do.

For example, the Ona engineers used the Sentry framework to capture more detailed application health and error information. This gives higher quality feedback to the agents and they will need your input less often. This approach is superior to logging or browser console messages. You could hook that up right away.

You could also start using separate agents to perform steps in your typical workflow instead of the same agent doing sequential tasks. Or trying to evaluate and improve the prompts you use over and over again. Another important step would be to start using long-running tasks, especially in a cloud-based environment, which is better suited for that than desktop work.

A key resolution would be to decide to automate more of your process instead of speeding up individual human-driven steps.

But as you make progress toward factory work, you are going to start wondering whether typical agile development processes should still be used. You will have plenty of company.

Warp, previously an agentic development environment vendor, has transitioned to being a platform to build software factories. Warp CEO Zach Lloyd recently announced at a major AI conference that we are transitioning into a future where all software is built in factories.

Is Lloyd… right? Certainly not yet, but I think most of the software we are building now could be built in software factories, and the prospect of this will doom or dramatically alter the agile software development process so many of us are using.

What software factories will do to the traditional software development lifecycle is the subject of the second part of this essay.

Software Factories, Part One: How They Work, How to Build One, By Ed Lyons