Open source alternative to Git for AI coding agents
Hey Product Hunt !
I'm Moss'Ab, co-founder of Murmell.
Earlier this month, Anthropic shared that it had moved its monorepo off Git after its agents took it from about 2,500 merged changes a day to more than 30,000. Their system, Scion, is internal. On Hacker News, the top complaint was simple: nobody outside Anthropic can use it.
We had hit the same wall at a much smaller scale. Murmell is currently two people and a lot of coding agents from different providers on one monorepo, and the agents had stopped being the slow part. Every change waited for a pull request and a CI run, rebased on a main that had moved, and two agents on the same file ended in a conflict someone had to settle by hand.
So we built AVP (Agent Versionning Protocol), and it's open source.
An agent opens a task, writes, and lands it. Every landing is proven on the exact head of main in seconds; if the line moved, the task is replayed on it and proven again. Every landing is still an ordinary Git commit, so GitHub and your deploys don't change.
On our repo, CI runs for pull requests went from 104 a day to 4. In our benchmark, with 6 to 8 Claude Code agents on one repo, main went red under Git and Jujutsu and tasks silently went missing.
With AVP, main stayed green and nothing was lost, in every run so far.
Method and numbers: avp.murmell.com
One binary: `avp up` in any Git checkout connects Claude Code and Codex.
The Git side is there to make the transition easy for teams on Git today.
At Murmell now we don't use Git ourselves anymore. We work through AVP, we're slowly moving to our own client, and GitHub only stays as a fallback that stores the code. I think most teams will make the same move in the coming years.
I truly believe AI will reshape the tools we use every day. MCP changed how agents interact with APIs. Now it’s time for AVP to replace Git.
Git was built for humans. AVP is built for AI agents.
Replies
What defines the validation an agent has to pass before landing? In particular, can a task edit the tests or configuration used to validate its own change, or is there a separate set of checks it can’t weaken? Proving a change on the current head sounds useful, but I’d want to distinguish “passes the configured checks” from “preserves the intended behavior.” I haven’t tried AVP yet; I’m curious how you handle that boundary.