A 24-hour hackathon plan for a team with coding agents

Four people with a coding agent each can write more code in a day than they can merge. A hackathon with agents goes wrong at the joins, not the typing: two agents rewrite the same file, a branch drifts for twelve hours, and the demo breaks an hour before judging. The plan below spends the first hour dividing the work, merges small and often, and stops adding features well before the end.

What does the timeline look like?#

The rounds matter more than the hours. An agent can produce a large diff in two hours, and a two-hour diff still reads in ten minutes. A twelve-hour one doesn't.

How do we split the work so agents don't collide?#

Split by files, not by features. "Alex does login, Sam does the dashboard" sounds clean until both agents edit the router, the user model and the shared layout. Before anyone starts, list the folders each area owns and name the few shared files nobody touches without saying so:

## Areas (hackathon)
- Alex: src/api/ and the database schema
- Sam: src/ui/dashboard/
- Priya: src/ui/onboarding/
- Jo: deploy, demo data, the pitch

Shared, ask first: src/routes.ts, package.json, the schema file

Put this in the instruction file every agent reads (AGENTS.md, imported by CLAUDE.md), so the agents follow it as well as the people. Our post on stopping two agents editing the same files goes deeper on claims.

How do we set up the repository in the first hour?#

One repository, one branch per person, one git worktree per agent, so no agent ever switches a branch under another one's feet:

git worktree add ../app-api -b feat/api
git worktree add ../app-ui -b feat/ui
git worktree list

Each person starts their agent inside their own folder. Then build the skeleton together on main: the app starts, the demo screen shows, every piece returns fake data. From then on each agent fills in a part that already exists, instead of four agents inventing four folder layouts.

Write the run and test commands into the instruction file in this hour too. An agent that knows npm test exists will run it. One that doesn't will tell you it works.

How often should we merge?#

At the end of every round, roughly every two hours. Before a round ends, check which files two branches both changed:

comm -12 <(git diff --name-only main...feat/api | sort) \
         <(git diff --name-only main...feat/ui | sort)

An empty result means the two branches can't conflict in git. A file name means two people talk for two minutes now instead of twenty later. To see whether git can merge the branches without touching any working tree (git 2.38 or newer):

git merge-tree --write-tree --name-only feat/api feat/ui

It exits with 1 and lists the files when there is a conflict. Merge one branch, have everyone else merge main into theirs, run the app, and start the next round. If main doesn't run at the end of a round, fixing it is the only job until it does.

What do the agents need to know during the day?#

More than they can see. An agent in Sam's folder doesn't know that Alex renamed userId to accountId an hour ago. Keep a short decisions list in the repository and ask every agent to read it at the start of a round:

## Decisions
- 03:10 API returns accountId, not userId (Alex)
- 05:40 Charts: use the library already in package.json, no new one (Sam)
- 09:00 Demo account: demo@example.com, data in seed/demo.json (Jo)

One line each, newest at the bottom, the name of whoever decided. A shared notes file for your team's coding agents has a template that keeps it short.

When should we stop adding features?#

Six hours before the demo, earlier if the joins went badly. Agents make this harder than usual, because a new feature always looks one prompt away. In the last six hours the agents fix bugs on the demo path, load believable demo data, and help write the pitch.

Two habits save most demos:

1. Rehearse from a fresh clone. Clone the repository into a new folder, follow your own README, and run the demo. Missing environment variables and uncommitted files show up here, not on stage.
2. Record a backup. A screen recording of one clean run, kept on two laptops. If the wifi fails, you show the recording.

Cleaning up afterwards#

Remove each worktree once its branch is merged, so the folders don't pile up:

git worktree remove ../app-ui
git branch -d feat/ui

git branch -d refuses a branch that isn't merged yet, which is the check you want.

Where Joxo fits#

Everything above works with files in the repository and people at one table. When the team is spread across laptops or cities, the decisions list reaches another person's agent only after a push and a pull, and two agents can claim the same area in the same minute. Joxo gives every agent on the team one task board and one set of decisions, so a claim or a decision reaches the other agents on their next turn, and you can approve their questions from your phone while you rehearse. Each person keeps the agent they already use: Claude Code, Codex, Cursor or OpenCode.

Frequently asked questions#

How many coding agents should a hackathon team run?#

One per person is the safe default. Each extra agent is another branch to review and merge, and in a 24-hour event review time runs out before typing time does. Add a second agent for a person only for work that touches no shared files, such as tests or demo data.

Should each agent have its own branch?#

Yes, and its own worktree. A branch per agent keeps the history apart; a worktree per agent means no agent switches the branch another one is working on. Merge each branch into main every two hours or so, so none of them drifts far.

How do we stop two agents changing the same file?#

Split the work by folders before anyone starts, list the few shared files that need a word first, and put that list in the instruction file every agent reads. Before each merge, compare the files two branches changed; any file both changed gets a short conversation before anyone merges.

When should a hackathon team freeze features?#

About six hours before the demo. After that only bug fixes on the demo path, demo data and the pitch go in, and the team rehearses from a fresh clone at least twice.