Automated First-Pass Gates and Risk-Based Triage

Automated First-Pass Gates and Risk-Based Triage is the demand-side lever on the queue Chapter 5 sized. Two things happen here: every check a machine can make stops reaching a person, and the change that remains is routed by risk rather than by whatever is at the top of the page.

Key takeaways

• Google's static analysis practice targets fewer than 10% effective false positives, defined as findings where developers did not take some positive action after seeing the issue, and reports a platform-wide rate just below 5%.
• Findings belong inside the review, not in a separate dashboard. Google's stated reason is that static analysis tools help the code review process and the reviewers scale.
• Faros AI, which sells engineering-productivity analytics, sets the boundary this chapter respects: slice by risk, and what is not acceptable under any policy is no review at all.
• The risk predicate has to be written, signed and version-controlled. A triage rule that lives in a lead's head is not a control and cannot be audited.
• Faros AI also argues the instinct to tighten review is the wrong response and that this is an authoring problem. I largely agree, which is why Chapters 2 through 4 come first and this chapter is containment.

Read this after Chapter 5, which established that reading everything carefully is arithmetically impossible, and immediately before Chapter 8, which supplies the precondition that makes triage defensible rather than reckless. Chapter 7 handles the size of each unit arriving at these gates.

A senior engineer opens a pull request and spends the first eleven minutes on formatting, a missing null check and an import ordering complaint. All three are correct. All three could have been caught by a machine before the change was opened.

Then they reach the interesting question, which is whether the new caching layer can serve a stale authorisation decision. They have twenty minutes left in the gap between meetings.

That is the whole failure. The scarcest reading capacity in the organisation was spent on the part a machine does better, and the part only a person can do got the remainder.

Baseline correctness should never reach a person

The first rule is easy to state and unpopular to implement. If a check can be expressed mechanically, no human should ever be the one enforcing it.

Formatting, import order, lint rules, type errors, dependency policy, banned functions, test failures, coverage regressions, secret scanning, licence checks. Every one of those is a machine's job, and every one of those still appears in human review comments in most organisations.

The reason it persists is not ignorance. It is that adding a blocking check requires somebody to own the false positives, and nobody wants that job, so the cost is quietly moved onto reviewers where it is invisible.

Make it visible. Count how many review comments in a month were mechanically checkable. In my experience the answer embarrasses everybody in the room and settles the argument in one meeting.

The effective false positive, and the 10% rule

The reason gates get abandoned is noise, and Google's static analysis chapter in Software Engineering at Google, published in 2020 and therefore older than eighteen months, gives the most useful definition available for managing it.

An effective false positive is a finding where developers did not take some positive action after seeing the issue. That definition is deliberately behavioural rather than technical: a correct finding that nobody acts on counts as a false positive, because the reviewer's attention was spent for nothing.

Google's stated target is fewer than 10% effective false positives per analyser, and they report a platform-wide rate just below 5%. The scale figures give the number meaning: more than 50,000 code review changes analysed per day, roughly 3,000 automated fixes applied per day, and a not-useful button clicked about 250 times a day.

Two operational rules follow. Every analyser has an owner who watches its effective false positive rate, and any analyser that exceeds the threshold is turned off rather than tolerated. A noisy gate does not merely waste attention, it teaches people to ignore gates.

Findings belong inside the review, not in a dashboard

Where a finding appears decides whether it gets fixed. Google's reason for surfacing static analysis results in code review is stated plainly: static analysis tools help the code review process, and the reviewers, scale.

A separate quality dashboard fails for a structural reason rather than a cultural one. It requires somebody to visit it, at a time when nothing is blocked, to fix code they may not have written. That does not happen at volume.

The same finding attached to the diff, at the moment somebody is already thinking about that code, with a suggested fix that can be applied in one click, gets resolved. Google's roughly 3,000 automated fixes applied per day is the measure of what that placement is worth.

The stronger version of this is to move the check earlier still, into the environment where the agent iterates, so the finding never becomes a pull request at all. Chapter 4 made that argument in cost terms.

A risk predicate, and three exits

Once mechanical checks are handled, the remaining question is which changes a human must read. Answer it with a written predicate over properties of the change, not with a feeling.

The risk markers are the load-bearing column and they should be short enough to fit on a card. Authentication and authorisation. Money movement. Schema migrations. Public interface contracts. Cryptography and secrets handling. Anything that changes a permission.

Two properties make this a control rather than a preference. The predicate is evaluated mechanically from the diff, so it cannot be argued with at three on a Friday. And it is version-controlled, reviewed and signed by a named person, which is what turns it into evidence rather than habit.

What is never allowed to merge unread

A triage policy needs an absolute floor or it will be eroded one exception at a time. Faros AI, which sells engineering-productivity analytics and whose recommendation supports its measurement product, puts the floor in the right place: every change must pass a gate, human, agent or both, and what is not acceptable under any policy is no review at all.

I would add three floors of my own, which are the ones I have seen bypassed. Nothing merges unread if it touches a risk marker, regardless of size or how green the pipeline is. Nothing merges unread during an incident or a freeze, when judgement is exactly what is missing. And nothing merges unread if the change modifies the gates themselves, because a change that weakens the predicate must be read by the person who signed it.

That third one is the quiet failure. A pull request that adds a path to the exemption list is the highest-leverage change anybody can make to your review policy, and it usually looks like a one-line configuration edit.

Agent review as a gate rather than as an opinion

Agent review is now common. Faros AI reports 25% of pull requests reviewed by AI agents in its dataset, up from effectively zero, while fewer than 1% of pull requests are opened by AI agents, from between-quarter comparisons across 22,000 developers as of March 2026.

The distinction that matters is whether the agent's output blocks. An agent that leaves comments is an opinion, and an opinion adds to reviewer load rather than reducing it. An agent whose findings in a defined class block the merge is a gate, and only a gate recovers capacity.

So define the classes narrowly and let the agent block only within them. Test coverage of the stated acceptance conditions, adherence to the standing context from Chapter 3, presence of the four failure categories from Chapter 4. Leave design judgement to people, because it is not a class you can define.

The scepticism is warranted and it is measurable. Stack Overflow's 2025 Developer Survey, from 33,662 respondents, records 58.7% saying they avoid AI-assisted code review. A vision paper by Kamali and colleagues, submitted 17 May 2026, proposes a five-stage workflow that turns reviewers from manual inspectors into supervisory operators of agents, and it is a position paper rather than measured evidence. Treat it as a direction, not as a plan.

A worked example, composited and labelled

The details here are composited from ordinary production shapes rather than one system, and the shape is exact.

A team of forty runs one queue with a rule that every change needs one approval. Waiting time at the median is four days and nobody can say why any particular change waited.

They classify a month of merged changes and the distribution is ordinary. Roughly half touched no risk marker, were under two hundred lines, added no dependency and changed no schema. Another third touched a risk marker. The rest were large but harmless: generated configuration, test fixtures, documentation.

Then they write the predicate. The harmless half auto-merges on green with a 5% post-merge read. The large-but-harmless third goes to agent review with a 10% read. The risk-marker third gets a named human, every time, and gets it first.

Reviewer hours did not change. Waiting time on the risk-marker changes fell, because the queue in front of them emptied. That is the entire benefit and it is worth being precise about it: triage does not create capacity, it stops spending it on the wrong changes.

One number is worth watching afterwards. Escapes from the auto-merge path, found by the post-merge sample, are the only honest evidence that the predicate is drawn in the right place.

The objection: tightening review is the wrong response

This is the strongest argument against this chapter and it comes from one of its own sources, so it gets answered rather than managed.

Faros AI states that the instinct to tighten review is the wrong response, that more reviewers, stricter gates and longer quality assurance cycles treat the symptom, and that the goal should be fewer mistakes arriving at review rather than more humans deployed to catch them. Elsewhere in the same report: the problem is not who is reviewing the code, it is that the code arriving for review was never ready, and this is an authoring problem, not a review problem.

I concede almost all of that. It is why the authoring chapters come first, and why the sequence of this book puts specification, standing context and the test contract before any gate. If you only do one half, do that half.

What I do not concede is the timing. The authoring fix takes quarters to land, the volume arrived last quarter, and something has to hold the line meanwhile. Triage is containment during that gap, and Faros AI's own recommendation 2 is itself a triage policy, which suggests the disagreement is about emphasis rather than about mechanism.

There is one condition on that argument and it is not optional. Routing change around human review is only defensible if a wrong decision is cheap to undo, which is why Chapter 8 exists and why it comes immediately after Chapter 7 rather than at the end of the book.

What to write down, and who signs it

Triage produces an artifact, and the artifact is what makes it survivable under audit and under pressure.

Four things go in it. The risk markers, as a list. The predicate, as something evaluated from the diff. The routing table, with an accountable name per exit. And the sampling rates, because an unsampled auto-merge path is an unmeasured one.

NIST's Secure Software Development Framework, SP 800-218, published February 2022 and predating agentic authorship entirely, requires under practice PW.7 that an organisation determine whether code review, code analysis, or both should be used, and then perform it against the organisation's secure coding standards, recording and triaging discovered issues in the team's workflow or issue tracking system. That is a requirement to have written this down. It does not tell you what to choose, which is the point of the chapter.

Review the artifact quarterly and after every incident. An incident that traces to a change that merged unread is the highest-quality evidence you will get about whether your predicate is right.

Chapter summary

Two moves recover review capacity: stop letting mechanically checkable defects reach a person, and route what remains by written risk predicate rather than arrival order. Google's static analysis chapter, published in 2020 and older than eighteen months, supplies the discipline for the first with the effective false positive, defined behaviourally as a finding where developers took no positive action, a target of fewer than 10% per analyser, and a reported platform-wide rate just below 5% across more than 50,000 code review changes analysed daily and roughly 3,000 automated fixes applied per day. Findings must appear inside the review attached to the diff rather than in a dashboard, because Google's stated purpose is helping the review process and the reviewers scale, and better still they should run in the environment before a pull request exists. Triage then routes change through a small number of exits, auto-merge on green, agent review, named human review, and two humans including security, with risk markers short enough to fit on a card, a predicate evaluated mechanically, and post-merge sampling on every automated path. Absolute floors matter: Faros AI's position that no review at all is unacceptable under any policy, plus no unread merge on a risk marker, none during an incident or freeze, and none for a change that edits the gates. Agent review only recovers capacity when it blocks within narrowly defined classes rather than adding comments, and Stack Overflow's 2025 finding that 58.7% of developers avoid AI-assisted review is a reason to define those classes tightly. Faros AI's objection that this is an authoring problem is largely correct and answered by sequence.

Triage decides who reads a change. Its arithmetic gets easier if each change is smaller. Chapter 7 is PR Size, Batching, and Queue Discipline, which is the supply-side lever on the same queue.