conflict check
Semantic conflict detection for parallel AI coding agents
I run multiple AI coding agents (Claude Code, Codex, Cursor) in parallel, in separate git worktrees, on the same repo. A few weeks in, I kept hitting the same nasty issue: two agents make changes that don't overlap in git's eyes; different files, sometimes different lines — so git merge says everything's clean. It isn't. One agent renames a function, the other (with zero visibility into the first) still calls the old name.
Green merge, broken code, found out later, the hard way. So I built conflict-check; a small CLI that catches this before you merge. You tell it what each agent's doing, it grabs their diffs, and asks an LLM if the two look like they're making conflicting assumptions about the same code. It actually works — the repo has a real recorded run where it catches a rename-related break that git completely missed.
Honest state right now: it's live, MIT-licensed, and has 0 stars, 0 users I know of. Posted about the underlying problem on LinkedIn to see if others hit this too; got a few real responses, first outside signal I've had.
What I'm actually unsure about: is "running multiple AI agents in parallel" still too niche to build something real around, or is this the "early is exactly right" case — where the habit's about to become common and being early with the safety tooling is the whole advantage?
Website: https://conflict-check.vercel.app/ (in mid of buying the DNS :) )
Repo + real demo: github.com/Cipher-08/conflict-check
Genuinely asking, not just launching — if you run agents in parallel, has this bitten you? And if you've been in "problem's real but audience is still small" spot before, how'd you know if it was worth pushing through?
7 Comments
Fair, and that's the real crux. my honest answer: I don't have hard data on frequency yet; I've hit it myself a handful of times over a few weeks of running 2-3 agents in parallel, which is often enough that I now run the check before every merge out of habit, but that's an n=1 sample.
My bet is it scales with how many agents someone runs and how long their sessions get before merging; someone running 1 agent, short sessions, rarely hits this. Someone running 3+ agents for hours before merging (which feels like where this is heading as agentic coding gets more common) hits it a lot more.
Haven't validated that at all beyond my own use though; if you (or anyone reading this) run multiple agents in parallel, genuinely curious how often this bites you vs. how often it doesn't.
Best guess, based on my own use: roughly 2+ agents on the same repo, each left unmerged for more than 30-60 minutes. Below that threshold; 1 agent, or frequent short merges ; you're naturally integrating often enough that conflicts stay small, git catches the obvious stuff, and you'd notice a break almost immediately anyway.
Above it; especially once agents are touching related (not identical) parts of the codebase; the odds of a silent semantic conflict climb fast, simply because more unreconciled change piles up before anything gets checked against reality.
Here's the reasoning behind those numbers: a semantic conflict needs two things, agents making assumptions about the same shared logic, and enough time passing that neither re-syncs before you merge.
Agent count affects the first. Unmerged time affects the second, and it compounds; every change made while unmerged is another chance to build on an assumption that's already gone stale.
Two agents syncing every 15 minutes barely have time to drift. Two agents left untouched for 3 hours have dozens of changes stacked on an assumption that broke early and was never caught.
That's why I'd bet on unmerged time as the stronger predictor, even without a formal study. Curious if that matches what you've seen.
That’s interesting. I’d be curious to hear what you learn as you validate it with other users. Happy to continue privately — what’s the best email to reach you on?
Thanks! I’ve just sent it over.
Looking forward to hearing your thoughts whenever you have a chance.