07 / 10
My coding agent already reviews its own work. Why isn’t that enough?
npx halfcycle Because it is reviewing the file in front of it, and that is not where the damage is. A rule enforced in the save path and never copied into the new restore path. A button keyed on data the feature refuses to touch. Each is correct on its own, green in every test, and invisible to anything reading one file at a time. Halfcycle reads the joins.
The bug was never in the file.
Start with what it is good at. An agent checking its own work catches a lot inside the file it has just written: a typo, a missing case, a function that does not do what its name says. Keep it doing that.
The damage on real projects mostly sits somewhere else. Take one small feature: letting somebody restore an earlier version of a document. In the existing code, a rule that stops archival documents being overwritten lived in the save path. The new restore path never repeated it, so restore could quietly overwrite exactly what the product promises never to touch (the full write-up). On the same feature, the restore button was set to appear based on a piece of data the system only attaches to the records the feature is forbidden to act on, so it would never have appeared for anybody (that one too). Nine problems were found on that feature before any code existed, and four of them would have reached users.
A test suite does not catch this kind of problem, because what is wrong is a rule that is not there. Every test of the new code passes, since a test proves what the code does, not what it forgot to do. An agent reviewing the file it wrote is reading the one place the problem is not.
What finds it is a review run by something that did not do the work, reading the plan against what already exists in the project rather than one file in isolation. That is also the answer to who checks the work.