03 / 08
The button would never have appeared. For anyone.
Found before a line of code was written. One feature, two screens and a button.
npx halfcycle It was set to show up based on a piece of data the system only attaches to the exact records this feature refuses to act on. The code is correct in isolation and the tests pass.
Would a code review have caught it?
No. It ships, it gets announced, and nobody can see it.
The restore button was meant to appear on documents that had earlier versions to go back to. To decide whether to show it, the interface looked for a particular identifier on the record.
The trouble was where that identifier comes from. The part of the system that assembles records for the screen only attaches it to one class of document: the archival ones the product promises never to change. Those are exactly the documents this feature is forbidden to restore. Everywhere the button was allowed to appear, the identifier was missing, so it never appeared at all.
Nothing about this is wrong in isolation. The component is correct and the types check. The unit tests pass, because they supply the identifier themselves. You would ship it, announce it, and then wait for somebody to ask where it is.
A code review would not have helped, because the fact that makes it fail lives in a different service from the code under review. The rule for when that field is present is written somewhere the change never touches. Somebody has to know it, or go and read it.
Most of the problems on these cards share that shape. The fault is not in a line of code. It sits between two pieces of code that are each correct, which is exactly where a model writing one file carefully cannot see, and neither can a person reviewing that one file.
Read the other seven, or the same argument in general terms: why an agent reviewing its own work is not enough.