They turned auto-merge off, and not because the code was bad

Not because the code was bad. A five-month experiment running coding agents on a production system stopped auto-merging because the changes arrived faster than two people could verify them. That is the constraint Backthread is built around: the reasoning behind each merged change, kept per area of the codebase, so a team can see where its understanding has run out.

The thread

On 9 October two engineers published five months of running coding agents as a teaching hospital — issues as patients, planning and coding and review as separate roles with separate context, a ledger recording tokens, time and cost at every stage. It reached 213 points and 107 comments, and the discussion under it is unusually concrete for the genre: a real team, a real production codebase, costs attached.

The part worth keeping is not the metaphor. It is the answer one of the authors gave when a commenter asked what they got wrong on the way.

The sentence

They had started in auto-merge mode. It worked, in the sense that changes landed and the system kept moving. Then:

This is not to say that they were bad, but that we had no way to convince ourselves that they were good.

That is ajstorm, in the thread on 9 October 2026. They put the system into human approval mode to stop the momentum, and only then found what had been going wrong.

Read that sentence twice, because it separates two things that get collapsed constantly. One is whether the code is correct. The other is whether anyone can establish that it is. A team can be entirely right about the first and still have no position on the second, and the second is what you are actually buying when you ask for review. Auto-merge did not fail a quality bar here. It outran a verification budget, which is a different quantity and the one that does not scale with model capability.

What they found once they looked

The specific defect is worth the price of admission. Issues were decomposed into a dependency graph, and sibling issues would each defer a piece of work on the assumption that the other would handle it. Neither did. There was no channel between siblings, so the work was dropped silently and the graph still closed green.

Nobody catches that from the diff. Each sibling pull request is individually defensible; the gap only exists between them. Their fix was not more review:

If any issue is going to defer scope it must comment about the deferral in the code, and write it to a special ledger with the rationale, and how/when the deferral should be actioned.

Same comment, same author. A record of the choice, written at the moment the choice was made, with the reasoning attached — because by the time the consequence shows up, the session that deferred the work is gone.

We measured the cost of not having that on our own repository: of 4,302 decisions captured from agent sessions, 1,613 carry any recorded deliberation at all, which means 62 percent record no alternative and no trade-off. A ledger with the rationale in it is the thing that moves that number, and a team arrived at it independently, from the other direction, after being bitten.

What it changes for an engineering leader

The honest caveat, which the authors make themselves: this is one team, a side project, on migration tooling, with no long-term maintainability data yet. They have not run the ablations. Neither have we on most of this. What the thread establishes is not a method you should copy wholesale — it is that a team which went in on agents hard, for five months, with money on it, hit the verification wall first and the quality wall not at all. That ordering is the finding.

If you are deciding where human attention goes rather than how much of it, what Backthread keeps about each area of a system is aimed at that question, and the six questions above the diff are the cheap version you can run without us.

Connect one repo and you get the first picture of which parts of your system anybody still has a model of, usually the same day; the trial runs fourteen days.