
Tablekeeper is a restaurant reservation service, built entirely by four Claude Code agents working together in one BAND room: a coordinator that plans and accepts, an implementer that builds the back end, a frontend agent that builds every screen, and a reviewer that checks everything and never fixes. I'm Vivek, entering solo from Melbourne, in the Tablekeeper track. The hackathon's hard rule is that a table must never be double-booked, including under concurrent requests, retries and time zones. The factory builds it in four stages: the reservations API, the booking screens with combined tables, booking policies with recurring bookings, and manager table-closure recovery. I sent one message per stage and nothing else. Each seat has one generic mandate file that says how it works and nothing about reservations. The coordinator accepts only a commit the reviewer actually checked, and I re-ran the official harness myself after every stage, outside the factory. All four stages were accepted, with 158 of 158 official checks passing at revision d268821. A fresh clone of the repository passes the same way. The run took about 7 hours 40 minutes from first dispatch to last report. BAND shows $180 for the room, which is BAND's own estimate at list prices. The repository has the four stage folders, the mandates, the unedited room log (room.json), and FACTORY.md, which covers the setup, what went wrong, and measured time and cost. Inputs I supplied before the run: a written design brief, six reference screenshots, five unDraw illustrations and one icon. The agents copied these in unchanged. Limits: the official harness runs only part of the judging tests, so I can vouch for the shipped checks and nothing beyond them. FACTORY.md section 9 lists the rest.
6 Oct 2026

Every team inherits a database nobody wants to touch. It works, nobody's quite sure why, and touching it feels like defusing something. Migrating it properly usually means someone spending most of a day just reading old stored procedures and triggers to figure out what will actually break, before a single line of the real migration gets written. That's the problem this project takes on with IBM Bob 2.0, and the goal from the start was to actually solve it, not just describe it nicely. Plenty of tools in this space stop at a good-looking risk report. We didn't want to build another one of those. So Bug Squash built a Legacy Migration Risk Assistant that audits a legacy database, scores its migration risk with real evidence, and then actually carries out the migration end to end into Postgres. We used Microsoft's own Northwind and Pubs sample databases as the test case, deliberately, because they're genuinely old — 1998-era SQL Server, with real deprecated syntax and business logic buried in procedures and triggers, not a toy example dressed up to look impressive. Bob audited both databases, generated the Postgres schema, wrote the data-migration script, and ran it. The result: 13 tables, 13 foreign keys, and 3,308 rows moved, with the row counts verified against the source — and verified twice, by wiping the target and re-running it clean, because a claim that only works once isn't a claim worth making. Why does this matter? Because the teams who'd actually use this need to trust an audit enough to act on it, not just admire it. Turning an 8-hour manual review into a 3-minute automated one, with the exact offending line quoted rather than a vague warning, is the kind of time saving that decides whether a modernization project gets greenlit at all. Where this stands apart from other entries covering similar ground is the follow-through. It would've been easy to stop at the report. Instead, Bob generated the migration, ran it, and then — in a separate step — verified its own result against the source data. That last part is the whole point: an audit you can trust is only half the job. The other half is proving the fix actually works.
27 Sep 2026