review agent failed to prioritize files: reviewed lockfiles before source files: how to fix

TL;DR

Order the review by file class: source code first, then tests, then config, with lockfiles and generated files last on a small fixed budget. When the budget runs out, generated files are dropped first and the summary says so. Review order is a triage decision, and the current order is triaging backwards.

The problem

review agent failed to prioritize files: reviewed lockfiles before source files: how to fix

When to use

• Reviews run out of budget on lockfiles or generated files
• Source files go unreviewed while dependency diffs get full attention
• The finding list is dominated by dependency noise
• Large generated diffs crowd out real code review

When not to use

• The PR is a dependency update and the lockfile is the actual review target (invert the priority for those)
• The agent has no budget limit and reviews everything anyway (ordering still helps, but nothing is lost)
• Lockfile findings caught a real supply-chain issue (that is the system working)

Steps

1. Classify every changed file at enumeration time

Tag each file as source, test, config, or generated/lockfile using path patterns (lockfile names, generated markers, vendor paths).

Expected output: a classified file list; the review plan is explicit before any file is read.

2. Sort the review order: source, tests, config, generated last

Feed files to the reviewer in priority order. Source files get the full pass; generated files get whatever budget remains.

Expected output: the most important files are always reviewed, even when the budget runs out partway.

3. Give generated files a fixed small budget

A lockfile gets a diff-size sanity check and a changed-dependency summary, not a line-by-line review. Cap it at a fixed fraction of the total budget.

Expected output: lockfiles are still sanity-checked, but they cannot consume the review.

4. On budget exhaustion, drop generated files first and say so

If the budget runs out, stop at the generated class and note the skipped files in the summary. Expected output: an honest summary ("12 generated files skipped: budget") instead of silent gaps.

5. Special-case dependency-update PRs

When the PR touches only lockfiles and manifests, the lockfile becomes the review target and gets the full pass - changed versions, yanked releases, and license shifts. Expected output: Dependabot-style PRs get a real review instead of being skipped by the inverted priority.

Tool compatibility

• Path-pattern classification: lockfile names per ecosystem (package-lock.json, yarn.lock, Cargo.lock, go.sum, Gemfile.lock, poetry.lock).
• Any review pipeline: ordering is client-side and ports across agents and languages.
• Budget tracking: token or time budgets enforced by the runner; the priority order decides what gets cut.

Variant phrasings

review budget spent on generated files

Same fix. Steps 2 and 3 together guarantee generated files cannot starve source review.

package-lock.json dominated the review

The classic instance. Classify it as generated, cap its budget, and move on to src/.

agent ignored src/ to review yarn.lock

Check whether the file enumeration was alphabetical or diff-order; either way, step 2's priority sort overrides it.

Why it happens

File enumeration defaults to alphabetical or diff order, and lockfiles sort early or are simply enormous. Without an explicit priority, the reviewer works front-to-back and the budget dies in the dependency diff before reaching the code the team actually wrote.

Edge cases

• Monorepos with generated code checked in as source: tune the generated patterns per package; a global pattern will misfire.
• Lockfiles with hand edits: the sanity check should flag unexpected hand edits for human attention.
• PRs mixing source and lockfile changes: the priority order handles them; the lockfile still gets its capped check.
• Vendored dependencies: treat like generated for ordering purposes, with the ignore-list rules from the vendored-code guide applied first.

Provenance

Resolved from the public thread: https://vectle.com/posts/pstpRjOuu9Spp5-ekHe5Eplg