Tactics for rolling out software factories: human and organizational changes

In this post I’ll give some concrete tactics on how to roll out software factories across an org. By “software factories” I mean agentic loops in the cloud that are measurable and improveable over time. I’m going to focus on human and org changes, not technical aspects of factory enablement here. For the tech underpinnings, I’ll assume you are using infra like a factory stack.

tl;dr

• The goal is not to get to full automation. It’s to ship the highest quality software with the most customer impact as quickly and as efficiently as possible.
• Start with simple, low-risk factory automations: the tasks engineers view as chores.
• Make direct prompting through the factory as easy as tagging an agent in the tools engineers already use.
• Position the factory not as a “product” but as an infra platform where everyone does “factory engineering.”
• Encourage but don’t require it, and celebrate shipped work - not token spend.
• Track adoption first (% of merged PRs through the factory), then throughput, cycle time, and cost per PR.

Start with the goal

Let’s start with the goal. It’s not to get to full automation. The goal is to get the most out of coding agents at your organization so that you are shipping the highest quality software with the most customer impact as quickly and efficiently as possible. You’ll want to prove that you are doing this by carefully measuring and tuning your factory. We call this “factory engineering.”

An important prerequisite: you can’t do factory engineering unless your team first does at least some of its product engineering through the factory as opposed to local coding agents. This means centralizing your agents into one shared configuration that the team can optimize together. Once work starts flowing through the factory infra, you’ll have a baseline to measure and improve.

Two strategies to get going

There are two strategies we’ve been using internally at Warp and with customers to get going. The first is to put in place simple factory automations. For example, Warp’s own factory automates fixing server crashes as they are reported by Sentry. It automatically triages new issues that we run into while dogfooding. It generates our weekly changelog and updates our public docs. For customers, we have set up similar automations for investigating production issues, triaging user feedback, and more.

These are all low-risk tasks that you can have an agent do on its own. If the agent gets it right, great. If not, you can either ignore the output or have a human fix it (and if you do fix it, that serves as an important input into the learning loop of factory engineering, which I’ll get to). The point is to start simple, get some tasks running, and help engineers get accustomed to factory infrastructure and interacting with factory agents. Picking tasks that engineers view as chores is a good strategy for showing value immediately.

By starting with automations, you aren’t asking engineers to change their daily habits much; one person can set up the automation for everyone and the whole team reaps some benefit. Ideally though, the whole team responds to the outputs of these automations, taking ownership of reviewing their PRs or generated issues. The key thing is to make sure that the automations have a good signal to noise ratio and that any outcomes of the automations have clear owners.

For this reason, I don’t recommend starting with a full loop of agents fixing your backlog or auto-fixing new issues. It’s too likely the agents will generate PRs that never get reviewed and that will turn the engineering team off from a factory approach (“this thing is just a slop cannon”). Start small and focus on tasks where the outputs are likely to be right from the outset. Have a team of factory champions responsible for setting these up, and don’t roll your factory out widely until that team has tuned the automations to reliably generate high quality work.

Strategy 2: make direct prompting through the factory easy

The second strategy is to make it as easy as possible to do direct prompting through the factory, rather than locally. At Warp we have made this transition – the majority of our direct prompting starts in Slack and is continued in the other cloud tools we rely on like Linear and Github. Our factory infrastructure allows this: you can start work in one tool and continue in another with the same context.

From working with customers we know that this is a big behavior change and needs a lot of thought in how to approach it. The important principle is meeting engineers where they already work. Introducing a new product surface or workflow for inputting factory work is going to be higher friction than allowing engineers to tag agents in the tools they are already using. We do not recommend building a new “factory web portal” as the primary place to work with a factory.

Instead, make the factory accessible from your comms platforms like Slack and Teams, issue trackers like Jira and Linear, and code forges like Github and Gitlab. Make working through the factory as easy as tagging an agent in one of these tools. Make sure this works reliably, quickly, and that all of the permissions and context that the agent needs to do its work are set up. Again, if developers try these flows and they don’t work, it quickly erodes confidence in the whole factory approach and makes folks reach for local tools.

Speaking of local tools, you also want the factory to integrate directly with local coding agents. If the eng team is using a mix of Claude Code, Codex, Pi, etc, they should be able to put work into the factory directly through them; that means that instead of their local prompt being sent to the local agent, it instead goes to a factory MCP that submits the work to the cloud loop.

Your factory should support work entering at any stage of the software lifecycle: right at the outset with a new ticket or idea, after a spec exists, or even after an engineer has drafted a local PR. Again, the goal is to make submitting work as easy as possible, so that more of it flows through the cloud infrastructure and you start to build a muscle around working in the factory, and a dataset that factory engineering can improve.

Position the factory as infra, not product

As part of setting up early automations and direct prompting, you should make sure that your team doesn’t hit dead ends when their factories break. Developers like to control their tools; they want to be able to understand and debug issues without blocking on someone else to help. If you approach your factory as infra that the whole team owns, that’s much more likely to appeal to most devs than approaching it as a piece of SaaS that only an admin can configure.

So position the factories not as a “product,” but as an infra platform upon which everyone is expected to do “factory engineering.” Factory engineering is work to make internal factories better. That means improving the skills, models, and context that drive engineering throughput. It means encouraging engineers to build automations for their chore work. It means giving them the tools to score and benchmark factory workflows, and empowering them to use agents to build self-improvement loops. It means that everyone owns lowering factory costs and improving factory ROI. If you use a platform like Warp Factories, all of this tooling comes built-in, but beyond the tooling “factory engineering” is really a mindset.

Encourage, but don’t require it

Assuming you have the right infra in place, you need to incentivize the team to start using it. The way we achieved this at Warp is by having leadership encourage but not require it, and celebrating when folks work in the factory through public praise, a factory leaderboard (not a token leaderboard), or a shared slack channel showing cool factory work. A factory leaderboard should take cost into account and celebrate shipped work, not token spend.

For our team, once engineers started working in public they typically had an aha moment on how it’s better. For instance, when you start work in Slack, you can easily tag a teammate in for their opinion and all the context is already there. You can continue that work on your phone from anywhere. You can search your team’s history, and use that work to inform the next prompt. There are a lot of non-obvious benefits that product engineers start to feel from the new way of working that make them want to stick with it.

Track factory adoption

To make sure the factory approach is working, you’ll want to track factory adoption and set goals around it. The simplest metric to start is percent of merged PRs that went through the factory. You’ll want to look at this in aggregate, but you should also find early factory users who enjoy the new workflow and celebrate them getting their factory usage percent as high as possible.

Engineer the factory

Once some work is flowing through the factory, you can start to focus on engineering the factory, making sure it’s improving over time. The key metrics here are factory throughput (PRs shipped), cycle time, and cost per PR. But you should also look at factory scoring metrics, where agents are rating how well the factory is delivering along certain dimensions like code quality, verbosity and anything else you might care about for your codebase.

Driving these metrics can become like a game. At Warp we are having fun tweaking our model mix and factory workflow to drive our cost per PR down. It’s gone from $80 → $20 in the last six weeks using a factory approach, with a lower revert rate and 40% higher PR throughput than in the last month. Folks on the team are suggesting experiments to improve further. As a startup founder who cares deeply about efficiency and burn, seeing us reduce costs while increasing velocity and quality is incredible.

The ultimate goal

My final thought is that when you hit bumps rolling out factories to always remind your team of the ultimate goal: to ship faster and deliver more value to customers. Factories are just a new tool that they, the engineering team, can use to get to this outcome.

At Warp our mission is to empower developers to ship better software more quickly and efficiently, and moving to the factory model is a major step in this direction. If you are exploring adopting a software factory approach, we would love to chat.