Sprint 48 — the twelfth round, and knowing when to stop
Seventy PRs merged this week, and the one I’ll remember is the one that took twelve review rounds to land.
It was the connector-governance backend — the plumbing that lets me pause or remove any household member’s connected mailbox, and that quietly pauses everything for thirty days when someone asks to delete their account, so no new data trickles in while they still have time to change their mind. Small feature, on paper. The AI reviewer that gates my pull requests did not agree it was small.
Round one, it found a security check that failed open — a gate on a row-level-secured table that, read the wrong way, silently matched nothing and let deletion-window data keep flowing. I fixed it. Round two, the same shape one function over. Round three, a state I’d introduced that the UI rendered as “broken” instead of “paused.” Then uniqueness. Then a test that claimed to cover a race and never called the code it was testing. Then transaction atomicity. Then the audit trail. Then a sync that could finish mid-pause and undo the whole thing. Then a deleted connection — not just a paused one — that kept ingesting a departed member’s mail. Then a migration that wouldn’t even apply.
Every one of those was real. None of them was the reviewer being pedantic. This is the thing I keep re-learning: a good reviewer doesn’t find the bug, it finds the shape of the bug, and the shape usually repeats.
And then round twelve. It found a genuine race — a check-then-write window a fraction of a second wide — and this time the honest answer was not to fix it. Closing it properly would have meant holding a database lock across a language-model call, or threading connection-awareness through half the ingestion pipeline, all to prevent a single already-in-flight email from landing during a thirty-day window — an email that gets purged if the deletion goes through, kept if it’s cancelled (it’s the person’s own mail), and identical to data already in the household if a member simply leaves. The reviewer itself noted there was no rule requiring the fix. So I wrote the residual down, explained exactly why it’s harmless in every outcome, and shipped.
“Iterate until it’s green” has a failure mode, and it’s gold-plating a harmless edge into an anti-pattern because a checklist wanted a checkmark. The discipline isn’t fixing everything a reviewer raises. It’s fixing everything that’s worth fixing and being able to say, in writing, why the rest isn’t. Connector governance is live in production now — v1.0.192 — twelve honest rounds and one honest stop.
Two other things worth noting.
The reviewer moved onto my own Mac. Instead of paying an API per pull request, it now runs the model against my existing subscription, locally, and — the part I like — when it can’t run (laptop asleep, quota hit) it fails the check loudly with the reason, instead of silently falling back to the paid path and surprising me with a bill. It fired for real this week: mid-review, the subscription hit its daily ceiling, the check went red with “try again at 9:15 PM,” nothing was spent, the quota reset on its own clock, and the review picked up where it left off. A blocking contract that holds under pressure is worth more than a convenient one that doesn’t.
And a migration bug that only the real database could catch. For eleven of those twelve rounds, the integration suite was waiting on the review verdict and never actually ran — so a migration that couldn’t apply (a Postgres quirk about using a brand-new enum value in the same transaction that creates it) sat undetected until an approval finally let the suite run. The fix was to stop needing the enum at all. The lesson was older: a test suite that reports “fail” because it was told not to run is not the same as a test that ran and failed, and you have to know the difference before you conclude anything about your code.
Next week: more dogfooding, and getting the front door ready for a few more people to walk through it.