When I recently started seeing Software Factory pop up on social media, I was not sure what it was about. I knew it had to do with agentic coding. I had thought that it was a fully automated software development process without a human in the loop. I was mostly wrong.
I came across a Vercel blog post on how they implemented their homegrown software factory for the AI SDK. It clarified how people have started putting the software factory into practice. What I found wasn’t a way to remove the human. It was a way to stop routing every single change through one human’s attention.
Let me put together a definition of software factory in my own words.
Software Factory is a multi-agent system deployed across the software engineering process, from the very first step (creating issues, bug reports, or feature requests) all the way to shipping the code. In other words, the requirements and fixes that go into the next iteration of software. And it applies to new software too, not just existing code.
In a traditional software engineering process, the release of a new feature or a fix goes through many steps, such as:
If it’s a new feature request, putting together a design.
Initial implementation, which needs to be evaluated, improved, and validated against the initial requirement.
Quality checking (QA).
Performance testing, and if it meets the bar, it goes out to production.
Feature documentation on how the feature works.
Every one of these steps used to take human efforts. That’s the part that changes.
All these steps, before agentic coding became a thing, were done by human engineers. Now that we have scaled up the production of software artifacts with AI coding agents, we have more code and more requirements coming up at a speed that is hard for human engineers to handle end to end by hand.
The idea is that for each software engineering step, whether building a new feature or fixing a bug, there is a specialized agent. At Vercel, that means a separate agent for each step in the pipeline, not one agent doing everything. Each agent gets its own prompts, context, and evals. It is refined for its task and measured on its performance.
Then the human engineers assume the role of reviewers, not doers, looking at what the army of agents is producing. They are the final gatekeepers to ensure that what gets delivered meets the quality bar.
This is how Vercel implemented it for the AI SDK. The AI SDK is a big open-source project, over 20 million npm downloads a week, and the repo has more than 26,000 stars. Keeping a codebase like that healthy means watching four things move at the same time: the model providers, the UI frameworks, the sandboxes the agents run in, and the harnesses. After a few years of growth, the repo was getting 100+ new issues every month. When Anthropic’s Opus 4.6 model came out, the pull requests hit an inflection point. By late June, they had over 1,000 open issues and almost 800 pull requests sitting there.
And this is the part that matters: you cannot fix that backlog by hiring more maintainers or asking the ones you have to work harder. Because generating code is cheap now, the pile only gets bigger. So instead of trying to scale themselves, they built a software factory. Four weeks in, it authors between 25 and 35% of the PRs they merge and closes 70 to 80% of their issues.
They started with an agent that classifies incoming issues as a bug, a feature request, or a documentation update. Once that agent achieved a high level of accuracy, they moved on to the next step.
For example, if it’s a bug report, another agent sets up an isolated environment and works on reproducing the bug. Another agent fixes it, and another reviews the PR. There are also agents for feature analysis, feature implementation, documentation updates, and backports to older versions. Each agent hands off to the next, and some of these runs go in parallel. Each agent is evaluated and improved in isolation.
It’s not one monolithic agent doing everything from beginning to end. If some agent is not reaching the bar, it can be isolated and improved on its own through better prompts, better context, or new eval cases.
The repo is open source, so anyone can open an issue or leave a comment, and the factory has to treat all of it as untrusted input.
How I would put this into practice
I would give an agent a responsibility only once it achieves a certain, measured level of performance on that task. So I went looking for how others are thinking about this. I found two posts that say the same thing. Port suggests having a human approve every step at first, and then taking the human out of the steps you trust, one at a time. Augment Code found that their teams needed time to look at what an agent was producing and correct it before trusting it with longer tasks. Both are saying the same thing I am saying. You do not hand over everything at once. You hand over one step at a time.
I think of Software Factory like teamwork, where a team lead distributes tasks among the developers in the team. If some of the developers are falling a little behind, the team lead spends more time with them. In the same way, if some tasks are not done well by an agent, the human can spend more time reviewing that part. The team lead is responsible for overseeing the work produced by team members in isolation and in coordination.
It’s a human in the loop, not a human removed from the loop.
So here is where I landed. A software factory is not a way to take the human out of software engineering. It is a way to move the human to the end of the line, where the judgment actually matters. The agent does the work. The human decides what ships.
If you are building or thinking about Software Factory, the real question is not which agents to build first. It is which steps you are willing to hand over, and which you want to keep your eyes on. Start with the ones you can measure, and hand them over one at a time.
I have only read a few posts on Software Factory so far. As I come across more, I will keep sharing.
References
Vercel, “Building a software factory for AI SDK”: https://vercel.com/blog/building-a-software-factory-for-ai-sdk
Port, “AI software factory”: https://www.port.io/blog/ai-software-factory
Augment Code, “Beyond AI coding agents: how we built Augment’s software factory”: https://www.augmentcode.com/blog/beyond-ai-coding-agents-how-we-built-augments-software-factory
The numbers in the Vercel section are theirs: open issues, pull requests, npm downloads, stars, and the share of merged PRs and closed issues. The teamwork analogy, the reviewer framing, and everything under “How I would put this into practice” are my own thinking.