878 tests, zero installs: what agent-built code checks and what nobody encoded

The race condition was catchable because it existed in prose. One agent produced a design, another agent read it, and a roughly 390-second index-creation call sitting next to a 300-second staleness default was right there on the page ^[5]. Five rounds of that before any code was written ^[4]. The packaging conflict had no equivalent artifact. Nothing in the four-agent loop produced a document describing what happens when a stranger types pip install, so nothing reviewed it, and the defect survived into a release with 483 tests green behind it ^[6].

The three bugs found in that first cold hour are one bug in three costumes. Each is an assertion about something outside the working tree. A default model name is only wrong once a real SDK answers ^[7]. An optional dependency is only absent on a machine that never installed it ^[7]. A dependency resolver only conflicts when it actually resolves ^[6]. On the author's own telling, the suite proved the code agreed with itself across the same tree and the same mocked seams, and nothing in it ever touched a clean machine ^[8].

Here is the arithmetic the post does not do. The suite was at 483 when install was broken, and the project reports 878 at v0.3, so roughly 395 tests were added after the discovery ^[11]. None of them is the thing that fixed the class of failure. That was a single CI job which builds a clean virtualenv, installs for real, and runs the quickstart on every pull request ^[9]. One job covered a category that 483 tests had not entered, which is a reasonable way to price test counts as evidence of readiness.

The asymmetry is the part worth carrying to other projects. Concurrent index provisioning is genuinely hard, and it got five design reviews and a caught defect before implementation ^[4][5]. Packaging is not hard, and it got nothing, because nobody encoded it as a gate. Reviewer agents inherit the attention of whoever wrote their brief, and that attention followed the interesting problem. The default staleness threshold is a small monument to the same habit: at 300 seconds against a 390-second call, the claim lapses by 90 seconds every time creation is slow, in the shipped default, before anyone tunes anything ^[12].

This is one developer's account of his own project, published to promote it, and it should be read that way ^[1][2]. The checkable part is that all three install-path bugs are named in the release notes, and the project says at v0.3 what is still missing ^[9][10]. That is more than most repositories with a green badge offer. The transferable asset is not the framework. It is the observation that an agent pipeline reviews artifacts, and install, first run, and real-SDK behaviour produce no artifact unless someone makes one.