Generating code faster does not necessarily deliver software faster. It can instead move the bottleneck into review, testing, debugging, and governance. That is the premise of Itamar Friedman, co-founder and CEO of Qodo, in his QCon AI New York 2025 presentation on reliable and controllable software-development automation. InfoQ published the 49-minute recording and transcript on July 8, 2026.
Friedman's proposed response is not simply to assign more work to one general coding agent. It is to build a quality-grounded system of specialist agents for planning, implementation, testing, review, context retrieval, and arbitration. The agents must operate within observable workflows, with explicit authority and access boundaries.
These notes separate Friedman's presentation from my synthesis. Numbers below are reported claims from the talk, not independently validated results. This matters because Friedman leads Qodo, several examples feature Qodo products, and the surveys and product telemetry described in the talk are not presented with enough methodology to establish causal effects.
What the Presentation Argues
Friedman describes three stages in AI-assisted development:
- Autocomplete accelerates local code writing.
- Agentic code generation completes larger implementation tasks.
- Quality workflows add automated testing, review, and verification.
He argues that the third stage still reaches a ceiling because every organization has changing architecture, standards, and delivery processes. His proposed next stage is an adaptive, quality-grounded multi-agent system that learns and applies what quality means in that organization.
The key change is the unit of optimization. Producing code is not the same as completing a reliable change. If generation increases pull-request volume while review and defect handling remain constrained, local productivity can rise as end-to-end delivery stalls.
Treat the Numbers as Signals, Not Proof
Friedman says he combined common findings from surveys by Qodo, Sonar, and Faros. The presentation does not map every slide statistic to a specific report, so the following are claims as he reports them rather than claims I could attribute more precisely from the InfoQ page:
- 82% of developers use AI development tools daily or weekly.
- 59% use at least three tools, and 20% use more than five.
- 28% say they do not trust AI-generated code.
- Developers spend 42% more time fixing bugs, 35% of projects are delayed, and teams see three times as many security incidents. Friedman mentions METR in this passage but does not identify which source supports each figure.
- Survey respondents using AI-assisted review report "2x better" code quality and 47% greater code-writing productivity. These are associations between self-reported tool use and outcomes, not measured causal effects.
- From Qodo's review of millions of pull requests, Friedman says 70% contain an issue and then says approximately one in five may contain a high- or critical-severity issue. The transcript's sentence around 70% appears to omit or misplace words, so these should be treated as two approximate Qodo product claims, not combined into one statistic.
In the Q&A, Friedman says Qodo contacted at least half of its more than 1,000 customers as well as non-customers, sought a varied sample, and stopped at 617 responses when the company judged the sample sufficiently diverse. That is not a reproducible sampling method. The talk does not provide respondent composition, question wording, response rate, confidence intervals, definitions for measures such as "code quality," or evidence that review and testing tools caused the reported gains.
The defensible lesson is therefore directional: adoption and output are rising while trust, review capacity, and quality remain concerns. The exact percentages should not be used as planning assumptions without reading the underlying reports and methods.
Tests Are Executable Specifications
Friedman recommends investing heavily in verification agents. He starts with unit tests because current coding tools handle them relatively well, then moves to integration and user-interface testing, which demand richer context and runtime access.
His concrete example begins with a coding agent making apparently simple UI changes to a chatbot application. A separate computer-use testing agent runs the changed application and discovers that an unrelated chat option was broken. The example illustrates why reviewing the requested diff is not enough: the relevant question is whether the system's behavior still satisfies its specification.
Friedman addresses the objection that the same model might make matching errors in both code and tests. His answer is that separate testing work allocates more inference and attention to edge cases and creates a feedback loop between implementation and verification. This can improve the result, but it does not make independently generated tests an independent oracle. Deterministic checks, human judgment, and tests derived from authoritative requirements remain necessary.
Code Review Is Both Gateway and Gatekeeper
The presentation gives code review two responsibilities:
- As a gatekeeper, it checks intent, defects, security, standards, and process requirements.
- As a gateway, it spreads knowledge and preserves shared ownership of the code.
Review automation that catches defects but removes human understanding solves only the first problem. This distinction is important as generated pull requests become too large or numerous for careful manual inspection.
Friedman recommends turning tacit conventions into explicit, checkable rules, including examples of acceptable and unacceptable code. A review agent can evaluate every rule deliberately, while a generative agent may inconsistently follow a long instruction file. The roles therefore need different prompts, tools, and evaluation criteria even if both use the same underlying model.
Context Retrieval Is an Agent Role
Friedman treats a context engine as more than retrieval-augmented generation (RAG), or vector search over the current repository. He describes it as an agentic subsystem with ingestion, query, and retrieval agents that may need to ingest and retrieve:
- Code and its version history.
- Pull-request discussions and earlier review decisions.
- Architecture documents and organizational standards.
- Logs, specifications, and repository-level rules.
- Relevant material from systems outside the codebase.
He reports that 88% of surveyed developers blamed context when code was untrusted or hallucinated; the transcript does not establish that this means 88% of all such outputs were caused by context. He also reports that improving context was the largest requested tool improvement, selected by 33% of respondents. Separately, Qodo telemetry attributed approximately 60% of tool use inside its review agent to fetching context, with 8% of that context-fetching activity involving non-code sources. These survey perceptions and product observations do not prove output causation, but they support a useful architectural point: context selection has its own tools, policies, failure modes, and evaluation needs. It deserves a defined component rather than an ever-growing prompt.
Multi-Agent Does Not Automatically Mean Better
The talk discusses Towards a Science of Scaling Agent Systems, a study by researchers from Google Research, Google DeepMind, and MIT. It compares a single-agent baseline with independent, centralized, decentralized, and hybrid multi-agent arrangements across 260 configurations, six agentic benchmarks, and three model families. Its result is not simply that multi-agent systems have no advantage: relative to the single-agent baseline, their effect ranged from a reported 80.8% improvement on decomposable financial reasoning to a 70.0% decline on sequential planning. Tool-heavy tasks incurred coordination overhead, while centralized verification limited error propagation better than independent aggregation. Architecture-task alignment, not agent count alone, determined the outcome.
His resulting design questions are practical rather than ideological:
- Can subtasks genuinely run independently and in parallel?
- Must the workflow operate across multiple interfaces such as an IDE, terminal, browser, and pull-request system?
- When outputs conflict, is there a defined arbiter?
- What latency and token costs does the topology introduce?
This is a stronger criterion than splitting a prompt among several named personas. A separate agent is justified when it has a distinct objective, context, tool set, permission boundary, execution schedule, or verification role. Otherwise, decomposition may add coordination cost without adding useful independence.
Make Agent Communication Human-Inspectable
Protocols such as MCP, A2A, or MCP-UI can connect agents, while queues, databases, and publish-subscribe systems can coordinate asynchronous work. Friedman presents these options as compatible and argues that, regardless of transport, people need an inspectable record of what each agent requested and changed.
His example has a Qodo review agent leave suggestions on a draft pull request and a Cursor workflow respond with commits. The interaction may use MCP, but its durable evidence remains in the repository workflow. A person can identify the reviewer, the implementer, the proposed correction, and the resulting change without searching an opaque internal trace store.
The recommendation is not that GitHub is the only control plane. It is that agent-to-agent work should surface in a human-facing system with attribution, history, and review semantics. Internal traces are still useful for debugging, but they should not be the only audit trail.
Arbitration Requires an Adequate Specification
Specialist agents will disagree. Two coding agents may edit the same file; a test agent may reject an implementation; or a planning agent and review agent may interpret intent differently. Friedman says the architecture must define who arbitrates these conflicts.
An arbiter cannot judge against an empty goal. In the demonstration, an agent checks whether a ticket contains enough information to evaluate the eventual implementation and asks for missing details, including the repository to change. This makes specification quality part of the control system rather than an optional prelude to coding.
More broadly, Friedman argues that AI can "shrink the V" of a conventional development lifecycle by applying review and test reasoning to the plan, not only to executable code after implementation. Earlier verification is useful only if the plan contains enough context to support a meaningful judgment.
The useful pattern is:
- Validate that the specification contains observable acceptance criteria and relevant system context.
- Preserve that specification as the reference for implementation, testing, and review.
- Assign an arbiter to resolve incompatible outputs against the reference.
- Escalate when the reference is ambiguous instead of letting one agent invent product intent.
Friedman calls the desired destination "viable coding": retaining the flow of vibe coding while adding rigor, correctness, ownership, and control.
Governance Is Part of the Architecture
The fuller architecture in the talk includes specification, implementation, testing, review, context, and arbitration agents around a shared "software DB" of code, rules, history, and other organizational knowledge. It also adds tools and secured runtime environments so agents can execute software, plus governance, observability, controllability, and continuous learning.
Friedman specifically argues for role-specific credentials. A testing agent may need access to an isolated staging environment, while a creative coding agent does not. Giving every agent the union of all permissions would erase one of the benefits of role separation. Runtime environments should also be secured against destructive actions, even when labeled as staging.
Continuous learning means retaining approved rules, specifications, architecture decisions, and review lessons so future agents can retrieve them. The talk does not describe an automatic policy-learning algorithm or show longitudinal production measurements. It presents the learning layer as a required direction and product architecture, not as a demonstrated guarantee that the system safely improves itself.
Synthesis: A Practical Adoption Sequence
The ordering and evaluation criteria below are my synthesis, not a sequence Friedman states verbatim. Friedman does, however, explicitly advise teams not to adopt the full architecture at once: find the current SDLC bottleneck and add quality agents incrementally.
- Measure the constrained stage. Track review delay, escaped defects, rework, test latency, and lead time rather than generated lines or pull requests.
- Create an authoritative change specification. Record intent, affected systems, acceptance criteria, and non-functional constraints before adding more autonomous actors.
- Add one independent verifier. Start where evidence is strongest in the local system: deterministic tests, static analysis, or a narrowly scoped review agent.
- Make every action attributable and reversible. Preserve suggestions, decisions, commits, tool calls, and approvals in an inspectable workflow.
- Separate permissions by role. Give each agent only the repositories, environments, data, and mutation rights its task requires.
- Introduce arbitration before parallel generation. More candidate implementations create little value if no trusted process can select among them or reject all of them.
- Evaluate the whole loop. Compare defect escape, human review effort, delivery lead time, cost, and rollback rate against a baseline.
The central lesson is that multi-agent architecture is not primarily about the number of agents. It is about creating independent checks, explicit decision rights, bounded capabilities, and evidence that humans can inspect. If those properties are absent, a multi-agent workflow can multiply output and ambiguity at the same time.
Canonical source: Itamar Friedman, "The Multi-Agent Approach: Building Reliable and Controllable Software Development Automation", recorded at QCon AI New York 2025 and published by InfoQ on July 8, 2026. The canonical page contains the video, transcript, and synchronized presentation imagery; no separate public slide deck was exposed during this review.