Skip to content
Easy AI How-To

AdvancedAgentsBuilding

The Software Factory pattern: how a ticket becomes a reviewed PR

A pattern by Greg Alton. The Software Factory is a spec-driven, test-driven production line for AI coding agents. A ticket goes in one end; a reviewed pull request, with a full paper trail, comes out the other. The line always runs in the same order: spec, then tests, then code, then validate, then review, then merge.

Time
About 15 minutes
Checked
Tools
AGENTS.md format, Model Context Protocol

If a button name on the screen does not match this guide, follow the action. These products rename buttons often. This is an advanced guide: it uses code, and each technical term is explained the first time it appears. Model names and prices change, so check the linked docs before you ship.

Steps

  1. See the production line

    The Software Factory treats software delivery like a factory floor. Work moves down one line, and every station has a gate that must pass before the next one starts:

    Ticket ─▶ SPEC ─▶ TESTS ─▶ CODE ─▶ VALIDATE ─▶ REVIEW ─▶ (you) MERGE
           │        │        │         │           │
         plan    RED test  GREEN +   full suite  structured review
         agent   first     refactor  + security  + one-fix-at-a-time

    Spec first. The spec says what must be true. Tests next, derived straight from the spec, and they must fail before any code exists (that failing state is called RED). Code last, the minimum needed to make those tests pass (GREEN), then cleaned up (REFACTOR). Validation gates each stage. Review happens on the published pull request (PR). Merging stays a human job.

  2. Meet the Factory Manager

    The whole line is written down in one file: AGENTS.md at the root of your workspace. Many coding agents read this file automatically. In this pattern it acts as the Factory Manager: it defines the SDLC (software development life cycle), the order of stations, the gates, the artifacts each station must leave behind, and what agents are never allowed to do (such as merge).

  3. Staff the stations with sub-agents

    Each station is a small, focused sub-agent: a separate AI worker with its own instructions, tools, and context window. A thin orchestrator dispatches them in order:

    • plan: turns the ticket and spec into a task table and a test-first plan
    • explore and research: read code, specs, and docs, and return short summaries
    • code: one slice at a time, RED, then GREEN, then REFACTOR
    • validate: runs focused and full test suites and records exact results
    • tracker clerk: the only agent that talks to Jira
    • pr-code-reviewer and pr-review-fixer: review the published PR and fix one finding per cycle

    The orchestrator never reads files or runs tests itself. Keeping its transcript small keeps it accurate.

  4. Let tickets flow in through MCP

    MCP (Model Context Protocol) is the open standard that lets agents use outside tools. The factory reads a Jira ticket through the Atlassian MCP server and writes progress back as structured comments: Plan, Test Results, Execution Summary, and Handoff. Pull request comments are read and written through the GitLab or Bitbucket MCP servers.

  5. Know what lands on your desk

    When the factory is done, you don't get a vague "done!" in chat. You get durable artifacts: the plan, the test table that went from RED to GREEN, exact verification commands, a structured code and security review on the PR, and a disposition report that accounts for every review finding. Your job is to inspect those artifacts and decide whether to merge.

  6. Follow the series

    The rest of this series builds each piece: the AGENTS.md Factory Manager, the sub-agents, the Jira connection, the PR comment loop, and the developer's review. Each guide includes generic example files you can copy and adapt.

Tips

  • Start with one repository and one ticket type. Add stations only when a real gap shows up.

  • The gates are the point. A factory that lets code skip the test station is just autocomplete with extra steps.

  • Keep agents away from merge buttons. Deny merge tools in your MCP client settings, not just in a prompt.

Common questions

Is this the same as 'spec-driven development'?

It builds on it. Spec-driven development says write the spec first. The Software Factory adds test-driven gates, specialized sub-agents for each station, and durable artifacts in your tracker and on the PR.

Do I need Jira, GitLab, or Bitbucket?

No. Those are the examples in this series. Any tracker and Git host with an MCP server works, because the Factory Manager describes the process in plain language.

Why so many agents instead of one?

Long agent sessions get less accurate as their context fills up. Splitting work into bounded slices keeps each worker focused and lets the orchestrator stay small. It also lets you use a cheaper model for routine stations.

More guides

Occasional notes

Hear when a new guide is up

A short note when a guide is added. No account, and no emails until this form is connected to a real list.

Placeholder. This form is not connected to an email service. Nothing you type is saved or sent.