next level nerdingThe software factory, from 30,000 feet
The software factory, from 30,000 feet
Zach Lloyd runs Warp, an open-source terminal with agents in it, and hasn't written a line of code in six months. His claim: every serious project will soon run a software factory, a closed loop of agents in the cloud that takes ideas in and ships changes out, with people stepping in at three points. Software engineering becomes factory engineering.
Start with the loop, or skip to building a mini factory in Cloudroom or where Warp fits.
Watch the talk
His AI Engineer talk, 21 minutes including Q&A. The loop is at 3:40, the four parts at 8:25, the architecture at 13:05. Slides are the pictures this page redraws.
- 0:00 Who he is, and Warp in one minute
- 1:55 The thesis: software engineering becomes factory engineering
- 3:40 The software factory loop
- 4:50 Why Warp went open source, and build.warp.dev
- 8:25 What a factory needs: four parts
- 9:25 Touring the factory floor: inputs to monitoring
- 12:30 Build or buy? The architecture slide
- 13:50 Measure and improve, skill loops
- 15:10 Where this leaves engineers
- 16:35 The starter repo
- 17:20 Q&A: build vs buy, new grads, taste
It's the SDLC, with agents at every station
“This loop could literally just say ‘the software development life cycle.’ It's the same thing.” Ideas in, triage, spec, implement, review, verify, ship, monitor, round again.
Like CI/CD, but for everything
“Every company, every open source project will have at its core a software factory. Kind of like the way CI/CD became just, oh, of course you have that.”
You code less, ship more
“You're not just building the product, you're building the thing that builds the product.” Six months since he wrote a line of code; Warp is hiring more than ever.
Read this first
One article, one talk, the docs, and a repo. All from Warp, but the ideas aren't Warp-specific. In order:
- 01ArticleAdopting the software factory model: crawl, walk, run Sep 15, 2026The one to read. Three stages from point automations to a closed loop, the questions to ask, and what breaks as you scale.
- 02Talk · 21 minSoftware Engineering Is Becoming Factory Engineering Sep 27, 2026His AI Engineer talk. The loop, the four parts of a factory, the architecture slide, and why he open-sourced Warp.
- 03DocsWarp Factories docs Early accessThe concrete version: foreman, work items, four default agents, factory-as-code, scorers and benchmarks. Useful even if you never use Warp.
- 04Repo · MITwarp-factory-examples The QR code at the end of the talkEight example factories as files. The default agents' real prompts are in 00. Read them to see what each station actually does.
Who he is: former principal engineer at Google, led engineering on Google Docs, 20 years an engineer. Founder and CEO of Warp (60k+ GitHub stars, 800k active developers), which he open-sourced in 2026 partly so he could run a public factory on it. He posts as @zachlloydtweets.
Words on this page
Thirteen terms, in plain words. Skip this if you already run coding agents in the cloud.
- Coding agent
- An AI model that reads a codebase, edits files and runs commands on its own. In a factory, one works at each station of the loop.
- Harness
- The program that wraps a model and lets it act as a coding agent. Claude Code, Codex and Warp Agent are harnesses; each can run different models.
- Sandbox
- A walled-off computer in the cloud with the repo checked out, where an agent can work without touching anything else.
- Branch, diff, PR
- A branch is a separate copy of the code to work on. The diff is the lines that changed. A pull request (PR) asks to merge that change, so people and agents can review it first.
- CI/CD
- Continuous integration and delivery: the pipeline that tests, builds and deploys code after a change is merged. Zach says factories will become as standard as it is.
- Cron
- A schedule written as five fields. "*/15 * * * *" means every 15 minutes. The mini factory uses cron jobs to check for new work.
- Cloud thread
- An agent session in Cloudroom or bb that runs in the cloud with its own sandbox and branch, so several can work at once.
- Skills
- Instruction files that teach agents how your team works: your codebase, conventions and tools. Observer agents propose edits to them.
- MCP
- A standard way to plug a tool or data source into an agent. "Your MCPs" are the connections to your own internal tools and knowledge.
- Sentry
- An error tracker. It alerts when the live product crashes, which is how the monitor station finds new work.
- Computer use
- An agent that operates a browser or desktop like a person, clicking through what got built and recording video and screenshots.
- Frontier vs open-weight
- Frontier models are the newest, most capable ones from the big labs. Open-weight models are ones you can download and host yourself.
- Tokens
- The unit AI models count and charge in. With human time, it is one of the two costs a factory should measure.
The loop
Eight stations, clockwise from the top. Agents work the stations; a person decides at the three boxed points. Click a station, or follow one piece of work all the way round.
- Human · approves the spec
- Human · reviews the code
- Human · reviews the product
- and back to intake
Station 1 of 8 · human
Ideas and bugs come in
Intake
In
A person with an idea, a bug report, a support escalation, or an alert from your monitoring.
What happens
Work enters through the channels you already use: the task tracker, Slack or Teams, GitHub issues, a webhook, a schedule, or an agent in your terminal.
Out
One work item that keeps its identity all the way round the loop, however many agents touch it.
Crawl version
A label on a GitHub issue, say factory-ready, is the simplest trigger there is.
In Warp Factories
Slack, Linear, Jira, GitHub, GitLab, webhooks, a Factory API, and a Factory MCP so any coding agent can hand work in.
In Cloudroom or bb
A GitHub label plus a scheduled automation that lists labeled issues every few minutes.
“The inputs are really ideas. They could be coming from your team, they could be coming from your users.”
Why it's a loop and not a pipeline: the monitor station files new issues at the top. “You take the output of this monitoring step and you feed it back into the top of the factory.” The three human gates are policy, not hardware. Warp writes them into the foreman's prompt; the merge gate is your branch protection.
Four parts, and one mindset
“It's really not that complicated to start, or at a high level.” From the talk, at 8:25. Everything further down this page is one of these four, in more detail.
- 01
Automations
Trigger, then agent activity. An issue gets labeled, a PR opens, an alert fires, a clock ticks. Each one starts an agent with a job.
- 02
Context and skills
What the agents know: your repo, your conventions, your tracker, your internal tools. This is the part every org has to build itself.
- 03
Humans at the right time
Approve the spec. Answer questions. Merge. Everywhere else, get out of the way. “When things get stuck on the factory.”
- 04
Self-improvement loops
Observer agents watch the working agents, see where they fail, and propose changes to skills and prompts. Nothing is adopted on its own.
The mindset
“The factory is not just a product, it's also a mindset. You need to measure and improve.” How much software shipped, at what cost in human time and tokens, and is that number moving. He calls it meta-engineering: engineering the system of agents that does the engineering. If your joy is writing code, you'll write less of it. If your joy is shipping, “it's never been a better time.”
Crawl, walk, run
Adopting all of it at once is daunting, so don't. Three stages, each with a clear finish line. Most teams he talks to are somewhere in crawl.
- 01point automations
Crawl
Simple Trigger → Agent Activity automations, each covering one discrete part of the lifecycle. Low risk, low cost, builds intuition.
Done when: You have two or three automations you'd miss if they stopped.
- ·Issue reproduction and triage
- ·Code review on every PR
- ·Respond to a Sentry alert
- ·Self-heal CI
- ·Autoupdate docs and changelogs
- ·Browser-use verification
- ·Simple bug fixes
Where it hurts: They don't share context, so a better review prompt doesn't help triage. No global view of cost-per-PR, cycle time or automation percent. Each one is its own setup, security surface and maintenance job.
- 02one loop, one simple surface
Walk
Deploy a first factory end to end on a simple product surface: your marketing site, an internal app. Get the whole loop going with low stakes before adding repos, services and stakeholders.
Done when: A request in Slack or the tracker becomes a shipped change with no human touch besides describing it and approving it.
- ·Development in the cloud by default
- ·One shared context layer across stages
- ·Central governance and complete traces
- ·Escape hatches for humans to take over
- ·Wired into Slack, Jira, GitHub
- ·Optionality on models and harnesses
- ·A way to test that it's improving
Where it hurts: Warp's own walk factory automates about 75% of changes to warp.dev, their marketing site. Not the terminal, which is a million lines of Rust.
- 03scale to real products
Run
Only after the basic loop works. Bigger repos, more services, more stakeholders, mission-critical apps. Now you need the full stack underneath.
Done when: A closed loop, measurable, improvable system. “Running empirically, not on vibes.”
- ·Factories as code, so configs can be tested against each other
- ·Multi-model and multi-harness, frontier and open-weight
- ·Own every byte of data the factory produces
- ·Model routing and harness choice as cost rises
- ·Audit trails and multiplayer sign-off
- ·A strategy for the PR pile: what gets human review
- ·Tools that close the loop from production
Where it hurts: Remote dev environments on large projects are hard. It gets harder to tell whether a change to the factory helped or just caused churn. Costs climb as agents run longer on harder code.
Before you walk, answer these
The questions organizations ask once the point automations start to sprawl. Most that think hard about them “land on something like a cloud software factory approach.”
- 1Where should development happen? Locally or in the cloud? Through what interfaces?
- 2What does a successful automated development process look like? What are the key metrics?
- 3What's our AI sovereignty posture? How important is it to own our coding agent data?
- 4How do we improve the process over time, control costs, and know we're improving?
- 5How are we future-proofing as models and agents improve? Regulatory risk to model access?
- 6How exactly should engineers participate? Designers, PMs and other builders?
- 7How are we securing development? What's the plan if the production process is compromised?
Build or buy? Wrong question
“No matter what path you take, you should expect your internal team to do some building.” Skills tuned to your codebase, your MCPs, your internal context: nobody can sell you those. Sandboxes, steering, handoff, measurement, computer use: every org needs the same ones. “Focus on building the pieces that are specific to your org, not the ones needed by every organization.”
The stack under a factory
Warp's picture of what a fully humming factory sits on. Seven layers, foundation at the bottom. You don't need all of it to crawl; you need most of it to run.
- 06AccessHow work gets in and how people watch it.
- Factory MCP
- Slack · Teams
- Jira · Linear
- GitHub · GitLab
- Web · mobile
- API · SDK
- 05OrchestrationWho does what, in what order, and when a human steps in.
- Triage / spec / implement / review / verify
- Multi-agent
- Live steering + handoff
- Automations: trigger / cron
- 04ImprovementIs the factory getting better? Measure it.
- Metrics: autonomy, cost, cycle time
- Scorers
- Benchmarks
- Self-improvement loop
- 03InferenceWhich model answers, and who hosts it.
- Multi-model, frontier + open-weight
- Bring your own inference
- Custom model routing
- 02ComputeWhere the agents actually run.
- Sandbox: Docker image · Kubernetes
- Agent runner: Mac · Linux · Windows
- Computer use: video / image
- 01Data and contextWhat agents remember and can reach.
- Runs + transcripts
- Agent memory
- PRs · reports · attachments
- MCPs / internal knowledge
- Access control
- 00Factories as codeThe whole thing in version-controlled files.
- factory.yaml
- Agent definitions
- Automation definitions
- Runners
- Repo config
Three layers he calls out as easy to miss. Factories as code: define the factory in files so you can test one configuration against another. Multi-model and multi-harness: frontier and open-weight models, Claude Code and Codex, so you're never stuck. Data ownership: store everything the factory produces, because “this is the raw material for improving its operations.”
Build a mini factory in Cloudroom or bb
- 01Pick a small, boring surface
Zach's advice: a marketing site or an internal tool. One repo, a preview deploy, tests that run in under a few minutes. For FakeNerd that would be this site.
- 02Intake: a label on GitHub issues
Add a factory-ready label. A person deciding to apply it is your first human gate, and it costs nothing to build.
gh label create factory-ready --color FFD84A \ --description "Ready for the factory"
- 03Implement: a scheduled Cloud thread per issue
A cron automation runs every 15 minutes, lists labeled issues that have no branch yet, and spawns one Cloud thread per issue. Each thread gets its own sandbox and branch, and ends by opening a PR that closes the issue.
room-cli automation create --project $ROOM_PROJECT_ID \ --name factory-implement \ --cron "*/15 * * * *" --timezone America/New_York \ --prompt "$(cat factory/implement.md)" \ --provider claude-code --model claude-fable-5-1 --reasoning high \ --permission-mode auto
- 04Review: a second automation on open PRs
Every 15 minutes, find open PRs with the factory label and no review yet. Review the diff against the issue's acceptance criteria and post findings as a PR comment. Advisory only.
room-cli automation create --project $ROOM_PROJECT_ID \ --name factory-review \ --cron "5,20,35,50 * * * *" --timezone America/New_York \ --prompt "$(cat factory/review.md)" \ --provider codex --model gpt-6.1-sol --reasoning high
- 05Verify and merge: you
Build the preview, open it, read the findings, merge. This is the human gate that stays. Later, hand the preview URL to a Cloud thread with computer use and let it screenshot each acceptance criterion.
npx opennextjs-cloudflare build && npx wrangler versions upload --tag pr-123
- 06Improve: a weekly observer
One more automation, weekly. Read the last week's factory PRs and every human comment on them. Propose edits to factory/implement.md and factory/review.md as a PR. You merge those too.
room-cli automation create --project $ROOM_PROJECT_ID \ --name factory-observer \ --cron "0 9 * * MON" --timezone America/New_York \ --prompt "$(cat factory/observe.md)" \ --provider claude-code --model claude-fable-5-1 --reasoning max
factory/implement.md · the dispatcher prompt, in full
You are the dispatcher for a small software factory. You never write code. 1. Run: gh issue list --label factory-ready --state open --json number,title,url 2. For each issue that no open PR references (check with: gh pr list --search "#<n>"), spawn one worker: room-cli thread spawn --parent-self --new-environment worktree --title "factory #<n>" --prompt "$(cat factory/worker.md) <issue url>" Then comment on the issue: "Factory picked this up." 3. Stop. factory/worker.md tells each worker to: read the issue, restate the deliverable in one paragraph, make the change on a branch named factory/<n>-<slug>, run the tests, push, and open a PR titled after the issue with "Closes #<n>", the restated deliverable, and screenshots. Label the PR factory-ready. If the issue is ambiguous, comment the question on the issue and stop instead.
The dispatcher never writes code. It spawns one worker thread per issue and stops, so each change gets its own sandbox, branch and PR. That is the same split Warp makes between the foreman and the implement agent, minus the routing.
What this doesn't give you yet
- Pick a provider per station, like Warp does. One model to implement, a different one to review, so the reviewer doesn't share the implementer's blind spots.
- Keep the three prompts in the repo under
factory/. That's your factory as code. Every correction you'd type in chat goes into those files instead. - Give it two weeks on the boring surface before touching anything you care about. Zach's walk milestone is one loop running end to end with low stakes, and nothing else.
Where Warp Factories fits
Zach's company sells the infrastructure this page describes. Here's what it actually is, from the docs and the examples repo, and how it differs from rolling your own.
Five agents every new factory starts with
Models are from Warp's own defaults, checked Sep 29, 2026. Note that three vendors share the work.
- Foremanclaude-5-opus-highThe one agent you talk to. Routes each work item through the shortest path that meets your policy, relays questions, posts the findings that need a human.
- Triagegrok-4-5-highResearches, reproduces, finds or creates the issue, sets size, reports ambiguity.
- Specgpt-5-6-sol-highInterviews you, writes product and tech specs, commits them as a draft PR, drives approval.
- Implementauto-geniusMakes the change, proves it works, opens the PR with evidence.
- Reviewgpt-5-6-terra-highAdversarial review of the diff. Findings only; never posts a verdict on the PR itself.
The smallest factory, as files
Example 01: one repo, two agents, one labeled-issue trigger, one PR out. A resource's name is its path.
- factory.yamlName, repos, agent defaults (model or harness, runner).
- agents/foreman/agent.mdagentType: FOREMAN. Exactly one per factory. Frontmatter picks the model; the body is the prompt.
- agents/implementer/agent.mdagentType: IMPLEMENT. The name is the path; rename means move.
- automations/issue-labeled/automation.mdTrigger: github / issue_labeled, filtered to factory-ready. Body: what to do.
- runners/linux-small.yaml2 vCPU, 4 GB, node:22-bookworm-slim. The image is where the toolchain comes from.
- skills/Skills here reach every agent. Skills under agents/<name>/skills/ reach only that agent.
Register it by pointing a factory at the directory in GitHub. Pushes sync after a warp/factory-config check passes. Details: factory definition, how factories work.
What's different
The foreman
One coordinator per factory holds one conversation per work item, picks the shortest path through the stages, and is the only agent that talks to you. The point automations you'd build yourself have no equivalent.
Factories as code
Agents, automations, runners, scorers and skills are files in your repo, synced on push after a config check. Config changes get review, history and rollback, and you can benchmark one tree against another.
Any harness, any model
Each agent picks its own harness and model. Their own defaults mix Anthropic, xAI and OpenAI models across the five roles. Your factory isn't tied to one vendor's agent.
Measure and improve
Scorers classify finished runs. Benchmarks replay your real past tasks across configurations. Self-improvement groups repeated failures into follow-up runs that propose fixes, as PRs, never applied on their own.
Open and public
Warp Terminal is open source (60k+ stars). Their own factory runs in public at build.warp.dev, so you can watch triage and contributors flow through it.
The honest caveats
Early access, so expect gaps. Runs consume platform credits. And Zach says it himself: whatever you pick, you still build the org-specific skills, MCPs and context. Nobody sells that part.
Three ways to get a factory
| Mini factory in Cloudroom | Warp Factories | Homegrown (SDK in Docker) | |
|---|---|---|---|
| Trigger | Cron polling GitHub | Events from GitHub, Slack, Linear, Jira, webhooks, schedules, MCP | Whatever you wire up |
| Routing | None; each job is fixed | Foreman decides stages per item, can skip or send back | You write it |
| Where agents run | Cloud threads, own branch each | Warp-hosted runners, or self-hosted on Enterprise | Your Docker + SDK |
| Harness / model | Any provider Cloudroom supports, per automation | Warp Agent, Claude Code or Codex, per agent | One SDK, usually |
| Human gates | The label, your merge | Spec approval, questions, merge; policy in the foreman prompt | You write it |
| Measuring | A spreadsheet | Dashboard, scorers, benchmarks replaying real tasks | You write it |
| Self-improvement | Weekly observer prompt | Flagged failures grouped into proposal PRs | You write it |
| Cost to start | Your existing subscription | Early access; up to $10k in credits for qualified teams | Weeks of platform work |
Warp Factories is in early access at warp.dev/factories. Measuring: scorers and self-improvement, benchmarks. Their factory, running in public: build.warp.dev.
FakeNerd's take
The loop is the SDLC you already have
Don't let the word factory scare you. Every station on the ring is a thing your team already does by hand. The only new idea is that an agent does the first pass and a person does the last.
Crawl is two cron jobs
A labeled issue and a scheduled thread that opens a PR. That's a crawl-stage factory, and you can have it running this afternoon in Cloudroom or bb. Do it on the site you'd be least sad to break.
Buy the layer you'd hate to build
Zach's rule of thumb holds: build what's specific to you (skills, context, MCPs), and think hard before building sandboxes, routing, metrics and benchmarks. Those are the same for everyone, and they're the boring part.
Lauren's kitchen and Zach's factory agree
Lauren Tan's pstack page says you're a head chef, not a factory manager; Zach leans into the factory. Both end at the same place: verification before trust, corrections pushed upstream into skills, humans at the pass.
Attribution
- Zach Lloyd (@zachlloydtweets): Adopting the software factory model: crawl, walk, run (Sep 15, 2026). The crawl list, the walk questions, the run bottlenecks and the stack diagram are his; quotes are word for word.
- Software Engineering Is Becoming Factory Engineering, AI Engineer (Sep 27, 2026). The loop with three human gates and the four parts come from the talk.
- Warp Factories docs and warp-factory-examples (MIT), for the foreman, the default agents and their models, and the file tree. Checked Sep 29, 2026. Early access; details may change.
- The Cloudroom recipe, the comparison table and the loop's “in, what happens, out” framing are FakeNerd's. Zach doesn't endorse Cloudroom or bb, and this page isn't sponsored by Warp.