No findings posted on a large PR

You opened a large PR, the review completed, and either no inline comments were posted or fewer files were covered than you expected. This page explains the most common causes and how to address them.

Symptom

What you see

• The PR-level summary comment shows a verdict (often ADVISORY) but no inline comments were posted.
• Some files have inline comments, others have none — even files that clearly contain reviewable code.
• The review failed with an error status rather than completing.

Or: no inline comments at all

If the PR contains only binary files or only files matched by the default exclusion patterns, the review is skipped and no PR comment is posted at all. Instead, the adopilot / ai-pr-review status check resolves as succeeded, with a description explaining why — for example, AI review skipped — no reviewable changes or AI review skipped — all files excluded by configuration.

Why it happens

Exclusion patterns removed the reviewable code

A built-in default list — binary files, .lock-extension lockfiles (yarn.lock, Gemfile.lock, composer.lock, and similar), and .map source maps — is stripped before the review starts, along with anything matching your own custom exclusion patterns. Note that package-lock.json and pnpm-lock.yaml are not excluded by default; add them to your patterns if you want them skipped. A PR that looks large in the Files tab but consists almost entirely of excluded lockfiles can shrink to a tiny diff (or zero) by the time the review starts. See Excluding files from review for what is excluded and how to tune it.

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.

Review error on a very large changeset

ADO Pilot reviews large PRs in full — there is no line-count cap that silently truncates the review. However, extremely large diffs put more pressure on model context windows and on downstream API calls. If the review cannot be processed, it fails with an error status check rather than silently returning a partial result. Pushing a new commit will trigger a fresh review attempt.

How to fix it

Split the PR

The most reliable fix is to break the change into multiple smaller PRs. As a rule of thumb, we recommend keeping each PR under 1,500 changed lines — smaller diffs tend to get more thorough review coverage, not just lower 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.

Tune your exclusions

If your repo has bulk-generated or vendor files that are not worth reviewing, add them to your exclusion patterns. Excluded files are stripped before the model sees the diff and do not count toward your review credits. See Excluding files from review.

How to prevent it

• Keep individual PRs under 1,500 changed lines when possible. 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.
• 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.