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
You shouldn't make the agent ring every doorbell in the building just to deliver one package. Parse CODEOWNERS, diff the changed files, compute the intersection, and request reviews only from the teams whose files were touched.
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.
The configuration that parses the CODEOWNERS file and changed file paths before creating the PR, computes the intersection of changed paths with ownership rules, and requests reviews only from the teams whose owned files were modified is correct because it operates on the right principle: determine, 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.
The configuration that always requests reviews from all five teams regardless of which files it modifies 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.
The configuration that allows GitHub's automatic CODEOWNERS review request mechanism to handle reviewer assignment without any agent-level configuration 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.
The configuration that modifies the CODEOWNERS file to assign all files to a single shared platform team that reviews all agent-generated PRs 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.