Daylight's two review lanes: the AI scores the risk, fixed rules make the call
With pull requests up 3.5x since January, Daylight stopped asking humans to read everything. An AI judge scores each change's customer impact, deterministic rules turn that into a low or high lane, and about half of changes now merge without waiting for a person, with no rise in reverts.
Source: Accelerating the Software Factory: Code Review for an AI-Native Team — Asaf Rosentswaig, Daylight
Asaf Rosentswaig's account of how Daylight rebuilt code review starts with the familiar curve. Once agents began writing changes end to end, the team opened more than 3.5 times as many pull requests per week as in January, and volume grew about 1.6 times from September to October alone. Every one of those changes still waited for a human approval, so the queue, not the writing, became what slowed work reaching customers.
Instead of trying to make humans read faster, the team asked what review is for. Their answer was shared knowledge of the system and protecting customers, and neither requires a person to read a dependency bump. So every pull request now answers two questions. Is it correct? CI runs, an AI reviewer looks for bugs, and the authoring agent fixes what it finds before a person looks. How far could it reach if we're wrong? That puts the change in a Low lane, approved automatically once its safeguards pass, or a High lane that waits for an expert.
Why it matters for code review
The design choice worth stealing is the split between judgment and decision. An agent investigates each change, follows it through the codebase, checks related feature flags, and scores customer impact on dimensions such as security, data access, and reliability. It never makes the call: fixed rules in code turn those scores into a lane, so the same scores always give the same verdict, and a disagreement becomes an argument about one score and its evidence. The pull request description is treated as a claim, not evidence, and the rules are read from main, so nothing in a PR can change how it is judged. Auth, permissions, migrations, and CI or deploy config always go to a human, and every approval is pinned to the exact commit, so a new push withdraws it.
They also measured the judge against the error that actually hurts. Hand-labeling real PRs showed that simple path and size rules would have cleared only a small slice of safe changes, while human judgment found about nine times as many. The team then iterated until the judge sent every change engineers had tagged for human review to High, across repeated runs, while still routing roughly two thirds of changes to Low. A planning skill now splits features into stacks of small changes and gathers the risky lines into one focused PR for the expert.
The reported result, in the repositories behind the gate: about 1.5 times as many changes reach production each week, median open-to-merge is about 3.4 times faster, nearly half of changes flow through the low lane, and the revert rate has not gone up. It is a company describing its own system, so the numbers are self-reported, but it is a concrete picture of what keeping steady agent throughput moving looks like once human reading stops scaling: spend expert attention by risk, and let verification, not a person's availability, decide when everything else merges.