shipcue

Coordinating a hackathon team when everyone has agents

October 1, 2026 · Chinat Yu

I have been around a lot of hackathons through MentorMates, and I think that one of the things that separates the teams that do well from the ones that do not is honestly not the idea, or even how fast they code, but how well they coordinate with each other on the product. Who is building what, what is broken, what matters most before the demo.

That was already hard with four people and a group chat. Now that everyone is also running coding agents, I think it has become a lot harder. Each person has two or three agents going, and the agents do not talk to each other. It is really easy to end up with two agents fixing the same bug in slightly different ways, or one agent undoing what another one just shipped, and then you spend the last hour before judging working out which version is the real one.

The fix I kept coming back to was basically a queue. Everyone on the team reports bugs and ideas through a small button at the bottom of the app they are building, and that goes into one list, sorted by how urgent it is. Agents pull from that list instead of from whatever someone pasted into a terminal. When an agent takes a report it is claimed, so no other agent can take it, and when it is done it closes it with the PR link, so the whole team can see what is fixed without asking.

I built this for my own projects, first as a one-off and then again and again, and I have now made it open source as shipcue. It is one table in the Postgres you already have, one handler and one React button, plus an MCP server so Claude Code and Codex can work the queue. It takes about ten minutes to set up, which I think is worth it in the first hour of a hackathon.

A few things I would suggest if you try it at your next hackathon:

  • Set it up before anyone starts building features, so the habit is "report it in the app" and not "mention it in the chat".
  • Give each teammate's agent its own name with SHIPCUE_AGENT, so you can see whose agent is on what.
  • Mark the things that would break your demo as blocking. They go to the top of the queue, and those are the ones you really want fixed first.
  • Let mentors and friends who try your app report into it as well too. That is pretty much free testing.

If you are building at a hackathon this season, I would love for you to add it on day one and tell me what breaks. The code is on GitHub and the setup is in the docs.