From Idea to Pull Request, With Humans at the Gates

An agent can take a ticket all the way to a pull request on its own. That’s the easy part. The hard part is the two ways it goes wrong.

Either it builds the wrong thing with total confidence, and you find out at review, when a day’s work gets thrown away. Or you try to stop that by watching every step, and now you’re pairing with a machine all afternoon.

Sound familiar? Neither is a workflow. One gives up control, the other gives up your time.

The fix I’ve landed on is gates: a feature moves through fixed stages, the agents do the work between them, and a person makes a decision at the few points where a decision actually matters. Part 1 covered how those decisions reach you. This part covers where they sit.

The stages

Every feature goes through the same seven stages:

1. Research: what’s the problem, what does it touch, what’s the risk?
2. Prototypes: three different takes on the user-facing part.
3. Plan: a written spec, or questions if anything’s unclear.
4. Build: the implementation, quality checks and a draft pull request.
5. Iterate: you try it running, and ask for changes.
6. Review: independent code review before it’s marked ready.
7. Launch: anything that ships alongside it, like docs or a demo video.

Agents run every stage. You only step in at four of them: picking a prototype, answering the plan’s questions, trying the build, and choosing which review findings get fixed.

Where to put the gates

A gate costs you attention, so each one has to earn it. I use one test: is this decision expensive to reverse, or does it need judgement the agent doesn’t have?

• Which prototype? That’s taste and product judgement. Change your mind after the build, and you pay for the build twice. Gate.
• What’s unclear in the plan? An agent that guesses at an ambiguous requirement writes a confident spec for the wrong feature. Gate, but only when the agent has a question. A clear plan goes straight through.
• Does it actually work? Tests pass; that’s not the same thing. Five minutes clicking through the running feature catches what the spec missed. Gate.
• Which review findings matter? Reviewers flag everything, from real bugs to matters of style. Gate, so the fix-up round only fixes what’s worth fixing.
• Which file does the button live in? Not a gate. That’s what the agent is for.

If a decision is cheap to undo, don’t gate it. Let the agent decide and move on.

Research: know what kind of work it is

The research stage writes a short brief: the problem in a sentence or two, the screens and files it touches, how comparable products handle it, and the risks that change the build (a data model change, a deploy, anything security-sensitive).

It also answers one question that shapes the rest of the pipeline: is this a feature, a bug or a support fix?

That matters because the gates that make sense for a new feature are pure overhead for a bug. Nobody needs three prototypes of a fixed date format.

The fast lane

Bugs and support fixes take a shorter route: no prototypes, no launch stage. Research and plan still run, because the plan writes the spec the build works from, but they only stop if there’s a genuine question. The build, the try-it gate and the review stay, so you still see the fix working before it ships.

Research picks the lane on its own. A request that starts from a user’s email (“the invoice total’s wrong”) is usually a bug, and the pipeline treats it like one. If it gets it wrong, there’s a button to move a run to the fast lane by hand.

The best gate is the one a run doesn’t need.

Prototypes you’re happy to throw away

For features, the prototype stage builds three genuinely different versions of the user-facing part, not three shades of the same idea. They run against fake data, so they’re quick, and they live in a throwaway folder that’s deleted before anything is committed.

Picking one is the most valuable decision in the whole pipeline. It takes a couple of minutes, and it’s where most “that’s not what I meant” moments used to happen. You can also ask for another round with a comment (“closer to B, but without the modal”), and the next three variants all build on your feedback.

Plan: questions before specs

The plan stage does one of two things. If the request is clear, it writes the spec: what changes, why, and how you’ll know it’s done. If it isn’t, it asks.

An agent that asks three good questions saves you from a spec built on three wrong assumptions. Your answers go into the next attempt, and the spec comes out right first time far more often.

Build: a fresh start every round

This one’s a cost lesson as much as a quality one. It’s tempting to keep one long agent conversation running from research to review, so it “remembers everything”. Don’t.

A single long-running session keeps growing, and every call re-reads all of it. Mine got so large that a single small fix-up call cost well over a hundred dollars, most of it re-reading history that had nothing to do with the fix.

Instead, every round starts a fresh session with a short brief: the spec, what’s been built so far, and what’s being asked now. It’s cheaper, and the agent works from what matters rather than from a long, muddy history.

Iterate: try it like a user would

Once the build passes its quality checks, it opens a draft pull request and the feature runs locally for you to try. Anything you want changed goes in as a comment (screenshots welcome), and each change round is pushed so the pull request always matches what you’re looking at.

If a change touches the back end, the pipeline says so, because the running app can’t show it until that part’s deployed. That’s where the environment-locked deploy button comes in, which gets its own post in this series.

Review: two reviewers who argue

When you’re happy, the pull request goes to review, and here I use two reviewers running on different models. Each reviews the change independently, then each gets to rebut the other’s findings. Anything they both agree on, and any serious issue that survives the rebuttal, comes to you as a list.

You tick the findings worth fixing. The agent fixes only those, runs the full quality checks one last time, and marks the pull request ready for review.

Two models catch more than one, and the rebuttal round removes most of the noise before it reaches you.

If you’re building your own

• Fix the stages first. The same pipeline for every feature makes the gates predictable, for you and for the agents.
• Gate decisions, not steps. Only stop for choices that are expensive to reverse or need your judgement.
• Give bugs a fast lane. Let the pipeline classify the work, and skip the stages that don’t apply.
• Start each round fresh. A short brief beats a long memory, on cost and on quality.
• Let the agent ask. A question at the plan stage is the cheapest fix you’ll ever make.

Next in the series: agents that earn their place, and the triage, SEO and error-tracking agents that feed this pipeline.