# The Software Factory pattern: how a ticket becomes a reviewed PR > A spec-driven, test-driven production line for AI coding agents: spec, then tests, then code, then validate, then review, then merge. An overview of the whole pattern. Level: Advanced Tool: Agents Category: Building Time: About 15 minutes Checked: 2026-10-15 Tools: [AGENTS.md format](https://agents.md), [Model Context Protocol](https://modelcontextprotocol.io) HTML page: https://easyaihowtos.com/guides/software-factory-pattern-overview **A pattern by [Greg Alton](https://www.linkedin.com/in/greg-alton-ios).** 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**. ## What you need - An AI coding agent that reads AGENTS.md and supports sub-agents (for example Claude Code, Cursor, Codex, or similar) - A ticket tracker and a Git host with MCP servers (this series uses Jira, GitLab, and Bitbucket) - A repository with a working test command ## 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: ```text 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. ## FAQ ### 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. --- This guide is from Easy AI How-To (https://easyaihowtos.com). It is independent of the tools named above. Screens and free-plan limits change, so check the date before you rely on a button name.