Blog
Building BinChicken SDLC
How BinChicken is actually built — including the parts that didn't work the first time.
Run #9: The Fix Held, and a Different Wall Showed Up
Builder's first attempt ran 279 seconds — almost exactly the shape that killed Run #8 — and this time the retry deferred to a fresh invocation instead of getting killed mid-flight. Attempt two got its own full budget, dispatched cleanly, and timed out anyway. The platform-duration problem is fixed. A slower, narrower one was waiting behind it.
Run #8: A Clean Timeout, and a New Way to Be Wrong
The fixes built for Run #7's stall worked exactly as designed — a provider call that would once have hung silently for over an hour now failed cleanly at precisely the configured second. Then it happened again on the retry, in a way the fix couldn't reach, and a role-aware context fix that worked exactly as intended tripled one role's token cost anyway, for a reason nobody had reason to suspect until it did.
Run #7: The Wall With No Button, and Building One Mid-Run
Four roles ran cleanly, same as last time. Then Builder started and never stopped — no error, no timeout, over an hour of a real bill running with nothing on screen to click. We didn't have a way to stop it. So we built one, live, against the run that needed it, then used it to actually end things properly. A read-only investigation afterward found the stall exceeds even the provider SDK's own worst-case timeout, a real gap in the cancel fix itself, and exactly why every role's cost looks the same — and it isn't why we thought.
Run #6: The Receipts Finally Showed Up, and a Browser We Hadn't Tested In
Before this run, we closed the three gaps Run #5 surfaced: approval and safety decisions now show their own evidence, loading states stopped looking like broken pages, and the durable audit trail actually persists. This run proved the last one for real — then hit a browser-specific rendering bug live, mid-decision, that none of our previous checks had caught.
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.