All posts
What is a multiplayer software factory?
Most software factories are built for one engineer at a time. A multiplayer software factory lets the whole product team start, shape and review agent work on the real codebase.
Ben Ong
October 25, 2026
ai-agents
product-development
PM, Design and Ops cards on a light orange background feeding into a Shared plan, then Preview, then Merge with a check mark
A multiplayer software factory is a software factory the whole product team runs together. PMs, designers, ops and engineers share the same agents, plans and previews on the team's real codebase, and every change still ships through engineering's pull request review.
Most software factories today are single-player. One engineer feeds tickets to agents and reads the pull requests that come back. A multiplayer factory lets the people closest to customers start and shape the work too, so the factory builds the right changes as well as more of them.
What is a software factory?
A software factory is a pipeline that turns requests into shipped code with coding agents doing most of the implementation. Work comes in as a Slack message, an issue or a ticket. An agent picks it up, works in an isolated environment, runs the checks, and opens a pull request for review.
Some teams already run one at scale. Stripe's Minions produce over 1,300 merged pull requests a week that contain no human-written code, and every one is reviewed by a human. StrongDM went further with a "lights off" software factory whose two rules are "Code must not be written by humans" and "Code must not be reviewed by humans."
Most teams sit closer to Stripe than StrongDM. Agents write the code, and people decide what ships. Our guide to what a software factory is covers the history and how the parts fit together.
Why most software factories are single-player
Software factories are usually built by engineers, for engineers. The agent is triggered from a terminal, a CLI, or an engineer's command in Slack. The input is a ticket someone already wrote. The output is a diff, which only an engineer can judge.
Product people sit at the edges. A PM files the request at the start and sees the result at the end. A designer finds the missing empty state after the code is written. Ops learns about the change when it ships.
That design made sense when engineering capacity was the constraint. Stripe's own write-up says "one of our most constrained resources is developer attention." A single-player factory spends that attention well. But once agents can build a change in an afternoon, the slow part moves to deciding what the change should be, and that knowledge mostly lives outside engineering. We cover that shift in The software factory needs to become a product factory.
What makes a software factory multiplayer
Five traits separate a multiplayer software factory from a single-player one:
- Anyone on the product team can start work. A PM, designer or ops lead describes the change in plain language, from the tools they already use, such as Slack, Linear or Jira.
- The plan is shared before any code is written. The agent reads the codebase and turns the request into a plan the whole team can see and edit, so gaps get caught while they're cheap.
- People work in the same session. A PM, a designer and an engineer can shape the same change together instead of passing it through a ticket.
- Every change gets a live preview. Each change runs in an isolated sandbox on the real product, so reviewers click through working behavior instead of reading a description.
- Engineering keeps the merge. Roles decide who can propose and who can approve. The pull request goes through the team's existing CI, required reviews and branch protection.
None of these remove engineers. They change where engineers spend their attention, from translating requests into code to reviewing changes that arrive with a clear plan and a working preview. We wrote about that team shape in Multiplayer Collaboration Is the Future of Development.
Single-player vs multiplayer software factory
| Single-player factory | Multiplayer factory | |
|---|---|---|
| Who starts work | Engineers, or tickets engineers refined | Anyone on the product team |
| Where the plan lives | In a ticket or the agent's context | A shared plan the team reviews before code |
| Who checks the result | An engineer reads the diff | Product people test the preview, engineers review the code |
| What it optimizes | Pull requests merged per engineer | The right changes shipped per team |
Lights on, with more people at the switch
The debate around software factories is often framed as lights on vs lights off: does a human review the code or not? A multiplayer software factory is lights on by design, and it adds people where their judgment matters most.
Product people check behavior, because they know what the customer needed. Engineers check the code, because they own the architecture and the risk. Agents do the implementation in between. In a LinearB discussion on software factories, the better goal is described as visibility rather than removing humans, "having night vision" while the factory runs.
How LightSprint runs a multiplayer software factory
LightSprint is built as a multiplayer software factory on your team's existing codebase. Here's the flow:
- Connect your repo. LightSprint works from the GitHub repository your team already ships from.
- Start from anywhere. Anyone on the team describes the outcome they want in LightSprint, or creates the task from Slack, Linear or Jira, with updates synced both ways.
- Plan together. LightSprint reads the codebase and turns the request into a visual plan. PMs, designers and engineers review it in a shared session before any code changes.
- Pick the agent. Run the change with Claude, Codex, a cloud agent, or your approved model gateway, including your own subscription.
- Review the live preview. Each change runs in an isolated sandbox, so the team clicks through working behavior before anything merges.
- Merge through your existing approvals. A Builder can propose changes and view previews but can't merge. An Approver, typically an engineer or lead, reviews and merges through your current CI and review rules.
You can also connect tools over MCP and ask LightSprint what to build next. More detail on guardrails is on our engineering page and security page.
How to start running one
You don't need to rebuild your pipeline to make it multiplayer. Start small:
- Pick one workflow where product people wait on engineering. Copy changes, UI fixes, onboarding tweaks and internal tools are common starting points.
- Give two or three product people Builder access. Keep engineers as Approvers.
- Require a shared plan and a preview for every change. This is what makes review fast.
- Track time from request to merged pull request. Compare it with the same kind of change done through tickets.
For a stage-by-stage view of where your team is today, see The 5 Stages of AI Nativeness.
FAQ
What is a multiplayer software factory?
It's a software factory that the whole product team runs together. PMs, designers, ops and engineers share agents, plans and live previews on the real codebase, and engineering approves every merge.
How is it different from a regular software factory?
A regular software factory is usually operated by engineers, who feed it tickets and review the pull requests. A multiplayer software factory lets non-engineers start and shape work, adds a shared plan before code, and gives every change a live preview the whole team can check.
Do non-engineers merge code in a multiplayer software factory?
No. In LightSprint, Builders propose changes and view previews but can't merge. Approvers, typically engineers or leads, review and merge through the team's existing approval rules.
Is a multiplayer software factory the same as a dark factory?
No. A dark or "lights off" factory removes human code review. A multiplayer software factory keeps humans in the loop and adds more of them: product people check behavior and engineers check code.
Can I run a multiplayer software factory on my existing codebase?
Yes. LightSprint works on the GitHub repository your team already ships from, and changes go through your existing pull request review. See how this compares to Lovable on an existing codebase.