Skip to content

What is Review Fatigue?

Last updated

Review fatigue is the decline in review quality that occurs when reviewers are overloaded with review requests — leading to rubber-stamp approvals, superficial comments, and missed defects. It is one reason rushed reviews catch fewer bugs.

Why does review fatigue matter for engineering teams?

When reviewers face a long queue, they skim rather than analyze, and attention drops on long diffs. Automated review can take the first pass so humans spend their limited attention on design and business logic. It has limits of its own: by default, once a PR reaches 60 files or 1,500 changed lines, Argus reviews only the 40 highest-risk files at shallow depth, and it refuses PRs of 400 files or 20,000 lines or more.

How does Argus handle review fatigue?

Argus takes the first pass. It reviews each non-skipped file under the Review Laws rubric with the file's dependents and team memory in the prompt, feeds the bundled static analyzers' results to the model as hints, and re-checks earlier findings for the files a PR touches. It posts at most 10 inline comments, blocking findings first, under a one-line verdict such as 'Fix 2 blocking findings before you merge.' Design tradeoffs, business context, and the merge decision stay with human reviewers.

Run Argus on your own repositories

Open source under AGPL-3.0, with no paid tier and no feature gating.

Self-hosted only: Docker Compose or Fly.io, Postgres with pgvector, a GitHub App and a Clerk app you create, your model keys and an embeddings endpoint.