The Last Human Code Review: Building Trust in AI-Generated Code

If AI can write code faster than your team can review it, who verifies that the changes match your intent, architecture, and engineering standards? Code generation can accelerate while the rest of the software development lifecycle remains constrained. The queue moves downstream to the people responsible for deciding whether the code should ship.

That verification requires knowledge specific to an organization. A model may recognize common programming mistakes without knowing why your team chose a particular architecture or which local practices protect production. Itamar Friedman introduces Qodo—short for quality of development optimization—as a system for bringing codebase knowledge, tribal knowledge, and best practices into review. The premise is that this knowledge does not arrive with an off-the-shelf model: the surrounding system must accumulate and improve it over time.

Before removing human review, separate the two jobs it performs.

The pull request is often a senior developer’s last opportunity to explain a design decision before code reaches production. Replacing the quality gate without replacing that exchange would remove part of the team’s learning process.

The question is whether these functions must remain inside human pull-request review. New tools or processes can move them elsewhere, provided both survive. Friedman frames the end of 2026 as a test of that transition: will human review still be mandatory, and will developers still inspect most PRs diff by diff? These are questions about the future workflow, not evidence that human review has already become unnecessary.

Conversations with engineering leaders during the previous evening’s drone show revealed two contrasting attitudes toward production bugs. This was an anecdotal split, but it exposes a decision every team must make:

• Verify before release: Require confidence in each change, with a human responsible for reviewing it before production.
• Repair after release: Accept that bugs will ship, prioritize velocity, and fix problems quickly when they appear.

Most organizations sit somewhere between these endpoints. Their position determines the confidence required to skip human review, the milestones toward automation, and the tools needed to reach them. A team cannot choose a sensible review policy without first deciding which risks it is willing to accept.

Useful review depends on knowing what matters in this system. Friedman argues that model capability is no longer the principal barrier. He describes a visit to an unnamed leading lab where code-review benchmarks had changed little across recent models. No model versions, benchmark details, or scores accompany that observation; it supports his emphasis on context, not a general measured claim that model improvements have stopped.

With the right context, a model can reason about which issues a particular change introduces. Without it, even a strong model may produce generic advice about error handling. Such advice can be correct and still fail to help a reviewer decide what to do: missing error handling may be critical in one location and relatively unimportant in another. The missing capability is not merely recognizing a programming concern. It is judging that concern against the purpose and consequences of the change.

Today, much of that context is scattered across AGENTS.md, CLAUDE.md, and SKILL.md. Organizations, subteams, and individual developers organize those files differently. Some use the same agent for coding and review; others use separate tools. Instructions alone do not ensure consistent behavior when the tools consuming them differ.

The execution environment is spreading out too. Alongside IDE and CLI agents, teams run coding agents in automated workflows. Friedman reports seeing teams generate more of their shipped code outside IDEs and CLIs than inside them. A governance system therefore has to cover the workflows producing code, not just the developer’s interactive session.

Model Context Protocol, or MCP, integrations and retrieval-augmented generation add further sources of context. They also add questions about visibility: what information did an agent receive, and what changed between reviews? Versioning MCP integrations and maintaining datasets or benchmarks for each change can help, but Friedman describes this as difficult to manage. The missing layer is governance over the context and tools on which review depends.

Some of the most valuable information has never reached an instruction file. It lives in developers’ experience, infrastructure documents, Slack threads, and Teams conversations. Codifying it means recovering the reasons behind a standard or architectural choice, including the knowledge that experienced engineers apply without having to look it up.

Once knowledge is captured, its representation becomes an interface design problem. Agents benefit from structured, explicit instructions. Developers need material they can read, understand, and maintain, such as a wiki or onboarding guide. A context engine must serve both audiences so they can collaborate on the same body of knowledge. An agent-only instruction store leaves people unable to inspect the basis of decisions; human-readable documentation alone may not deliver the relevant knowledge to an agent at review time.

The Qodo rule system provides the human-facing example in the talk. It collects the team’s rules and standards and exposes their use during review. In the Qodo example, many rules are applied and four are reported as violated. The review links to all the rules used, allowing a person to inspect the standards behind the result. That traceability is the mechanism for trust: reviewers can examine the basis of a finding instead of accepting an unexplained judgment. Qodo is the demonstrated tool, but the requirement applies to other review systems as well.

The agent-facing interface carries the process beyond an explanation. In the demonstrated handoff, an agent-directed Qodo comment reports five issues in the PR. Friedman describes the following sequence:

1. Qodo reviews the original PR and identifies issues.
2. Background tasks use a Claude Code harness to prepare fixes.
3. A separate, closed PR holds those fixes.
4. An agent returning to the original PR can cherry-pick the prepared changes, which Friedman describes as satisfying the relevant rules and standards.

The closed fix PR is a source of changes for the returning agent; it is not evidence that those changes have been merged into the original PR or deployed.

The handoff connects the same review context to two consumers: people need understandable findings and their supporting rules, while agents need information and links that let them continue the work. Gathering context is only part of the system. Making it available at the point of review and repair is what allows the workflow to progress.

As this process improves, developers should have fewer additional comments to make. Friedman proposes roughly 100 PRs without further human review contributions as a readiness heuristic for automation, not a measured safety guarantee. The useful signal is whether humans still supply judgment that the system lacks. A declining comment count can motivate examining readiness, but the proposed threshold does not establish that the review system catches every consequential defect.

Rules, standards, and skills capture only part of organizational knowledge. The next layer is architecture: how the system fits together and how changes propagate through it. Consider the recent P0 outage an experienced developer remembers—a change to one microservice’s contract broke another microservice. That incident may matter more to the next review than a general coding guideline. Friedman says this architectural knowledge is difficult to build into a review system and is available in some specialized review tools.

The graph shown in the talk represents a microservice, its related repositories, and their connections. An edge records the contract between software components. Relevant graph elements also link to developer discussions and the root-cause analysis from earlier failures. The graph therefore records more than dependency: it preserves evidence about why a relationship needs protection.

For a concrete representation of that mechanism, suppose an order service returns an order_id that a fulfillment service consumes. A compact JSON record could keep the contract and the reason for preserving it together:

{
  "nodes": [
    { "id": "orders", "repository": "orders-service" },
    { "id": "fulfillment", "repository": "fulfillment-service" }
  ],
  "edges": [
    {
      "id": "order-response",
      "provider": "orders",
      "consumer": "fulfillment",
      "contract": {
        "requiredFields": { "order_id": "string" }
      },
      "history": [
        {
          "incident": "INC-42",
          "discussion": "RCA-42",
          "lesson": "Renaming order_id broke fulfillment."
        }
      ]
    }
  ]
}

These example service names and records illustrate the representation. The important placement is the incident lesson on the affected relationship: a reviewer examining an order-response change can retrieve both the consumer’s dependency and the experience that makes it consequential.

With architectural context in place, automated approval and blocking become policy questions. The system needs to learn when the team approves a change and when it refuses one. Friedman calls for semantic rules that express those decisions, rather than allowing an AI reviewer to choose without explicit criteria. In the order-service example, a proposed rule could block removal of order_id while fulfillment still requires it. This is a policy applied to a dependency, not simply a warning that a line changed.

The proposed review surface then expands from an isolated PR to a graph of work in progress. Multiple PRs can appear together with the contracts they may breach. A change that looks acceptable on its own may interact badly with another pending change. The purpose of the graph is to make those relationships visible while the work is still in flight; Friedman presents this as the direction of software governance, rather than demonstrating a completed deployment of every part of it.

That graph must remain open to human audit and control while its context evolves. PR history, accepted and rejected outcomes, developer discussions, and production failures all supply new knowledge. Merely accumulating more files is insufficient: the context needs a meaningful location so an agent can determine where it applies. Governance infrastructure then exposes the overall state of the PRs and software, including the context behind decisions.

If AI-generated code already arrives faster than humans can review it, the bottleneck is present, not hypothetical. More generation does not remove the need to decide what can safely ship. Friedman invokes promised 10× velocity as a motivation for governance infrastructure, not as a measured result. His operational prescription begins with owning the rules and standards and collecting evidence about how they work.

The feedback loop has three parts:

1. Measure rule use. Track which rules, standards, and skills participate in review, how often they produce findings, and whether they remain useful or need updating.
2. Expose contract conflicts. Show the software graph, its connections, and the contracts affected by pending work. Look for PRs that touch the same edge incompatibly.
3. Expand automated gates incrementally. Add rules for blocking and approval over time instead of immediately delegating every decision.

This makes automation a gradual change in the scope of decisions the system can handle. Rule analytics and graph visibility provide the feedback needed to decide what to automate next.

Trustworthy automated review places team rules and standards at the relevant nodes and edges of the software graph. It also preserves the less formal knowledge accumulated in discussions and software history: what to do, what to avoid, and why. Both people and agents need access to that experience.

Friedman calls this move from intelligence to artificial wisdom. Experienced developers currently hold much of the judgment about which changes are good or bad. Transferring some of that judgment to tools requires codifying experience in the right form and attaching it to the right part of the system. The final slide brings together team standards, repository relationships and architectural history, tribal knowledge, and that accumulated judgment.

Qodo’s stated ambition for 2027 is zero outages and zero production bugs, qualified to at least critical and high-severity bugs. It is a future target, not a reported achievement. The substantive shift is where responsibility for review lives: developers must be able to maintain and inspect the knowledge and policies that guide automated decisions, even as they spend less time reviewing individual diffs.