What this video shows
An OpenAI developer-experience host interviews Qodo CEO Itamar Friedman about reviewing code produced by coding agents. Friedman describes a system that gathers repository context and team knowledge, gives that context to the coding agent, and then reviews the resulting pull request. He argues that teams should write down the architecture, conventions, and policies that experienced reviewers already apply.
The strongest practical idea is reviewer independence. A reviewer should inspect the task, diff, surrounding code, and organization-specific review rules instead of accepting the producing agent's account of its work. Teams can apply that idea with Qodo or another reviewer, but they should keep deterministic tests and static analysis as separate gates, then require a person to judge risky design, security, and product decisions.
Read Qodo's platform architecture for the vendor's description of its context and knowledge layers. Compare the claims with GitHub's documented limits for AI code review, including missed issues, false positives, and insecure suggestions.
What you will learn
- A diff rarely contains the full reason behind an architecture rule, migration sequence, security boundary, or compatibility requirement.
- An AI reviewer needs explicit repository and organization context, but retrieved context can still be incomplete or stale.
- The producing agent and reviewing agent can share blind spots, especially when they use related models or the same incomplete context.
- Tests and static analysis check properties that prose review may miss, while a human reviewer remains responsible for accepting the change.
How to apply this safely
- Write a short review policy for one repository that names required tests, protected boundaries, compatibility constraints, and the changes that need specialist approval.
- Give the reviewer the task, diff, relevant tests, repository instructions, and a small set of trusted architecture documents.
- Ask the reviewer to cite a file, test, rule, or observed behavior for each finding and to mark uncertainty instead of guessing.
- Run tests and static analysis independently, then have a person inspect high-risk changes and decide whether the evidence supports merging.
Important limitations
- This is a vendor interview rather than an independent benchmark. The speakers describe Qodo's approach without reporting a controlled comparison, false-positive rate, or defect-detection rate.
- More context does not guarantee a correct review. Old documents, missing runtime behavior, and shared model blind spots can still produce confident mistakes.
- AI review should supplement domain, security, and product review when a change can affect customers, data, access, money, or production systems.
Sources to check
- Qodo platform architecture Qodo's description of its code graph, knowledge layers, and review system.
- Responsible use of GitHub Copilot code review GitHub's published limitations and recommendation to supplement AI comments with human review.
Continue learning on Learnetto
Best coding-agent courses
Learn how to scope, test, and review agent-generated changes.
Best AI agent evaluation courses
Build cases and graders for tool-using systems.
AI evals guide
Compare deterministic checks, model graders, and human review.