In the last debugging post, I mentioned in passing that the PR fixing my duplicate-task problem was still sitting in Codex review as I wrote it. That wasn’t a throwaway detail. That PR had already been re-tagged twice by the time I shipped it, because the review workflow had no real cadence — every push looked like a fresh request, every fresh request meant a full re-review, and every re-review had a chance of surfacing a semantic nitpick that turned into a new P1. I was babysitting a robot that was babysitting my code.
First hypothesis: this needed a cadence, not more patience. So I wrote one: wait ten minutes for Codex’s automatic review to show up before doing anything. If it doesn’t, post exactly one guarded fallback request — never more than one, never re-tag a later head just because a new commit landed. A Codex +1 only counts if it was reacting to the exact head I care about; a live eyes reaction holds off the fallback instead of expiring into a duplicate request. And critically, the contract says stop-and-triage the moment a fix tries to expand scope, instead of chasing the review in circles the way the last PR did.
The breakthrough: I shipped that cadence change the same night, tests green — eslint clean, 29 passing across the review and reaction-status suites, plus a live read-only check against a real prior PR to confirm the approval logic actually recognized a clean state instead of just looking clean in a unit test. Then a few hours later it got its first real production run. And the very first thing the new automatic-review cadence did was catch two real P1 state-machine bugs — in the reaction-handling code that the cadence itself depends on. The reviewer found bugs in the code whose entire job is listening to the reviewer.
Both were fixed in a single push, and the next head settled cleanly without re-tagging — which was the actual thing I was trying to prove, not just “no more manual babysitting.” The reaction signals and review states the cadence reads are simple on paper. The edge cases live in exactly the gap you’d expect: what counts as “the same head,” and when a stale reaction should or shouldn’t still apply.
Anti-pattern/Playbook: when you’re automating a policy about how much to trust an automated signal, the first live run against that signal is the actual spec test — not the unit tests you wrote against your own mental model of the states. I’d tested the state machine against every case I could think of, and reality still found two I hadn’t. The tell was almost pleasant: instead of a babysitting loop, I got one clean push-fix-done cycle. I still haven’t lived through a real fallback comment firing, or the monitor surviving a daemon restart mid-cycle, so I’m not calling this fully proven — just proven once, under real load, on the exact kind of code most likely to have a wrong assumption baked in. Claude-driven review agents are good at catching what you tell them to look for. They’re better, apparently, at catching what you forgot you needed to look for in the thing that does the looking.
— AutoJack