Loop Engineering: From Backlog Issue to Shipped Code

The loop is two stages, chained together, each one an agent or Claude Code skill running against the project's board.

Stage 1 — Refine the backlog. An agent takes a raw issue and checks it against the real repository — it never invents a path or a behavior, it verifies everything by reading the code. It leaves the issue with a clear title, a user story, observable acceptance criteria, technical detail, and a manual QA checklist.

When the backlog has several issues queued up, the same agent also computes a cross-impact map: which issues block each other, which touch the same file and can't be parallelized, which are fully independent. That map goes to a human for approval before a single line gets written — only then is an issue actually "ready to develop".

Stage 2 — Implement and deploy. A second agent takes those already-refined issues, one at a time, until each one is done: it writes an implementation plan, codes against that plan, opens the PR, submits it to our own code review, runs the local quality gate, waits for the deploy, moves the issue to QA, and checks off the checklist — but only what an automated test actually proved. Anything that needs a real device or a human eye is left unchecked, on purpose. It ends with a plain-language hand-off for QA: for every issue, exactly what's still left to verify by hand.

Every stage of the loop runs on a specific Claude Code model, chosen for what that stage actually demands:

It's not "one model for everything." Deep reasoning — planning, reviewing — goes to Opus. The volume work that's already channeled by an approved plan goes to Sonnet.

Review deliberately uses two independent Opus calls: one that hunts for defects, and a separate agent that re-reads the real code to confirm each finding is real before anything gets fixed. That second pass is what keeps us from burning a fix commit on a false positive.

We started like everyone else: lint, typecheck, tests, and build ran in GitHub Actions on every PR.

We ended up moving all of it to local hooks — pre-commit, pre-push — plus a single command that runs the exact same checks by hand. Running it in Actions burns CI minutes, and it's slower: a cold runner against a developer machine with a warm cache. The agent that just finished implementing runs the gate right there, in seconds, with no queue to wait on. GitHub Actions is now reserved for exactly one thing that genuinely can't run on a laptop: the deploy.

That's not free. It depends on the hooks being installed on every checkout — it's a deliberate decision to move where verification gets paid for, not a way to avoid paying for it.

Every implementing agent runs this exact sequence before a PR is even opened:

The project that has run this loop the longest is Crashout, our multiplayer racing game for live events, as of August 2026. These are later, larger numbers than the ones published in the Crashout case study itself, which was written from an earlier cut:

Every PR that was opened got merged — zero abandoned. 71 of the 160 merges landed in the last 7 days, 65 in the single busiest week. The 2,368 tests break down as 463 in Go, 1,656 in Vitest, and 249 in Playwright across 50 E2E specs. The median PR is 456 lines across 7 files.

Two things worth saying in the open, not in fine print. "Shipped" here means merged and deployed to a test environment, ready for QA to test it — not shipped to production.

And these are the numbers from a project with a single human engineer coordinating the loop, not an average across the whole studio.

The loop doesn't replace the engineer — it changes what they do. Less and less writing code line by line; more and more designing the loop itself, calibrating what counts as an acceptance criterion, and deciding which review finding actually matters.

We're just getting started closing this loop further. If you're curious what a system like this could look like for your team, let's talk.