How the work actually happens

Most of the cost of software is coordination. This is the pipeline we use to remove it — and the places where it does not help, which matter just as much.

The loop

Work is drained from a project board one card at a time. Nothing is batched, and no issue ever sees another issue's context.

01A card goes into ReadyOne issue, one scope, written down before anything gets built.

02A fresh session implements itIts own branch. Code plus a test. The session runs the suite itself before committing.

03On red, a second sessionIt receives the failure log and nothing else — not the issue, not the first attempt.

04Green merges, red haltsAn unrecoverable failure stops the whole queue and leaves it for a human.

Three decisions that make it work

A fresh process per issue

No context carries between issues, and none carries between an issue's main session and its auto-fix session. This is deliberate. Carried context is where an agent starts confidently describing code that belonged to the last task — the failure mode is not that it gives up, it is that it invents. Throwing the context away is cheaper than policing it.

The failure log, and only the failure log

When the suite fails, the second session is scoped to the failure and nothing else. Given the original issue as well, an agent tends to re-litigate the design instead of fixing the break. Narrowing the input narrows the diff.

Halt, rather than retry forever

A merge conflict, a failed production deploy, or a test failure the second session cannot clear stops the queue. Nothing further is attempted. A pipeline that retries until something passes will eventually pass for the wrong reason, and by then it has moved on.

The gates are the product. The agent is doing the typing; the test suite, the scoping and the stop conditions are what make the output safe to deploy. That is why this transfers to another team's repository — we bring the policy, not the model.

The record

On kudo.kids, as of September 2026: 232 changes landed on mainacross 115 distinct issues. 63 went through a pull request. 169 were merged directly by the agent once the suite was green. 209 of those were production deploys.

Where this does not work

It is worth being specific, because the limits are real and you will find them anyway.

It needs a test suite worth trusting. The gate is only as good as the tests behind it. On a codebase without meaningful coverage, this pipeline automates the production of plausible-looking, unverified changes — which is worse than writing them by hand.
It needs issues written at one-scope granularity. That is a skill, it takes real time up front, and it is the part that does not automate. A vague issue produces a vague diff.
It does not do product discovery. Deciding what should exist, and what should not, is the work before this loop starts.
It does not replace review on anything security-relevant. Auth, access control, key handling and anything touching personal data get read by a person. Every time.

Email us about your projectSee the work →