Ten-Person Merge Gate: Bot-Approved Paths and Human-Owned Paths

A pull request is ready, and a bot has already approved it. For a small team, the merge decision is which file paths that approval may cover. A path-tier approval matrix turns that call into a rule you can inspect, test, and change.

The default keeps human approval

GitHub leaves Copilot approvals disabled by default, and repository administrators may restrict the file paths that Copilot can approve. When an administrator enables the feature, a Copilot approval is counted against the repository's required-approval threshold. The first question is whether a path can survive a machine approval.

Path choice controls the merge. If the path is wrong, the bot has already done the thing you would normally reserve for a person. You can change the setting on purpose.

Blast radius sets the tier

Use blast radius as the practical test. A documentation change can fail without touching money, access, or data, while authentication, billing, or migration scripts can put the whole product at risk. The tier you assign should match that damage, not the author's confidence. The tier should change when the risk changes.

Start with the paths that already have a human owner. Billing belongs to the person who owns revenue; data migration belongs to the person who owns production data. Documentation can be bot-only when the damage is small and the fix is easy. The owner is the person who answers when the path misbehaves.

Review effort changes the cost of confidence. GitHub estimates that a Lite Copilot code review consumes an average of $0.25 in AI credits, a Balanced review consumes $1.50, and a Max review consumes $10. GitHub added Max as a third review effort level next to Lite and Balanced, using multiple independent review agents that draw on models from different providers.

The multi-agent Max review cannot guarantee detection of every defect or vulnerability. A 2026 arXiv paper, CooperBench, found that AI agents had success rates about 30% lower on collaborative tasks than on the same tasks done individually. The cost and the limits do not ban the bot. They mark where a human approval should stay.

The checklist makes the rule testable

The checklist is the artifact. Each item should be testable quickly, because a rule you cannot check quickly will drift.

• Can you name the paths that touch authentication, billing, or data?
• Can you mark each named path as bot-only, bot-plus-human, or human-only?
• Can you confirm the bot can approve only the paths you marked bot-only?
• Can you confirm a human approval is still required for bot-plus-human paths?
• Can you point to the decision log entry that records the tier rule, owner, and date?

The first two items make the rule visible. The last three test the approval flow and the record.

The decision log keeps the rule honest

A path tier is only as good as the record that explains it. The decision log should name the path, the tier, the owner, the date, and the reason. If a path moves from bot-only to human-only, the log should show why. That keeps the next founder, ops lead, or new engineer from guessing.

The log also gives you a place to disagree. If a bot approval feels too loose, the team can point to the rule instead of arguing about taste. If a human-only path feels too slow, the team can propose a tier change with a named owner. The document turns a disagreement into a dated decision.

Review the log in the same meeting where you review incidents. One path that caused a bad merge gets a tier review. Another that has been safe for a while may get a broader bot approval. The log makes that change visible in the next incident review.