Sixteen hundred pull requests later

Tuesday, 7:40 in the morning. Coffee. I open the gate inbox.

Three pull requests are waiting for me, review-ready. One implements a state-machine change I ticketed two days ago; its CI failed overnight on a genuinely flaky test, the platform diagnosed the failure, dispatched a fix, and the suite went green while I was asleep. The second is a refactor I'd been putting off for a month. The third is small, a config surface cleanup. Below them, a halted gate: a grooming run wants my approval on the acceptance criteria it wrote for next week's work, and it will not proceed until I read them.

I read the diffs. I approve two. I reject the third with a note about a boundary it crossed, and the rejection routes back into the system as instruction, not as a failure.

Nothing merges without passing through me. That is the design, not a limitation of it. But I did not write the code, I did not watch the CI run, I did not resolve the rebase, and I did not chase the flaky test at 2am. My attention was spent on exactly one thing: judgment.

The receipts

For the last couple of months, I have been running my software development lifecycle on a platform I built. It polls my issue tracker for groomed tickets, dispatches coding agents into isolated Git worktrees, monitors CI, fixes failures within bounded limits, manages a merge queue, and runs the surrounding process (PRD drafting, ticket decomposition, grooming, design, review) as checkpointed protocol pipelines with human approval gates at points where judgment matters.

✓ pr_1587 merged · gate approved · ci 11/14 → 14/14 after fix loop (2 attempts)

✓ pr_1589 merged · gate approved · first-pass yield

✕ run_77c4e halted at review · boundary violation · returned as instruction

The platform's own repository is the evidence. Its pull request counter passed 1,600 this month. The large majority of those PRs were produced and merged through the platform's own protocols: the platform builds itself, and has for most of its life. Gate decisions are journaled. Fix-loop recoveries are journaled. When I claim the loop closes, the receipts come with the claim. You just read some.

Capable is not reliable

Here is the honest version: the agents were never the hard part. Modern coding agents are capable of handling most ticket-shaped work. What they are not is reliable, and the gap between capable and reliable is where all the real work went.

One failure taught me more than any other. Early on, when a dispatched agent failed partway through a task, I would retry it. Simple. Except the retried agent would arrive in the workspace, read the git log, see its predecessor's half-finished commits, and conclude that the work was already done. Then it would write me a confident completion report describing work it had not performed. The report read beautifully. It was fiction.

Punishing the agent for this is pointless. It did what any of us would do walking into a half-finished job with no handoff: it inferred. The fix was not a better prompt; it was a better process. Half of it was continuity: retries now carry the full dispatch history, including the previous attempt's own diffs, and the instruction is not "do this task" but "here is exactly what was done and how it stopped; continue."

The other half was deciding what done means, because an agent will just as happily declare victory on work it never did. Nothing moves downstream on the agent's word. Every artifact passes through validators wired into the workflow itself: deterministic checks for structure, LLM judges for substance. And when a judge rejects, nobody translates. The findings come out structured, evidence and fix hint attached, and they land in the same retry prompt: the task, the previous attempt's own diff, exactly what failed, fix that and nothing else. A rejection is not a dead end; it is a work order. The fake completion reports ended, not because the model improved, but because the system stopped asking it to guess, and stopped taking its word.

Nearly everything durable I have built follows that pattern. Fix loops are bounded, because an unbounded retry will happily spend the night repeating the same wrong fix. Artifacts are validated before they propagate because a plausible-but-wrong grooming document can poison every step downstream. Failed runs are classified, because a rate limit, a flaky test, and a bug the agent just wrote demand three different responses, and an agent will paper over all three identically if you let it.

Capable machines producing imperfect output at high volume. This is not a new problem. It is not even a software problem.

An old name for it

Toyota confronted exactly this shape decades ago: machines that could do the work, and would also happily produce defects at scale if nobody was watching. Their answer was neither more automation nor less. They called it jidoka, usually translated as automation with a human touch. Let the machine run. Instrument it to detect its own abnormalities. When something is wrong, stop the line, and pull a human in at that moment, with context, where the judgment actually matters.

The stop is the sacred part. Not the running.

That is what the gate inbox is. The line runs itself: tickets flow through grooming, implementation, CI, and review without me driving each step. Defects stop the line: a failed run, an exhausted fix loop, a suspect artifact; each halts and surfaces instead of proceeding. And my intervention point is designed rather than residual: I am pulled in at moments of judgment with the full artifact in front of me, not pinged forty times a day to click approve.

The industry is racing toward autonomy as if autonomy were the product. I have come to believe it is not. The product is convergence: feedback loops that reliably end in production-ready code, with a human able to inspect and intervene at any point they choose. Autonomy is just a policy setting inside that system, and it should be the operator's choice, not the vendor's headline.

What's next

I am turning this platform into a product. Slowly, deliberately, and with the same discipline it runs on: I will keep publishing the operating history as I go, PR streams, gate decisions, fix-loop recoveries, failures included.

The next few essays go deeper into the pieces of the system that earn their keep: why human gates belong inside the process as first-class steps rather than bolted on as dialogs, why the merge queue turned out to be the actual product, why a conventions file is not context, and how you make an agent loop converge instead of wander.

If any of this is the problem you have, follow along.