How to Build Your Own Software Factory

A guide on building a "software factory" — a fleet of coding agents that take work from tickets, chat and schedules, each writing code in its own sandbox and sending pull requests through review — cites Stripe merging over 1,300 agent-written pull requests a week, Ramp's agent Inspect writing about 30% of merged pull requests in its frontend and backend repos, and Shopify's River coauthoring one in eight merged pull requests. The guide, which draws on Addy Osmani's "harnessing loops at scale" framing, lists the shared components teams report: a pre-warmed machine per task (Stripe's devboxes ready in about 10 seconds, Ramp sessions starting from a repo snapshot rebuilt every 30 minutes), scoped Git credentials, an AGENTS.md, and capped CI retries — Stripe allows two rounds before a person takes over. It also reports that Omnara's general agent loop matched Claude Code and Codex pass rates on Terminal-Bench 4.0, ran 12% faster than Claude Code and 11% cheaper than Codex, and scored 69.6% with Claude Opus 5.5, the top score, with every trace and the harness public.

All guides https://www.omnara.com/guides How to Build Your Own Software Factory Sandboxes, Git, loops, and review for a fleet of coding agents On this page A software factory is a fleet of agents that take work from tickets, chat, and schedules. Each agent writes code in its own sandbox and sends pull requests through review into production. Addy Osmani calls it "harnessing loops at scale" https://addyosmani.com/blog/software-factories/ . Companies that built their own now get a large share of their merged pull requests from agents. Stripe merges over 1,300 agent-written pull requests a week https://stripe.dev/blog/minions-stripes-one-shot-end-to-end-coding-agents-part-2 . Ramp says its agent, Inspect, writes about 30% of merged pull requests https://builders.ramp.com/post/why-we-built-our-background-agent in its frontend and backend repos. At Shopify, River coauthors one in eight https://shopify.engineering/under-the-river merged pull requests. Devin and Factory sell products built on the same idea, and Factory calls its product "Software Factory" https://factory.com/product/software-factory . The Short Version What a Software Factory Needs Every team that has written up its build lists the same parts: - A machine per task. Each agent gets an isolated VM or container with the repo cloned, dependencies installed, and the services its tests need. Stripe keeps a pool of pre-warmed devboxes that are ready in about 10 seconds https://stripe.dev/blog/minions-stripes-one-shot-end-to-end-coding-agents-part-2 . New Ramp sessions start from a snapshot of the repo that's rebuilt every 30 minutes. - Work that fits. Tasks with a clear check, small enough for one pull request. Someone triages the queue and splits or rejects the rest. - A repo agents can work in. A build that runs the same way every time, fast targeted tests, seed data for integration tests, and an AGENTS.md with the commands that matter. - Git access. Credentials scoped to the repos a task needs, and fixed steps for linting, pushing, and opening pull requests. Stripe's "blueprints" run those steps as code instead of leaving them to the model. - A way in. Slack, Discord, pull request comments, tickets, and schedules. - Sessions that outlive their sandbox. Sandboxes crash, time out, and get replaced. As Shopify's team wrote, "Cells die, sandboxes die, machines die. The conversation doesn't." https://shopify.engineering/under-the-river - Checks before a pull request exists, and review after. The agent runs tests and linters itself. CI retries have a cap, and Stripe allows two rounds before a person takes over. Review rules match the risk of the change. - Limits. Untrusted input, scoped secrets, network rules, and budgets, covered below security-and-spending . There's No Such Thing as a Coding Agent A coding agent is a general agent loop with a shell, file access, and a machine that has the repo on it. Claude Code and Codex are general agents pointed at code. Each team that built its own picked a different agent. Stripe runs a fork of goose, and Ramp built Inspect on OpenCode. Spotify's Honk mostly runs Claude Code. What these teams wrote about most was the machines, repo setup, tools, and review around the loop. The same agent that writes a fix can review a pull request, answer a question in Slack, or investigate an alert. Omnara building-it-on-omnara runs one general agent loop for all of it. On Terminal-Bench 4.0, Omnara matched the pass rates of Claude Code and Codex on the same models. It ran 12% faster than Claude Code and 11% cheaper than Codex. Its 69.6% with Claude Opus 5.5 is the top score. Terminal-Bench's own runner graded every run. Every trace https://terminal-bench.omnara.com/ and the harness https://github.com/omnara-ai/omnara-terminal-bench are public, so you can rerun it yourself. Git Doesn't Need to Change Agents should work the way engineers already do, with a branch per task, a pull request, review, and a merge queue. Git already handles agents the way it handles large engineering teams. GitHub says more than 40% of new pull requests started as an agent's draft https://github.blog/news-insights/octoverse/octoverse-commits-pushes-reach-new-highs-in-2026-as-developers-build-with-agents/ by September 2026. Anthropic built its own source control server after its daily merges grew from about 2,500 to over 30,000. Even so, Anthropic wrote that its server "is by no means a suitable replacement for git for general use." https://www.anthropic.com/engineering/redesigning-source-control The bottlenecks are CI and review. Anthropic's CI job volume grew 25x in six months https://claude.com/resources/articles/agentic-coding-is-straining-ci-heres-how-we-scaled-test-impact-analysis-at-anthropic . Teams that use AI heavily merge 98% more pull requests, and their review time rises 91% https://www.faros.ai/blog/ai-software-engineering . Spend the effort on test selection, a merge queue that serializes conflicting changes, and review rules, not on a new version control system. Review by Risk Split the codebase into tiers and route agent pull requests by what they touch, the way Anthropic tiers its codebase by risk https://claude.com/resources/articles/how-anthropic-secures-its-ai-native-software-development-lifecycle . - Low risk: docs, tests, and config with no runtime effect. A reviewer agent and a quick human look, or auto-merge when checks pass. - High risk: auth, payments, database migrations, infrastructure, CI config, and new dependencies. Approval from the owning team, every time. GitHub supports this with CODEOWNERS and the rulesets required reviewer rule https://github.blog/changelog/2026-02-17-required-reviewer-rule-is-now-generally-available/ , which can require, for example, two security-team approvals for changes to auth files. In every tier, an agent never approves or merges its own pull request. Ramp opens each pull request with the requester's own GitHub token, so the person who asked for a change can't approve it. Measure the whole factory by cost per merged pull request, revert rate, and reviewer time, not by how many pull requests it opens. Loops: Agents on a Schedule A loop is an agent that repeats a narrow job on a schedule or an event until a stop condition is met. The idea started with Geoffrey Huntley's "Ralph" https://ghuntley.com/ralph/ , a Bash loop that feeds an agent one task at a time. The term now covers any scheduled agent that opens pull requests on its own. In one GitHub experiment, a loop wrote more than 1,400 tests over 45 days for about $80 https://github.blog/ai-and-ml/generative-ai/continuous-ai-in-practice-what-developers-can-automate-today-with-agentic-ci/ in tokens and opened them in small daily pull requests. Give each loop one part of the codebase and one job with a clear check: - A security loop reviews services/auth/ every night. It opens one draft pull request per confirmed finding, with a failing test that proves it. When a fix needs a design decision, it files an issue instead. - An integrations loop calls each external API you depend on every morning and compares the responses with your recorded fixtures. When a response changes, it opens a fix. - The same pattern covers flaky tests, dependency upgrades one package at a time, and docs that drift from the code. The practices that keep loops useful come from GitHub's agentic workflow playbooks https://github.com/github/gh-aw/blob/main/.github/aw/maintainer.md . Handle one item per run, with one small draft pull request per item. Skip the run when too many of the loop's own pull requests are still open. Label everything the loop creates so it can find its own work. When CI fails the same way twice, stop retrying. Pair each loop that writes code with an agent that checks it in a fresh context, as Anthropic's guide to loops https://claude.com/resources/articles/getting-started-with-loops recommends. Give a loop more autonomy only while its merge rate holds up and its reverts stay rare. Interfaces and Multiplayer Slack is the most common way in. Stripe engineers tag their agent in a Slack thread, and their flaky-test tickets have a button that hands the fix to an agent. Pull request comments, a CLI, and an API for your own tools cover the rest. Shopify's River only works in public channels https://shopify.engineering/under-the-river , so anyone can watch a session and join it. Ramp lets several people work in one session and attributes each prompt to its author. Security and Spending Treat tickets, pull request comments, issues, and dependencies as untrusted input, since any of them can carry instructions aimed at the agent. Keep production data and broad credentials out of sandboxes, and limit network egress where you can. Stripe's agents run without access to real user data, production services, or arbitrary network egress https://stripe.dev/blog/minions-stripes-one-shot-end-to-end-coding-agents-part-2 . That isolation is what lets them run without permission prompts. Loops run while nobody is watching, so give them a cap on concurrent machines, a token budget per loop, and a way to pause one that misbehaves. Building It on Omnara Omnara is an open-source managed agent platform that runs any model. It handles the machines, Git access, ways in, durable sessions, and limits from the list above. Its integrations are built in, so there's no Slack bot or webhook server to write. Start from the Slack coding agent example https://docs.omnara.com/examples/slack-coding-agent and give its setup prompt to Claude Code, Codex, or Cursor. That tool walks you through setup, then creates the agent in your project and connects it to Slack. After that, mention the agent in Slack, Discord, or on a pull request. It makes a focused fix in a fresh clone of your repo and opens or updates a pull request. - Machines. The agent loop runs in Omnara's control plane. Agents run commands on sandboxes from providers like E2B, Daytona, and Modal https://docs.omnara.com/machines/providers/overview , or on your own computers through an outbound-only daemon. An agent can use several machines at once. Omnara Cloud's default machines come with Git, the GitHub CLI, Postgres, Redis, and Playwright https://docs.omnara.com/machines/pools default-machine-environment , and a startup script clones the repo. Files, dependencies, and running processes persist across turns https://docs.omnara.com/machines/pools what-persists , and idle machines sleep on providers that support it. For a faster start, bake the clone and install into the provider's image or snapshot, then rebuild it on a schedule as Ramp does. - Git. Connect your own GitHub App https://docs.omnara.com/integrations/github to start agents when a pull request opens or someone mentions the bot. Agents get Git credentials https://docs.omnara.com/integrations/github git-credentials scoped to the repos you choose, read-only unless you allow pushes. They open pull requests with gh and a fine-grained token from secrets https://docs.omnara.com/organization/secrets . Omnara's review tools post comments, never approvals, so your GitHub rules decide what merges. - Loops. Cron triggers https://docs.omnara.com/api-reference/endpoints/configs-and-profiles/create-cron-trigger launch a new agent from a profile on a schedule or send a message to an agent that's already running. They can also open a new Slack or Discord thread https://docs.omnara.com/integrations/overview start-a-new-thread-on-a-schedule each time so the team sees the results. Memory stores https://docs.omnara.com/agents/configuration memory-stores give a loop shared notes on what it already checked. - Multiplayer. Agents live in Slack https://docs.omnara.com/integrations/slack and Discord threads, where anyone in the thread can correct a running agent and answer its questions and approvals https://docs.omnara.com/integrations/overview route-questions-and-approvals without an Omnara account. Each message is attributed to the person who sent it. Put factory agents in channels where everyone can be trusted to steer them. Your own tools can use the API, the TypeScript SDK, or the CLI. Claude Code, Codex, and Cursor can launch agents through Omnara's MCP server https://docs.omnara.com/api/authentication connecting-mcp-clients . - Durability. The conversation lives in Postgres, not on the machine, so if a worker crashes, another continues the agent from its last saved step. A tool call cut off by a worker crash isn't rerun. A command keeps running on its machine. A call to an outside service comes back to the agent marked as interrupted, so the agent can check before trying again failure handling https://docs.omnara.com/agents/failure-handling . If a sandbox dies, the agent keeps its full history and can continue on a new machine. Pushed work survives but unpushed changes don't, so have agents push early. - Security and spending. MCP credentials stay on Omnara's workers and never reach the machine. Each tool can run immediately, require approval, or be blocked https://docs.omnara.com/tools/permissions . For network limits, use a sandbox provider with egress rules. Every pool has a required cap on total machines, and the API reports token usage and model cost per agent. Disabling a loop's cron trigger pauses it. Subagents can run on different models, such as a cheap one for triage and a strong one for the fix. Self-Host It or Use Omnara Cloud Self-hosted, the whole software factory runs on your infrastructure. The API, workers, and agent history https://docs.omnara.com/self-hosting/architecture use your own Postgres, Redis, and object storage. Agents run commands in sandboxes on your own provider accounts or on your own machines. If code can't leave your network, use models you host https://docs.omnara.com/organization/model-providers through vLLM or Ollama. Self-hosting is free under Apache 2.0, and Omnara's team can also deploy and manage it in your own cloud BYOC or on premises. To set that up, book a call with the founders https://cal.com/ishaan-sehgal-8kc22w/chat-with-omnara . Omnara Cloud https://www.omnara.com/pricing runs the same open-source platform and operates the workers, database, and machines for you. There's no platform fee, and your own model keys and machines cost nothing. Models cost the provider's token rates. A 4 GiB machine costs about $0.17 an hour while it runs, plus a small storage charge. That's about the same as a comparable sandbox from E2B or Daytona. Models and machines are paid with credits that carry a 5% service fee covering provider costs. That makes Omnara the cheapest of the options here, since Devin and Factory add per-seat plans on top of usage. Building your own adds the engineers who maintain the orchestration. Devin, Factory, and the Labs' Cloud Agents Devin gives each session its own machine https://docs.devin.ai/enterprise/deployment/overview and takes work from Slack, Linear, Jira, GitHub, and an API. Factory runs its Droids from a CLI, Slack, Linear, and CI. Its automations https://docs.factory.com/automations/overview start from cron schedules, Slack, GitHub, and webhooks. Both fit a team that wants a finished product and is fine with the vendor running the agent loop. Devin's https://devin.ai/pricing team plan is $80 a month plus $40 per full seat, and Factory's https://factory.com/pricing is $60 a month plus $40 per seat. Neither is open source. Devin's Outposts run sessions on your machines while the agent loop stays in Devin's cloud https://docs.devin.ai/cloud/outposts/overview . Factory's on-premises deployments are part of its enterprise plans. GitHub Copilot's cloud agent, Codex cloud, Claude Code on the web https://code.claude.com/docs/en/claude-code-on-the-web , and Cursor's cloud agents also turn a task into a pull request. Each is a hosted product billed through a subscription or credits. The Codex and Claude Code versions run their own lab's models. They fit teams already standardized on one of those vendors and fine with that vendor running the agent loop. For a software factory you own, choose Omnara. It runs any model, has no platform or seat fees, and can run entirely on your own infrastructure. FAQ What is a software factory? A software factory is a fleet of AI agents that take work from tickets, chat, and schedules. The agents write code in isolated sandboxes and open pull requests that go through review into production. People set direction and review the riskiest changes, while agents do most of the implementation. Older uses of the term, like the U.S. Department of Defense's software factories, describe DevSecOps pipelines rather than agents. How much does it cost to run a software factory? The main costs are tokens, compute, and the review time the factory creates. Measure cost per merged pull request, not per run. Seat-priced products add a monthly fee per engineer, while Omnara has no seat fees and is free with your own keys and machines. Credits for Omnara-managed models and machines carry a 5% service fee covering provider costs. Can I self-host a software factory? Yes. Omnara is open source under Apache 2.0, and everything from the agent loop to each agent's history can run on your own servers with models you host. Devin keeps its agent loop in Cognition's cloud, and Factory's on-premises deployments are part of its enterprise plans. What should a software factory's first loop do? Start with one narrow job that has a clear check, like fixing the flakiest test each night or upgrading one dependency at a time. Have it open small draft pull requests that a person reviews. Add loops as each one earns trust.