Software Factories in September 2026

by

In August, LaunchDarkly, Cloudflare, Vercel, and Uber each published a detailed account of a software factory they built. Let’s see how software factories work today and where the approach may lead.

A personal note

It’s been twelve years since my last post!

My most popular posts have always been related to whatever I was working on at the time: processor caches, branch prediction, skip lists, and Reed–Solomon coding. Today, I’m writing about software factories, a topic close to my current work.

1. Teams are building software factories

The “we built a software factory” posts keep coming, with four landing in the month of August:

With various teams reporting results from software factories, it’s time to ask: what are software factories, how do they differ from cloud agents, and do they work? Let’s look at the published examples.

2. What is a software factory?

The definition of a software factory is emerging:

A software factory starts work from events and coordinates agents through structured engineering workflows. Agents read and write artifacts such as specs, issues, and pull requests, while people approve key decisions.

For example, a software factory could take a bug report through reproduction, diagnosis, verification, and a proposed fix.

From coding agents to software factories

A software factory builds on coding agents and cloud agents:

  • Coding agent: An agent harness that uses a model and tools to complete a task.
  • Cloud agent: A coding agent running on managed remote compute.
  • Software factory: A system of coordinated agents running structured engineering workflows.

3. Software factories in practice

Factories described by Cloudflare, Vercel, and Uber are interesting examples to examine more closely.

Astro / Cloudflare: resolving bug reports

Astro’s factory is focused on a single workflow: resolving incoming bug reports. According to Cloudflare, issue triage was chosen as the first use case because it was a painful, time-consuming, unrewarding part of the project. A report could take hours just to reproduce.

The factory reproduces and diagnoses the problem, decides whether it is really a bug, prepares a fix, and publishes a preview for the reporter to check. It runs on GitHub Actions:

  1. Start: Opening or reopening an issue adds a needs triage label. A new comment with useful information can also restart a stopped attempt.
  2. Reproduce: The label starts the triage run. The stages run sequentially in a GitHub Actions workspace. The reproduction agent writes the result to report.md in a triage directory. If it cannot reproduce the bug, the issue is marked as needing more information.
  3. Diagnose and verify: Once the issue has been reproduced, separate agents read report.md and append the root cause and further analysis.
  4. Fix: Now that the bug is verified, a fixing agent starts and adds tests and a code change, pushes a branch, publishes a preview, and marks the issue as fix pending.
  5. Confirm: Finally, the reporter can accept the fix to create a pull request, provide more details, or reject the fix to mark the issue as fix rejected.

Cloudflare reports that the number of open issues in Astro’s GitHub repository fell from more than 200 to about 30.

💡 Astro’s details are public. The orchestration code and agent instructions are public, so we can see the label-based state machine and the reports passed between agents.

The system was also covered by The New Stack and InfoQ.

Vercel: a factory for one open-source project

Vercel built a factory to develop and maintain one project: its open-source AI SDK. The repository receives more than 100 new issues a month, so it is reasonably active. By late June, it had more than 1,000 open issues and almost 800 pull requests.

The factory classifies issues, reproduces and fixes bugs, analyzes and implements features, updates documentation, reviews PRs, and backports changes to older releases. GitHub webhooks start the work, specialized agents run in isolated sandboxes, and a dashboard displays the queue. Humans review and merge every change.

Vercel illustrates the process with a request to add blocked-domain support to OpenAI web search. The factory classified the request, wrote a specification, implemented and tested the feature, and opened a PR. A review agent assessed the risks before a maintainer reviewed and merged it. That merge opened two backport PRs. When one hit a conflict, an agent repaired it and updated the PR seventeen minutes later.

After four weeks, Vercel reported that the factory created 25-35% of merged PRs and closed more than 75% of the issues closed in July.

Uber: a company-wide platform for software factories

Among the published examples, Uber has gone furthest in building a company-wide platform for software factories. In its published account, Uber describes shared infrastructure that teams use for managed agents across the software lifecycle.

Teams have built workflows for CI repair, code review, bug investigation, on-call alert triage, feature implementation with visual checks, and maintenance. More and more of these sessions are started by workflows rather than people.

A demo shared by Uber takes an idea from a Slack message through planning, coordinated PRs, automated checks, and human review.

4. Software factory graph

A software factory can be modeled as a graph:

  • Nodes. Artifacts such as requirements, issues, pull requests, alerts, support tickets, etc. Agents, humans and deterministic systems read and write the artifacts.
  • Edges. Agent-driven processes that transform one artifact into another. Agents do the work, while human approvals (e.g., PR merge) and automated checks (e.g., CI) control when work advances.

Consider this graph of a rudimentary software factory:

Agents work along the edges, reading artifacts from one node and producing artifacts for the next. For example, planning agents turn requirements into tickets, coding agents turn tickets into pull requests, and review agents prepare pull requests for merge.

Public examples as graphs

Let’s look at representative paths through the publicly known software factory graphs.

  • Astro / Cloudflare: Issue → reproduce and diagnose → report.md → fix → fix branch and preview → reporter confirms → PR
  • Vercel: Issue → classify and specify → specification → implement and test → PR and evidence → review → risk assessment → human merge → backport PRs
  • Uber: Slack message → research and plan → requirements and designs → implement → draft PRs → validate → evidence → human review. CI failures and alerts start repair and triage workflows.
  • LaunchDarkly: PR → review and risk checks → feature-flagged change → guarded release → production measurements → correct or clean up → follow-up change
  • Augment Cosmos: Goal → plan → plan and tickets → implement → PRs → review and verify → evidence → human decision. Alerts start investigation and remediation workflows.
  • WorkOS: Requirements → decompose → issues → human review → implement → PR → human merge → next unblocked issue
  • Ona: Human specification → plan → issues and plans → implement and review → PRs → merge and smoke test → production errors or feedback → replan

These examples show the variety of software factory graphs already in use. They start from different events, connect different artifacts, and stop at different human approvals.

💡 Agents can help changes (e.g., pull requests) get merged.

Coding agents can generate a lot of code. Often, the problem is how to build confidence in the code and get it merged.

From personal experience, a meaningful threshold of software factory adoption is when you can hand off draft PRs to a software factory and have agents handle much of review, verification, fixing, addressing feedback, and so on, only asking for input on the most judgement calls.

5. Where do software factories work best?

Software factories work best when a standardized process makes agents more autonomous. That is a familiar engineering question: how much process is the right amount?

Process is worth it: production alerts. A factory can collect logs, trace the problem to a recent change, open a rollback PR, wait for approval, deploy it, and watch for recovery.

Process is not worth it: brainstorming a new feature. You don’t yet know what you are building, so forcing the work through fixed roles and stages just adds unnecessary friction. An engineer working freely with an agent works better.

Teams that adopt software factories see work split into two types. Some work is free-form: designing a novel feature, deciding what the product should do, or choosing between two architecture options. That work stays interactive, with an engineer and an agent in a loop. Other work fits an existing pattern: adding another payment provider, the same migration across forty services, or the CRUD endpoint that looks like the last twenty. That work goes to a factory.

6. What types of teams find success with software factories?

Much of this post is based on public examples and data. For this section, I’ll go by personal experience, because publicly referenceable information on software factories is still scarce.

I’ll start with one characteristic that doesn’t seem to correlate with success: team size. I’ve seen software factories work at a wide range of team sizes:

  • Single-person projects. A single-person project can run on a software factory, resulting in a self-building web app or service that improves itself based on user feedback, metrics, reported issues, and so on. Every change still needs human approval, but the setup can work. The maintainer reviews PRs already annotated with screenshots, risk analysis, key decisions, and other evidence produced by the factory.
  • Large engineering organizations. A company like Uber can use software factories to automate well-established processes like alert triage and feature development.

So what team characteristics matter most when it comes to success with software factories?

  • Heavy agent use. A team ready for a software factory is already using agents a lot. Their agents can work in the codebase, build it, access logs, run end-to-end tests, post to Slack, and so on. The team already has the MCP servers, skills, credentials, and all that stuff set up.
  • A preference for structure. Some teams invest in developer experience, process, and structure, while others work in a much more free-form way. Software factories fit more naturally within teams that already value structure and processes.
  • Someone to make it happen. Introducing a software factory changes both technology and how people work. Someone needs to take the initiative, build it, and help the team adopt it.

7. Will agents eventually be prompting us?

When you look at software factory examples, you can spot a deeper promise: an inversion of control. Instead of a human prompting an agent through each step, the system starts the work and asks for context, approval, or judgment only when it needs them. A human still provides input and approval, but agents drive the work forward.

Today, most engineering work starts with a human taking initiative. But the set of tasks a software factory can drive on its own is growing: adding a small UX feature, triaging a routine alert, fixing a CI failure.

As the trend continues, agents may end up prompting us more often than we prompt them! And yes, to an engineer working with agents today, that may sound disconnected from today’s reality, given how much effort it takes to get agents to build something substantial. But keep two things in mind. First, AI advances fast. Second, responding to agent prompts may turn out to take more mental effort than prompting agents ourselves, as anyone who does a lot of code reviews can imagine.

So “agents prompting us” won’t necessarily mean “building software is easy.”

Could software factories NOT be the future?

It is interesting to think through the negative: if software factories fail to become the next paradigm, why did it happen? I see two ways how this could happen:

  • Software factories plateau before reaching a critical mass of use cases. It is possible that software factories never get past addressing routine alerts and implementing simple tickets.
  • Software factories get disrupted by another paradigm. It is also possible that something else arrives that makes software factories obsolete. For example, if we get a “synthetic engineer” AI that can join an engineering team, read the documentation, proactively ask questions and start working, a software factory may no longer be necessary.

I think the evidence is emerging that software factories make agents more autonomous and improve productivity even today. With models and software factory methods continuing to improve, it seems like a safe bet that software factories will become more autonomous. But, the risk of disruption by another paradigm is real and hard to quantify.

All that said, based on the technology available today, software factories show promise as a way to orchestrate agents through a defined software development process.

Conclusion

Software factories are becoming real, with Cloudflare, Vercel, and Uber all describing their software factories within the past month. The premise is to embed agents into the software development process so they can respond to events, create artifacts, and interact with humans.

The technology is still early, but the available evidence suggests that agents become more autonomous when organized into a software factory. Interesting times ahead.

1 thought on “Software Factories in September 2026”

Leave a Comment