Copilot Code Review and a 30-File Migration
Tailspin has 45 engineers and merges about 60 pull requests per week. Branch protection on main requires one approving review, dismisses stale approvals, and requires status checks. Two senior engineers are the bottleneck. The engineering manager enables Copilot code review and asks whether it can satisfy the required approval so PRs can merge faster. Separately, the team needs to migrate 30 files from a deprecated logging library to a new structured logging API. A developer proposes using Copilot Edits to change all 30 files in one pass, then opening a single PR. The manager wants a recommendation that does not weaken review quality or branch protection. Copilot is licensed through Copilot Business; the organization has not yet defined a policy for AI-generated review comments.
1. Can Copilot code review satisfy the required approval? Explain what it does and does not do, and how to set expectations with the manager.
Read the worked answer
No. Copilot code review does not satisfy a required approval.
Copilot code review is an AI reviewer that can read a pull request diff and post comments, questions, and suggested changes. It can be requested on a PR and can provide a useful first pass. It does not approve a pull request, does not dismiss stale approvals, and does not count toward branch protection's required approving review count. It also does not replace status checks or code owners. The manager's premise - that AI review can remove the human gate - is the error.
Set expectations:
- It reduces the time a human spends on obvious issues: null checks, missing tests, inconsistent error handling, risky patterns.
- It can be wrong in both directions: false positives create noise, and false negatives create false confidence.
- It should be labeled as an automated comment source, not a gate.
- The required human approval stays.
The productivity gain comes from making the human review faster and more focused, not from removing accountability. If the bottleneck is two senior reviewers, also consider CODEOWNERS routing, smaller PRs, and a reviewer rotation.
2. Design a review workflow that uses Copilot code review without flooding reviewers, including configuration and metrics.
Read the worked answer
Workflow design.
- Enable Copilot code review only on repositories where the team agrees to triage its comments. Do not turn it on everywhere on day one.
- Configure it to run on ready-for-review PRs, not drafts, and exclude generated files, lockfiles, and vendored code. If automatic review is available, limit it to PRs under a size threshold; large PRs produce shallow comments.
- Add a label such as
copilot-reviewand a short comment template: 'AI review is advisory; resolve or dismiss each comment with a reason.' - Keep the human approval and status checks. Assign a rotating 'review shepherd' to triage AI comments daily so they do not accumulate.
- Measure: time to first human review, number of AI comments accepted vs dismissed, review comments per PR, escaped defects, and reviewer load. Do not measure 'comments generated' as value.
Stop or narrow the rollout if dismissal rate is high or if reviewers spend more time triaging than they save. The test is whether the human review gets better, not whether the bot is busy.
3. For a 30-file migration, would you use Copilot Edits or Chat? Explain the tradeoffs and guardrails.
Read the worked answer
Use Copilot Edits for the mechanical migration, but in controlled batches.
Copilot Edits is designed for multi-file changes across a working set: you select the files, describe the change, review the proposed edits, and accept or reject them. That fits a 30-file library swap better than a long Chat thread, because the unit of work is the diff. Chat is better for planning the migration, understanding the old API, and resolving one tricky call site.
Guardrails:
- Create a branch and a draft PR; do not let it push to
main. - Split into batches of 5-8 files by module, not one 30-file accept. Review each hunk.
- Attach the new API's canonical usage and the old-to-new mapping. State that behavior must not change except for logging fields.
- Use search to find all call sites, including tests and configuration; Edits only changes files in its working set.
- Run the build and tests after each batch; require CODEOWNERS review before merge.
- Watch for silent changes to log levels, message text, or dependency versions.
A single PR is acceptable if commits are batch-sized and the description maps each batch. A 30-file AI patch is not reviewable as one blob.