The Delivery Pipeline I Run: Tickets In, Reviewed Pull Requests Out

Most teams treat AI as autocomplete. That caps the value at faster typing. The better question is how much of the distance between a ticket exists and reviewed code is merged can be automated — without lowering the bar.

Here is the pipeline my team runs, and where it deliberately stops.

The shape of it

1. The ticket is the input. An agent pulls it directly — acceptance criteria, links, context — rather than a human retyping it as a prompt.
2. The design is read, not described. The pipeline reaches into the design file itself. Spacing, states, and tokens come from the source, not from someone's paraphrase of a Figma frame.
3. Implementation arrives as a pull request. A branch and a diff against the real codebase — not a snippet in a chat window.
4. QA agents review before any human does. A separate stage checks the work against the criteria and the surrounding code.
5. A human approves. Always. Nothing merges on a machine's say-so.

The first four steps produce the speed. The fifth makes them defensible.

Sources of truth, not summaries

The typical failure of AI-assisted work isn't bad code — it's code that solves a slightly different problem than the one that was filed. That gap opens during translation: a person reads a ticket, forms a mental model, types a prompt. Every paraphrase is a chance to drop a requirement or invent one.

Wiring the pipeline directly to the ticket system and the design tool removes those translation steps. It's a boring architectural decision that matters more than any prompt engineering.

Why QA is a separate agent

An agent asked to check its own work thinks the work is good. Separating implementation from verification is the same principle as not letting an engineer solo-approve their own PR: whoever just built something is the worst-placed person to see what it's missing.

The QA stage cheaply catches skipped criteria, unimplemented states, and regressions in adjacent components. It does not catch architectural drift. That's the human's job.

Why the gate doesn't move

Every few months someone asks: if the QA agent is good, why not auto-merge the clean ones?

Because the gate isn't about catching bugs. It's about ownership. A merged commit is a promise to whoever depends on the code, and when something breaks at 2am, "an agent approved it" is not an acceptable answer. Someone read this and thought it was right — that sentence has to stay true.

There's a practical reason too: the gate keeps engineers reading the codebase. Remove it and within a quarter you have a team shipping a system none of them can reason about. The gate isn't friction. It's what keeps the humans qualified to run the pipeline.

What actually changes

Time spent on translation and boilerplate drops sharply. Time spent on review goes up — it's now a bigger share of a senior engineer's day, because review is the load-bearing step.

That's a trade worth making every time. Reviewing is the highest-leverage thing a senior engineer does; typing is not. A pipeline that moves hours from typing into reviewing makes the team more senior, not less.

If you're building one

• Connect to sources of truth, not summaries. Every human paraphrase loses requirements.
• Separate the thing that builds from the thing that checks. Self-review isn't review — for agents or people.
• Fix the gate's position before you build, then don't move it. Teams that add governance after tasting the speed never manage it.

The pipeline is worth building. The gate is what makes it worth trusting.