Code review exists to check code quality and architecture, and to give developers a final chance to align and learn before production.
2
Models are no longer the main limit on automated review; the useful difference comes from giving them the context of a team's rules, architecture, contracts, and past failures.
3
Teams should move gradually from pull request review toward graph-based software governance, with rules that can automatically approve or block changes.
Summary
Itamar Friedman argues that AI-generated code has moved the bottleneck from writing software to reviewing and governing it. He frames code review as having two jobs: checking quality, safety, maintainability, and architecture, while also giving senior developers a chance to teach and align with the team. Friedman says models can already reason well when they receive the right context. That context is scattered across instruction files, tools, documents, Slack, and developers' memories. Teams therefore need a context system that works for both humans and agents. Humans need visible rules and audit links, while agents need structured review results and prior fixes. The richer version includes service contracts, architecture, discussions, and production outages. Friedman's end state is a software graph where several pull requests can be checked for conflicts together, and approval or blocking rules are added gradually. His position is aimed at teams shipping generated code faster than people can inspect it.
Code review checks software quality and creates a final teaching point
Friedman gives code review two purposes. The first is to check that code is high quality, safe, maintainable, and consistent with the intended architecture and team practices. The second is alignment and learning. Senior developers get a final chance to act as a gatekeeper before code reaches production, while explaining decisions to other developers. Any automation has to preserve both jobs. A faster pull request process is useful only if it still lets the team validate the code and share its standards before release.
Engineering teams differ on whether speed or human trust comes first
Friedman describes two positions he heard from engineering leaders. One group wants every line of code to be trusted by a human before it ships. The other accepts that bugs will reach production and prefers to fix them quickly because velocity matters more than getting everything right beforehand. Most teams sit somewhere between those positions, but the choice still affects the tools and milestones they need. A team that wants to skip human pull request review needs a different level of confidence from a team willing to repair failures after deployment.
The missing ingredient in automated review is context
Friedman says models are no longer the main barrier to useful code review. He had recently examined code review benchmarks from leading model labs and said they had not changed much across recent model releases. With the right context, models can reason about issues in a code change. Without it, even a strong model may produce generic suggestions such as asking whether the developer considered error handling. That advice can be correct in one system and irrelevant in another. The team's actual standards and situation determine whether a finding matters.
Team context is scattered across tools and varies between groups
The information needed for review is spread across files such as AGENTS.md, CLAUDE.md, and SKILL.md, along with coding agents in IDEs and agents running in automated workflows. Different teams and sub-organizations use different standards, and they may use different agents for coding and review. Friedman also mentions MCP and RAG-style context as sources that are difficult to manage and version. More generated code is already being shipped from workflows rather than directly from a command line or IDE, so teams need a governance layer that can control all of these sources.
Much of the team's real knowledge remains in people and conversations
Friedman says an organization's experience and tribal knowledge exists partly in documents and infrastructure documentation, but much of it stays in developers' heads. Other parts are buried in Slack or Microsoft Teams conversations. This knowledge affects how experienced developers judge what is safe, useful, or likely to break. To automate that judgment, teams need to collect it and turn it into usable review context. The task is larger than copying existing instruction files because important decisions may only appear in a discussion or in a developer's memory.
The context system has to be readable by humans and usable by agents
Friedman describes codified knowledge as an interface for collaboration between agents and humans. Agent-facing material may need to be verbose and structured, while developers prefer wiki-style pages and practical getting-started documentation. Both forms are needed. In his Qodo example, a review can show people which rules were used and which rules were violated, with links to those rules. The same review can leave a structured comment for another agent, including detected issues and the fixes already attempted. People get an auditable explanation, while agents get information they can act on in a later pass.
Fewer human comments can indicate readiness for automation
Once reviews use the right context and provide information for both audiences, Friedman expects developers to write fewer comments on pull requests. He proposes observing this over a large set of pull requests, then using the decline in human intervention as evidence that the process is ready for more automation. The automation should not appear all at once. Teams can add rules that block or approve changes gradually, based on the standards they have accumulated and the review cases they understand.
Architecture and past outages are part of the review context
Rules and coding standards are only the simpler layer of organizational knowledge. Friedman says a deeper context engine needs to understand system architecture, service contracts, and serious bugs that caused outages. His example is a change in one microservice's contract that breaks another service. He describes a graph connecting repositories and services, with contracts on the edges and links to developer discussions about root-cause fixes. This information lets a review reason about the consequences of a change instead of judging the edited lines in isolation.
Software governance can move from individual pull requests to a connected graph
Friedman's proposed end state is a graph view of software development. Pull requests appear as changes in the graph, and the system can identify when several changes in flight may collide or break a contract. Approval and blocking decisions come from semantic rules owned by the team, rather than from an agent making an unexplained choice. The infrastructure should track which rules are used, how often they catch issues, and whether they need updates. Teams can then add automatic approvals and blocks step by step.
"Software development, at least code governance, is going to change from reviewing your pull request to actually reviewing your entire software development from a graph abstraction."14:16
Who should watch
Your team is shipping AI-generated code faster than developers can review it, and you need to decide what evidence would justify skipping line-by-line review.
You are building coding agents across IDEs and automated workflows, but their rules and context differ between teams.
You want to connect code review with service contracts, architecture, prior incidents, and gradual automatic approval or blocking.
