Should you build a "software factory"?

Why are people building AI software factories now?

AI software factories make a lot more sense now because coding agents have moved from helping with individual edits to running real engineering work in the background.

The freshest evidence comes from teams already using agents heavily. Uber recently reported that more than 70% of its pull requests are now attributed to local or cloud agents. Its engineers have created more than 3,600 agent skills and run more than 30,000 skill executions per day. Weekly agentic requests increased 9.4× over roughly six months.

The products are moving in the same direction. Codex can run several agents in parallel and keep them in separate worktrees. Cursor's cloud agents can now subscribe to a pull request or Slack thread, wake up when something changes, fix CI failures and continue working toward the goal. Anthropic has been developing long-running harnesses and agent teams around Claude Code.

A year or two ago, building a “factory” around an AI coder would have meant repeatedly rescuing agents that got stuck. These days, an agent can often receive a task, inspect a repository, change several files, run the tests and come back with reviewable work. Once that happens, running several jobs simultaneously starts to make sense.

The bottleneck has moved from getting an AI to write useful code at all to deciding how much work we can safely delegate.

What does an AI software factory actually look like?

A useful AI software factory looks more like an automated development pipeline than a fake company filled with “CTO agents” and “senior developer agents.”

Ona gave us one of the clearest public examples when it built a software factory around a Notion-style application called Memo. By the end of the experiment, 16 automations covered different parts of the software lifecycle. An issue could trigger implementation, another agent could review the pull request, CI failures could trigger repair work, production could be smoke-tested and errors could create more work.

Factory.ai describes a similar model: outside inputs such as bugs, customer feedback and requirements enter the system, then agents execute different parts of the engineering workflow.

The useful part here is the workflow itself. Each job has a trigger, relevant context, a defined output and some way to check whether the work succeeded.

Be skeptical when a personal software factory mostly consists of ten agents chatting with each other about who should do what. The systems showing the most convincing results currently rely much more on tasks, branches, tests, environments, events and review gates.

Can an AI software factory really build an entire app today?

Yes, an AI software factory can already build a substantial application today if the environment is controlled and humans provide enough direction.

Ona's Memo experiment began with an empty repository. Ten days later, agents had merged 375 pull requests, written more than 67,000 lines of code and generated 1,067 tests. The median issue took 38 minutes to close, while the median pull request went from opening to merge in 4.9 minutes. Ona estimated that about 87% of merged work happened without a human intervening during execution.

That was a real application with authentication, workspaces, rich-text editing, search and database-like functionality rather than a landing-page generator.

Anthropic pushed multi-agent coding much further in a different direction. A team of 16 Claude agents spent almost 2,000 Claude Code sessions building a C compiler from scratch. The result contained about 100,000 lines of Rust, could build the Linux kernel on x86, ARM and RISC-V, and reached a 99% pass rate on several compiler test suites. The experiment cost just under $20,000 in API usage.

OpenAI has also described an internal repository built under a “no human-written code” rule. That project eventually led to Symphony, its open-source specification for dispatching Codex agents from a project-management queue.

These examples settle one part of the debate. Whole-project autonomous coding is already possible. What they leave open is how reliably this approach works when requirements are messy, the existing codebase is ugly and nobody has built excellent tests around the agents.

Example	What the agents built	What humans still provided
Ona Memo	67,000+ lines, 375 merged PRs, 1,067 tests	Specs, factory setup, escalation decisions
Anthropic compiler	~100,000-line C compiler capable of building Linux	Initial objective, harness and evaluation
OpenAI internal project	Repository built under a no-human-written-code rule	Workflow, repository structure and guardrails

Are software factories already working inside real engineering teams?

Yes. Factory-style coding is already production work at some advanced engineering organizations, although humans still control what ultimately ships.

Uber's recent numbers are the strongest public example. More than 70% of its pull requests are attributed to agents, and a growing amount of work begins automatically rather than through someone opening a coding chat. Uber describes agents reviewing code, repairing CI, completing end-to-end changes, triaging alerts, debugging bugs and handling maintenance.

Other teams are heading the same way. At a background-agent summit earlier this year, engineering leaders reported more than 1,000 agent-generated pull requests per week at Stripe, more than 1,500 agent pull requests merged at Spotify and roughly 30% of pull requests coming from agents at Ramp.

The important distinction is autonomy during implementation versus autonomy over the whole product. These companies are comfortable letting agents do surprisingly large amounts of execution. Review, permissions, deployment rules and escalation still surround that execution.

So when people say software factories are already here, that claim is largely fair. When they mean that mature companies are handing the entire engineering organization to autonomous agents, the evidence does not support that version yet.

Are five coding agents actually better than one?

Often no. Multiple coding agents become useful when the work can genuinely happen in parallel, and current agents still struggle surprisingly badly when they have to coordinate tightly.

CooperBench tested two agents working on potentially conflicting software changes. GPT-5 completed about 48% of the benchmark in the solo setup but only about 28% when two agents had to cooperate. Claude Sonnet 4.5 fell from roughly 47% solo success to 26% with cooperation. Agents even spent as much as 20% of their available budget communicating, yet the communication did not remove the overall performance gap.

A separate study called CAID produced almost the opposite result. Researchers improved performance over single-agent baselines by 26.7 percentage points on paper-reproduction tasks and 14.3 points on Python-library development. The difference was how the agents worked. One manager created a dependency-aware plan, each worker operated in an isolated workspace and the system merged the outputs through executable verification.

The answer here is fairly sharp. Five independent jobs can justify five agents. Five agents simultaneously reasoning about the same tangled code change can easily create more coordination work than useful work.

This is why simply increasing the number of agents is a weak factory strategy. Good task boundaries produce the leverage. Not the headcount.

Experiment	Single-agent result	Multi-agent result	What happened
CooperBench, GPT-5	48.3%	28.0%	Coordination hurt
CooperBench, Claude Sonnet 4.5	47.1%	25.9%	Coordination hurt
CAID, PaperBench	Baseline	+26.7 points	Isolated, dependency-aware delegation helped
CAID, Commit0	Baseline	+14.3 points	Structured parallel execution helped

Can we trust software-factory code just because the tests pass?

No. Passing the available tests is currently too weak a standard for letting a software factory ship arbitrary code without oversight.

METR tested this directly by asking active maintainers of scikit-learn, Sphinx and pytest to review 296 AI-generated pull requests. The automated SWE-bench grader scored the patches about 24 percentage points higher, on average, than the maintainers' merge decisions.

Roughly half of the AI patches that passed the automated benchmark still would not have been merged by maintainers. Some broke unrelated code. Others technically solved the issue but ignored repository standards or produced code the maintainers considered poor enough to reject.

This was based on agents that are older than the newest models available today, and METR also points out that the agents were not allowed to respond to reviewer feedback the way a developer normally would. So it would be a mistake to treat the result as a permanent ceiling.

The gap itself is much harder to dismiss. A factory can satisfy the tests we happened to write while still producing software we would rather keep out of production.

Recent industry research suggests teams are already feeling that shift. In GitLab's 2026 AI Accountability research, cited by IBM when it launched new multi-agent development features, 85% of surveyed DevSecOps professionals agreed that AI had moved the bottleneck from writing code toward reviewing and validating it.

As coding gets cheaper, proving that the code is good becomes a larger part of the job.

What work still stays human in an AI software factory?

Humans currently remain strongest at deciding what should be built, describing it precisely and judging whether the result actually feels right.

Anthropic analyzed roughly 400,000 Claude Code sessions involving about 235,000 users. The typical division of labor was remarkably clear: people made most of the planning decisions about what to do, while Claude made most of the execution decisions about how to do it.

The same pattern appeared inside Ona's factory. As seen above, agents handled most of Memo's implementation, but the system performed much worse when people supplied weak specifications. A five-line description of a Notion-style database feature produced something functional overnight, yet property editing, date-picker behavior and several edge cases came out rough. Ona concluded that many of those problems came from missing detail in the specification rather than an inability to write the underlying code.

Design created another ceiling. Memo gradually drifted toward the familiar AI-generated SaaS look until the team added stronger visual references and Storybook examples. Even then, automated improvements could fix measurable properties while making some subjective design choices worse.

During the first three days of the experiment, humans still spent eight to ten hours per day building the harness, writing conventions, improving prompts and defining review loops. By the second week, that fell to roughly two or three hours per day.

The human workload can clearly shrink. For now, it concentrates higher up the stack: product judgment, specifications, architecture, evaluation and taste.

Will a software factory help us ship more products or just more code?

A software factory can multiply how much software we produce, but product discovery does not automatically accelerate at the same rate.

This distinction becomes especially important for indie hackers. Imagine we reduce the effort required to build an MVP from two weeks to one day. We still need to decide which MVP deserves that day, get people to try it, understand why they leave, position it, price it and find distribution.

A factory can actually make this problem more visible. Once agents empty a development backlog faster than users generate useful feedback, “what should we build next?” becomes the slower loop.

Ona encountered exactly that problem and eventually worked on feeding real user feedback back into planning. The factory could keep generating features, but feature production on its own did not tell the system which features deserved to exist.

For builders who already have strong demand and an overflowing roadmap, faster implementation is extremely valuable. For someone still searching for a good product, multiplying software output can mostly multiply experiments that nobody asked for.

The scarce resource is increasingly good decisions about what to build.

Will Codex, Cursor and Claude make custom software factories obsolete?

They will probably absorb a large share of the generic software-factory plumbing, and that process is already moving quickly.

Look at what people recently had to build themselves. Running agents in parallel required an orchestrator. Isolating work required custom worktree logic. Long-running jobs required infrastructure. Scheduled tasks required another service. Agents reacting to CI or GitHub events required more integration code.

A growing share of those capabilities now comes directly with the coding platforms.

Codex is explicitly designed around multiple parallel agents, cloud environments, worktrees, skills and background tasks. OpenAI has also published Symphony, an orchestration specification that can turn a Linear project into a queue for coding agents.

Cursor recently went further with cloud-agent subscriptions. An agent can watch a pull request or conversation, wake when something changes and continue working. Anthropic provides subagents, skills, hooks and increasingly sophisticated long-running-agent harnesses around Claude Code.

There is another unusually strong clue: Ona, one of the companies most explicitly building software-factory infrastructure, has now joined OpenAI as part of the Codex organization.

Spending weeks recreating generic orchestration therefore carries serious platform risk. By the time a personal orchestrator becomes stable, one of the coding platforms may have shipped most of its useful features.

What part of a software factory is actually worth building yourself?

Own the knowledge that makes agents good at our software, and let platforms handle as much generic agent infrastructure as possible.

Uber's setup shows where the durable value starts accumulating. Its engineers have created more than 3,600 skills for recurring workflows. They also built a context graph spanning 24 million nodes and 80 million edges across more than 30 internal systems.

In one comparison, the same model answered an internal question correctly in 38 seconds when it could use that graph. Without the additional context, the agent spent more than 20 minutes searching, spawned two subagents, hit three errors and eventually gave the wrong answer.

For a solo builder, we obviously do not need an Uber-sized graph. The smaller version can still compound: clear architecture documentation, reliable setup scripts, examples of good code, product rules, deployment conventions, design references, regression tests and reusable skills.

Those assets remain useful if we switch from Claude to Codex, from Codex to another model or from a custom runner to functionality built into the IDE.

The orchestration code itself has a much shorter shelf life.

Is running a serious software factory too expensive?

Cost can become meaningful surprisingly fast. A small personal factory does not need anything close to the most extreme experiments, thankfully.

Anthropic's 16-agent compiler project consumed about two billion input tokens and 140 million output tokens across almost 2,000 sessions. The API bill came to just under $20,000. That sounds outrageous for a personal coding workflow, although Anthropic's researcher argued that manually producing the same compiler would have cost far more in human engineering time.

Large production systems also create less obvious waste. Uber found that agents carrying too many tool definitions could start a conversation with 50,000 to 70,000 unnecessary tokens of schema. In another example, changing how tools were called reduced token consumption by more than 50% on several simple queries and by more than 90% on some bulk workflows.

Uber has managed to push its unit costs down while usage exploded. Holding the model constant, it reported cost per 1,000 requests falling almost 34% from its peak and cost per session falling 52% from a previous peak.

For an individual builder, the lesson is simpler. Running two agents on two useful independent jobs can be cheap and rational. Allowing a large swarm to repeatedly debate, inspect the same files and retry poorly specified tasks can burn a surprising amount of inference for very little additional output.

Scale agent count after finding useful parallel work, not before.

Who should actually build a serious software factory?

A serious custom software factory makes the most sense when someone has a lot of recurring engineering work that looks similar from one task to the next.

Large software companies fit that profile extremely well. They have endless bugs, migrations, code reviews, dependency updates, tests, alerts and repetitive maintenance. An agency using the same stack across dozens of clients could also reuse a factory repeatedly. A prolific builder maintaining ten related SaaS products might reach the same point.

The case is weaker for someone trying to launch one application. Spending three days building sophisticated orchestration can easily consume more time than letting a strong coding agent build the first version directly.

It becomes weaker again when the actual bottleneck sits outside engineering. If we have no distribution, no users and no confidence in the idea, increasing our coding throughput by another 5× solves the easiest part of the business.

Before building much infrastructure, ask one practical question: are we repeatedly waiting for agents to finish similar work?

If the answer is yes, some factory investment is probably justified. If we mostly wait for ourselves to decide what to ask the agents to do, a bigger swarm will have little to work on.

What is the smallest software factory worth building today?

The best personal software factory today is probably one strong coding agent surrounded by good context and verification, with extra agents added only where parallelism clearly saves time.

First, make the repository extremely easy for an agent to work in. Setup should be reproducible. Architecture and conventions should be written down. Tests, types and linting should catch predictable mistakes. Frontend changes should generate something we can inspect visually. Production errors should be easy to feed back into the development queue.

Then we can add independent background work. One agent can build a feature while another fixes unrelated bugs. Another can review completed changes if that review demonstrably catches problems. CI can automatically return failed work to an agent. Routine maintenance can run on a schedule.

This already captures most of the useful factory effect without turning our development setup into another product we have to maintain.

Worth building around our product	Better left to coding platforms
Architecture and repository instructions	Generic agent spawning
Tests and custom evals	Worktree management
Product and design rules	Basic parallel execution
Reusable domain-specific skills	Generic scheduling
Deployment checks	Model API plumbing
Production feedback loops	A dashboard showing agents talking
Clear definitions of done	Elaborate artificial employee hierarchies

So, should you build a software factory?

Mostly no: we should build a lightweight factory around our actual development work, but most individual builders should avoid spending weeks creating an elaborate autonomous multi-agent company.

The software-factory trend itself is real. Currently, agents already write and review large amounts of production code, operate in the background and complete projects that would have sounded unrealistic very recently. The direction here is difficult to dispute.

The mistake is assuming that the people who benefit from software factories must build all of the factory infrastructure themselves.

Multi-agent benchmarks show that coordination can wipe out the advantage of adding more workers. Real factory experiments show that specifications and verification still determine the quality ceiling. Production deployments show that humans continue to control the highest-level decisions. Meanwhile, Codex, Cursor, Claude Code and other platforms are rapidly packaging parallelism, long-running execution and orchestration into standard product features.

Build the parts that become more valuable with every project: better tests, better context, clearer product rules, reusable skills, stronger design references and feedback from production. Everything else should earn its way into the system.

When one agent becomes a bottleneck, add another. When review becomes the bottleneck, improve automated checks. When the same task keeps appearing, turn it into a repeatable workflow. When agents repeatedly make the same mistake, encode the lesson into the repository.

That path can eventually produce a genuine software factory, but we arrive there by removing real bottlenecks one at a time.

For most indie hackers today, the winning setup is likely much simpler than the multi-agent diagrams circulating online: excellent context, excellent verification, one powerful primary agent and a few disposable workers whenever the task genuinely splits into parallel pieces.