AI has sped up code writing, but has made code reviews the main bottleneck

Agents are already writing a significant portion of the code that makes it into production, but humans still review that code. As a result, the bottleneck in development has shifted: the challenge is no longer how to generate more pull requests, but how to identify which ones are truly risky.

According to survey data cited in the article, teams with a high level of AI adoption in 2025 merged 98% more pull requests than they did the previous year. At the same time, review time increased by 91%, and the size of pull requests grew by 154%. The rate of pull request generation is growing faster than humans’ ability to make sense of the results.

This is bad news for the traditional “small pull request—quick review” process. An agent can create a database migration, a model, a service, and tests in a single pass. Breaking such a change down into multiple pull requests doesn’t necessarily make it easier to understand: the context is simply spread across different locations, making it harder for the reviewer to see the big picture.

Assess the Cost of Failure First

One suggested approach is to focus not on the size of the change, but on the consequences of a failure. Updating a dependency is usually reversible: if something breaks, the problem can be detected in tests or on staging and rolled back. Database migration is a different class of operation: the consequences can be serious, so manual oversight is required here.

This is an important shift in thinking. Not all code needs to be reviewed with the same level of thoroughness. For low-risk changes, you can rely on automated checks and review agents. For changes affecting data, access permissions, or critical components, you need to designate a person in advance to make the decision.

Rootly, for example, has added a risk label to every PR. It is determined by what would happen if there were a failure in production: the scale and severity of the impact. A template is also attached to the PR explaining the reason for the change, its essence, access control checks, exception logging, and a rollback plan.

Don’t Speed Up Reviews; Make Mistakes Less Costly

Trying to force people to review at the speed of agents is a questionable strategy. It’s more reliable to ensure that a mistake doesn’t turn into an incident lasting hours.

This requires automatic rollbacks, canary deployments, feature flags, and CI/CD capable of safely halting a change. At Intercom, according to the article, features are separated from the deployment and can be disabled in less than a minute. The team also focuses not only on the state of the systems but also on user outcomes: an automatic rollback is triggered when key customer metrics deteriorate after a deployment. As a result, downtime caused by breaking changes has decreased by 35%, and the frequency of deployments has doubled.

AI reviews are useful here, but they are no substitute for a safety architecture. An agent can detect policy violations, security issues, and common errors. However, if a change is irreversible, even a good automated comment does not answer the question of who should assume the risk.

“Who wrote the prompt” is not the answer

As agents scale, another problem arises: ownership. An organization may have dozens of autonomous processes connected to different services, and there may be no single place where their interdependencies and permissions are visible.

Responsibility cannot be shifted to the agent itself. If an agent modifies a component and causes an incident, the owner must be the person or team responsible for that component. This is a more robust approach than trying to identify the author of a specific prompt: in a fully automated process, that author may not even be involved in every change.

This leads to a practical requirement for the agent platform: every process must have an owner, a clear set of permissions, and an action log. Otherwise, the growth in the number of machine identities will quickly turn into an increase in areas for which no one is accountable.

The Speed of Code Lines No Longer Proves Anything

Companies are gradually moving away from measuring efficiency by the number of lines of code generated or tasks completed. What matters more is what user outcome was delivered and at what cost to system reliability.

The article cites Uber as a telling example: according to its COO, about 70% of the company’s code is generated by AI, but there is no direct correlation between this figure and the growth of useful features for users yet. Generating more code is not the same as creating more value.

The main conclusion is simple: mature AI development is not built around maximizing agent autonomy. It is built around risk classification, reversible changes, rapid rollbacks, and clearly defined accountability. Until these mechanisms are in place, increasing the generation speed merely fills production with code faster—code that the team doesn’t have time to truly understand.

Source: Hacker News - Newest: ""AI" "LLM""