The Last Human Code Review: Building Trust in AI-Generated Code — Itamar Friedman, Qodo

Are you all set up with your AI factory? Everything is smooth as you're sitting here, your code is being deployed, errors are growing,right? If it's like that, raise your hand. No? Oh, okay. Two people. Great. Let us know, like, before and after this talk, what's the error and.

And do you feel like there is a bottleneck, a new bottleneck, that is not on writing code, rather somewhere else and they still see? Is that your biggest thing to tackle, if you are tackling thatright now? Okay, so you're in theright place.

And what about, like, code review, verifying that the code worked according to your intent, according to your architecture standards, best practices, etc.? Is this something that you're tackling day to day or week by week? Okay, so you're in theright place.

So I'm Itamar Friedman, the CEO and co-founder of Qodo. I don't share it too much, but Qodo stands for Quality of Development Optimization. Our mission is to help you all have a code governance, code review platform that understands your code base, your tribal knowledge, your best practices, and that does not come off the shelf from a model.

It requires a system that optimizes for you as we go, and that's why we decided to name our company this way. So I'm going to talk about the last human code review and what do we need to do in order to get there.

Okay? And can you switch instead of seeing myself, seeing the presentation here? Thank you. So I think, like, first of all, we need to agree on why do we have code review at all. So I think basically these are two buckets that we should agree on, and I think it's quite common.

One is we want to validate the code that is in high quality, safe, maintainable, theright architecture according to our best practices, etc. The second reason is actually alignment and learning,right? Like where senior developers, for example, have one last chance, a gateway, a gatekeeper, before

code is being pushed to production, to have that alignment and teaching,right? So these are the two reasons. And then that's what you need to think if you're trying to automate a code review. Can humans still do that? And if this is theright place, the code review process, the pull request process, is that theright place to still doing these two things?

If you have new tools, new processes that will help you unblock this bottleneck but let you still do these two buckets of tasks, then you're on theright path. So we're here to ask, yes or no, is human code review still optional end of 2026?

Is it becoming optional, or is it still mandatory? Okay? That's what we're here to answer. Do you think, like, every PR or the majority of PRs are going to be reviewed line by line or, you know, bucket by bucket in the chunks and the hunks by your developers?

Raise your hand. Or do you think, do you think by end of this year your developers are still going to review diff by diff? Okay. So try to think why is that happening. Now, I wanted to share with you that yesterday night we did a drone show, and I had the opportunity to talk to different people during that drone show, different engineering leaders.

And what I can tell you is that I saw two very different groups of schools of thought. Okay? They both agree that bugs are coming in different shapes. For some, this is fine and we're just going to fix that quickly after it hits production, and for some, not.

So actually, we do see two teams. Those that are thinking about the room is split into two, those that are thinking like, hey, we have to make sure that every piece of line is trusted and that humans must review that.

Or the other group, somewhat reckless or so, saying, let's, like, push those bugs into production and we quickly fix that. And that's how we actually do things because it's much faster. Velocity is more important than getting thingsright. And I think, like, you need to think, like, where do you sit?

Of course, I put it in two sides of the spectrum, but there's somewhere in between. And you need to think what's your philosophy because that will lead you to different milestones or different tools that you need to use in order to get that confidence that you can skip over a human review in the pull request and the code review.

So let's start talking about what is the process? How do we need to start thinking about it? So I claim that models are not a barrier anymore. Like, it's not a matter of, you know, a model doing a good job or not, having theright reasoning or not.

Basically, the models are improving, but I'm telling you, I just came from one of the leading labs where we were inspecting how benchmarks for code review did not change a lot throughout the latest model. The key here is actually context.

Okay? Like, the models, if you give them theright context, and what is thatright context we're going to talk about, they could already reason pretty well over what are the issues that we need to surface for a certain change in the code.

Otherwise, if you don't have the context, even the best model out there, they will give you different types of bugs and issues. Some of them are really good, but in many cases, they will simply tell you, hey, did you consider error handling or not?

By the way, error handling could be like a really good thing to handle. Depends. In some cases, it's critical. In some cases, it's not. And again, the context is what matters. Right now, our context is like spread all across.

Like, we have agents MDs, Claude MDs, skills MDs, and the thing is that each one of them has like different standards. Different organizations and sub-organizations are dealing with it differently. Even within a certain team, you might be using that differently.

And you're actually maybe using, like, the same one team is using the same agent to do code review and, sorry, coding and code review. The other might be using something else. And all of that does not bring you the trust and consistency that you're looking towards.

By the way, like, you also might have, like, coding agents that are running in your IDE, but you're probably building the AI factory that's running those agents, like, in workflows to automate some of the coding. I see teams that are already having more lines of code being shipped that are not generated from the CLI or the IDE.

So how do you control all that? Like, that's missing. Like,right now, like, in our tools, in our infrastructure. And let alone if you add those MCPs and RAG, like, style context. I don't know if you have, like, great visibility.

There are ways to tackle that. There's great talks out there. Check how you could have, like, MCP versioning and have datasets for every, like, a benchmark for every MCP change. But that's hard to manage. We're missing, like, a governance layer for us to move to the next level.

Okay? Like, where we can actually trust the code without human reviewing it. So where is that context? Where is that context? Basically, I would say experience, tribal knowledge, wisdom of your developers is a lot in their heads. There are in some documents, there are documents, infrastructure documents, but a lot, by the way, a lot of them are Slacks or Teams or so.

The data is there, but a lot of the information is in your developer heads. And we need, like, to codify them. Now,

I think, like, basically another thing that I'm saying, like, when I'm saying that we need to codify human knowledge, what we're actually saying is that we're trying to build an interface for agents, an interface for humans to collaborate with each other on that knowledge.

And that's a very important

point. When you want to extract that information, the tribal knowledge from your, like, senior developers, etc., and codify that, do you codify that only in agent language, which is very maybe verbose and structured, or you want to codify that in a wiki style, get started and all that, what developers love doing?

And the answer is that you probably need to build your context lake, your context engine. As I mentioned, that's the real, like, gold mine here. To get the code review, like, automated, you have to have it fitting for both.

So what you're seeing here, for example, is that Qodo, as an example, but you can use other tools, helps you collect all the rules and standards that your team owns, that your team is using day to day. And then it will provide that information during the review for humans.

Hey, notice that Qodo used four rules, sorry, used many rules and four are violated. And that includes a link to all the rules that were being used. That's for humans in order to trust. Okay? In order to trust the results that are coming from your code review tool, etc., you have to build that interface for humans.

You have to accumulate that knowledge and have an interface for humans. But you also want to have an interface that is dedicated for agents. What you're seeing here, for example, is a comment, for example, by Qodo that is speaking to another agent.

Hey, dear agent, Qodo just reviewed this PR and has found five different issues. Qodo already spent, like, some background tasks and used Claude Code, for example, Harness, in order to do fixes. And there is a closed PR. Like, you can see here on the topright, there are some closed PRs with all the fixes.

And now, when an agent is coming to review this PR once again, then it has, like, a cherry-picking moment with everything that all the code that is actually is passing your rules, your standard, and everything, like, more architectural decisions that we're going to talk about.

So what I said so far is that, just to, like, recap so far, if you want to trust and you want to get to a point where you're trusting the code is being shipped, you need to have theright context that is being gathered and being used during the code review process.

Then you will see that this code review process has links and information for humans and has links and information for agents. Okay? And when that is in place, you will see that developers are writing less and less comments in the pull request.

And then after 100 of these pull requests, there is no more human review, you know that you're ready for automation. Okay? Now, back to the context. So far, I talked about relatively simple context. I talked about rules and standards and skills.

But actually, the human knowledge, the tribal knowledge in your organization sits in understanding the system architecture. What are the P0s, the bugs that actually made an outage for you, unfortunately, in the last, like, three months or so? When a microservice one changed its contract and broke a microservice two,right?

That does not exist in most code review. And, like, if you try to build yourself, it's really hard to build, but it is available in some of those code review solutions that are dedicated for that. For example, what you're seeing here is the graph being built for a certain microservice and all the repos and their connection.

And in each node and edge, there is, what is the, if it's an edge, what is the contract between two pieces of your software? But also links to history of discussions between developers that they had when they fixed an issue because of root cause analysis, and now you need to codify that.

Okay? And when you get to that level of a context engine, now you're ready to start approving and blocking PRs automatically. And you want to do that, not just by letting AI some, like, choose by yourself, rather giving some semantic rules that, for example, when do you guys approve or block a PR?

And that knowledge also needs to be accumulated as part of your context. What I'm actually saying is that software development, at least code governance, is going to change from reviewing your pull request to actually reviewing your entire software development from a graph obstruction, where you're seeing your PRs as bubbles with all the issues that might happen.

Even with three different PRs that are on the fly, which contract they might bridge, they might ruin. Okay? And that's how the software development future is going to look like. What you need to do in order to get there is to codify your standards.

It needs to be built in a way that humans can trust and audit and control. You need to build real-time self-learning context, learning from peer history, learning from accepted and unaccepted, learning from discussions between developers, learning from those cases that broke your production.

And that context needs to be not just, like, thrown into files. It needs to sit and locate it in a place that agents understand where that context is fitting. And then you need the governance infrastructure that gives you that visibility of what's happening.

Rather the graph I presented, but there is more to that. Okay? I'm going to show you very soon another visualization that helps you understand the overall status of your PRs and software. If you are already shipping AI-generated code faster than your humans can review, I'm actually saying that you are in the problem.

You're not, like, ahead of the problem. If you put the infrastructure, if you gather the context, if you start accumulating how code review can be automated for you, then that's where you're going to get the 10X velocity that you're being promising your CEO or yourself or your developers.

Because otherwise, it's a bottleneck. You need to own your rules and standards and codify them and get analytics and statistics about each one of them. How many times they're being caught, which rules and standards and skills are actually being used during the review process, and is it useful or not, or does it need to get an update?

You need to have full visualization of your software graph. What is the connection? What are the contracts? What is working? What is not working? What are two PRs that are going to crash very soon because they're touching the same agent and they don't know?

And you need to start learning how to auto-approve and auto-block. That won't happen in, like, immediately. That needs to gradually be automated for you step by step by adding more rules for blocking and more rules for approving over time.

So trustworthy automated review, your rules, your standards in your software graph, placed in theright edge and theright node of your software. Learning from the tribal knowledge of discussions of history of your software and codifying that. There's so much tribal knowledge of what to do and not to do, and that needs to be codified as well, both for the agents and for the humans.

And basically, you need to accumulate that experience and codify that. And sorry for the buzz or whatever you want to call it. That's moving from artificial intelligence to artificial wisdom. Becauseright now, you know better than I that your developer holds the judgment of what's bad and what's good.

It's not your software, not your AI tools. If you want to get to a point where judgment is moving to your AI tools, that's AI wisdom where that experience needs to be codified in theright way, theright place for agents and humans.

And that's why we are here, Qodo, to help you. And our vision and mission is not far away from now. We want to reach in 2027 to a place where you have zero outages, zero bugs in production, at least the critical and the high ones.

That's why we're here. Thank you so much for having me.