Itamar Friedman on AI Code Review and Engineering Context

OpenAI developer-experience team member Danielle interviews Qodo CEO Itamar Friedman about reviewing AI-generated code. Friedman is presenting his company’s product and vision at DevDay 2026; its claims are not an independent evaluation of review quality.

Friedman says Qodo gathers engineering context and uses it both to assist coding agents and to review their changes. He describes a software map that records relationships and how they change over time.

He distinguishes prompt engineering, workflow engineering and coordinating several specialized agents. His argument is that a review product needs task-specific workflows, tools and constraints rather than a generic instruction alone.

The interviewer asks what an organizational reviewer needs beyond the code. Friedman calls accumulated experience “wisdom” and argues that information about previous decisions and operational behavior should be recorded for future work.

He gives a customer example in which a locally reasonable database change could affect a downstream service. He says a broader software map can help surface that dependency, though the example is a company account rather than a published controlled test.

Friedman recounts moving from single prompts to engineered workflows and then to agent groups. He says agent delegation and tool selection can be wasteful if left unconstrained, and argues for grounding findings in evidence.

Asked how to know whether review improves an outcome, he proposes reducing interruptions to developers while producing high-quality changes. That metric alone would not measure missed defects, so review quality still needs independent evaluation.

The speakers discuss disagreements among a coding agent, an adversarial reviewer and a human. Friedman suggests that differences in context can explain some disagreement and that evidence should accompany claims.

Danielle asks what happens when agents agree but are both wrong. Friedman acknowledges that failures will happen and proposes recording incidents and lessons in a shared knowledge base; agreement does not prove correctness, and learning from one incident does not guarantee it cannot recur.

He describes reconstructing organizational knowledge from past repository discussions and communications, especially when experienced developers leave. Access permissions, privacy and the accuracy of inferred dependencies matter when assembling such a record.

Friedman predicts that an engineering task will increasingly span multiple pull requests and repositories. He argues that a review should consider the end-to-end capability, not only each individual change.

He previews a Qodo feature intended to relate pull requests to a larger work package. This is a company product announcement, and the interview does not establish its availability or effectiveness beyond the demonstration.

For developers building reviewers, he recommends breaking a task into workloads, selecting tools and models for each role and considering cost. The appropriate degree of automation depends on the task and the consequences of failure.

The interview closes by noting that developers still need training even as review workflows change. The title’s suggestion of a “last human review” is a vision, not evidence that human oversight is obsolete.