A Review Gate Design for Safely Folding Parallel Agents' Diffs into One Branch

Antigravity 2.0 made running multiple agents in parallel practical, but verifying each agent's output and integrating it into one branch is left to you. Here is how to build a diff-level review gate in stages, with judgment criteria and scripts.

Antigravity²⁸³ agents¹⁰⁸ review⁵ integration⁷ design¹¹

✦ Premium Article

You ran three agents in parallel and each cleared a different task. So far, comfortable. The problem comes next. In what order, and checking what, do you fold three branches into the mainline? Do this ad hoc and even if each agent is individually correct, the moment you integrate, it breaks.

Antigravity 2.0 made parallel execution of multiple agents practical, but how to bundle the outputs is left to your design. As an indie developer, when I first handed parallel agents the job of revising several sites, the integration step is exactly where I got burned. Each passed on its own, yet together CI failed, and I was stuck chasing causes by hand one at a time.

From that lesson I built a "diff review gate" to pass before integration: a mechanism that mechanically surfaces parallel-work conflicts before merging.

Know the three parallel conflicts first

Understanding what collides in parallel work before you design integration determines the gate's shape. The three I hit repeatedly are these.

Conflict type	Typical symptom	Detection starting point
Overlapping edits	Two agents change one file with different intents	Intersection of changed-file sets
Mutual dependency	One deletes a function the other calls	Matching symbol adds/removes
Test regression	Passes alone, fails when combined	Bulk tests on an integration branch

The point is that none of these are visible by looking at individual branches alone. Each surfaces only when you match multiple diffs against each other. So the review gate is designed to look at relationships between diffs, not at branches one by one.

Gate 1: mechanically reject overlapping edits

The first gate checks whether multiple agents touched the same file. If there is overlap, give up on auto-merge and route it to a human.

#!/usr/bin/env bash
# overlap-gate.sh base branch1 branch2 ...
# detect files changed in common across multiple branches
set -euo pipefail
base="$1"; shift
 
declare -A counts
for br in "$@"; do
  for f in $(git diff --name-only "$base..$br"); do
    counts["$f"]=$(( ${counts["$f"]:-0} + 1 ))
  done
done
 
overlap=0
for f in "${!counts[@]}"; do
  if [ "${counts[$f]}" -ge 2 ]; then
    echo "⚠️ overlapping edit: $f (${counts[$f]} branches changed it)"
    overlap=1
  fi
done
[ "$overlap" -eq 0 ] && echo "✅ no overlap" || echo "→ route overlapping files to human review"

For files with overlap, a human decides which change to take. I recommend that if there is even one overlap, you pull that set of files out of auto-integration. When a machine merges both in good faith, a contradictory state tends to remain.

✦

Thank you for reading this far.

Continue Reading

What follows includes implementation code, benchmarks, and practical content we hope you'll find useful. This site runs without ads — server and development costs are supported entirely by members like you. If it's been helpful, we'd be truly grateful for your support.

WHAT YOU'LL LEARN

✦A three-stage review gate to pass before integrating parallel agents' work

✦Three parallel-specific conflict patterns (overlap, mutual dependency, test regression) and how to detect them

✦A threshold-based script that routes diffs between auto-merge and human review by size

Secure payment via Stripe · Cancel anytime

✦

Unlock This Article

Get full access to the rest of this article. Buy once, read anytime. This site is ad-free — your support goes directly toward keeping it running.

Unlock all articles with Membership →

Gate 2: match symbol-level mutual dependencies

Even without overlap, if one branch deletes a function the other calls, the build breaks after integration. This happens even when changed files differ, so filename comparison will not catch it. Match the additions and removals of symbols.

# extract top-level function names removed on one branch
git diff "$base..$branchA" \
  | grep '^-' | grep -oE 'function [a-zA-Z0-9_]+' \
  | awk '{print $2}' | sort -u > /tmp/removed_syms.txt
 
# match against newly called sites on another branch
while read -r sym; do
  if git diff "$base..$branchB" | grep -q "^+.*\b${sym}\b"; then
    echo "🔴 dependency conflict: $branchB uses ${sym} that $branchA removed"
  fi
done < /tmp/removed_syms.txt

When this match produces a crossing of "one side's deletion" and "the other side's new use," reordering integration will not solve it. Asking one of the agents to redo the work is the right path. In my experience, mutual-dependency conflicts were about 20% of the total, but missing them was the nastiest kind, dragging post-integration debugging out the longest.

Gate 3: bulk-test on an integration branch

Finally, collect the diffs that passed the gates so far onto a temporary integration branch and run the tests there in bulk. Passing alone and passing together are different problems.

# create a temp integration branch, merge each branch in turn, test
git switch -c integration/tmp "$base"
for br in "$@"; do
  git merge --no-ff --no-edit "$br" || { echo "🔴 merge conflict: $br"; exit 1; }
done
npm test || { echo "🔴 integration test regression"; exit 1; }
echo "✅ integration branch passed"

The integration branch is a disposable for verification only. Only after tests pass here do you judge taking it into the mainline. A pitfall: if you make this integration branch the mainline directly, the intermediate commits from verification mix into history. I confirm the result on the integration branch, then re-apply cleanly to the mainline.

Route review by size

Reviewing all three gates by hand is not realistic. Route by diff size between what may proceed automatically and what a human should read.

# decide the review route by lines changed
lines=$(git diff --shortstat "$base..$br" \
  | grep -oE '[0-9]+ insertion' | grep -oE '[0-9]+')
if [ "${lines:-0}" -le 50 ]; then
  echo "$br: small (auto-merge candidate)"
else
  echo "$br: large (human review required)"
fi

My threshold is 50 changed lines. Below that, anything that passed the three gates rides as an auto-merge candidate; above it, I always read the diff. This routing let me spend time only on diffs that truly need eyes. In practice, diffs needing human review settle at about 30% of the total. Pushing the remaining 70% to automation is when the benefit of parallel execution finally stays in your hands.

Integration quality decides parallel value

Running agents in parallel is no longer the hard part. The difference in value comes from how you design the bundling of the outputs. Whether you have a gate that mechanically rejects the three conflicts (overlap, mutual dependency, test regression) before integration decides whether parallel execution saves time or breeds a mountain of debugging.

Since I started running parallel revisions across multiple sites at Dolice Labs, what I tuned most was not smarter prompts but this unglamorous integration gate. So as not to waste the speed of parallelism, I suggest starting with the overlap detection of gate 1.

Thank You for Reading

Antigravity Lab is ad-free, supported entirely by members like you. We publish practical guides daily with implementation code, benchmarks, and production-ready patterns. If you've found it useful, we'd love to have you on board.