Faros AI: AI Agents Drove a 98% Rise in Pull Requests, but Review Time Grew 91%

Teams with AI agents write code faster, but it doesn't reach main any faster, and in places it arrives more slowly. Habr examined this paradox using data from Faros AI, CircleCI and DORA. The most-cited figure comes from the Faros AI report, which is based on telemetry from more than 10,000 developers: those who actively use AI close 21% more tasks and merge 98% more pull requests. Review time, however, grew by 91%.

The logic is simple. Code generation has become nearly free, but review is still human work. If twice as much material enters the pipeline and the same reviewer sits at the end, the queue grows.

Where code gets stuck

The problem is not the number of PRs but their size. According to Faros AI, the average pull request in teams with a high level of AI adoption grew by roughly 154%. An agent readily does a large refactor, adds tests and touches neighboring modules. The reviewer has to hold more context in their head, and a careful read of an 800-line diff takes far longer than one of 300 lines.

QA is the second point of loss. Faros AI recorded a rise of roughly 9% in bugs per developer. Every additional defect sends a task back through the loop: comments, fixes, another CI run, another review. The "tasks closed" metric goes up, while lead time to production stays flat or increases.

DORA data paints the same picture from a different angle. In the 2024 report, a 25% increase in AI adoption correlated with a 1.5% decline in delivery throughput and a 7.2% drop in stability. DORA later described AI as an amplifier: it speeds up good processes and exposes weak ones. CircleCI looks at the problem through CI pipelines. They show where failed builds and long runs pile up, that is, where writing speed runs into verification speed.

Metrics worth tracking

Commit statistics alone are not enough to find the bottleneck. You need an end-to-end view from the first commit to deployment:

• Time to first review: how long a PR waits before anyone looks at it at all.
• Total review time: from opening to approval.
• PR size in lines and files, plus the median and the 90th percentile.
• Share of PRs sent back for rework after review or QA.
• Change failure rate and time to recover from an incident.
• Lead time for changes: from commit to production.

If the first two metrics rise along with the number of PRs, the problem is review. If the share of returned PRs and the change failure rate rise, the culprit is the quality of the generated code and tests themselves.

What teams should do

First: limit the size of changes. Many teams are introducing a hard cap on PR size and asking agents to split work into small, atomic pieces. This is cheaper than hiring two more reviewers.

Second: bring AI to the review side as well. Automated first-pass review, linters, static analysis and test generation take the routine work off humans and leave them with architectural questions. But the quality of that review also needs to be measured, otherwise the bottleneck will simply move somewhere else.

Third: rethink productivity metrics. In the era of agents, the number of PRs and closed tasks per person says almost nothing. Lead time and release stability are more telling, and these are the metrics DORA has used for many years.

Fourth: strengthen automated checks before review. The more reliable the CI and the test coverage, the less work is left for people. Here is a practical check for any team lead: take the last 100 merged PRs and see how much time each spent waiting for review rather than in development. Most likely, that is where the gain the agents promised you is sitting.