Subscribe to Newsletter

Module 2: Upgrade Your Factory's Line

Your basic factory has four stations. This module grows it into a full line with specialized agents, and shows you how to write issues that an agent can finish.

Start module Module 2 of 5 · 2 lessons
You will learn
  1. 2.1Grow your line into a pipeline of specialized agents
  2. 2.2Write issues and specs an agent can finish
2.1

Grow your line into a pipeline of specialized agents

A factory works best as a pipeline of specialized agents, rather than one coding agent with an enormous prompt. Each agent owns a narrow part of the SDLC.

Add the missing stations

The full flow adds a spec agent, a verification agent and a monitor agent to your basic line:

1 New issue from a human or a monitor agent 2 Triage agent understands and reproduces it 3 Spec agent when scope needs it; a human approves Ambiguous ask a human and re-run, or park it ambiguous automatable spec approved 4 Implementation agent writes the code 5 Code review agent reviews the code 6 Verification computer use or other checks 7 Human review code + verification output if needed: back to triage, spec, implementation or review 8 CI/CD runs the pipeline 9 Ship the change goes out 10 Monitor agent opens new issues from production completes the loop agent human or system step
Scroll sideways →Source: Warp, A guide to cloud software factories.

The spec agent works with a human on larger tasks, and the human approves the spec before implementation starts. The verification agent checks the change with computer use or other tests. The monitor agent watches production and opens new issues, which closes the loop.

Treat this flow as a base, and keep your orchestrator flexible enough for custom agents. For example, you can add an agent for canarying or one for dead-code cleanup.

Keep the writer and the reviewer apart

Guild's engineering team runs this kind of pipeline on its production codebase. A GitHub or Jira event starts the process, and a label on a well-scoped issue can start the full run:

FROM EVENT TO PR Event GitHub or Jira Dispatcher routes to a workflow Planner reads code, writes a plan Implementer sandbox, lint, types, tests Reviewer separate agent Human final approval opens a draft PR marks it approved
Scroll sideways →Source: Guild engineering team.

Two details make this line reliable:

  • The implementer runs your existing checks. It runs the repository's linters, type checks and tests before it opens a draft PR.
  • A separate agent reviews the code. The agent that writes the code never decides whether its own work is correct.

The factory never merges its own PRs. Agents do the work, and people own the outcome.

Add agents that maintain the factory

An agent that writes code is getting easier to build. A system that keeps running reliably for months is harder, so some of your most important agents should write no product code at all:

AgentJob
Conflict resolverKeeps factory branches in sync with main and resolves routine conflicts.
JanitorFinds stale or stuck jobs, retries them, and escalates after a set number of attempts.
Code healthFinds duplicate helpers, dead code and inconsistent implementations, then opens scoped issues for the factory.
Test triageSorts CI failures into flakes, regressions and infrastructure problems, then creates follow-up work.

Agents like code health and test triage create work for other agents. Production logs can feed the factory the same way, and that loop turns a coding agent into an engineering system:

THE CORE LINE Dispatcher Planner Implementer Reviewer Human AGENTS THAT KEEP THE LINE RUNNING Production logs log-triage agent Conflict resolver branches in sync Janitor retries, escalates Code health dead or duplicate Test triage flake? regression? agents open issues that trigger the factory
Scroll sideways →Source: Guild engineering team.

The Code: Your daily unfair advantage in software engineering.

Join 350,000+ software engineers, tech leads, and CTOs who start their morning with The Code.

Subscribe to Newsletter
2.2

Write issues and specs an agent can finish

The quality of intake sets the ceiling on everything downstream. The better you scope a problem, the more reliably the factory executes it.

Write the issue as if it were the prompt

Treat each issue you assign to an agent as its prompt. Before an agent takes an issue, check that it states these four things:

  • Acceptance criteria: a complete description of what a good solution looks like.
  • Scope and boundaries: what the agent should change, and what it should leave alone.
  • Success criteria: how you will judge the result.
  • Verification steps: how the agent proves that the change works. Avoid leaving these undefined.

If an item is missing, add it before the agent starts.

Approve a plan before the agent writes code

A spec stage catches a misread requirement before any code exists. You can review a plan in minutes, but a 2,000-line PR built on a misread requirement takes days.

Have the agent produce a plan from your prompt, then review and refine it before an agent implements it. Run the planning step in read-only mode, and save each plan. A reviewer can then see what the agent believed about the codebase before it changed any file.

For the full method, see our guide to spec-driven development.

END OF MODULE 2

By this point you should have:

  • A full line with spec, verification and monitor stations, and a separate reviewer.
  • Maintenance agents that keep the factory running and feed it new work.
  • A four-point check for every issue, and a plan-first habit for larger tasks.