Meta's RADAR sends low-risk diffs past human reviewers as per-developer diff volume climbs 51%

RADAR runs several stages, and the rules differ depending on who or what produced the change ^[8]. It does not ask an LLM whether a patch looks safe and merge whatever it approves ^[8]. The first stage is static. Eligibility and safety checks enforce hard constraints on the source of a change, its scope, its review requirements and the restricted areas of the codebase ^[9].

The post also says which work the system is aimed at. Routine formatting, dead-code removal and mechanical refactoring can often be verified by deterministic checks plus automated semantic inspection, while security, business logic and substantial architectural decisions deserve more scrutiny ^[13]. Meta's RACER already produces work in the first group. Developers hand it dead-code removal, framework migrations, complexity reduction, lint fixes and test generation, and it builds diffs in a sandbox, runs verification and submits them for review ^[6]. RADAR adds an automated path for qualifying changes to move through review and landing ^[7]. We'd expect RACER output to be much of the early traffic.

Two of the post's figures combine into a load estimate. Diffs per developer per month rose 51% ^[2], and significant lines per human-landed diff rose 105.9% ^[1]. If both cover the same developers, 1.51 times 2.059 is about 3.1, so significant lines landed per developer per month roughly tripled ^[17]. That is our product of two ratios, not a figure from the paper, and the post itself cautions that lines of code are an imperfect measure of complexity ^[12]. It attributes more than 80% of the increase in diff volume to agentic AI ^[3].

The post's author frames this as a queueing problem: if changes arrive faster than reviewers can process them, the queue grows ^[11]. Shrijith Venkatramana wrote that "writing code is getting cheaper, but establishing that the code is safe to ship still requires scarce human attention." ^[14]

On outcomes, the post says the paper reports reduced review latency and substantially lower revert and production-incident rates than non-RADAR changes ^[16]. For that to transfer, the non-RADAR group would have to be matched on risk. A filter that admits only low-risk diffs lowers revert rates before any reviewer looks at them. We think the result is consistent with an eligibility filter that selects safe diffs, and it leaves the LLM review's own contribution unmeasured. The post never puts a number on the latency cut or the revert gap, and its pipeline description stops after the static checks.

Provenance matters here too. Venkatramana opens by saying he is building LiveReview, "a blast-radius aware AI code review built for your business-critical systems" ^[10]. His post is a secondary account of the paper, so the figures are worth checking against the paper itself ^[15].