The problem
Coding agents produce plausible fixes quickly. But an agent's report of its own success is weak evidence, and giving it repository or deployment credentials widens what can go wrong. The dispatcher handles a narrow version of this for one operator. A person approves a bug report, an isolated agent proposes a fix with a regression test, the dispatcher checks that work independently, and a person accepts or rejects the resulting draft pull request. The scope is one host, one execution slot and registered projects, starting with Deck Lab.
Contribution and AI assistance
Dylan ran the single-host pilot and owns the repository. The recorded PR timeline shows him marking the DYL-11 draft ready and merging it on September 8; release records show verified owner approvals for subsequent fixes. The case study describes the implemented design without assigning undocumented manual authorship.
How AI contributed
Coding-agent sessions contributed implementation and documentation, but the reviewed records do not provide file-level attribution or a reliable breakdown by tool. Separately, the product's DYL-11 run used a Cursor coding worker and an independent model reviewer. The evidence records those two roles and their outputs rather than treating either model's verdict as proof.
Two consequential decisions
Decision 1
A new test must fail on the original code
Each candidate must add a test that fails when copied onto the untouched base commit, then passes in a new offline container. The agent's own claims are ignored. This rejects fixes that prove nothing. DYL-11 showed the limit: the test checked CSS text rather than the rendered layout, and the reviewer passed the fix while calling the test weak. A test that fails before and passes after proves something changed, not that the change is correct.
Decision 2
Authority tied to evidence, not to status
Approval is tied to one report revision and one policy fingerprint, and editing either revokes it. Before writing, the publisher rechecks the base commit and the artifact digest. It records its intent first, so an ambiguous response is reconciled rather than repeated. On 2026-09-09 the release controller refused a status change that arrived without a verified owner webhook. The cost is one execution slot on one trusted host, with no high availability.
Verification
- Publication audit, 2026-09-14: 191 tests passed with Docker tests enabled, and Ruff, Black, pip-audit and a credential scan passed. Coverage was 65% with Docker tests and 60% without. The audit says it is not a penetration test.
- For the public replay on 2026-10-02, 19 tests pinning failure paths passed at commit c8c4b94. The live evidence is queue events exported from September 2026, not a new run for this review.
Outcome and progression
12.4 min
Report intake to draft pull request, DYL-11
One live pilot job against the Deck Lab repository on 2026-09-08: 4.7 min of coding, a 79.4 s review over 236,118 input tokens, and 1,350 tests passing. The owner merged it 9.6 min after the draft opened. One job is not a rate, and provider billing was not measured.
3 of 3
Blocked sample issues that reached a pull request after pipeline changes
Recovery experiment recorded on 2026-09-08. Changes to review evidence, repair and reconciliation took DYL-10, DYL-12 and DYL-13 to pull requests, which were released after the owner authorized it. The experiment also exposed a backup disk-space failure. The sample is small and was chosen, not random.
Milestones
- 2026-09-08First repository commit. The first live pilot job (DYL-11) opened a draft pull request.
- 2026-09-14Publication audit and preparation for the public release.
- 2026-10-02Demo rerun without credentials, and public replay exported.
What I would measure next
Replace CSS-text regression tests with a repeatable browser layout check. Then, over a fixed set of new reports, measure how many candidates pass review on the first round, how many need repair, and the median time from intake to draft, with provider billing recorded for each job.
Explore the evidence
- Open the replay and read 'Where the boundaries are' to see which component holds which credential.
- In 'The run', compare the Demo run and Live run · DYL-11 lanes at 'The new test must fail on the original code'.
- At 'Independent model review', open 'What the reviewer checked, and what it couldn't'.
- Read 'When things go wrong' for the runs that were blocked, reconciled or refused, then 'How this page was made' for its limits.
Evidence and further reading