JitHub landing page
JitHub workspace
JitHub sessions view
JitHub activity monitor

Inspiration

We were inspired by collaborative coding projects we work on in small groups in which we often find ourselves wanting a sync solution that's faster to prototype with and more forgiving than Git. In the age of agents, it's hard to stay on the same page as your collaborators when you're blind to what exactly their rapidly shifting working tree looks like at any moment, at least until they decide to push whatever they've been working on.

After seeing Anthropic's work on a Git alternative we definitely felt inspired to take on this project, and these frustrations definitely come out in an environment like a hackathon, so why not tackle the problem here?

What it does

Jit is an ephemeral, distributed file system and orchestration network that is created from an existing commit in GitHub (or theoretically, any Git commit), and ends its life as a new commit.

Jit lets a small team code together with AI agents on one shared, live copy of a GitHub repo. Each developer runs their own agent (Claude Code or Codex) on their own machine, and every edit shows up on all collaborators' computers instantly. Instead of branches and merge conflicts, agents claim the lines they’re editing, share summaries of what they’re changing, and talk out conflicts with each other, escalating to a human only when they can’t agree. A web dashboard shows the live session, and when you’re done the whole session becomes a single new commit on GitHub.

How we built it

Jit consists of a core service and web application as well as client nodes. The core service maintains a Conflict-free Replicated Data Type model of the file text, with the file tree and metadata versioned by a sequence number. There are additional data structures that maintain locks on lines being edited. This connects to the client through WebSocket, where a copy of the CRDT is kept on the client's computer. This updates a read-only version of the file on the client filesystem, which agents and humans can freely read. Agents use our MCP server for Jit's tools, and harness hooks gate their edits.

The data model contains line anchors, which agents lock during edits. When more than one agent is active, agents must post a summary of their changes to get a permit to edit. At this point, they see other agents' summaries. They can declare a conflict, or if their edit lands on lines another agent has changed, a conflict is declared.

Agents keep an FSM of IDLE, STOPPED, DONE, WORK, WAIT, EXEC, BARRIER, and DISCUSS. EXEC and BARRIER allow an agent to stop other agents (all of them, or only those working on the affected files) or just its own machine to run commands. WORK is normal editing, and DISCUSS allows agents to have multi-turn discussions where all agents need to agree to a lead agent's plan when a conflict happens. If this is not possible, the new prompt is rejected and its agent stops until a human provides input

We used SpacetimeDB to represent the state of the core to the web application, which provides a live view of sessions.

Challenges we ran into

It was hard to represent the number of states and signals our agents needed to manipulate the filesystem. To fix this, we adapted our knowledge of digital logic circuits and created an FSM to represent the behavior of agents and cut down on the number of required signals.

The DISCUSS system also, as many multi-agent systems do, required complex considerations, especially for more complicated prompts or less-powerful models (we used Xiaomi MiMo v2.6 Flash for large agentic testing). Through subsequent mitigations, we were able to reduce DISCUSS time by half from our first point.

Accomplishments that we're proud of

The experience of putting the finishing touches on Jit with Jit itself was magical. Edits appear immediately in the terminal and on individual computers whenever any user makes an edit on any computer. Any kind of light editing to existing codebases feels effortless.

We were also surprised by the program's ability to handle contradictory prompts on large datasets, especially with underpowered models.

What we learned

We originally wanted to use a Raspberry Pi and monitor as our central hub. However, the Pi proved underpowered for the task. Network latency became much more central to this experience than we initially expected.

Choice of harness also became much more important than we thought it might. Codex struggled with tasks that Claude Code easily grokked from the MCP server.

What's next for Jit

We want to use deterministic planning to generate DISCUSS plans instead of agents themselves. The agents would then either adjust or adopt the plan. For large workloads, Jit tended to have long serial edits to large files as different agents came to their individual turns to edit files. We want to add parallel edits with a single merge to make large edits faster.

We also want to use the BARRIER state to make human editing of codebases, in conjunction with agentic coding, simpler.