🤓 Latest Submissions
Tablekeeper — Built by A Dark Factory
Tablekeeper is a restaurant reservation service where a table can never be double-booked — under concurrency, retries and time zones. All four stages of the track are complete and passing: 158 shipped checks green in the graded isolated configuration — no network, 2 CPUs, 2 GiB. No human wrote a line of its application code. A three-seat AI software factory, running in one BAND Desktop room, built it one stage at a time. The human sent one task per stage and nothing else — four messages in total. The factory is the deliverable. Tablekeeper is what came out of it. Architect (OpenCode, MiniMax-M2.5) plans and routes every handoff. Developer (Claude Code, claude-sonnet-5-5) writes all application code. QA Lead (OpenCode, MiniMax-M2.5) reviews on a different model family than the implementer, so the checker does not share the builder's blind spots. Three decisions carry the whole thing. The mandates name nothing about this track — search them for "tablekeeper" and you get nothing, so swapping the dispatch keeps the factory. QA writes acceptance tests from the specification rather than from the shipped checks, and builds every reviewed revision from a clean checkout. And the full specification is pasted into every handoff, never referenced, because each seat sees only what is addressed to it. It caught real defects. Stage 1: QA found 10 of 120 checks failing and rejected the revision with three root causes. Stage 3, with every shipped check green: QA reported PASS on the harness, kept reading the specification, and failed the build anyway over two deviations the checks never exercise. A passing test suite is not a passing spec. The service is Go standard library, SQLite with WAL and bcrypt — a static binary in one container that builds and serves with no outbound network, with a server-rendered browser UI over the same JSON API. 1 h 44 min. $0.88. Sixteen commits across the stage folders, not one of them human.
6 Oct 2026
EchoCode: Voice-First AI Pair Programmer
Students now "vibe code": they tell an AI "fix this" and paste in whatever comes back. Getting a real explanation takes more effort than copying, because it means typing a long prompt, pasting code into a chat window, and matching the answer back to the right lines. So they skip the why and ship code they cannot explain. EchoCode makes asking why as easy as turning to the person next to you. It is a VS Code extension: hold one key, ask out loud, and let go. EchoCode already knows your file, selection, errors and the rest of your project, so nothing is copied or pasted. A voice explains in plain language, the lines it mentions light up at the moment they are spoken, files it names open by themselves, and a suggested fix appears as a code card with a Replace lines button. Most voice coding tools stop at voice in: your speech becomes text, a command or a prompt. EchoCode is built on voice out. It uses the word-level timing of the AssemblyAI Voice Agent API as a control signal for the editor, so the AI's own speech drives what you see. The AssemblyAI LLM Gateway writes each code card in a separate call after the answer, so it never slows the voice down. Audio streams straight from VS Code to AssemblyAI, and the API key stays on our Vercel backend behind single-use tokens. Our users are students and bootcamp learners, who use EchoCode free. Our buyers are the bootcamps and university departments that teach them, at $25 per learner per cohort or $36 per seat per year.
30 Sep 2026
ChatToPR
During a production incident, engineers agree on the root cause and fix in Slack, but turning that conversation into a branch and a pull request still means leaving the chat, switching tools and writing everything up while production is down. ChatToPR removes that hand-off. With one click, it ingests an incident thread (every author, timestamp and message), extracts ticket and PR references (#4821, #312), code references and participants, and highlights the root-cause, fix and rollback messages. It then builds a structured incident record, triage/INC-<id>.md, commits it to a new branch, and opens a real GitHub pull request through the GitHub API. Nothing is ever merged automatically: a human always reviews. We built ChatToPR with IBM Bob IDE as our development partner, from an empty folder to a deployed app across 8 task sessions: the project scaffold and Slack-style UI, the Next.js API route, the Octokit branch-commit-PR pipeline, frontend-to-API integration, the landing page and documentation. Bob even diagnosed a "Bad credentials" error from a pasted screenshot. All task sessions are exported in the repo's bob_sessions folder. Next: AI-generated patches and regression tests with IBM watsonx.ai Granite, a real Slack app, and an IBM Bob custom mode that implements the fix from the triage PR.
27 Sep 2026
