Every pull request arrives with a silent tax. Before a human reviewer can think about architecture or business logic, they have to wade through missing descriptions, oversized diffs, leftover debug statements, and formatting inconsistencies. Over time, that tax compounds into review fatigue. The most effective way to fight it is to automate code reviews with DangerJS to avoid review fatigue entirely. DangerJS is a PR bot that runs deterministic checks in your CI pipeline and leaves clear, contextual feedback on the pull request—so the first human review starts at the decisions that actually require a human.
This year, when AI pair-programmers are generating code more rapidly than ever, the queue of pull requests is only getting longer. That makes the case for automation stronger, but it also demands a tool that is predictable, transparent, and easy to tune. DangerJS is exactly that tool.
Why Review Fatigue Is the Real Bottleneck in Modern Development
Review fatigue is not just about the number of pull requests. It is about the mental energy spent on repeated, low-signal checks. When a reviewer opens a PR and sees that the title follows no convention, the description is empty, and the diff contains a dozen whitespace changes, they are already paying a cognitive cost before they reach the logic.
A fatigued reviewer is less likely to catch subtle architectural issues, because their working memory is already full of nits. They might even approve a risky change just to get it out of their queue. Automating the repetitive parts of review restores the conditions for good judgment.
What Makes DangerJS Different from a Linter or a CI Check
Linters and formatters are great, but they work in the abstract. They don’t know that this specific pull request touches the payment module, or that your team’s convention requires a changelog entry. DangerJS sits in that sweet spot: it’s a scriptable harness that runs inside your CI environment and has access to the full pull request context—title, description, changed files, commit messages, labels, and reviews.
Unlike AI-based review tools that can sometimes produce vague or hallucinated suggestions, DangerJS uses rules you own. If a rule is wrong, you fix it and commit the change. The result is an auditable, deterministic PR bot that behaves exactly the way your team wants. It can also post its own review summary, so human reviewers start with a clean, annotated diff instead of a blank page.
Anatomy of a Dangerfile
A typical Dangerfile reads like a checklist of the same issues that come up in every review. It’s JavaScript or TypeScript, and it runs as part of your CI pipeline. Here’s a small example that flags two common errors before a human ever looks:
// Dangerfile.js
danger.on("pull_request", async () => {
const pr = danger.github.pr;
// Common error 1: empty or generic description
if (!pr.body || pr.body.length < 20) {
fail("Add a PR description that explains what changed and why.");
}
// Common error 2: huge diffs are hard to review
if (pr.additions > 500) {
warn("This PR adds more than 500 lines. Consider splitting it.");
}
});This is deliberately simple, but the pattern scales. You can use danger.git.modified_files to enforce test coverage, danger.github.pr.body to validate documentation, and danger.git.commits to check commit message conventions.
Add a PR Bot That Flags Common Errors Before a Human Ever Looks
Once DangerJS is connected to your CI system, you can start codifying the exact common errors your reviewers are tired of mentioning. Here are five to consider for your initial Dangerfile:
- Empty or generic PR descriptions. Require a minimum length and reject placeholder text like “changes” or “fix bug.”
- Missing issue links. If your team tracks work in Jira or Linear, warn when no issue ID appears in the title or branch name.
- Oversized diffs. Warn when a PR adds more than a few hundred lines or touches an unusually large number of files.
- Debug leftovers. Flag
debuggerstatements,console.logcalls, and commented-out code in the diff. - Inconsistent file placement. Enforce naming patterns or directory structures that align with your project’s conventions.
Keep the Bot Helpful, Not Noise: Rules for Sustainable Automation
A PR bot that generates too many warnings will be ignored just like a noisy teammate. The key is to make DangerJS a respectful assistant. Use fail() for things that must be fixed, warn() for suggestions, and message() for informational context.
Here are a few rules of thumb for building a bot that reduces fatigue instead of adding to it:
- Start with rules your team already states in review comments.
- Make every message an instruction, not a judgment. “Add a PR description” is better than “Description is missing.”
- Set thresholds you can defend. If a rule causes debate, tune it or remove it.
- Review the bot’s feedback every couple of weeks as part of your engineering hygiene.
A Practical Rollout Plan for Your Team
If you’re introducing DangerJS into an existing codebase, resist the urge to enable every rule at once. The goal is to eliminate review fatigue, not to create a gatekeeper that blocks every PR. Start with one or two rules that address the most common friction points and build from there.
- Week one: add DangerJS and run it in message-only mode to collect data without blocking anyone.
- Week two: turn on warnings for the highest-frequency issues you saw in the data.
- Week three: promote the most important warnings to
fail()once the team agrees on the thresholds.
This gradual approach gives your team time to adjust and gives you a clean signal about which automated checks actually change behavior.
Measuring the Impact of Your Automated Code Review Safety Net
The real win is visible in review time and reviewer sentiment. Track metrics like median time to first human review, percentage of PRs that require no nitpick comments, and the number of review threads that are purely mechanical. DangerJS can help with this too: because every bot comment is marked, you can easily filter and see how often it catches an issue before a human does.
You can also watch for softer signals—developers complaining less about tiny comments, more energy spent on design discussions, and fewer “LGTM” approvals on risky changes. Those are the signs that your PR bot is doing its job.
DangerJS won’t replace the nuanced judgment of a senior engineer, and it shouldn’t try. But it can absorb the repetitive, low-level noise that makes code review exhausting. By adding a PR bot that flags common errors before a human ever looks, you give reviewers their attention back—and attention is the scarcest resource in software development.
