Hacker News: naw103

New comment by naw103 in "Show HN: Foremerge – Catch intent conflicts between parallel coding agents"

naw103 — Tue, 22 Sep 2026 13:45:35 +0000

Thats exactly what we've seen using this in our development workflows at GPTree since Jan and why we opensourced it. I really think this becomes an essential new part of the dev stack as coding with multiple agents in parallel increases even more. What I cant count right now is the rework a missed one costs because that dosnt surface until a fix commit possibly days later and thats the measurement Im trying to find a clever way to get. Worse case is though that you would still have that conflict even without using Foremerge. The difference is how much trust you can put in the final code.

New comment by naw103 in "Show HN: Foremerge – Catch intent conflicts between parallel coding agents"

naw103 — Tue, 22 Sep 2026 13:29:34 +0000

There were several comments here that got marked dead but had some legitimate points and questions so answering them on gh discussions instead https://github.com/naw103/foremerge/discussions/32 laika23 asked for two kinds of conflicts: replace vs extend and contract change by one agent vs new agents writing against the old contract. The first case already exists today and the second will also catch if the agent declares it but currently today no rule evaluates the dependancies at acceptance unless it is specifically declared as a check. We already added to the roadmap from initial feedback to solve this through a treesitter code graph. We've measured it internally but havnt build it yet. One thing that we found while measuring this was that only edges the parser extracted are usable and the ones it had to guess were name collisions on common helper names.

New comment by naw103 in "Show HN: Foremerge – Catch intent conflicts between parallel coding agents"

naw103 — Tue, 22 Sep 2026 02:03:00 +0000

You might be surprised, it works exceptionally well. If you decide to give it a shot and run into any issue feel free to reach out to me with any feedback.

... and Jev is a sore point for me right now lol we have been training our own decision intelligence model, Corgen, for the last year and a half. We're already using it in GPTree but havn't released it to the public yet. Im actually in the process of running it against JevBench right now to see how it stacks up.

New comment by naw103 in "Show HN: Foremerge – Catch intent conflicts between parallel coding agents"

naw103 — Tue, 22 Sep 2026 01:45:52 +0000

Here are some questions I normally get asked:

What does an agent do with it? The agents publish intents and scopes of what they are about to change (at the start and right before they make the change if its something different). Foremerge returns a signal of related work already in progress on different worktrees (even across different branches or in the same worktree) and the agents/humans who are working on it. Agents can then negotiate on the solution prior to writing any code or generating any conflicts and Foremerge runs an acceptance check (defined by a human) prior to commit.

Why advisory claims instead of locks? Once a repo gets busy locks turn into a queue and deadlocks. A lock that the agent cant see the reason for is the worse case scenario so the hard gate is at the acceptance not the start.

What are the gaps? Ultimately Foremerge is deterministic (does not use any judge model) so it can detect some false positives and negatives though we see that very infrequently and worst case it would have likely of been missed anyway without Foremerge. Acceptance also dosnt currently compare the actual diff by default and there are no push notificiations so the earlier agent only learns about the conflict on its next status check (both of these are on the roadmap for the next version)

There are more questions and answers here: https://foremerge.com/blog/31-questions-coordinating-paralle...

New comment by naw103 in "Show HN: Foremerge – Catch intent conflicts between parallel coding agents"

naw103 — Tue, 22 Sep 2026 01:23:43 +0000

You're right when the agent starts with a plan and no file list and the files only exist after edit, but the way I designed Foremerge to work, it works anyway. The initial intent does not have to be complete, it just has to be right about any destructive parts. That is why Foremerge works by declaring intent as prose, not as a file list or methods. The agents them selves determine if something conflicts based on the signals Foremerge returns. It only asserts a HIGH warning on declared scope and only a HIGH signal blocks acceptance (to avoid false possitives based on prose alone). The declaration can change at any point and the auto installed skills into the agents encourage such (the initial intent is released by the agent and the new intent is committed)

New comment by naw103 in "Show HN: Foremerge – Catch intent conflicts between parallel coding agents"

naw103 — Tue, 22 Sep 2026 01:15:39 +0000

I think before AI was writing most of the code and with small teams the solution was probably just ownership and talking (and meetings about meetings). Things moved at a pace where it was more possible to have someone oversee this, though I agree on larger teams it has always been a problem. I think Foremerge solves that too even without agents but the manual overhead outweighs more of the cost that it does with agents. Even if you can use AI to resolve the conflicts at PR time, you need the right context and you've already burned through tokens building and now even more fixing. Scale that across 10's or 100's of agents and you have a mess of each one running in its own direction. The custom solution for us became one worktree per task, and before an agent writes a line of code they lease/commit their intent and scope into an immutable log and verify drift as the acceptance check...thats now Foremerge

New comment by naw103 in "Show HN: Foremerge – Catch intent conflicts between parallel coding agents"

naw103 — Tue, 22 Sep 2026 01:07:43 +0000

Thanks! It' become a critical part of our development flow at GPTree since I built it back in Jan. So much so thats the reason I decided to open source it. I don't neccessarily see it as a replacement for version control, the diff is still doing most of the work at the point that really matters but Foremerge prevents those conflicts before you get to that point. Declared intent is what the agent thinks it will do and the diff is what it actually did, and the changeset being accepted currently depends on that diff. Where I definitely agree with you though is that not human or agent should be discovering a conflict by finding it in a diff. Its too late by that point and its the layer that git dosnt solve.

Show HN: Foremerge – Catch intent conflicts between parallel coding agents

naw103 — Mon, 21 Sep 2026 16:22:06 +0000

At, GPTree, we run several coding agents across our team on one repo using parallel worktrees. Apart from wasted time reviewing and fixing conflicts at PR time, the failures that hurt the most are when multiple plans or tickets cause architecture changes that cannot both be true. Ex. one agent replaces a class while another one is in the process of extending it. Git only notices if the resulting patches happen to touch the same lines and the review only catches it if they are familiar with both tickets.

Foremerge is a local "git like" coordination layer that sits above git (ie. does not interact with or change the way git and worktrees function), Before editing each agent publishes an intent and the scopes it will change, with the operation it plans to complete on each one.

    foremerge intent publish --agent "$A" \
        --summary "Replace PaymentService with StripePaymentService" \
        --scope symbol:PaymentService=replace
    foremerge intent publish --agent "$B" \
        --summary "Add PayPal support to PaymentService" \
        --scope symbol:PaymentService=extend

The publish by the 2nd agent returns a HIGH destructive_vs_additive finding before writing any code. Agents keep their own worktrees and the shared state is one SQLite file in gits common direectory. No hooks, no merge drivers, nothing rewrites your history.

It ships as one Rust binary with a CLI and MCP server with 18 tools and `foremerge setup all` wires it into Claude Code, Codex and Cursor. Because the protocol has nothing provider specific, a Claude agent and a Codex agent coordinate through the same store. Before any work is accepted, Foremerge runs a named check that you configured against the exact git state of the change. An agent that says tests pass is recorded but it dosnt satisfy the acceptance gate without running the check itself.

Detection is deterministic, no judge model reading your code. HIGH conflicts are only asserted for declared operations, ie. matches inferred from prose cap out below high. Claims are advisory leases, not locks so two agents can still hold the same scope without deadlock. The open source version is single matching and so not a distributed consensus.

We have tested this up to 98 parallel agents all working on the same repo with zero conflicts (was supposed to be 100 but 2 agents failed to run due to resource limitations)

I replayed 76 intents on my own agents from a build last week in the order they happened. The sample had exactly 1 conflict (which was flagged) and the review found a blind spot where one agent claimed scope by class name and the other claimed it by an internal method. We are working on fixing that for the next release.

Setup is a 30s install by pasting the quickstart instructions from the readme.md into your agent or manually: `curl -fsSL https://foremerge.com/install.sh | sh` or `cargo install --locked foremerge`, then `foremerge init && foremerge setup all` in a repo. Apache-2.0.

The feedback I want most is which conflicts between your agents plans would you actually want flagged and which would you tollerate as noise?

Repo here: https://github.com/naw103/foremerge Website: https://foremerge.com

More information on the problems this solves: https://foremerge.com/blog/

Comments URL: https://news.ycombinator.com/item?id=49789356

Points: 45

# Comments: 15

Worktrees isolate files not plans

naw103 — Thu, 17 Sep 2026 16:47:23 +0000

Article URL: https://naw103.substack.com/p/parallel-coding-agents-without-the

Comments URL: https://news.ycombinator.com/item?id=49743375

Points: 1

# Comments: 0

Foremerge: Catch conflicts between AI coding agents before they code

naw103 — Tue, 01 Sep 2026 12:44:17 +0000

Article URL: https://github.com/naw103/foremerge

Comments URL: https://news.ycombinator.com/item?id=49521212

Points: 1

# Comments: 0

New comment by naw103 in "Show HN: We built open OpenRouter that turns usage into a better model"

naw103 — Fri, 28 Aug 2026 13:14:25 +0000

We built our own model router at GPTree but this looks interesting. Caching is definitely one of the hardest parts to get right, especially in our scenario where users can branch from any part of the conversation and keep the dynamic context from the parent (unlike most other platforms that lock in the context once you branch).