{"slug": "parallel-coding-agents-without-the-carnage", "title": "Parallel coding agents without the carnage", "summary": "A developer has open-sourced Foremerge, a coordination protocol that helps parallel coding agents avoid semantic conflicts that Git cannot detect. The tool allows agents to declare their intents before acting, and it detects collisions between plans, such as one agent replacing a symbol while another extends it. Foremerge is a Rust binary that uses a local SQLite store and is available under Apache-2.0.", "body_md": "We build GPTree with several coding agents working the same repository at once: Claude Code, Codex, and Cursor, each in its own git worktree. The failure that finally made us build tooling for it was small and completely silent.\n\nOne session was told to replace `PaymentService`\n\nwith a Stripe-specific implementation. Another was told to add PayPal support to `PaymentService`\n\n. Different worktrees. Different files. Zero textual conflict. Git merged both branches cleanly, and the second change now depended on an extension point the first had deleted. Nothing in the toolchain had an opinion about it at any moment.\n\nGit compares diffs. It cannot compare plans.\n\nWorktrees became the standard answer to parallel agents for a good reason: two sessions editing one checkout will overwrite each other's files and poison each other's context. Isolated checkouts fix that completely.\n\nBut three failure modes survive file isolation, because they were never about files:\n\nA shared task list helps with the second one, if every agent reads it, every time. Nothing in that setup catches the first or third, because the collision is between intentions, and intentions live in prompts, not in any file a tool can watch.\n\nForemerge is the internal tool we built for this, open-sourced this week. It is a coordination protocol that sits above Git: agents declare what they are about to do, before they do it, in a form precise enough to check.\n\nA declaration is an intent with one or more semantic scopes, each carrying an operation:\n\n```\nforemerge intent publish \\\n  --agent \"$AGENT\" \\\n  --task \"modernize-payments\" \\\n  --summary \"Replace PaymentService with StripePaymentService\" \\\n  --scope symbol:PaymentService=replace\n```\n\nScopes are not file paths. The vocabulary covers symbol, api, schema, config, migration, contract, and more, because file paths miss API, schema, configuration, and cross-language collisions entirely. The operation (replace, extend, and so on) is declared rather than parsed out of the summary, so it does not matter how the agent phrased its plan.\n\nWhen a second agent declares work on the same scope, deterministic rules compare the declarations and raise a finding while both pieces of work are still plans. This is real output from 0.4.0, captured while writing this post:\n\n```\n{\n  \"kind\": \"destructive_vs_additive\",\n  \"severity\": \"HIGH\",\n  \"scope\": { \"kind\": \"symbol\", \"key\": \"PaymentService\" },\n  \"explanation\": \"One intent will replace `PaymentService` while the other will extend it; both declare the same semantic scope.\",\n  \"suggestion\": \"Coordinate on a stable `PaymentProvider` contract first, then implement StripePaymentProvider and PayPalPaymentProvider behind it and migrate callers deliberately. This is a heuristic suggestion, not an automatic design decision.\"\n}\n```\n\nThe finding names the rule that fired, explains itself, and suggests a resolution. It does not block anyone. Claims in Foremerge are leased and advisory: overlap produces a warning and shared context, never a lock, because two agents can often work the same region compatibly and a lock would serialize work that did not need serializing.\n\nThe other half of the protocol is evidence. When an agent finishes, it publishes a ChangeSet, and acceptance is gated on verification that Foremerge runs itself: your named check (a build, a typecheck, a test target you registered) executed against the exact candidate fingerprint. An agent saying \"tests pass\" is recorded as provenance; it does not satisfy the gate. If the tree changed after validation, the attempt is non-authoritative and the gate says so.\n\nMechanically it is one Rust binary. The CLI, a local JSON API, and an MCP server are adapters over the same SQLite store, which lives inside your repository's git common directory, which is exactly why worktrees work well with it: linked worktrees share that directory, so every agent in the repo sees the same declarations while keeping isolated files. Local-first, no cloud, Apache-2.0.\n\nThe five-minute version\n\nThe fastest path is to let your agent set it up.\n\nPaste this into Claude Code, Codex, or Cursor from inside the repository you want to coordinate:\n\n```\nSet up Foremerge in this repository so we can coordinate parallel agents.\n1. Install it:      curl -fsSL https://foremerge.com/install.sh | sh\n2. Initialize:      foremerge init\n3. Wire this client and any others in use: foremerge setup all\n4. Register the check I should be validated against, for example:\n                    foremerge checks set test -- cargo test --all-targets\n5. Confirm:         foremerge doctor --client all\nThen read the Foremerge skill that step 3 installed for this client and follow\nit from now on: publish your intent with semantic scopes before editing, claim\nthe scope, and check for conflicts before you start.\n```\n\nThe MCP server gives the agent the full lifecycle as tools: publish intent, claim scope, check conflicts, publish ChangeSets, run verification, record the commit that landed. Set it up once per repository and every agent connected to that repository shares the same awareness.\n\nDoing it by hand instead is the install line,\n\n`foremerge init`\n\n, and the commands in the README, which walks two throwaway agents into the exact conflict above in under five minutes.\n\nWhat it deliberately does not claim\n\nThis is a pre-1.0, local-first MVP, and the parts it does not do are documented as carefully as the parts it does:\n\nDetection is deterministic and explainable, but heuristic. It can miss synonymous concepts and warn on work that was always compatible.\n\nClaims warn. They never lock files, symbols, or agents.\n\nPassing validation proves that the recorded command passed for the recorded fingerprint. Nothing more.\n\nThe store is per-machine SQLite. Shared multi-machine mode does not exist yet.\n\nThere is a reproducible benchmark harness in the repo, but no published coordinated-versus-uncoordinated results yet. Performance claims wait for numbers.\n\nThe full list is in docs/limitations.md. We think a coordination tool that overclaims is worse than no coordination tool, because severity is the signal an agent uses to decide what to stop for, and a false HIGH is worse than silence.\n\nWhere this goes\n\nThe protocol is the part we most want feedback on: is the scope vocabulary the right shape, where would the conflict rules warn on compatible work in your codebase, and which collisions would they miss? Issues and Discussions are open.\n\nRepo: github.com/naw103/foremerge\n\nSite and install: foremerge.com\n\nCrate: cargo install foremerge\n\nIf you run parallel agents and have hit collisions worktrees could not see, we would genuinely like to hear what they looked like.", "url": "https://wpnews.pro/news/parallel-coding-agents-without-the-carnage", "canonical_source": "https://dev.to/naw103/parallel-coding-agents-without-the-carnage-gf9", "published_at": "2026-08-27 18:21:26+00:00", "updated_at": "2026-08-27 18:48:47.141349+00:00", "lang": "en", "topics": ["developer-tools", "ai-agents", "ai-tools", "mlops"], "entities": ["Foremerge", "Claude Code", "Codex", "Cursor", "Git", "SQLite", "Apache-2.0"], "alternates": {"html": "https://wpnews.pro/news/parallel-coding-agents-without-the-carnage", "markdown": "https://wpnews.pro/news/parallel-coding-agents-without-the-carnage.md", "text": "https://wpnews.pro/news/parallel-coding-agents-without-the-carnage.txt", "jsonld": "https://wpnews.pro/news/parallel-coding-agents-without-the-carnage.jsonld"}}