Module 1: Build Your First Software Factory

What a software factory is, and why your job now has two halves

A cloud software factory is an automation around the core loop of development: triage → spec → implement → review → verify → ship → monitor. At every step, a mix of agents and humans moves the work forward.

Factories are a variant of the agent loop, and they are spreading fast. The main stage of the AI Engineer World's Fair gave a whole track to factory engineering.

Why factories are catching on now

First, agents are now good enough for true automation. An agent can triage an issue, propose a fix, implement it, verify it, ship it and monitor it on its own:

Second, interactive agents create problems with cost, governance and security, because each engineer uses them differently. One engineer picks the most expensive model for a simple task, and another installs an MCP server with too much access. A factory replaces that variation with one system that you can control, secure and measure for ROI.

The gains in productivity, cost management and control are profound. Zach Lloyd, founder and CEO of Warp, believes the shift is inevitable.

Your two jobs

You now have two jobs: build the product, and build the factory that builds the product.

• Product engineering improves the product. You still own its quality and usefulness, and you cannot delegate that to agents. You now do this work through the factory, and you prompt cloud agents from tools like Slack and Jira, in public.
• Factory engineering improves the agents that improve the product. You measure the factory, find what to improve in skills, context and model mix, and ship changes that raise automation. Measure, test and benchmark before you change anything, and never adjust the factory on vibes.

Engineers at Warp use the term "factory engineering" for the second job. Ben Holmes, a software developer at Warp, also uses a nickname for it from Lauren (@poteto), who works on Grok at SpaceXAI: "gardening." The two jobs map to two loops:

What factories ship today, and where they break

Teams already run factories against their production codebases:

Guild's team built its factory to remove "ditch digging": work that is small, bounded and verifiable, but expensive because a person must stop other work to do it.

Where factories break: review load and stability

Coding agents raise PR volume long before your organization can absorb it. Faros AI's 2025 telemetry, across more than 10,000 developers, shows the cost:

The 2025 DORA report finds a similar pattern. AI adoption raises delivery throughput, but it keeps hurting delivery stability. Teams without strong automated tests and fast feedback loops see more change turn into instability.

The constraint moves from writing code to verifying it:

A factory answers this with defined stages and human gates at the spec and the merge, so you plan review capacity instead of discovering it. The lessons on the factory workflow and on measurement show how.

Set up a basic factory in six steps

A factory pays off once it handles some of your issues, and that share grows over time. Start with one workload and a short line of agents, then add to it.

Step 1: Pick a first workload

Pick work that is small, bounded and verifiable. Good first candidates are server crashes, simple bugs, flaky tests, small UX papercuts and dependency upgrades.

Step 2: Move one agent off your laptop

You cannot build reliable automation on a laptop that might sleep, and you want one standard environment for every run. Pick a runtime:

• Run the agent in a cloud development environment, if your team already has one.
• Package your environment with Docker and run it on a Docker host.
• Run your environments on Kubernetes or another orchestration platform.

Put the runtime on a host in a public cloud or on your own infrastructure. Inside it, install a coding agent that can change your codebase.

Keep the environment definition in version control alongside the code. Record its base image, the repositories it can reach and its variables. An environment that lives on one laptop can't be reviewed or rolled back.

Then connect the agent to your source code forge, and add MCP servers for your task tracker and chat. Decide who the agent acts as (authentication) and what it can reach (authorization), and keep that access tight.

Step 3: Launch the agent from a trigger

The factory needs a system that launches agents in response to a trigger. A trigger can come from a human, such as a Slack message or a new ticket, or from a schedule.

Put the trigger where your team already works, rather than add a new tool to check.

Step 4: Wire a minimal line

Start with four stations. A label on a well-scoped issue, or any trigger from the last step, starts the run:

1. A triage agent tries to understand and reproduce the issue. If the task is automatable, it hands the task to the implementation agent. If the task is ambiguous, it asks a human for input or parks the issue.
2. An implementation agent writes the code in its sandbox. It runs the repository's existing linters, type checks and tests, then opens a draft PR.
3. A code review agent reviews the PR before a person spends time on it. Keep it separate from the writer, so no agent judges its own work. Once satisfied, it removes the draft status and marks the PR as factory-approved.
4. A human reviews the code and decides whether to merge. If the work falls short, the human sends it back to triage, implementation or review. CI/CD then ships it.

Add spec, verification and monitoring agents later, as the lesson on the factory workflow shows.

Step 5: Define the factory as code

Keep all factory config in files, under version control, just as you do for other infrastructure. Your coding agents can then act on those files and update them too.

Step 6: Track two numbers

Track the percentage of tasks that ship fully automated, and what they cost to complete. These two numbers matter most at the start. "Fully automated" means an agent did all the work: triage, spec, implementation, review, verification and monitoring.

For tasks that still need a person, count the human touches per PR: the first prompt, each spec iteration and each manual review. Each time a human must step in, record it and learn from the failure. Over time, the touches should fall.