Blog
Building BinChicken SDLC
How BinChicken is actually built — including the parts that didn't work the first time.
Run #5: A Real Spec, Real Parallel Steps, and a Rejection We Couldn't See Enough to Avoid
The two bugs from Run #4 got fixed by hand first — a backend id collision and a confirmation dialog that didn't fit the screen. Then a real, deliberate task ran cleanly through four real model calls, two of them genuinely in parallel, until a human correctly rejected an approval because the interface never showed what was being approved.
Run #4: A Collision Before It Started, and a Safety Gate That Did Its Job
Before this run could even start, a lot of manual engineering happened — real GitHub write support, a production readiness check, and a couple of gaps that check turned up and got fixed. Then the run itself hit a genuine backend bug, ran on a garbled specification by accident, and got stopped by a safety gate reacting to a false alarm. Nothing was written to GitHub. That's the actual headline.
Run #3: A Real Failure, a Stale "Running", and Nothing to Click
The ux-provider fix landed before this run even started — and never got exercised, because scope failed first with a new variant of run #1's bug. Worse: the UI kept saying "running" for ten minutes after everything had actually stopped, with no way to cancel it.
Run #2: Three Real Calls, One Silent Mock, and an Approval Nobody Could Click
BinChicken's second real run tried to fix the bug from its first one. Three real Anthropic calls succeeded, one step quietly wasn't real at all, and the run ended up correctly waiting on a human decision the UI had no way to show — so we terminated it by hand.
BinChicken's First Real Run — What Worked, What Broke, and Why That's the Point
We pointed BinChicken at its own repository for the first time, using a real Anthropic key. It got through the setup, made a real model call, and then failed cleanly on a JSON-parsing error — exactly the kind of failure a governed system is supposed to surface, not hide.