A ticket queue that outran the team.
A Series-C fintech with a 60-engineer team was shipping fast, but the backlog of well-specified, low-ambiguity tickets — the bread-and-butter changes — grew faster than anyone could clear it. Senior engineers spent their best hours writing first drafts of code that the ticket had already fully described. The work wasn't hard; there was just too much of it.
They didn't want a bigger team. They wanted the first draft to write itself — and their engineers reviewing, not typing.
Ticket in, PR out — gated by a tester.
We built a pipeline that reads a ticket, writes the code, and opens a reviewable PR. A dev agent ingests the brief, the repo, and the most relevant prior diffs, then drafts the change. A tester agent generates acceptance specs and runs the suite, kicking the work back to the dev agent with context when it fails. A DevOps agent spins a per-task preview environment and gates the merge on green. A human reviews the PR — the way they always did.
- A plain-markdown brief schema — no proprietary ticket format
- Per-task isolated runners, with spend caps on the client's own model keys
- A rejection loop that re-enters the dev agent with the failing diff and the reason
- Snapshot step-rewind, so any run can be replayed from the last good state
"By the third week, our seniors were reviewing twenty PRs a morning instead of writing three. Same people, very different day."
How it fits together.
The tester is the load-bearing part. The dev agent is allowed to be wrong — the suite and the re-entry loop are what make its first draft worth reviewing instead of rewriting.