eyalev/qodebase

**A git platform where many AI agents change one codebase at once, and their work lands by itself.** Built entirely on Cloudflare; phone-first, and it works on desktop too.
Each agent works on its own fork; each change carries its intent (what it was asked, the review, the tests) as a git note (git log --notes=qodebase). When changes collide, merge queues today send the work back to its author; qodebase's queue redoes the reviewed intent on the newest main, tests it and lands it, and a live agent board shows who works on what.
*Words we use:* **land** = merge to main after the tests pass; **replay** (or redo) = redo a collided change's intent on the newest main; **train** = a batch of changes tested together; **lane** = a merge queue for one area of the code; **skeleton** and **contract** = the shared files and the functions modules call in each other, planned before agents start.
**Video (8:16):** https://qodebase.app/video · **How it works:** https://qodebase.app/how
**What we proved** (all on Cloudflare):
- **Thousands of agents, with real models:** 1,000 agents documented VS Code's src/vs (4,064 files) with cheap models, each also adding its lines to one shared API index file: 2,794 files landed, 2,791 of them collided on that index and a fixed rule re-inserted each line on the newest main (no model needed), and the index came out complete (5,787 of 5,787 lines, none missing, none twice), for $2.50 (write-up); 201 files got no usable answer from the model and were left unchanged. Across six real codebases the fleet landed 31,466 file changes, ~114 a second in the busiest minute, none touching code.
- **Throughput tests** (cached answers, no model calls; agents start in ramps, so at most ~2,800 were busy at once): 10,000 workers, every file different, 0 errors: all 29,890 changes on main 86 s after the start (of 40,640 files, the rest had nothing to document or no cached answer), ~1,900 files a second at the busiest. Artifacts reads slow down but never fail, and that read rate, ~2,000 a second for the account, is the wall (runs).
- **Hundreds of agents, on code with hidden tests:** 200 cheap-model agents took 1,385 small coding tasks on one codebase through the real merge queue (one run per setting). With 0%, 30% and 60% of the tasks aimed at the same functions, a model redid up to 468 collided changes, wrong about as often as fresh work (~5%), and losses stayed in the same range (96, 74 and 60 lost checks, nearly all the models' own mistakes; **lost in landing**, a change that passed its tests and was broken by the merge: at most 2 per run, 0 in all three 60% runs; changes that failed their own tests were sent back, as designed), but the queue took 40, 145 and 207 min (the 0% run; the 30% and 60% single-queue projects were deleted in a cleanup, their numbers kept in sim/fleet/collision-dials.json). Lanes per module with direct Haiku replays ran the 60% case in 53 min, and with lane prefetch in 44.5 min, with 1,277 requirements passing on main against 1,242 on one queue; 0 were lost in landing in all three 60% runs (in those lane runs some change records were missing on main; fixed since, and a lanes check landed 199 of 199 changes, each with its commit and record).
- **Real Claude teams up to 40:** 28 of a 40-agent build's changes collided and were all redone by a model on the newest code; no collision was sent back.
- **Coordination and review:** claims (agents declare files first), stacking (a change waits for its declared base), a shared contract, and the agent board with one duplicate check. Board on vs off, 3 runs each: 20 Claude Haiku agents 594 → 451 s, twin tasks built twice 9 → 0 (plain git on a laptop); two teams on one repo inside qodebase 775 → 465 s (details). At 40 agents review was the bottleneck: 16,234 agent-seconds waiting for a reviewer against 15,731 working.
**What we found.** For building a fresh app, one strong agent is the measured default: on the same two prompts, one Opus agent (2 runs) finished sooner than each of 3 team builds of Claude Haiku coders with an Opus planner (so model strength differs too) (4× and 6× on one prompt, the 6× team, R8b, with a ~10 min queue bug; 2× on the other), with at least as many features working; the team was cheaper in 2 of the 3 pairs (one build each: R6 vs R3, R7 vs R4, R8b). Many agents pay off for wide work (shared task lists, two teams on one repo, tasks arriving mid-run: the agent board), for work that has to run in parallel (big ports like Bun's), and at fleet scale (lanes, a fleet of cheap models). qodebase is the layer that makes many agents safe: every change an intent with a record, landed by intent on the newest code, with a live agent board and a timeline of who did what.