🤝 Top Collaborators
🤓 Latest Submissions
Four-Seat Dark Factory — tablekeeper
Our factory is four Claude Code seats in one BAND Desktop room, each with a generic mandate that names no endpoint, field or error code. - foreman routes the work, sends self-contained handoffs and accepts only commits the verifier checked from a clean clone. - auditor reads the spec independently, writes a numbered requirements ledger, flags what the shipped checks don't exercise, and writes its own API and browser acceptance tests from the spec alone. - builder is the only seat that writes product code; it copies each stage forward and extends it. - verifier clean-clones every revision, builds it with no network, runs every suite plus the auditor's tests and its own probes (concurrency, retries, DST, limits, 320 px screens), then answers ACCEPT or REJECT with evidence. The shipped checks cover only 83/41/11/21% of the graded suites, so the factory builds to the written spec. In the submitted dark run it reached all four stages in 2 h 28 m with no blockers. Stage 4 ends with 218/218 API and 39/39 browser acceptance tests passing, the replan planner matching brute force on 1,800 random cases, and no 5xx under 50 concurrent requests. Review changed the work twice, both beyond the shipped checks: the verifier rejected a stage-3 revision that labelled a policy-closed day "no times left" instead of "closed", and the auditor rejected a stage-4 revision, which the verifier had accepted, where one unchanged occurrence past its cutoff blocked a whole recurring-reservation change. Each was fixed in one round and left a regression test. Git history has 24 seat commits, each authored by its seat, and room.json holds the full collaboration. Point the same mandates at a different spec and the same band works.
6 Oct 2026
VivaVoice: Rehearse Your Viva Out Loud
Final-year students must defend their projects in a viva, and job seekers face interviews. Both tests are spoken, yet almost everyone prepares by reading. Mock vivas need a lecturer's time, and generic bots ask textbook questions unrelated to your work. VivaVoice is a real-time voice examiner for your own material. Drop in your report PDF (the abstract, methods and results are extracted in the browser) or paste a job description, choose a supportive or strict examiner, and start talking. Questions come from what you submitted, and vague answers get a follow-up built on your exact words, like a real panel. While you speak, the agent calls client-side tools: show_question puts the question on screen and record_score fills a five-criterion rubric with evidence and a tip. VivaVoice also coaches delivery: speaking pace, filler words and thinking time. Ramble too long and the examiner cuts in and asks for your main point. At the end you get a report with a mark, a radar chart, priorities to fix and your weakest question answered two ways: what you said next to a model 5/5 answer. Sessions are saved so you can track progress and drill your weakest area. Everything runs on one AssemblyAI Voice Agent API WebSocket, configured per student: keyterms extracted from the report so jargon like YOLOv8n and NCNN is transcribed correctly, a transcription_prompt, "thinking time" turn detection, barge-in, tool results timed to reply.done, automatic session.resume after a network drop, and a wrap-up before the session cap. A zero-dependency Node server mints short-lived tokens, so the API key never reaches the browser. MIT licensed, 42 tests.
30 Sep 2026
DevPulse: grading IBM Bob as a security auditor
Every AI code review demo we've watched goes the same way. The tool lists some problems, everyone's impressed, and nobody asks what it missed or how many of those problems were real. But those are exactly the things a team needs to know before they let an AI reviewer anywhere near their releases. DevPulse tests IBM Bob like an exam. We wrote two small Express apps and hid security bugs in them: 10 textbook ones in the first (SQL injection, MD5 passwords, a hardcoded secret), and 12 subtler ones in the second, an invoicing API (an IDOR, an admin check using jwt.decode instead of jwt.verify, SSRF, path traversal, command injection, prototype pollution and more). The second app also has 7 traps, bits of code that look dangerous but are actually safe. The answer keys stay with us. Bob never sees them. Bob does the real work. It runs in a custom Security Auditor mode that can read the whole project but can only write to the audit folder, so it can't touch the code it's checking. A skill tells it what to look for, Bob splits the files across subagents running in parallel, and writes its findings to JSON. A second skill hands each finding to its own subagent to write a patch. A small script then marks everything: recall, precision, how many traps Bob fell for, and whether each patch actually applies with git apply --check. Bob found all 22 bugs, raised no false alarms and left all 7 traps alone. The patches were the interesting part. In round one Bob picked the right fix every time, but 8 of 10 diffs failed to apply because the line numbers were off. We added one rule to the fix skill, that a patch doesn't count until it passes git apply --check, and in round two all 12 patches applied first time. Who it's for: engineering and security teams already using AI to write or review code, who now have to decide how much to trust it. They plant bugs and traps in their own code, run the Bob skills, and get a real hit rate before an AI reviewer is allowed to block a release. Findings export as SARIF, so they land in GitHub code scanning, and the website lets anyone click through each finding, the exact line Bob flagged and the patch it wrote. What makes it different is that we don't just show Bob's output, we grade it. Most AI review tools are judged on how impressive their findings look. DevPulse measures misses, false alarms, traps and whether the fixes are usable, and it caught a real problem (patches that looked right but wouldn't apply) that a normal demo would have hidden. Every Bob task is recorded in the bob_sessions folder with what it cost, including the one that didn't work, and the whole project used about 7 of our 40 Bobcoins. The site only displays files that Bob and the scoring script wrote.
27 Sep 2026
