Software Delivery

From Ticket to Reviewed Pull Request

Five roles — product manager, architect, developer, tester, reviewer — take a ticket through to a pull request a human merges. We know it works because it is how Forge itself gets built.

A validator between every step

A management agent reads each handoff and decides: advance, send it back with instructions, or escalate to you. Weak output does not flow downstream and quietly become someone else's problem.

The work is a branch, the handoffs are commits

Every role's output is a commit on the run's branch. You can diff attempts, read why a decision was made, or take over mid-run by committing a corrected handoff yourself.

A human merges. Always.

The run opens a pull request. Auto-merge exists and is bounded by an autonomy budget, but the default is that a person presses the button.

One archetype among several

This is the most mature chain we ship, not the product. The same engine runs research, content and operations teams — the roles differ, the machinery does not.

The job

“The backlog is full of changes that are clear, small, and never quite worth interrupting someone for.”

Most engineering backlogs are not blocked on difficulty. They are blocked on attention — the well-specified two-hour change that waits three months because nobody has an uninterrupted afternoon.

What Forge does

The chain most teams recognise, with a supervisor between every step:

Ticketinput
PMPMturns it into requirements + AC
ArchitectArchitectdesigns the approach
DeveloperDeveloperwrites code and tests
QAQAverifies against acceptance criteria
ReviewerReviewerreviews, signs off
Pull requestoutput

What makes this different from pointing a coding assistant at a ticket is the validator between transitions. Each handoff is read by a management agent that decides whether the next role should receive it. When the answer is no, the work goes back with specific instructions — bounded, so a stuck run escalates to you instead of looping forever.

The other difference is that everything is written down. Each role’s output is a commit; the reasoning, the rejected attempts and the verdicts are all in the branch. When you review the PR you are not reading a black box’s output — you can see how it got there.

Evidence

The strongest evidence we have is that this is how Forge is built.

An autonomous driver reads our roadmap, picks the next actionable item, dispatches this workflow against it, and the resulting pull request is merged into the platform’s own repositories. That loop has been running for months — including the runs that failed, the ones that had to be re-dispatched, and the safeguards we added after they did.

The platform’s own repositories are private, so we won’t pretend you can go and audit them. What we can do is walk you through real runs: the branch, the handoff commits, the verdicts that sent work back, and the ones that escalated to a human. It is the same code you would be running, and we would rather show you that than a benchmark.

The honest limits

  • A human merges. We do not claim autonomous merging is a good idea by default; auto-merge is opt-in and budget-bounded.
  • Well-specified tickets work best. A vague ticket produces a vague PR — the PM step surfaces ambiguity rather than inventing an answer, which is correct but does mean it comes back to you.
  • It is one archetype. Treating this as the whole product would be a mistake; the engine is not specific to software.

Under the hood

A backlog of changes nobody has an afternoon for?

Point it at one repository and one well-specified ticket. The first pull request tells you more than any demo.