A metaphor can carry policy
Cockroach Labs describes a coding pipeline called MOLT Sinai. GitHub issues become patients. Planning agents perform workups. A separate Review Attending checks each plan. Another agent writes the code. A Discharge Nurse checks that review, CI, and records exist before merge.[1]
That vocabulary is memorable, but the transition rules do the work. The pipeline rejects code written before an approved plan. It sends changed scope back to plan review. It separates test changes from implementation changes. It requires a structured handoff when an agent gets stuck.
A role name matters when it removes authority from the actor who wants to move the work.
The report is impressive and incomplete
The authors report more than a million lines of code over nearly five months. They say the system handled 1,238 pull requests and spent more than $135,000 on model tokens, about $84 per issue. They also report that an IBM Db2 migration feature moved through the pipeline in less than two days for $4,172.[1]
The same article gives the boundary that the headline numbers need. No human reviewed the Db2 code during that initial test, and the team says it is still confirming that the support is correct. The pipeline later ran with human approval before customer-facing work shipped. Output, review records, reverts, and confirmed product behavior are different measurements.
Throughput needs a different gauge
Cursor's SQLite swarm experiment makes the contrast plain. Its newer harness produced fewer commits and fewer conflicts than an older version while scoring better on a held-out SQL suite. Cursor reports that its old Grok run created about 68,000 commits in two hours and more than 70,000 conflicts before the team stopped it. The lower-churn run performed better.[2]
Commit count can measure motion while missing progress. Hospital count can do the same. Count rejected plans, repeated review rounds, unverified claims, escaped defects, human interventions, and the cost of each path. A busy ward is not a healthy system.
The workflow engine has its own traps
MOLT Sinai uses GitHub Actions and issue labels to move work between stages. GitHub's concurrency controls can keep one job in a group running at a time, but the default allows only one pending run. A newer run replaces the pending one. Group names also span workflows unless they are made unique.[3]
That matters when labels carry state. A clean diagram does not prove every event ran once, in order, or with the intended authority. The workflow needs idempotent stages, a case record, explicit concurrency keys, timeout ownership, and a way to reconcile a missed transition.
Instructions become maintenance debt
The team audited 25 agent skill files with more than 100,000 words. It marked 23 percent as removable without changing a gate, command, template, or sentinel. One discharge role loaded about 29,000 tokens of instructions before reading the pull request.[1]
That is the sharpest lesson in the report. Procedures need tests and deletion work. Keep the rule beside the gate it controls. Give each gate one owner, one input record, one output record, and one failure route. Remove prose that does not change behavior.
Build the gate before hiring the cast
Start with four transitions: reproduce, review the plan, inspect the change, and review the release packet. Give each transition an independent witness. Add a countable stop when review loops stop converging. Keep merge authority with the named human until your own evidence supports a narrower policy.
The admission gate below turns that sequence into a copyable review packet. It does not run tests, inspect a repository, or approve a merge. Its completed state means the packet structure is ready for real evidence.