Copilot Review Without the Grind

You open a PR. Request a Copilot review. Fix the issues. Re-request. New issues appear. Fix those. Re-request. More issues.

Sound familiar?

This isn't a bug. It's how diff-driven review tools work. Every change you make creates new surface area for feedback. Fix one thing and the next "best practice" it didn't mention earlier becomes visible. Some of the feedback is subjective -- style preferences, micro-optimizations -- so there will always be something.

The question isn't how to make Copilot stop finding things. It's how to decide when you stop listening.

---

The Practical Cadence

Two reviews per PR. That's it.

First review at PR open. This catches the baseline issues -- bugs, security holes, type problems, architectural concerns.

One re-review after you address the big items. Safety, correctness, anything structural.

After that, stop re-requesting unless you made major new changes or touched critical paths.

More than two rounds is almost always diminishing returns. You're chasing perfection on a tool that will always have an opinion.

---

Classify Before You Act

When the comments come in, don't treat them equally. Triage:

Must-fix

Correctness bugs. Security issues. Data loss risks. Concurrency problems. Type unsoundness. Broken API contracts. Performance cliffs.

These get fixed. No debate.

Should-fix

Maintainability improvements that pay back soon -- better naming, extracting a function, adding a missing test. Things that make the next person's life easier.

Fix the cheap ones. Track the rest.

Nice-to-have

Style nits. Micro-optimizations. "This could be cleaner." Subjective rewrites that don't change behavior.

After the second pass, park these. Open a follow-up issue if they're worth remembering. Don't let them block your merge.

---

Why It Finds Something New Every Time

Three reasons:

• Diff-driven analysis. New code means new suggestions. The tool re-evaluates the full diff on each pass, not just what changed since last review.
• Cascading visibility. Fixing one problem often reveals the next layer. Remove a god-function and suddenly the naming in the extracted pieces gets scrutinized.
• Subjective surface. Some feedback categories -- style, "idiomatic" patterns, naming conventions -- are bottomless. There's always a "more elegant" way to write something.

Understanding this makes it easier to draw the line. The tool isn't broken. It's doing exactly what it's designed to do. You decide when the signal-to-noise ratio has dropped below useful.

---

The Single Biggest Lever: Smaller PRs

Most of the review grind disappears when you shrink the diff:

1. Aim for under 300 lines changed per PR
2. Split by feature slice, not by layer
3. Use feature flags to merge incomplete work safely

Small diffs produce stable, focused reviews. Large diffs produce a firehose of suggestions that compound with each iteration. This isn't just about Copilot -- it's true for human reviewers too.

---

A Sane Workflow

Here's the complete flow:

1. Open PR, request Copilot review
2. Triage comments into must-fix / should-fix / nice-to-have
3. Fix must-fix items and cheap should-fix items
4. Re-request review once
5. Handle any new must-fix items only
6. Comment summary of what was addressed vs. deferred
7. Merge

No third re-request. No chasing the last nit. The goal is consistently good code, not theoretically perfect code that ships next week.

The best engineers aren't the ones who address every suggestion. They're the ones who know which suggestions matter.