# What a software factory is and how we run ours My take on what a software factory is, why it runs on cloud agents, and how we run ours at Replicas: automations that open PRs on their own, proof instead of diff reviews, and agents in CI. - Author: Saai Arora - Published: 2026-10-22 - Category: Best practices - Canonical: https://replicas.dev/blog/how-we-run-our-software-factory My company Replicas, is a cloud coding agent, and I frequently get asked what our internal factory looks like, what the best practices are, and how we ship fast. There's a lot we do internally, but the term software factory is still a bit of a black box; everyone I talk to has their own definition and even the companies that built one do it in different ways. So this write-up is my take on what a software factory is and how we run ours - and hopefully I can help you build yours. Before I start, a disclaimer. Replicas is a product that helps you build your factory, and while I'd love for everyone reading this to use it, you don't have to. There are other great tools out there, most notably Devin, Cursor Cloud, Capy, and more, and they've all put a lot of time and effort into making their products great. Each one comes with tradeoffs, so evaluate them against what your team cares about. ## What is a software factory I define a software factory as the system a team uses to ship as fast as possible without breaking things. To do that you need agents that can one-shot changes, have a way to verify a change works without reading the diff, and set up agents that are proactive enough to start PRs on their own without anyone asking. The first one is the easiest part today since frontier models are really good once they can see your logs, traces, database, and remember what your team has taught them. We do that with [learnings](https://docs.replicas.dev/features/learnings), which are the corrections someone tells an agent to remember for the whole team. The other two take a good setup, and that starts with a cloud coding agent platform. ## Why cloud agents Running agents locally in worktrees is very limiting, since you can't run more than a few at once, every agent shares the same memory, CPU, and ports, and nothing keeps running once you close your laptop. A software factory can't run like that. Once the agent has its own computer in the cloud, you can start work from Slack, Linear, GitHub, or your phone and run as many tasks as you need, and anyone on the team can open a workspace to see what the agent did or pick up where it left off. This makes engineering a multiplayer experience. It's also what makes proactive work possible, since a cloud agent can pick up an incident at 2am and open a PR with the fix, which a local setup can't do. ## Start automating repetitive tasks Once everyone has access to a cloud agent, start setting up [automations](https://docs.replicas.dev/features/automations) for any repetitive tasks. We have a #triage channel where anyone can drop a bug, and an agent turns each one into a Linear ticket and assigns it round robin across the team so nobody has to decide whose bug it is. When a bug lands in Linear or an incident fires, an agent picks it up, investigates, and opens a PR with the fix. We also run agents on crons for things like daily Postgres query optimizations, Linear cleanup, weekly changelog, stale PR cleanup and code simplification audit. Automations don't have to be about code either. An agent runs our lightfield CRM, and every morning it asks my cofounder or me in Slack for the follow-ups. ## Stop reviewing PRs and babysitting them Once agents are opening most of your PRs, code review becomes the bottleneck, and nobody on our team reads every diff anymore. What we look at instead is the proof the agent sends with each change, usually a video or screenshots on the PR and in Slack, and most of the time that's how we decide whether something was built right. This only works if the agent can access services your product depends on, the same way an engineer on your team would. For a web app, that means the app, the database, and anything else it talks to, plus a browser the agent can drive and record. We also have a mobile app, so our agents get [iOS and Android simulators](https://docs.replicas.dev/features/mobile-testing) through an integration with [Limrun](https://limrun.com), and some of our experiments requires GPUs, which Replicas agents can [access from within the sandbox](https://docs.replicas.dev/features/gpu-sandboxes). We put agents inside CI too, every commit runs agent checks like no unused code, DRY, and no unnecessary comments. When one of those checks fails or [Greptile](https://www.greptile.com) review leaves a comment, an autofix agent picks it up in the same workspace with full context, pushes the fix, and replies to the bot without cluttering the main agent conversation. By the time we open the PR, CI is green and the bot comments are already handled. ## Get the whole team in The value of cloud agents scales directly with how much your team buys in. Everyone contributes context and tooling, automations, learnings to the agent, so the more of the team that's bought in, the faster the whole factory gets. Here's what our factory looks like end to end. It’s a bunch of pieces that we’ve already built into replicas, none of them are hard to set up and can be added over time: Our software factory: you or an automation start a task for an agent in a sandbox that uses logs, traces, and learnings, verifies with video, and opens a PR that autofixes CI. You watch and merge, and it learns from your corrections.