Agents write code fast; without gates that produces unreviewed change. Our workflow turns GitHub issues into an assembly line: an approved brief, an approved plan, a build in the dark, review by a second agent from another provider, evidence against the branch head, and human gates for the pull request and the merge.
Before
What we built
Exactly one state per issue: needs-operator, needs-plan, ready, working, for-operator. Silence, labels or time never create approval.
Every plan offers two or three approaches, names exact files and interfaces, and starts with a failing test.
The build runs without interruptions and writes a crash-safe ledger, so a dead session resumes where it stopped.
Spec, standards and security reviewed by a fresh reviewer, with Codex reviewing Claude's work. Up to three fix rounds, then adjudication.
A gate script re-runs the checks and requires evidence at the branch head, a changelog and chronicle entry, and a clean review. Then a person says “make the PR” and “merge it”.
Decisions
Every gate is a person, quoted into the record.
Evidence is a fresh run, read before it's claimed. Audits that over-claim are corrected in writing.
Skills are scanned and block on any high finding; design-system components are signature-verified on install.
The hard part
Speed without unreviewed change
The bottleneck moves to review. We keep changes small, make agents write the tests, use a second agent for pre-review, and keep people for the judgement calls.
Measuring it
Per project we track releases, review rounds and rework. For client teams we baseline lead time, change failure rate and review wait before we start.
Built with
Next: Packaged for client engineering teams, inside their repos and CI.
Issues in, reviewed releases out: how we'd build it for youA one-hour call with a founder and an engineer. Bring a BOQ, a stack of POs, last month's invoices or a backlog, and leave knowing what would work, what wouldn't, and what it would take.
170+ projects · 65 companies · founders on every engagement