Git conflict detection works on lines of text. Two AI agents running in separate worktrees against the same repository can each touch completely different lines and still produce code that actively contradicts itself — one agent replaces a PaymentService class while another extends it, both changes merge cleanly, both pass lint, and the resulting system is broken in a way no diff tool will ever flag. That’s the specific, narrow problem a new open-source project called Foremerge went after, launched on Show HN September 21 by a single maintainer with no funding announcement, no backing company, and — by its own README’s admission — no published benchmarks yet.
It’s worth covering anyway, because it’s the first real attempt this blog has seen at solving a problem that only exists because agentic coding scaled past single-agent workflows.
How it works#
Foremerge is a Rust binary that wraps Git and keeps a SQLite store in .git/foremerge/, shared across every worktree in a repo so agents running in isolation can still see each other’s stated intentions. The protocol is small: an agent registers, then declares semantic scopes in a kind:key=operation format — symbol:PaymentService=replace, for instance — before it starts editing. Foremerge compares declared operations deterministically (no judge model in the loop) and raises a HIGH advisory the moment one agent’s “replace” collides with another’s “extend” on the same scope, before either has written a line of code. Agents can then “claim” a scope (advisory only, not a lock), implement, publish a change set, run the repo’s own verification gate, and record an integration commit. It ships as a CLI, an HTTP JSON API, and an MCP server — meaning it plugs into Claude Code, Codex, and Cursor without any of them needing to build coordination logic themselves.
What the maintainer claims, and what the README doesn’t let them claim#
The Show HN post reports a test run of 98 parallel agents with zero conflicts — a genuinely striking number, and one that should be read as exactly what it is: a single self-reported run from the tool’s own creator, with no independent reproduction. To its credit, the README doesn’t try to oversell past that. It states plainly: “Public schemas may still change. Published benchmark results do not yet exist.” It goes further, listing its own limitations without being asked — conflict detection is heuristic and can miss synonymous concepts phrased differently; claims are advisory only, with no actual file locking; a passing verification gate proves a test passed for one specific fingerprint, nothing more; “local SQLite is not shared-mode consensus”; and, most importantly, “Foremerge does not replace code review, architecture ownership, CI, security scanning.” That’s an unusually honest scope statement for a pre-1.0, 0.5.0 project with 474 stars and 18 forks a day after launch — the kind of self-disclosure this blog has had to go dig for in vendor posts far larger than a one-person GitHub repo.
The Hacker News thread split predictably. One commenter dismissed the whole premise: “you’ve got a completely fucked up workflow and instead of fixing the workflow, you’re going to bolt something else onto it” — the view that uncoordinated parallel agents are a process failure, not a tooling gap. Another took the opposite position: “current version control mechanisms are meant for humans, not agents,” framing Foremerge as an early instance of “the future of version control in an agent-first world.” Both readings have a point, and neither is settled by a one-day-old repo.
Why this belongs in the same story as Claude Code’s own roadmap#
This gap is not hypothetical for the tools this blog covers most. Claude Code’s Agent Teams already puts fifteen agents to work concurrently via a mailbox architecture, and git worktree isolation is a first-class part of how Claude Code keeps parallel sessions from clobbering each other at the file-system level. GitHub’s own Copilot app GA shipped agent-merge across parallel worktrees with the same underlying assumption: agents working in isolation, merged back together, checked mainly at the text level. None of that stack currently does what Foremerge attempts — catch a semantic collision before two agents write conflicting code, rather than after, at merge or review time.
That a solo maintainer got there first, ahead of any frontier lab productizing the equivalent natively, is the actual story here. It’s consistent with a pattern this blog keeps running into: the frontier labs are extremely good at shipping bigger, faster, more capable individual agents, and consistently later to the coordination primitives that only become necessary once you’re running many of those agents against the same codebase at once. Foremerge is a scrappy, honestly-scoped patch over a real gap — not a finished answer to it, and its own README says so louder than any critic needs to.
The takeaway#
Treat the “98 agents, zero conflicts” number as a promising anecdote, not a result, until someone other than the author reproduces it. But the underlying diagnosis — that line-based version control has no concept of intent, and multi-agent coding needs one — is correct, and it’s a genuinely new category rather than a repackaging of anything already on this blog’s radar. Worth watching whether Foremerge gets to 1.0 with real benchmarks, or whether Anthropic, GitHub, or Cognition end up building the same primitive natively into their own orchestration layers first.
Sources: Foremerge on GitHub · Show HN discussion