Qodo CEO on AI Code Review: When 'Wisdom' Is Worth More Than the Code Itself

At an on-site interview during OpenAI DevDay 2026, Itamar Friedman, founder and CEO of Qodo (formerly CodiumAI), shared an ambitious vision: delivering "the last human code review." His customers describe Qodo as "Codex's best partner" — on one side collecting the tacit knowledge of engineering teams to feed into Codex, and on the other side reviewing Codex's output as it writes code, with the goal of generating clean, well-structured PRs from the very start.

This conversation went beyond product promotion. It touched on a core question of the AI programming era: as models grow increasingly capable, what role do human engineers actually play in the software factory?

Three Leaps: From Prompt Engineering to "Swarm Engineering"

Itamar traced three phases in Qodo's technical evolution. Around 2023, the industry still treated "prompt engineering" as a specialized discipline — used to build simple Q&A capabilities, and the primary way models participated in coding competitions.

In 2024, Qodo published a paper called Alpha Codium, arguing that model usage shouldn't be limited to back-and-forth Q&A. Instead, the developer's complete workflow should be "downloaded" and treated as an integrated process — what they called "flow engineering."

Today, models can build their own workflows. But the truly valuable layer has become "swarm engineering": designing multiple agents with clearly defined goals, tools, guardrails, and strategies. Itamar cautioned that allowing agents to spawn sub-agents and customize their own tools is still very early-stage and can be extremely resource-intensive. He cited a warning from an OpenAI speaker: for a product built on trust, outputs must be data-grounded, and swarms must provide evidence for their work.

Alpha Codium is a research result published by Qodo in 2024. Its core idea is to replace single-prompt code generation with a "test-driven iterative process." Rather than generating complete code in one shot, the model first understands the problem specification, generates public and private test cases, then iteratively refines the code until all tests pass. On the coding benchmarks HumanEval and CodeContests, this approach significantly improved accuracy over zero-shot prompting. The paper elevated "process design" to the same level of importance as the model itself, and laid the theoretical foundation for Qodo's subsequent evolution toward an agent-based architecture.

The Divide Between "Intelligence" and "Wisdom"

The most illuminating part of the interview was Itamar's distinction between intelligence and wisdom. He explained it through a progression: raw data → information → knowledge → intelligence. The leap to "wisdom," he argued, depends critically on experience.

Intelligence is analogous to the brain itself, while experience can only be gained through a complete system — a complete body. What makes a senior developer unique is their ability to understand how software behaves, through experience.

This is precisely what Qodo is trying to "codify." If you want to build an end-to-end software factory where humans focus more on strategy and managing swarms, you must first capture and preserve that experience — that wisdom. Qodo calls this mechanism a wisdom base, and Itamar openly acknowledges that in some cases, this wisdom is more valuable than the code itself.

Looks Fine Locally, But Could Break Everything Globally

Itamar shared a real customer case to illustrate the value of a review agent. The company serves millions of small and medium-sized businesses, giving them highly flexible application-building capabilities — including near-direct database access. As a result, a large share of code changes touch the database.

The problem: a change might look completely normal in isolation, with no semantic errors, but when viewed in the context of the entire software system, it could trigger massive downstream outages. These cross-component downstream effects are extremely difficult for coding agents to detect — and equally hard for human reviewers.

Itamar offered a sharp analogy: if you pit him against Google on "understanding a single page," he'd win. But if the contest is "scanning an entire codebase," he'd lose every time. And that's exactly where human review is weakest. Qodo's solution is to have the review agent continuously run "sleep time compute" in the background, constantly updating a software map (software graph), while the coding agent performs real-time review on top of it.

"Sleep time compute" refers to a mechanism where the model or system continues background reasoning and index updates during idle periods when no real-time user requests are being processed. Unlike on-demand analysis triggered only when code is committed, sleep time compute allows the review agent to traverse the codebase and update software dependency graphs during off-peak hours. When a developer submits a PR, the agent can immediately draw on pre-warmed context for deep review, rather than scanning from scratch. This mechanism is especially critical for understanding hidden data-flow dependencies across services — the kind that can't be discovered through static analysis at the file level and require a continuously maintained global view.

When Agents Start Prompting Humans

On the question of "how to tell whether a review agent is actually improving outcomes," Itamar offered a refreshingly grounded metric. In the early days, code review tools simply piled findings onto the PR page — something he bluntly said "will look absurd when we look back in 2027," because it created enormous cognitive overhead.

The ideal state: the coding agent and the review agent first reach agreement between themselves. Only when they can't agree does the issue get escalated to a human developer. The roles are reversed — instead of developers prompting agents, agents are prompting humans. The simplest measure is how many times the developer needs to be prompted before a task is complete.

Host Danielle added a remark from an OpenAI internal API developer that resonated perfectly: "I'm not prompting Codex anymore — Codex is prompting me."

Disagreements, Mistakes, and the "Never Make the Same Error Twice" Mechanism

When two agents disagree, what should be escalated to humans? Itamar referenced a theoretical principle: two agents (human or AI) with the same information, both reasoning soundly, should ultimately reach the same conclusion. When a coding agent diverges from an adversarial review agent, the root cause is a difference in context. As long as everything is grounded, they should eventually converge.

The trickier scenario is when two agents agree — but they're both wrong, the code ships to production, and an incident occurs. Itamar's core position: never make the same mistake twice. Once an incident or bug occurs, it must be captured intelligently into the knowledge base and wisdom base. He sees this as a unique advantage of the AI era over the pre-AI era: tacit knowledge used to accumulate in people, and when they left, it walked out the door with them. Now, mistakes can be permanently codified into a developer's "memory," and pruned only when they're no longer relevant.

A large financial institution customer exemplified this well: hundreds of repositories, multiple microservices, and a wealth of knowledge about "what works at scale and what doesn't" concentrated in a handful of senior developers — some of whom had already left. Qodo's approach was to retrospectively scan GitHub, GitLab, Bitbucket, and years of developer discussions on Slack and Teams, codifying that tacit knowledge into a software map that captures what a change to one service means for another — especially hidden dependencies connected through data flow rather than explicit code.

The "tacit knowledge" referenced here is a classic concept in knowledge management, introduced by philosopher Michael Polanyi. It refers to experiential knowledge that is difficult to explicitly articulate, codify, or transfer — for example, a senior engineer's intuition that a particular database query will break down under high concurrency, even if they can't state the exact rule. Its counterpart, "explicit knowledge," can be documented. The longstanding pain point in software engineering is that vast amounts of architectural decision history and hard-won lessons exist only as tacit knowledge in people's minds — and disappear when those people leave. Qodo attempts to systematically convert this tacit knowledge into an explicit knowledge base — searchable and citable by agents — by retrospectively scanning commit histories, PR comments, and instant messaging records.

Redefining "Task": From PR to End-to-End Capability

Looking ahead, Itamar posed a question worth every developer's consideration: today's models are the dumbest they will ever be. As agents become capable of handling increasingly long-horizon tasks, we need to reimagine what a "task" actually is.

Today, we define a "task" as a pull request — largely because of tool and capability constraints. But who actually cares about that PR? What you really care about is end-to-end delivery of a new capability or feature — which typically spans 5 to 15 PRs across the same repository or even multiple repositories. Those PRs together constitute a single "task," yet there's no way to discuss them as a whole on a single GitHub PR page.

To address this, Qodo previewed an upcoming work package triage feature, designed to help understand how multiple PRs relate to each other in delivering a shared task — and to review them holistically.

"Work package" is a project management term referring to a group of related work units that must be completed together to deliver a specific outcome. In software engineering contexts, a feature often requires PRs across multiple repositories — spanning frontend, backend, database migrations, configuration changes, and more — before it's fully deployed. Current review mechanisms on platforms like GitHub treat individual PRs as the atomic unit, with no native support for reviewing these PRs as a whole. This means reviewers can't see, in a single interface, whether five PRs together actually deliver the intended functionality or introduce cross-repository consistency risks. Qodo's previewed work package triage feature aims to build a task-level view on top of the PR layer, enabling both agents and humans to perform end-to-end quality assessment of a complete feature delivery.

Practical Advice for Developers

For developers building review systems on OpenAI models, Itamar offered several directions worth trying right away:

• Pay attention to the new Decision API — he previously worked at a company that built embedding models and understands the potential of rapid decision-making firsthand, noting that some well-known decision models in the industry were built on technology his team originally developed.
• Break tasks down into workloads.
• Design the swarm needed for each workload — likely two to five agents you build yourself.
• Select the right model for each "player" on the board, balancing cost efficiency — because once this system genuinely helps you get things done, you'll use it heavily, and cost control becomes critical.

Itamar frames this methodology — designing swarms by workload and optimizing costs with the right models — as the "game board" for the foreseeable future. The interview closed with a half-joking reminder: even if you actually achieve "the last human code review," don't forget — you'll still need to invest in developer training.