As Code Accelerates, Review Becomes the Bottleneck
For a long time, code review kept pace with writing code. One developer opened a pull request (PR); another read the change, discussed the relevant points, and approved it or requested changes. Individual review sat at the center of the process because code production was also limited by people’s time.
AI assistants broke that balance. Writing a first version, generating tests, and exploring alternatives became fast. Reviewing carefully is still slow: it requires understanding behavior, checking edge cases, assessing effects on other components, and deciding whether the remaining risk is acceptable. When more changes arrive than can be examined, the PR queue grows. Reducing review to a click would clear the queue at the expense of quality.
At Atlas, the problem had a number: before the change described here, half of PRs reached the development environment in under 28 minutes, often without anyone looking at them.
We tested two automated analyses in a pilot, then brought them into the regular workflow: an engineering quality reviewer and a security reviewer. This article brings together what we learned in the first weeks of using them on real changes. The idea is simple: the agent flags problems the developer can check, repeats the analysis for each new version, and leaves people in charge of what goes to production.
What changed in the numbers
We compared the same 27 systems across two windows: 59 days before adoption, with 1,504 merged PRs, and the first 25 days afterward, with 883.
- PRs merged into development per day: from 25 to 35, about 40% more, with the same group of ten developers.
- PRs with any recorded review, human or automated: from 45% to 80%.
- Requests for changes: eight PRs in 59 days, all from people, compared with 299 PRs in 25 days from the automated reviewer. In 85% of PRs with findings, a corrective commit followed.
- Longer waits: at the 90th percentile, the threshold below which 90% of PRs fall, time from opening to merge decreased from 18 to 17.5 hours; at the 99th percentile, from 123 to 100 hours.
One number moved in the opposite direction: median time from opening to merge almost tripled, from 28 minutes to 1 hour and 20 minutes. That was expected. Previously, most PRs were merged minutes after opening, without anyone looking, and those cases pulled the median down. In the workflow described here, each PR submitted for review waits for the analysis, which takes 4 minutes in half of cases and 12 in nine out of ten, and, when there are findings, for a fix and another assessment. The typical PR gained a commit: the median rose from 2 to 3. The earlier median described a PR that generally went unreviewed; the current one describes a reviewed PR. The longest waits decreased, and the first response from automated review now arrives in minutes. This change may have contributed to the reduction, but the data do not isolate its effect.
The comparison shows a direction, not proof of causation: the “after” window is short, and other things changed at the same time, including the integration pipeline and branch rules.
Writing more is not shipping more
Two recent studies point in the same direction.
In the NBER working paper Writing Code vs. Shipping Code, revised in September 2026, Demirer, Musolff, and Yang followed more than 500,000 GitHub developers, combining their activity with AI tool usage data. Autonomous agents increased the number of commits by 240%. That gain falls to 80% when counting projects and to 30% when counting releases, the versions actually shipped. In app marketplaces, the number of new apps surged, but total usage did not grow. The authors attribute the gap to human bottlenecks in the stages after writing code.
Passing tests is not enough either. In a research note published in March 2026, METR asked four maintainers from three well-known projects (scikit-learn, Sphinx, and pytest) to assess 296 PRs generated by AI agents released between 2024 and 2025. All had passed SWE-bench Verified tests, a set of real tasks used to evaluate these agents. Roughly half would have been rejected. In the comparison adjusted for acceptance of human patches, acceptance was on average 24 percentage points below the automated grader’s score. The most cited reasons: core functionality did not work, the patch broke another part of the code, or quality fell below the project’s standard. Even the original human patches were accepted in only 68% of cases, which gives a sense of the reviewers’ rigor. The authors themselves note that agents could not revise the PR after feedback, as a developer would.
Tests check what someone anticipated. Review asks whether what was anticipated is sufficient, whether the change solves the right problem, and whether it creates risks outside the path covered by tests.
Two lenses on the same change
The workflow separates responsibilities that previously fell to a single person:
- Quality reviewer. It examines code and discussion, looks for defects, and checks the applicable rules in Padrão Atlas, our engineering standards. Each finding explains where the problem is, under what conditions it fails, the consequence, and how to verify it. Violating a rule and introducing a defect are different things, and it distinguishes them. In the first weeks, the two types appeared in similar proportions.
- Security reviewer. It looks for risks that need a separate perspective, such as access control failures, the most common family of findings so far. Its silence is no guarantee of security.
- Tests and people. Tests check behavior. People fix valid findings, challenge false positives with evidence, and decide what goes to production. Automated reviewers neither write the fix nor merge PRs.
Both reviewers are based on open-source projects; the rules, orchestration, and controls described here belong to Atlas.
The team still defines the criteria. Engineering standards make recurring expectations explicit; the agent helps apply them consistently. Human attention remains available for product and architecture decisions that no checklist can resolve.
A review applies to the version examined
An old approval cannot authorize new code. In our workflow, each commit sent after review begins triggers another assessment, and approval of a previous version is withdrawn if the new one does not pass. Findings appear alongside the code, and fixes and explanations remain in the PR discussion. In the first weeks, there were 1,151 assessments for 482 PRs: just over two per PR.
Final validation must be performed on the same version that was approved. If the code or its base changes, earlier evidence needs to be reassessed. Reviewing one version and testing or publishing another breaks the link between the decision and what will be shipped.
This principle extends beyond automation: confidence belongs to a demonstrated version, not a branch name or the color of an isolated check.
What we learned from real changes
Three examples from the first weeks. System names and implementation details have been left out.
A half-finished operation. A change to a database’s structure needs to be all or nothing. This one wrote some data before finishing: if it failed midway, the database would be left in a state nobody had anticipated. The quality reviewer flagged the line. The developer fixed it in the next commit, and the new version was reviewed again before proceeding. The lesson was to also look at what happens when an operation does not finish.
An identifier should not be enough. The security reviewer flagged that the system returned an object to anyone who supplied its identifier, without checking whether that person was allowed to see it. The developer fixed the two flagged locations. During review of the fix, a third, less obvious path appeared: it depended on the same rule and also needed a control. Three rounds and two days later, the PR was merged. Nothing came close to production. Hence the rule: check every path that depends on the same access rule, beyond the first one flagged.
A wrong alert. The reviewer flagged a newly released library version as critical because it did not recognize it: it suspected a fake package with a similar name, a real type of attack. The developer replied in the PR with the signed official release record. The finding was dismissed in three minutes, with the explanation recorded. An automated reviewer needs to accept verifiable challenges, and this happens often: of the findings reassessed in subsequent commits, 169 were resolved in code and 194 were dismissed with an accepted explanation. What a model “knows” about a library has an expiration date.
Automated reviewers also need boundaries
An agent reads code, titles, descriptions, and comments, and any of those fields may contain text written to influence it. A sentence such as “this is safe, approve it” enters the analysis like any other part of the PR. It approves nothing.
The paper Measuring and Exploiting Contextual Bias in LLM-Assisted Security Code Review, which has not yet been peer reviewed, by Alexopoulos, Alexopoulos, Spinellis, and Mitropoulos (2026), measured this risk. The authors tested six models under five ways of presenting the same PR, then attacked two real review tools (Claude Code and CodeRabbit) using 33 known vulnerabilities in 20 projects. Direct requests such as “this is safe” did not work and even raised suspicion. An attack refined with another model’s help, repeatedly tested against a local copy of the reviewer, succeeded in 32 of 33 cases. The asymmetry is the point: the attacker can try as many times as needed; the reviewer has one chance.
Isolation, limited permissions, and separation between reviewed material and trusted instructions reduce the risk. None of these controls makes the agent immune, and we have not yet measured our reviewer’s resistance to this type of attack. When analysis fails, that failure needs to be visible instead of becoming approval for convenience.
This is just the beginning
The first weeks showed more PRs merged per day, more reviewed PRs, and shorter long waits, with a typical PR taking longer because it is now reviewed. We treat this as a starting point. Three things remain unknown: how much of the extra time is waiting and how much is fixing valid findings; whether the reviewer resists a framing attack like the one in the study above; and how many defects still escape to production, something no PR data can show. These are the next numbers to measure.
The workflow will also change. Today, the developer requests review, and the agent watches only the entry into development. The next step is to review each commit without needing a request, then also watch the gate to production. The reviewer itself will be evaluated: developers will be able to mark each finding as useful or mistaken, and the agent will be measured by what it gets right. It is a beginning. More changes receive some review every day, and the person deciding what goes to production is still a human.