An agent generates code changes across a monorepo containing services owned by five different teams, each defined in a CODEOWNERS file. The agent's PRs frequently fail because they modify files owned by multiple teams but only one team is requested for review. Which configuration MOST correctly solves this problem?
Select an answer to reveal the explanation.
Short Explanation and Infographic
A courier who rings every doorbell in the building to deliver one package makes enemies fast. The agent should know, before submitting, exactly whose front door to ring based on what's in the box. Parse CODEOWNERS, diff the changed files, compute the intersection — only then request reviews. GitHub's automatic CODEOWNERS mechanism helps but can't account for the agent needing to structure the PR or split changes that cross team boundaries.
Full explanation below image
Full Explanation
Monorepo agents must be CODEOWNERS-aware to avoid PR failures and team friction. The failure mode described — PRs failing because only one team is notified for multi-team changes — is a common operational problem.
Option A (always request all five teams) generates unnecessary review noise for teams whose code was not touched. Teams will stop paying attention to agent PRs, and the signal-to-noise ratio of review requests degrades across the organization.
Option B is correct and operates on the right principle: compute, before creating the PR, exactly which teams need to review based on which files were changed and who owns them. CODEOWNERS parsing is straightforward — the file contains path patterns and owner usernames/teams. Diffing against changed files and computing the intersection produces the minimal, correct reviewer set. This keeps review requests accurate, minimal, and targeted. An advanced implementation might also choose to split the PR by ownership boundary when changes span teams, allowing each team to review and merge independently.
Option C (rely on GitHub's automatic CODEOWNERS) is partially correct — GitHub does automatically request reviews based on CODEOWNERS for matched file paths. However, this approach has limitations for agents: the agent cannot split PRs by ownership boundary, cannot predict reviewer assignment before submitting, and cannot take proactive action when a PR's scope needs to change. Agent-level CODEOWNERS awareness enables more sophisticated behaviors than passive reliance on GitHub's mechanism.
Option D (assign all files to a shared platform team) destroys the organizational value of CODEOWNERS — that each team retains ownership and review responsibility for their own code. It creates a bottleneck at the platform team and removes domain-specific expertise from the review process.