Sabotage

Among Us for code review. Your team votes to merge or reject each change, while one reviewer secretly wants the bugs to ship. Play with friends, or start right now with bots.

Comment

Play it: https://trmi.onrender.com/
trmi session ID: so6lqfgdbb5w / ashank-crazy-hackathon-vlifpx

Inspiration

More and more code is written by agents, and code review is becoming the last human check before it ships. Most people are worse at that check than they think. An approve click takes a second, and a subtle bug looks fine at a glance.

Multiplayer tools usually show you other people's cursors. We wanted a game where the other people are the whole point, so we asked: what if one of your reviewers wanted the bug to ship?

What it does

Sabotage is Among Us for code review, for 4 to 6 players in the browser.

  • Everyone joins from a link. One player is secretly the saboteur.
  • Otto, the in-game agent, proposes changes. The team has 90 seconds to read each diff, comment on lines and vote to approve or reject.
  • The saboteur knows which changes hide a bug. They argue for shipping those and try to look helpful.
  • Every two changes there is a retro, where the team can vote someone out.
  • Reviewers win by shipping 4 clean changes or voting out the saboteur. The saboteur wins by getting 2 bugs merged, or by getting so many clean changes rejected that the team can't reach 4.
  • The debrief reveals everything: each hidden bug, the offending line, who fell for it and who caught it.

Playing alone? Bots fill any empty seat. They comment, vote, raise false alarms and can even be the saboteur. A person joining a full room takes a bot's seat.

How we built it

We built Sabotage in a shared trmi room, with our prompts and agent work happening in one session instead of in separate editors. Screenshots of the session are in media/trmi in the repo. trmi created a private team repo, so we keep a public copy at ashank-crazy/trmi for judges (the trmi repo is trmi-dev/heckathon-e5taflgu1fqx).

  • Stack: TypeScript in strict mode, React and Vite on the client, Express and Socket.IO on the server.
  • Server-authoritative game: every rule runs on the server, and each player receives only what their seat may see. Only the saboteur's client ever gets the bug information.
  • Change bank: Otto's 33 changes are hand-written, in TypeScript and Python. 17 of them hide a planted bug with an explanation. Each game deals 9, so there's no API key or live model to go down mid-game.
  • Seats: a secret token rebinds your seat when you refresh or reconnect, and a game carries on if someone drops.
  • Tests: unit tests for the rules, plus integration tests that drive real Socket.IO clients through full games.

Challenges we ran into

  • Writing fair bugs. If a bug is obvious, the saboteur has nothing to do. If it's too obscure, the debrief feels like a cheat. Each one has to be spottable in 90 seconds and still look reasonable.
  • Making bots feel like players. Bots can't cheat, so they only act on what their seat can see. They catch a hidden bug about 45% of the time, raise occasional false alarms and suspect whoever approved a merged bug.
  • Real-time races. Our integration tests failed intermittently because votes could arrive before every client had reached the next phase. We traced it to the cause and fixed it instead of re-running until it passed.
  • Not looking like a kids' game. Our first interface was bright and playful. We rebuilt it as a dark, serious dev tool, because the tension works better when it looks like a real pull request.

Accomplishments that we're proud of

  • It's a real game with real bluffing, not a demo of a multiplayer feature.
  • One person can try it in one click, and a full table can start from a single link.
  • Hidden information stays hidden, because the server never sends it to the wrong player.
  • The debrief quietly teaches you to spot real bugs.

What we learned

  • Social pressure changes how people review code. It's easy to approve a change when someone confident says it looks fine.
  • Multiplayer state is mostly about who is allowed to know what, and when.
  • Building in one shared session changes how a team works, because everyone can see the same work as it happens.

What's next for Sabotage

  • Bring your own diff: play on your team's real pull requests as a code review training session.
  • Generated changes: have a live model write Otto's changes and hide new bugs every game.
  • Team stats: track who catches which kinds of bugs over time.
Share this project:

Updates

Submission history