No findings posted on a large PR

You opened a large PR, the review completed, and either no inline comments were posted or only some files were covered. The most common cause is the 5,000-line cap: ADO Pilot reviews up to 5,000 changed lines per PR and gracefully degrades to a partial review past that. Splitting the PR into smaller chunks gets you full coverage.

Symptom

What you see

• The PR-level summary comment shows a verdict (often ADVISORY) but lists fewer reviewed files than the PR's Files tab.
• The summary comment notes a partial review or names a file count smaller than the PR's actual change set.
• Some files have inline comments, others have none — even files that clearly contain reviewable code.
• The PR's RC charge is lower than you might expect for the diff size.

Or: no inline comments at all

If the PR contains only binary files, only files matched by the default exclusion patterns, or only files large enough to trigger the per-file size cap, the review runs but has nothing to comment on. The summary comment will say so explicitly.

Why it happens

PR diff exceeds 5,000 lines

ADO Pilot caps the per-PR review at 5,000 changed billing lines. Above that, the orchestrator picks a prefix of the diff that fits under the cap, reviews it normally, and reports the partial result with a note in the summary comment. This is graceful degradation — you get a useful review on part of the PR rather than no review at all.

Exclusion patterns removed the reviewable code

Generated files, lockfiles, minified bundles, and anything matching your custom exclusion patterns are stripped before the review starts. A PR that looks large in the Files tab but consists almost entirely of regenerated lockfiles can shrink to a tiny billing diff (or zero) by the time the orchestrator gets it. See Excluding files from review for what is excluded and how to tune it.

Per-file size threshold

Individual files above a size threshold (separate from the 5,000-line PR cap) are skipped. This catches one-shot vendored files and accidentally-committed minified output. Other files in the same PR are still reviewed normally.

Binary-only changes

A PR that touches only images, archives, or other binary files has zero reviewable content. The review completes successfully with an empty finding set.

How to fix it

Split the PR

The most reliable fix is to break the change into multiple smaller PRs. Aim for under 1,500 changed lines each — that's the size sweet spot for review quality, not just for cost. Splits work best along feature or layer boundaries (one PR per module, one PR per migration step).

Rebase onto latest main

If the PR is bloated with merge artifacts from a stale base branch, rebasing onto the current main often shrinks the diff substantially. Verify with git diff main...HEAD --shortstat before pushing.

Stack PRs

For a feature that genuinely needs to land as one logical unit but is too large for a single review, stack PRs: open PR #2 against PR #1's branch, PR #3 against PR #2, and so on. Each PR is reviewed independently against its own base. Most ADO teams use stacked PRs for refactors that touch many files but break cleanly into steps.

Accept the partial review

If the cap was hit but the partial review covers the changes you most care about, that may be enough. The summary comment lists which files were reviewed; if the unreviewed files are uncontroversial (mechanical refactors, generated code, test fixtures), shipping with the partial result is reasonable.

How to prevent it

• Keep individual PRs under 1,500 changed lines when possible, and under 5,000 always. This is good practice independent of ADO Pilot — large PRs are also harder for human reviewers and merge less cleanly.
• Tune your file exclusions. If your repo has files that should not be reviewed (generated code, vendored dependencies, etc.), add them to your exclusion patterns. Excluded lines do not count against the 5,000-line cap or your RCs. See Excluding files from review.
• Set a team policy on PR size. Many teams enforce a soft cap (e.g. "no PR over 2,000 lines without sign-off") via review culture rather than tooling. If your team would benefit from automation, ADO branch policies can require approver count or block on file count.