When AI starts inflating pull requests, most engineering organizations reach for the fixes they already trust. They add reviewers, tighten approval rules, and lean harder on the senior engineers who know where the architectural traps are. The response looks disciplined, and it makes the queue longer, because every one of those fixes adds human attention to a process that was already short of it.
Itamar Friedman, Co-founder and CEO of Qodo, contends that the process itself was sized for a different era. “For decades, code quality was built around people,” he explains. “This worked because software was being written at human speed.”
Qodo builds AI code review and governance tools, so Friedman argues from inside the market he writes about. The case he makes still applies well beyond any single product, and it starts with where the old model stopped fitting.
Review processes were sized for human speed
The quality system most teams inherited rests on senior engineers reviewing pull requests, coding standards documented in wikis, linters, test coverage targets, and a review cadence that kept all of it moving. Friedman sees that system straining under a load it was never designed to carry. “Teams using AI heavily are already producing much larger PRs, reviews are taking longer, and more bugs are making it into production,” he observes. “That’s not because engineering teams suddenly became less disciplined, but the system they’re relying on was designed for a completely different pace of development.”
His alternative moves governance out of people’s calendars and into the platform. “The next evolution of software engineering is treating governance as infrastructure,” Friedman says. “This means standards are machine-readable, consistently enforced, and automatically applied by the agents participating in the software lifecycle.” The knowledge that currently protects a codebase needs a new home as well. “Visibility into codebase health and architectural integrity can’t live in the heads of a handful of senior engineers anymore,” he underscores. “It has to be built into the engineering system.”
Before changing any process, establish what AI adoption has actually done to review in your own repositories. Pull median PR size, time to first review, time to merge, and escaped defects for the last two quarters, and split each by whether the change was AI assisted. Industry figures vary widely by team and tool, and your own numbers show exactly where the queue builds, which gives you a baseline to judge every governance investment that follows.
Standards living in wikis cannot scale
Treating governance as infrastructure assumes the standards exist in a form a machine can read, and Friedman’s next point is that most organizations fail that test before they start. “Most organizations have coding standards,” he points out. “They just aren’t stored anywhere a machine can understand them. Instead, they live in wikis nobody reads, in scattered PR comments, and in the institutional memory of senior engineers.” That arrangement survived for years for a specific reason. “This was tolerable when code was being written at human speed because experienced engineers had time to coach the rest of the team.”
Many teams have responded by writing guidance into agent instruction files such as .cursorrules and AGENTS.md, and Friedman credits the instinct while doubting the result. “And while this approach helps individual developers, it doesn’t scale across enterprise environments,” he cautions. “Different tools rely on different instruction formats and rules become fragmented across repositories and agents. Simply giving AI access to guidelines doesn’t guarantee that they’ll be enforced consistently.”
The cost of that gap compounds in three places. Senior engineers turn into review bottlenecks, repeating the same guidance across dozens of pull requests a week. “Standards drift because they’re enforced differently by different reviewers,” Friedman notes. And he warns that “code that looks clean on the surface can still violate architectural decisions or organizational best practices because there is no centralized, machine-enforceable source of truth.”
Give your standards one canonical, versioned home and govern it the way you govern code, with changes proposed and reviewed through pull requests. Generate or sync every tool-specific instruction file from that source rather than letting each file become its own authority, so a rule changes once and every agent picks it up. Start with the ten comments your reviewers repeat most often, since those are the rules already costing the most senior time.
Mine the rules reviewers already enforce
Writing a rulebook from scratch is the step where most teams stall, because nobody has a free quarter to author one. “As teams grow, that tribal knowledge becomes more difficult to scale,” Friedman adds, and his answer starts from the reviews teams already perform. Qodo’s Rules Miner analyzes existing pull request history, identifies the patterns reviewers consistently enforce, and turns them into rules, so the organization captures standards it already practices rather than inventing new ones.
Friedman is direct about the weakness in learning from the past. “But like any system that learns from history, it still needs oversight,” he reasons. “If a team has been consistently enforcing an outdated rule, the system can learn that too.”
Treat every mined rule as a proposal rather than as policy, whether a tool does the mining or a staff engineer samples a quarter of review comments by hand. Each rule needs an owner who approves it, one line explaining why it exists, and a date for its next review. Look hardest at rules that trace back to a single reviewer or to code the team has since migrated away from, because those are the places where history encodes one person’s habit rather than the organization’s intent.
Agent skills need governing as a program
Once standards exist in machine-readable form, the next question is who governs the instructions agents follow, since those have started multiplying faster than anyone tracks. An agent skill packages a SKILL.md file with supporting context that encodes how a team wants AI to work, from coding standards and architectural decisions to ownership maps and review checklists. “Because it’s open and agent-agnostic, adoption is spreading fast,” Friedman says.
Scale is where the format creates its own governance problem. “Once skills are scattered across repositories, there’s no visibility into what exists, what’s active, or what impact they’re having,” he explains. “The organization’s engineering intent exists, but it’s effectively invisible and inconsistently applied.” The timing matters because the files have changed roles. “The governance layer is becoming necessary now because AI has turned these instructions into active participants in the development process,” Friedman maintains. “When agents are executing against them at scale, you can’t treat skills as passive files anymore. Governing skills as a program means discovering them across repos, surfacing them centrally, and tracking their impact, so governance becomes measurable and traceable.”
Take an inventory this month. Search every repository for SKILL.md files and other agent instruction files, list them in one place with an owner and a last-modified date, and retire the duplicates and contradictions you find. Require the same review for a change to a skill as for a change to shared code, since both change what ships, and track which skills agents actually invoke so you can tell a working standard from a forgotten one.
Most breakage starts between repositories
Skills and rules govern what agents do inside a repository, and the failures Friedman worries about most happen at the edges between them. “The biggest engineering failures rarely happen inside a single repository,” he warns. “They happen at the boundaries between systems.” A developer updates a shared library, changes an API contract, or modifies a schema, and the pull request passes review because nothing looks wrong inside it. Another service depends on that code, and nobody reviewing the change can see it. “The first sign something broke is often a production incident days later,” Friedman notes.
Qodo’s answer is Cross-Repo Code Review, and the mechanism generalizes to any team that owns shared components. “When a PR modifies a shared component, the system analyzes connected repositories before the merge and surfaces downstream impacts, whether that’s a broken API contract, a schema change, or a function signature mismatch, with links to the affected code,” he explains. “The real shift is moving risk detection from after deployment to before merge.” The urgency tracks the volume of generated code. “As AI generates more code and more cross-repository changes, that level of visibility isn’t just helpful,” Friedman argues, “it’s becoming essential.”
Start with a consumer map for your shared libraries, public APIs, and schemas that records which services depend on each one, and attach it to every pull request that touches those components. Add a required check for changes to any of them, and back it with contract tests between producers and consumers, which catch many of the same breaks without new tooling. The goal is for the author to see downstream impact before merge instead of the on-call engineer finding it after deploy.
Infrastructure decides when review can relax
Each of these moves shifts verification away from a person reading a diff, and Friedman expects that shift to change what review means for some organizations within a year. “Within twelve months, I expect mandatory human review of every pull request will become optional for more and more organizations,” he predicts. “Not because quality matters less, but because verification will move from manual inspection to governed, automated review.” He expects the timing to vary widely. “For some industries and developer organizations this is a 2026 change. For others, it will take until 2030.”
That forecast comes from a CEO whose company sells automated review, so leaders should read it as a conditional rather than as a timeline, and Friedman frames it that way himself. “What separates the two is not appetite,” he contends. “It’s infrastructure.” The conditions he points to are how much engineering context and tribal knowledge a team has codified, whether review and verification agents can govern standards and architecture, how mature its automated tests and runtime verification are, and whether the organization trusts the governance layer that manages all of it.
Score your organization honestly against those four conditions, service by service rather than company-wide. Relax mandatory human review first where all four are strongest, typically low-risk, well-tested services with clear ownership, and keep human reviewers on everything else. Let the defect data from that first group decide how fast the change spreads.
The principle Friedman keeps at the center of all of it is worth carrying into any of these decisions. “The goal isn’t to replace engineering judgment, but to capture it, scale it, and keep it current,” he says.