AI Engineer World's Fair 2026
The Last Human Code Review: Building Trust in AI-Generated Code
Read the talk
The Last Human Code Review: Building Trust in AI-Generated Code
Automating review requires more than finding bugs: it requires team standards, architectural contracts, and accumulated experience that both people and agents can inspect.
From a talk by Itamar Friedman
Before you start: Familiarity with pull requests, coding agents, and service API contracts will help you follow the review and governance examples.
Who verifies the code your agents write?
If AI can write code faster than your team can review it, who verifies that the changes match your intent, architecture, and engineering standards? Code generation can accelerate while the rest of the software development lifecycle remains constrained. The queue moves downstream to the people responsible for deciding whether the code should ship.
That verification requires knowledge specific to an organization. A model may recognize common programming mistakes without knowing why your team chose a particular architecture or which local practices protect production. Itamar Friedman introduces Qodo—short for quality of development optimization—as a system for bringing codebase knowledge, tribal knowledge, and best practices into review. The premise is that this knowledge does not arrive with an off-the-shelf model: the surrounding system must accumulate and improve it over time.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Preserve validation and learning
Before removing human review, separate the two jobs it performs.
| Review function | What it preserves |
|---|---|
| Validation | Quality, safety, maintainability, architecture, and best practices |
| Alignment and learning | Shared understanding and guidance from experienced developers |
The pull request is often a senior developer’s last opportunity to explain a design decision before code reaches production. Replacing the quality gate without replacing that exchange would remove part of the team’s learning process.
The question is whether these functions must remain inside human pull-request review. New tools or processes can move them elsewhere, provided both survive. Friedman frames the end of 2026 as a test of that transition: will human review still be mandatory, and will developers still inspect most PRs diff by diff? These are questions about the future workflow, not evidence that human review has already become unnecessary.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Decide what confidence must mean
Conversations with engineering leaders during the previous evening’s drone show revealed two contrasting attitudes toward production bugs. This was an anecdotal split, but it exposes a decision every team must make:
- Verify before release: Require confidence in each change, with a human responsible for reviewing it before production.
- Repair after release: Accept that bugs will ship, prioritize velocity, and fix problems quickly when they appear.
Most organizations sit somewhere between these endpoints. Their position determines the confidence required to skip human review, the milestones toward automation, and the tools needed to reach them. A team cannot choose a sensible review policy without first deciding which risks it is willing to accept.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Context makes a finding relevant
Useful review depends on knowing what matters in this system. Friedman argues that model capability is no longer the principal barrier. He describes a visit to an unnamed leading lab where code-review benchmarks had changed little across recent models. No model versions, benchmark details, or scores accompany that observation; it supports his emphasis on context, not a general measured claim that model improvements have stopped.
With the right context, a model can reason about which issues a particular change introduces. Without it, even a strong model may produce generic advice about error handling. Such advice can be correct and still fail to help a reviewer decide what to do: missing error handling may be critical in one location and relatively unimportant in another. The missing capability is not merely recognizing a programming concern. It is judging that concern against the purpose and consequences of the change.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Bring scattered knowledge under governance
Today, much of that context is scattered across AGENTS.md, CLAUDE.md, and SKILL.md. Organizations, subteams, and individual developers organize those files differently. Some use the same agent for coding and review; others use separate tools. Instructions alone do not ensure consistent behavior when the tools consuming them differ.
The execution environment is spreading out too. Alongside IDE and CLI agents, teams run coding agents in automated workflows. Friedman reports seeing teams generate more of their shipped code outside IDEs and CLIs than inside them. A governance system therefore has to cover the workflows producing code, not just the developer’s interactive session.
Model Context Protocol, or MCP, integrations and retrieval-augmented generation add further sources of context. They also add questions about visibility: what information did an agent receive, and what changed between reviews? Versioning MCP integrations and maintaining datasets or benchmarks for each change can help, but Friedman describes this as difficult to manage. The missing layer is governance over the context and tools on which review depends.
Some of the most valuable information has never reached an instruction file. It lives in developers’ experience, infrastructure documents, Slack threads, and Teams conversations. Codifying it means recovering the reasons behind a standard or architectural choice, including the knowledge that experienced engineers apply without having to look it up.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Give humans an inspectable basis for review
Once knowledge is captured, its representation becomes an interface design problem. Agents benefit from structured, explicit instructions. Developers need material they can read, understand, and maintain, such as a wiki or onboarding guide. A context engine must serve both audiences so they can collaborate on the same body of knowledge. An agent-only instruction store leaves people unable to inspect the basis of decisions; human-readable documentation alone may not deliver the relevant knowledge to an agent at review time.
The Qodo rule system provides the human-facing example in the talk. It collects the team’s rules and standards and exposes their use during review. In the Qodo example, many rules are applied and four are reported as violated. The review links to all the rules used, allowing a person to inspect the standards behind the result. That traceability is the mechanism for trust: reviewers can examine the basis of a finding instead of accepting an unexplained judgment. Qodo is the demonstrated tool, but the requirement applies to other review systems as well.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Turn review findings into an agent handoff
The agent-facing interface carries the process beyond an explanation. In the demonstrated handoff, an agent-directed Qodo comment reports five issues in the PR. Friedman describes the following sequence:
- Qodo reviews the original PR and identifies issues.
- Background tasks use a Claude Code harness to prepare fixes.
- A separate, closed PR holds those fixes.
- An agent returning to the original PR can cherry-pick the prepared changes, which Friedman describes as satisfying the relevant rules and standards.
The closed fix PR is a source of changes for the returning agent; it is not evidence that those changes have been merged into the original PR or deployed.
The handoff connects the same review context to two consumers: people need understandable findings and their supporting rules, while agents need information and links that let them continue the work. Gathering context is only part of the system. Making it available at the point of review and repair is what allows the workflow to progress.
As this process improves, developers should have fewer additional comments to make. Friedman proposes roughly 100 PRs without further human review contributions as a readiness heuristic for automation, not a measured safety guarantee. The useful signal is whether humans still supply judgment that the system lacks. A declining comment count can motivate examining readiness, but the proposed threshold does not establish that the review system catches every consequential defect.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Remember contracts and the incidents that exposed them
Rules, standards, and skills capture only part of organizational knowledge. The next layer is architecture: how the system fits together and how changes propagate through it. Consider the recent P0 outage an experienced developer remembers—a change to one microservice’s contract broke another microservice. That incident may matter more to the next review than a general coding guideline. Friedman says this architectural knowledge is difficult to build into a review system and is available in some specialized review tools.
The graph shown in the talk represents a microservice, its related repositories, and their connections. An edge records the contract between software components. Relevant graph elements also link to developer discussions and the root-cause analysis from earlier failures. The graph therefore records more than dependency: it preserves evidence about why a relationship needs protection.
For a concrete representation of that mechanism, suppose an order service returns an order_id that a fulfillment service consumes. A compact JSON record could keep the contract and the reason for preserving it together:
json
{
"nodes": [
{ "id": "orders", "repository": "orders-service" },
{ "id": "fulfillment", "repository": "fulfillment-service" }
],
"edges": [
{
"id": "order-response",
"provider": "orders",
"consumer": "fulfillment",
"contract": {
"requiredFields": { "order_id": "string" }
},
"history": [
{
"incident": "INC-42",
"discussion": "RCA-42",
"lesson": "Renaming order_id broke fulfillment."
}
]
}
]
}
These example service names and records illustrate the representation. The important placement is the incident lesson on the affected relationship: a reviewer examining an order-response change can retrieve both the consumer’s dependency and the experience that makes it consequential.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Apply explicit policies across concurrent changes
With architectural context in place, automated approval and blocking become policy questions. The system needs to learn when the team approves a change and when it refuses one. Friedman calls for semantic rules that express those decisions, rather than allowing an AI reviewer to choose without explicit criteria. In the order-service example, a proposed rule could block removal of order_id while fulfillment still requires it. This is a policy applied to a dependency, not simply a warning that a line changed.
The proposed review surface then expands from an isolated PR to a graph of work in progress. Multiple PRs can appear together with the contracts they may breach. A change that looks acceptable on its own may interact badly with another pending change. The purpose of the graph is to make those relationships visible while the work is still in flight; Friedman presents this as the direction of software governance, rather than demonstrating a completed deployment of every part of it.
That graph must remain open to human audit and control while its context evolves. PR history, accepted and rejected outcomes, developer discussions, and production failures all supply new knowledge. Merely accumulating more files is insufficient: the context needs a meaningful location so an agent can determine where it applies. Governance infrastructure then exposes the overall state of the PRs and software, including the context behind decisions.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Measure the rules and automate gradually
If AI-generated code already arrives faster than humans can review it, the bottleneck is present, not hypothetical. More generation does not remove the need to decide what can safely ship. Friedman invokes promised 10× velocity as a motivation for governance infrastructure, not as a measured result. His operational prescription begins with owning the rules and standards and collecting evidence about how they work.
The feedback loop has three parts:
- Measure rule use. Track which rules, standards, and skills participate in review, how often they produce findings, and whether they remain useful or need updating.
- Expose contract conflicts. Show the software graph, its connections, and the contracts affected by pending work. Look for PRs that touch the same edge incompatibly.
- Expand automated gates incrementally. Add rules for blocking and approval over time instead of immediately delegating every decision.
This makes automation a gradual change in the scope of decisions the system can handle. Rule analytics and graph visibility provide the feedback needed to decide what to automate next.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Move experienced judgment into the system
Trustworthy automated review places team rules and standards at the relevant nodes and edges of the software graph. It also preserves the less formal knowledge accumulated in discussions and software history: what to do, what to avoid, and why. Both people and agents need access to that experience.
Friedman calls this move from intelligence to artificial wisdom. Experienced developers currently hold much of the judgment about which changes are good or bad. Transferring some of that judgment to tools requires codifying experience in the right form and attaching it to the right part of the system. The final slide brings together team standards, repository relationships and architectural history, tribal knowledge, and that accumulated judgment.
Qodo’s stated ambition for 2027 is zero outages and zero production bugs, qualified to at least critical and high-severity bugs. It is a future target, not a reported achievement. The substantive shift is where responsibility for review lives: developers must be able to maintain and inspect the knowledge and policies that guide automated decisions, even as they spend less time reviewing individual diffs.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Resources
From the talk
Explains how Qodo discovers, enforces, measures, and maintains organizational engineering rules.
Further reading
Setup and usage instructions for fetching repository rules and resolving Qodo review findings inside coding agents.
Documents an injected-issue PR benchmark and the precision, recall, and F1 metrics used to evaluate review tools.
Friedman develops his argument that software governance requires accumulated context, memory, and organizational standards.
Friedman argues for treating oversight of coding agents as shared engineering infrastructure.
Updates since the talk
An August 2026 explanation of contextual evidence retrieval and cross-repository relationship mapping.
Read the complete timestamped transcript
- 0:00
[upbeat music] Are you all set up with your AI factory? Everything is smooth?
- 0:18
As you're sitting here, your code is being deployed, ARR growing, right? Is- if it's like that, raise your hand. No? Oh, okay. Two people, great. Um, let us know, like, before and after this talk what the ARR and, and
- 0:33
do you feel like there is a bottleneck, a new bottleneck that is not on writing code, rather somewhere else, else in the SDLC? Is that your biggest thing to tackle if, if you are tackling that right now?
- 0:47
Okay, so you're in the right place. And what about, like, code review, verifying that the code work according to your intent, according to your architecture, standards, best practices, et cetera?
- 0:59
Is this something that you're tackling day to day or week by week? Okay, so you're, you're in the right place. So I'm Itamar Friedman, the CEO and co-founder of Qodo.
- 1:09
Um, I don't share it too much, but Qodo stands for quality of development optimization. Our mission and, and, uh, is to help you all have a code governance, code review platform that understand your code base, your tribal knowledge, your best practices, and that does not come off the shelf from a model.
- 1:32
It requires a system that optimize for you as we go, and that's, uh, why we decided to name our company, uh, this way. Uh, so, uh, I'm gonna talk about the last human code review and what do we need to do in order to get there.
- 1:48
Okay? And, um, c- can you switch, instead of seeing myself, seeing the presentation here? [laughs] Thank you. Um, so I, I think like first of all, we need to agree
- 1:59
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, I think it's quite common.
- 2:08
One is we wanna validate the code that is in high quality, safe, maintainable, the right architecture, according to our best practice, et cetera. The second re- reason is actually alignment and learning, right?
- 2:21
Like where senior developers, for example, have o- one last chance, a gateway, a gatekeeper before, uh, it's being, uh, uh, code is being pushed to production to have that alignment and teaching, right?
- 2:34
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 human still do that? And this, if this is the right place, the, the code review process, the pull request process is that the right place to still doing these two things?
- 2:51
If you have, uh, 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 the right path.
- 3:04
Uh, so we're here to ask yes, no. Is human code review still optional end of twenty twenty-six? Uh, is it becoming optional or is it still mandatory? Okay? That's, that we're here to answer.
- 3:19
Do you think like every PR or the majority of PRs are gonna be reviewed line by line or, you know, bucket by bucket in the, in the chunks, in the hunks by your developers?
- 3:30
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?
- 3:38
Okay. So try to think why, why is that happening. Now I, I, I wanted to share with you that yesterday night we did a drone show and I had to, uh, opportunity to talk to different people during that drone show, different, uh, engineering leaders, and what I can tell you is that I saw two very different groups
- 4:00
of school of thoughts. Okay? They both agree that bugs [laughs] are coming in different shapes. For some this is fine, [laughs] and we're just going to fix that quickly after it hits the production, and for some not.
- 4:15
So, so actually we do see two teams. Those that are thinking about the room is split into two. The other are thinking like, "Hey, we have to let, make sure that every piece of line is, is trusted, uh, and, and a human must review that."
- 4:31
Or the other group, somewhat [laughs] reckless or so, saying, "Let's, 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.
- 4:47
Velocity is more important than getting, getting things, uh, right." And I think like you need to think like where do you sit? Of course I put it in two, two sides of the spectrum, but there's some, somewhere in, in between and you, you need to think what, what's your philosophy because that will lead you to different milestones
- 5:06
or different tools that you need to use in order to get that, uh, uh, confidence that you can skip over a, a human review in the pull request, in the code review.
- 5:17
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, not a barrier anymore. Like it's not a matter of, of the, you know, a model doing a good re- good, good job or not, having the right reasoning or not.
- 5:35
Basically the models are improving, but I'm telling you I just came from one of the leading labs [laughs] where we are inspecting how benchmarks for code review did not change a lot throughout the latest model.
- 5:50
The, the key here is actually context. Okay? Like the models, if you give them the right context, and what is that right context we're gonna talk about, they could already reason pretty well over what- Is the issues that we-- What are the issues that we need to surface for a certain change in the code?
- 6:09
Otherwise, if you don't have the context, even the best model out there, they will give you different types of, of, uh, bugs and issues. Some of them are really good, but in many cases, they will simply tell you, "Hey, did you consider error handling?"
- 6:22
Uh, uh, like, 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 are not.
- 6:31
And again, the context is what, what matters. Right now, our context is like spread all across. Like, we have agents MDs, Claude MDs, skills MDs, and, and the thing is that each, each one of them has like different standards, uh, different org-organization and sub-organization are dealing with diff-differently.
- 6:52
Even within a certain team, you might be using that, that differently. And you're actually maybe using like the same, uh... One, one team is using, uh, the same agent to do code review and-- Sorry.
- 7:05
Co-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, uh, towards. Um, 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 running those agents like in workflows
- 7:26
to automate some of the coding. I see teams that are already, uh, having more lines of code being, uh, shipped that are not generated from the CLI or, or the IDE.
- 7:37
So how do you control all that? Like that's, that's missing, uh, like in-- right now, like in our, in our, uh, tools, in our infrastructure. A-and let alone if you add those MCPs and, and, and RAG like, uh, style, uh, context, I, I don't know if you have like great visibility.
- 7:57
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 M-- Uh, like a benchmark for every MCP change, but that's hard to manage.
- 8:09
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, where is that context?
- 8:21
Where is that context? Basically, I would say experience, tribal knowledge,
- 8:28
wisdom of your developers is a lot in their heads. They are in some documents. There are documents, infrastructure documents, um, but a lot-- By the way, a lot of them is our Slacks or, or Teams or, or so, um, the, the data is there, but a lot of the information are, are in your developer heads, and we
- 8:47
need like to, to codify them. Now, um,
- 8:53
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 and interface for humans to collaborate each other on that, on that knowledge.
- 9:11
And that's a very important conte-- Uh, um, a very important point. When you want to extract that information, the tribal knowledge from your s-- Uh, like, uh, senior developers, et cetera, and codify that, do you codify that only in agent's language, uh, which is very maybe verbose and structured, or you wanna codify that in a wiki style,
- 9:34
uh, get started and all that, what developers love, love doing? And the answer is that you probably need to build your context lake, your context engine. As I mentioned, that's the s-- The, the, the real like goldmine here to, to get the code review, uh, like auto-automated.
- 9:51
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, help you collect all the rules and standards that your team own, that your team is using day to day, and then it will provide that information during the review for humans.
- 10:16
Hey, notice that Qodo used four rules... Uh, sorry. Uh, used, uh, uh, many rules and four are violated, and that includes a link to all the rules that are, were being used.
- 10:29
That's for human in order to trust, okay? In order to trust the results that are coming from your code review tool, et cetera, you have to build that interface for, for human.
- 10:40
You have to accumulate that knowledge and have an interface for human. But you also want to have an interface that is dedicated for agents. What you're seeing here, uh, for example, is a com-comment, for example, by Qodo, that is speaking to another agent.
- 10:56
"Hey, dear agent, Qodo just reviewed this, uh, PR and has found five different issues." Qodo already spent, uh, like, uh, some back-background task and use Claude Code, for example, Harness, in order to do fixes, and there is a closed PR, like you can see here on the top right, there is some closed PR with all the fixes.
- 11:20
And now, when an agent is coming to review this PR once again, then it has like a cherry-picking moment, uh, with everything that all the code that is actually is passing your rules, your standard, uh, and everything like we're, like more a-architectural decision that we're gonna talk about.
- 11:39
So what, what I said so far is that
- 11:43
just to, to ca-- Uh, 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 the right context that is being gathered and being used during the code review process.
- 11:59
Then you will see that this code review process have links and information for human and have links and information for, for agents, okay? And when that is in place-
- 12:11
You will see that developers are writing less and less comments in the pull request, and then after one hundred of these pull requests, there's human-- no hu- more human review, you know that you're ready for, for automation.
- 12:24
Okay? Now, back to, back to the context. So far, I talked about relatively simple context. I talked about, uh, rules and standards and skills, but actual, the human knowledge that the tribal knowledge in your organization sits in understanding the system architecture.
- 12:43
What are the P-zeros, the, the bugs that actually made an outage, outage for, for you, unfortunately, in the last like three months or so? When a microservice, uh, one changed its contract and broke a microservice two, right?
- 12:57
That is-- does not exist in most code review and, and like if you try to build yourself, it's really hard to build, but it is available in some of the, those like code review, uh, solutions that is dedicated for that.
- 13:09
For example, what you're seeing here is the graph being built for a certain microservice and all the repos and, and their connection. And in each node and edge, there is-- what is the con-- if it's an edge, what is the contract between two, uh, piece of your software?
- 13:26
But also links to history of discussions between developers that they had when they fixed an issue because a root cause analysis, and now you need to codify that, okay?
- 13:38
And when you get to, 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, that, for example, when you-- when do you guys
- 14:03
approve or, or, or block a PR? And that knowledge also needs to be accumulated as part of your, 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,
- 14:28
where you're seeing your PRs as bubbles with all the issues that might, uh, happen, even with three different PRs are in on the fly, when they-- which, which contract they might bridge, they, they might ruin,
- 14:43
okay? And that's how the software development, uh, uh, future is gonna 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.
- 15:01
You need to build real-time, self-learning context, learning from peer history, learning from accepted and unaccept, learning from discussions between, between developers, learning between, uh, learning like from those cases that broke your production.
- 15:18
And that context needs to be not just like thrown into files. It needs to f- to, to, to sit and located in a place that agent understand where is that context fitting.
- 15:30
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 gonna show you very soon another vi- uh, visualization that helps you understand the overall status of your PRs and software.
- 15:47
If you are already shipping AI-generated code faster than your human can review, I'm actually saying that you are in the problem. You're not like ahead of the problem. You, you-- 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 gonna get the
- 16:08
ten x velocity that you're being promising your CEO or yourself or, 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.
- 16:23
How many times they're being caught? Which rules and standards and skill is actually being used during the review process? And is it useful or not, or does it need to get an update?
- 16:33
You need to have visi- 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 are gonna crash very soon because they're touching the same agent and they don't, and they don't know?
- 16:48
And you need to start learning how to auto-approve and auto-block. That won't happen in like immediately. That needs to gradually being automated for you step by step by adding more rules for blocking and more rules for, for, for approving over time.
- 17:11
So trustworthy automated review, your rules, your standards in your software graph placed in the right edge and the right node of your software. Learning from the tribal knowledge of discussions, of history of your software and codifying that.
- 17:30
There's so much tribal knowledge 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.
- 17:44
And sorry for the buzz or whatever you wanna call it. That's moving from artificial intelligence to artificial wisdom. Because right now, you know better than I that your developer holds the judgment of what's bad and what's good.
- 17:59
It's not your, your software, not your AI tools. If you wanna get to a point where judgment is moving to your AI tools, that's AI wisdom, where that experience needs to be codified in the right way, the right place for agents and humans.
- 18:16
And that's why we are here, Qodo, to help you, and our
- 18:21
vision and mission is not far away from now. We wanna reach in twenty twenty-seven to a place where you have zero outages, zero bugs in production, at least the critical and the high ones.
- 18:33
That's why we're here. Thank you so much for having me. [audience clapping] [upbeat music]