AI Writes the Code, But Humans Can't Review It All. Now What?

The debate about whether AI can write production code is over. Companies are handing work to fleets of agents, and at many of them, agents write most of the code that ships to production.

The next challenge is everything that happens once an entire engineering organization runs this way, at full speed. Teams that generate code 10 times faster still review it at human speed, and that mismatch is now the constraint. Code ownership is also becoming an issue as developers learn to trust agentic processes a little too much. When an agent breaks production, who is responsible?

This article is inspired by insights from a recent panel on running AI at enterprise scale, featuring engineering leaders and moderated by Ian Sinnott, a Member of Technical Staff at Anthropic.

The bottleneck moved from writing code to reviewing it#

When agents write code faster than humans can vet it, code review becomes the constraint. A recent survey found that high-AI-adoption teams merged 98% more pull requests in 2025 than a year prior, but PR review time rose 91% and PR size grew 154%. So what is a scalable solution that does not burn engineers out?

More AI is obviously part of the answer, but AI review alone does not fix AI risk. Twingate's VP of Engineering, Eran Kampf, shared that they focus on two specific metrics: “We look at reversibility and judgment density.” For reversible operations like upgrading a dependency, the agent can commit; if it breaks, it will probably break in tests or staging. For operations like a database migration, on the other hand, you want a human to review the code.

Rootly went after the review process itself. It first tried to enforce small pull requests, but “AI agents don't work that way,” shared its CTO, Quentin Rousseau. While humans think and execute incrementally, coding agents generate an entire migration, model, service, and tests in one shot. Splitting that into five PRs just scatters the context a reviewer needs.

Rootly built an agent that attaches a risk label to every PR, which determines whether a human should review it. That risk level is based on what happens if the PR breaks production—the severity and scope of impact—rather than how big the change is. Each PR also uses a specific template that requires the author to explain the why and the what, and includes a checklist covering access control, logged exceptions, and a rollback plan for safely undoing the change.

Optimize for reversibility, not faster review#

Betting on rollbacks seems to be a winning strategy for the agentic era. Rather than trying to make human review keep pace with agent output, Rousseau invested in making mistakes cheaper. “We improved our CI/CD pipeline with better automation, rollbacks, canary deployments, and people can ship much faster that way.” Agents now handle most reviews. “To be honest, they review code better than I do,” he said, with dedicated security and best-practices agents enforcing the organization's rules on every PR.

The pattern holds outside the panel. Intercom's engineering team ships around 180 times a day, with feature flags that separate deploy from release and can switch a feature off in under a minute. To know how a deployment is doing, the team stopped monitoring systems only. Instead, it focused on outcomes: automatic rollbacks fire when heartbeat metrics—customer outcomes rather than system health—dip after a deployment. It paid off, with downtime from breaking changes dropping by 35% while deployment volume doubled.

Who is responsible when things break?#

Reversibility makes mistakes cheap, but it does not answer a harder question. When an agent does cause an incident, who is accountable?

“Beyond the identity, you also want to set the accountability for the agent's behavior,” said Port CEO Zohar Einy. “Set a human owner to the agent, making sure that there is someone accountable for what the agent is doing. When no one is accountable, you can blame the agent.”

CyberArk's 2025 Identity Security Landscape found 82 machine identities for every human in the average organization, and most companies cannot say what all of them are doing.

Descope's Head of AI Strategy and Developer Experience, Kevin Gao, described the mess underneath that number. “You have like 10 different teams who have all built agents doing vastly different things, and there's no unified central place where I can just look and see which agents are connecting to which services.”

Here, common sense is to hold the developer who initially directed the agent to make the change accountable. But what happens when the whole process is automated? Einy argues that “the owner would be the team in charge of that component, the part in the system that the agent is touching.” Accountability stays with whoever owns the component, not whoever wrote the prompt.

The hype gap: is anyone “AI-native” yet?#

An audience member asked the panel a simple question: what should you expect from engineers now?

The consensus was that velocity is no longer what engineering leaders look for; they prioritize quality and delivered value instead. “It went from who is shipping the most lines of code per day to who is actually shipping value,” said Rousseau. Kampf was blunter: “Now that anyone can do slop AI, you ship a lot, but is it valuable stuff or crap?”

That echoes Uber COO Andrew Macdonald, who recently shared that 70% of Uber's code is AI-generated and that the link to product value is “not there yet.” As he put it, “It's very hard to draw a line between one of those stats and ‘now we're actually producing 25% more useful consumer features.’”

Most engineering organizations are far from being comfortable with the agentic era. The capability is real, but the work of turning it into a reliable, production-grade engineering practice is mostly still ahead. For Einy, most companies are still in the “AI-assisted” stage.