Two AI agents, one repo — main kept breaking, so I built a PR traffic controller as a GitHub App

RollNuts — Fri, 17 Jul 2026 01:45:54 +0000

What I built

Veripsa Core is a GitHub App that warns you — before merge — when open PRs are about to collide on main.

Install it on a repository and covered pull requests get an advisory check.

Install: https://veripsa.com/go/install?source=devto:veripsa-parallel-pr-collision
Site: https://veripsa.com

Why this problem shows up

When you run several AI coding agents in parallel — Claude Code, Codex, GitHub Copilot — the number of open PRs goes up.

Say one agent works on auth, another on the API, another on tests. Each PR looks correct on its own. CI is green on all of them.

And main can still break depending on the order they land:

PR-A and PR-B rewrote the same area, separately
one landed first, the other carried a stale assumption in
no line-level conflict ever appeared, but merging both broke the meaning

Humans working in parallel hit this too. Parallel AI agents just make it much more visible, because the PR count and rebase count go up.

Why existing tools don't quite see it

Collisions aren't a new problem. What makes them hard to see is that per-PR inspection and PR-to-PR relationships are different things.

git tells you about conflicts at merge time. If the lines don't overlap, two changes can collide in meaning without ever being a git conflict.
CI runs each PR in isolation. A green and B green says nothing about "what if A and B both land?"
Review happens one PR at a time. Nobody re-checks every other open PR heading toward the same surface.
Merge queues stabilize the final merge of ready PRs. That's a different time window from the draft / pre-review stage where parallel-agent traffic piles up.

The blind spot is not inside a PR. It's between PRs.

What it does

Veripsa Core does not auto-resolve conflicts.

Before merge, it posts decision material as a GitHub check and a PR comment:

This PR is heading for the same landing area as another open PR.
There's a PR that should land first.
Here's what to check before you rebase.

Three properties:

Advisory: Veripsa never blocks a merge by itself. Whether it gates anything is decided by your branch protection / required status checks.
Content-free: it may read file bodies transiently to compute the signal, but it does not store or display source file bodies or diff contents. What it keeps is minimal operational metadata — details at veripsa.com/trust.
Not a safety proof: it never says "this merge is safe." It reports the PR-to-PR relationships it can see.

Turning the pause into an actual gate

For heavy collisions, Veripsa surfaces a pause with an acknowledgement path.

It only actually blocks the merge button if you mark the Veripsa check as a required status check in branch protection or rulesets. Without that, the comment and check stay advisory.

Whether required checks are available on private repositories depends on your GitHub plan. On public repositories they're free.

What it actually looks like

Here's the comment two PRs touching the same file produced (public PR #1):

✓ Clear to land — nothing is blocking you

This PR reserves: orders/pricing.py, tests/test_pricing.py

⏳ 1 in-flight PR is waiting behind this one — PR-2.

That comment is traffic information at the moment both PRs were open: PR #1 in front, PR #2 queued behind. After PR #1 merged, PR #2's final state changed to Cleared — the earlier overlap has resolved.

Pricing

Free to install while in early access.
If paid plans come later, they'll live in GitHub Marketplace-native billing.
Required-check management, retention, team dashboards, audit trails, priority support are future candidates — nothing paid is being promised as of this article.

https://veripsa.com/pricing

How to use it

Install the GitHub App and covered PRs get the check. Nothing to add to CI.

If your agents open PRs, rebase, and drive them to the edge of merge, add one rule to your CLAUDE.md / AGENTS.md: read the Veripsa check and comment before merging. That's how the advice enters the loop.

Install: https://veripsa.com/go/install?source=devto:veripsa-parallel-pr-collision
Site: https://veripsa.com
Running it with agents: https://veripsa.com/docs/with-agents

As AI agents generate more PR traffic on GitHub, the scarce thing stops being PR generation or review.

It becomes: which PR, in which order, with which warnings read, gets to land on main.

Veripsa Core is a GitHub App that puts that pre-merge decision material right on the PR.

Git worktrees aren't enough for parallel AI agents

RollNuts — Fri, 17 Jul 2026 01:40:41 +0000

Worktrees isolate each AI agent's working directory, but two agents in separate worktrees can still write code that only collides when both PRs merge to main.
If you run several AI coding agents at once, you have probably reached for git worktrees. It is the standard answer, and it is a good one: give each agent its own worktree, and no agent overwrites another agent's files mid-run. Each agent gets a clean, isolated checkout on its own branch, off the same shared repo.
Use worktrees. They solve a real problem. But they solve the execution problem, not the merge problem — and for parallel agents, the merge problem is the one that bites.
What worktrees actually isolate
A worktree gives each agent a separate working directory. Agent A editing files in its worktree cannot clobber the files Agent B is editing in a different one. No half-written file from one run leaks into another. No branch-switch thrash. The agents stop stepping on each other's filesystem.
That is genuinely valuable, and if you were previously running multiple agents against a single checkout, worktrees will feel like a night-and-day upgrade.
What worktrees don't isolate
Here is the gap. Two agents in two isolated worktrees can still change related code — code that reads clean in each branch on its own, and only clashes when both branches land on main.
The isolation is spatial: separate directories. It is not semantic. Nothing about a worktree knows that Agent A's change to a shared helper and Agent B's new caller of that helper assume different things about how it behaves. Each PR compiles. Each PR passes its own tests. Each PR looks correct in review. The problem lives in the relationship between the two open PRs, and no single worktree can see the other one.
This is not a rare edge case. AgenticFlict, a large-scale study of merge conflicts in AI coding agent pull requests (arXiv, 142k+ agent PRs across 59k+ repositories), found a 27.67% merge-conflict rate — and textual git conflicts are only the visible slice. The quieter failures are the ones where git merges cleanly and the breakage shows up later, on main, after both PRs are already in.
Why nobody catches it
Walk the tools you already have and notice what each one looks at:
Git compares text at merge time. If the two changes touch different lines,
it reports no conflict — even when the logic collides.
CI runs on one PR's branch. It exercises the interactions your tests cover,
in isolation from the other open PR.
Code review looks at one PR at a time. A reviewer approving PR #12 is not
also holding PR #47 in their head.
Merge queues serialize ready PRs and rebuild them in order — useful, but
they engage at the end, once a PR is already ready to land.
Every one of these is doing its job correctly. The common blind spot is the same one worktrees have: they each see a single PR. Nobody is watching the cross-PR relationship while the PRs are still open — which is exactly when a heads-up would let you order the merges, or ask one agent to rebase on the other, before anything breaks.
The layer worktrees are missing
Worktrees isolate agents so they can run in parallel. The missing piece is something that watches the open PRs so they can merge in parallel — a layer that looks across branches instead of within one.
That is the gap Veripsa Core fills. It is a GitHub-native, advisory check that looks at your open pull requests and warns which ones may overlap before they reach main. It posts the signal on the PR, where authors and reviewers already are. It stays advisory — it does not hard-block your merge; a human can review the situation and proceed. And it is content-free: it never stores your source file bodies. It works within a single repository today.
It is not a merge queue, not an AI reviewer, and not CI. It is the cross-PR heads-up those tools were never built to give.
The short version
Worktrees are the right first move for parallel AI agents — set them up. Just know what they cover: they keep agents from overwriting each other while they run. They do not keep two independent branches from colliding when they merge. For that, you need something looking at the relationship between open PRs, not at each one alone.
See how the advisory check reads on a real PR in the sandbox at /try, compare it against merge queues and AI reviewers on /compare, or read the product contract in /docs.

DEV Community: RollNuts