WEBVTT

NOTE Sentence-level transcript of https://www.youtube.com/watch?v=_mi3alkqy4s

NOTE One cue per sentence. Cue ids are the line anchors on /transcripts/_mi3alkqy4s.html. A cue ends where the next begins, or 2 s after its last word.

s1
00:00:01.309 --> 00:00:03.309
[music]

s2
00:00:12.960 --> 00:00:13.920
Hello everybody.

s3
00:00:13.920 --> 00:00:20.400
Thank you for following on a session about the death of the code review with a session about the death of the code review.

s4
00:00:20.400 --> 00:00:27.359
Uh who knows howululing decisions get made, but uh Swix decided it would be funny for those two to be backtoback.

s5
00:00:27.359 --> 00:00:28.960
Uh, hi.

s6
00:00:28.960 --> 00:00:29.920
Uh, I'm Lori.

s7
00:00:29.920 --> 00:00:32.239
I'm head of developer relations at Arise AI.

s8
00:00:32.239 --> 00:00:39.280
Uh, some of you may remember me from when I used to co-found npm, Inc. These days, I think about AI and how to test it.

s9
00:00:39.280 --> 00:00:42.879
Uh, I'm here to talk about a problem that everyone is seeing right now.

s10
00:00:42.879 --> 00:00:49.039
The rise of AI agents has dramatically increased how fast developers can produce code.

s11
00:00:49.039 --> 00:00:52.320
Uh, but the speed at which humans can review code.

s12
00:00:52.320 --> 00:00:55.360
Uh, yeah, I am having a talk right now.

s13
00:00:55.360 --> 00:00:56.399
Thank you, notion.

s14
00:00:56.399 --> 00:00:58.160
very good reminder.

s15
00:00:58.160 --> 00:01:04.080
Uh the team the speed at which humans can review code has stayed exactly the same.

s16
00:01:04.080 --> 00:01:04.845
Um

s17
00:01:04.845 --> 00:01:05.119
[snorts]

s18
00:01:05.119 --> 00:01:08.240
and that is creating a new bottleneck that everybody is feeling.

s19
00:01:08.240 --> 00:01:10.799
Engineering teams across the industry are feeling it.

s20
00:01:10.799 --> 00:01:12.640
Uh so what can we do about it?

s21
00:01:12.640 --> 00:01:16.479
Some options are uh we could skip human review entirely.

s22
00:01:16.479 --> 00:01:18.000
Uh some folks are trying that.

s23
00:01:18.000 --> 00:01:20.000
Can we automate reviews reliably?

s24
00:01:20.000 --> 00:01:21.840
Some folks are trying that too.

s25
00:01:21.840 --> 00:01:31.680
Uh what we're doing going to do today, what I'm going to do for you is I'm going to look at what the industry is really doing right now uh and try to figure out what you can do

s26
00:01:31.680 --> 00:01:34.240
uh today when you leave the room.

s27
00:01:34.240 --> 00:01:36.000
So let's start with two numbers.

s28
00:01:36.000 --> 00:01:46.560
Uh recently three economists tracked more than 100,000 GitHub developers uh matched them against telemetry that showed exactly when each one started using AI.

s29
00:01:46.560 --> 00:01:56.159
Uh the developers who turned on autonomous agents wrote 741% more code but only 30% more software shipped.

s30
00:01:56.159 --> 00:01:58.880
Uh that is the scale of the problem right there.

s31
00:01:58.880 --> 00:02:01.200
They were writing code nearly eight times faster.

s32
00:02:01.200 --> 00:02:04.240
Uh but their actual ship software only rose by a third.

s33
00:02:04.240 --> 00:02:08.560
Uh and the authors of the study are blunt that review was the bottleneck.

s34
00:02:08.560 --> 00:02:12.879
Um the problem is that the route to production still runs through humans.

s35
00:02:12.879 --> 00:02:19.280
uh and the human steps uh in particular code review uh choke everything downstream.

s36
00:02:19.280 --> 00:02:21.920
Um producing code is suddenly a whole lot cheaper.

s37
00:02:21.920 --> 00:02:29.040
Knowing whether to trust it is still very expensive, especially if you have uh sensitive code with a blast radius.

s38
00:02:29.040 --> 00:02:37.599
Um how can we bring that second number down and thus bring this the amount of software that we ship back into line with the amount that we can code?

s39
00:02:37.599 --> 00:02:40.000
Uh let's zoom out first.

s40
00:02:40.000 --> 00:02:41.680
Let's be clear that the problem is real.

s41
00:02:41.680 --> 00:02:43.680
generation is no longer the bottleneck.

s42
00:02:43.680 --> 00:02:51.760
Uh Stripe in Anthropics launch materials for Fable this year reported migrating a 50 million line Ruby codebase in a single day.

s43
00:02:51.760 --> 00:02:56.400
Uh which is work that they'd estimated would take over two months for a team.

s44
00:02:56.400 --> 00:03:04.080
Um Bun, which is now part of reported that they migrated over a million lines of Zigg uh to Rust in six days.

s45
00:03:04.080 --> 00:03:08.640
Uh and of course all of us in this room are feeling this on a smaller scale.

s46
00:03:08.640 --> 00:03:17.680
uh our agents are generating whole apps and we're just sort of hitting the merge button and feeling guilty about the fact that we haven't read these code diffs and we're just sort of hoping that it works.

s47
00:03:17.680 --> 00:03:21.200
Uh we can't possibly keep on going like that.

s48
00:03:21.200 --> 00:03:25.760
Um so the obvious answer and the answer some people are trying is you just review more.

s49
00:03:25.760 --> 00:03:32.319
You take people whose job was previously to review code as well as write code and just say review code all the time.

s50
00:03:32.319 --> 00:03:33.760
This is your job now.

s51
00:03:33.760 --> 00:03:35.680
Uh and that doesn't work.

s52
00:03:35.680 --> 00:03:39.440
uh partly because that's really boring and those people burn out really fast.

s53
00:03:39.440 --> 00:03:53.760
Um but also the numbers say that we can't um the best study we have on this was done uh two decades ago at Cisco um over 10 months they took 2 and a half thousand reviews they took 3.2 2 million lines of code.

s54
00:03:53.760 --> 00:04:05.280
Uh, and the study says that reviewers stop finding defects effectively if they try to read more than 400 lines of code in one sitting and their effectiveness completely falls off a cliff.

s55
00:04:05.280 --> 00:04:10.080
Uh, if they try to review more than 450 lines of code in an hour.

s56
00:04:10.080 --> 00:04:19.359
Uh, if you do the math on that mean that means that a 10,000line agent pull request at that pace would take three or four working days to get a real human review.

s57
00:04:19.359 --> 00:04:21.440
that is one pull request from one agent.

s58
00:04:21.440 --> 00:04:32.560
10,000 lines is uh absolutely you know absolutely an expectable number of of lines of code uh for an agent that is doing a lot of work for you.

s59
00:04:32.560 --> 00:04:35.840
Uh and a developer can now run a dozen agents at once.

s60
00:04:35.840 --> 00:04:43.600
Um although I'm tend to be suspicious of the people who do um so we can't just review harder and we're all feeling that too.

s61
00:04:43.600 --> 00:04:46.720
The people who are trying to review harder are burning themselves out.

s62
00:04:46.720 --> 00:04:48.960
So what is the alternative?

s63
00:04:48.960 --> 00:04:53.040
Uh some people have decided to just stop reading the code entirely.

s64
00:04:53.040 --> 00:04:58.880
Uh Peter Steinberger who is the creator of OpenClaw uh says that you shouldn't be prompting coding coding agents anymore.

s65
00:04:58.880 --> 00:05:01.680
You should be designing the loops that prompt your agents.

s66
00:05:01.680 --> 00:05:08.240
Uh Andre Karpathy who is one of OpenAI's founding engineers has made the same argument about taking yourself out of the loop.

s67
00:05:08.240 --> 00:05:12.479
Uh because the human in the loop is holding the system back.

s68
00:05:12.479 --> 00:05:15.840
Uh but this goes beyond bold claims on Twitter.

s69
00:05:15.840 --> 00:05:24.560
Uh in February this year, OpenAI published an account of building an internal product uh with in their words no manually written code.

s70
00:05:24.560 --> 00:05:29.120
They started with a completely empty repository uh and agents wrote everything.

s71
00:05:29.120 --> 00:05:39.120
Five months later they had about a million lines of code about 1500 merged pull requests uh pull requests uh and they had done used three engineers to do this.

s72
00:05:39.120 --> 00:05:44.479
Uh even the scaffolding of the agent to review the agent and stuff like that was also written by agents.

s73
00:05:44.479 --> 00:05:50.000
What they said was humans may review pull requests but they are not required to.

s74
00:05:50.000 --> 00:05:56.320
Uh we've pushed almost all review effort towards being handled agent to agent.

s75
00:05:56.479 --> 00:06:08.240
I think the interesting thing about the OpenAI experiment is that they did not tell us what the product did and they did not review an open they did not release an open source product saying and this is how we did it and this is how you should do it which suggests to me that there are still holes

s76
00:06:08.240 --> 00:06:09.840
in that strategy.

s77
00:06:09.840 --> 00:06:11.919
Um but it is one possibility.

s78
00:06:11.919 --> 00:06:15.520
If open AAI says that you can do it, maybe you can do it.

s79
00:06:15.520 --> 00:06:21.120
Um but one poss so agent open AI says that's one thing you can do.

s80
00:06:21.120 --> 00:06:24.639
The bet there is that loop design substitutes for inspection.

s81
00:06:24.639 --> 00:06:32.800
Uh whether you can build a loop that is good enough uh to review all of your code for you depends entirely on what the loop can see.

s82
00:06:32.800 --> 00:06:34.800
Uh but that is an enormous caveat.

s83
00:06:34.800 --> 00:06:40.560
What exactly can the loop see and is it reliable enough to do code reviews?

s84
00:06:40.560 --> 00:06:49.680
For years, the industry's proxy for uh reliable for quality has been whether the tests passed uh because that is what the benchmarks measured.

s85
00:06:49.680 --> 00:06:56.639
In March this year, uh a research group called Meter, who you've probably heard about before, uh tested that proxy directly.

s86
00:06:56.639 --> 00:07:11.680
They hired four active maintainers of open- source projects uh from the same open source projects that Swebench tests against and they got them to look at uh PRs that had already passed

s87
00:07:11.680 --> 00:07:13.039
SWEBench is greater.

s88
00:07:13.039 --> 00:07:26.560
So SweetBench said this pull request is is good enough to merge and they got the open source reviewers to look at exactly the same PR and say is it really good enough to merge and it was only good enough to merge about half of the time.

s89
00:07:26.560 --> 00:07:31.680
Uh, and the failures weren't about correctness because obviously the PRs were passing all of the tests.

s90
00:07:31.680 --> 00:07:38.560
They were about code quality and they were about changes that quietly broke other code, things external to the test suite.

s91
00:07:38.560 --> 00:07:44.319
Uh, one caveat that meter mentions is that the agents got no chance to iterate on feedback.

s92
00:07:44.319 --> 00:07:50.000
So, a human uh, contributor obviously being told that their PR isn't going to get merged get another go at it.

s93
00:07:50.000 --> 00:07:51.759
They can take another swing.

s94
00:07:51.759 --> 00:08:03.360
Uh but that caveat doesn't really isn't really relevant to our purposes because that's just putting a human in the loop and what we're trying to see is whether or not we can take the human out of the loop entirely.

s95
00:08:03.360 --> 00:08:10.560
Uh Cognition, the makers of Devon, uh built a benchmark around the maintainer's actual question, which is would you merge this?

s96
00:08:10.560 --> 00:08:14.000
Uh they called it frontier code and they launched it in June.

s97
00:08:14.000 --> 00:08:21.440
Um more than 20 maintainers built 150 tasks from their own repositories, each one over 40 hours of expert work.

s98
00:08:21.440 --> 00:08:28.400
Uh Frontierbench grades behavioral correctness, regression, safety, scope, discipline, test quality, and maintainability.

s99
00:08:28.400 --> 00:08:32.719
This is a human review rubric uh made machine checkable.

s100
00:08:32.719 --> 00:08:44.560
Um, and what they found was that Fable 5 before it got pulled and then unpulled, uh, scores 88% on Swebench Pro, but only 29% on the hardest slice of, uh, Frontier code.

s101
00:08:44.560 --> 00:08:57.680
So, the same model on the same surface with the same job does 51 points less uh, less well if you're asking not does it pass the tests, but whether or not uh, you would actually merge the result.

s102
00:08:57.680 --> 00:09:00.240
Um, and this isn't one model having a bad day.

s103
00:09:00.240 --> 00:09:04.480
on the same set of tests uh GPT 5.5 scores under 6%.

s104
00:09:04.480 --> 00:09:11.279
So the strongest models we have are nowhere near uh passing human review reliably.

s105
00:09:11.279 --> 00:09:15.519
So somebody has to write down what mergeible actually means.

s106
00:09:15.519 --> 00:09:18.959
That is it's clear that we haven't done that yet.

s107
00:09:18.959 --> 00:09:22.320
Uh the moment they do something will happen.

s108
00:09:22.320 --> 00:09:36.000
Sarah Guo who is a prominent investor in AI uh wrote about it and said that solving for that solving for that benchmark a benchmark of genuine mergeability uh will be a critical turning point in the development of coding models

s109
00:09:36.000 --> 00:09:46.399
um in the essay where she was talking about this she made clear why models got so good so fast at generating code and that is because a compiler is a free verifier

s110
00:09:46.399 --> 00:09:58.080
a test suite is a free verifier and anything that you can verify cheaply you can train against until you beat it and that is what has been happening uh at the major model trainers.

s111
00:09:58.080 --> 00:10:08.640
Uh so a benchmark of mergeability if we could if we could make one wouldn't only be a measurement it would immediately become a training signal for the frontier models.

s112
00:10:08.640 --> 00:10:18.160
Uh which means maintainability scope discipline regression safe safety the moment somebody comes up with reliable tests for those the big models will be trained on them.

s113
00:10:18.160 --> 00:10:24.240
Uh and whoever writes today's review standard is writing next year's default model behavior.

s114
00:10:24.240 --> 00:10:28.560
Uh we have some prior art here knowing we have seen this happen already.

s115
00:10:28.560 --> 00:10:35.279
Uh which is that in 2024 OpenAI trained a model called critic GPT to catch bugs in model written code.

s116
00:10:35.279 --> 00:10:40.640
Uh human reviewers working on it beat the model alone uh and the human alone.

s117
00:10:40.640 --> 00:10:48.079
Um, so OpenAI built a model to review the models in order to clean the training and it created a training signal that's now built into the models.

s118
00:10:48.079 --> 00:10:51.600
It made the models better almost instantly.

s119
00:10:51.600 --> 00:10:54.560
But mergeability standards are still in the future.

s120
00:10:54.560 --> 00:11:05.279
Right now we do not have a good rubric that captures everything that a human decides uh to uh consider when they are deciding whether something is mergeable.

s121
00:11:05.279 --> 00:11:08.240
And I promised you something that you can do today.

s122
00:11:08.240 --> 00:11:13.200
Um so who is actually running automated review right now?

s123
00:11:13.200 --> 00:11:15.120
Uh one company is GitHub.

s124
00:11:15.120 --> 00:11:24.240
GitHub is uh copilot's reviewer has done 60 million reviews and now accounts for more than one in five uh code reviews on all of GitHub.

s125
00:11:24.240 --> 00:11:29.519
So machine review of pull request is the mainstream default uh on the world's largest code host.

s126
00:11:29.519 --> 00:11:30.720
That is more than an experiment.

s127
00:11:30.720 --> 00:11:35.200
That is a large production uh a large production deployment.

s128
00:11:35.200 --> 00:11:38.079
Uh, Curser is also doing an enormous amount of code review.

s129
00:11:38.079 --> 00:11:43.760
Cursor uh, has published its reviewer's architecture, so we know how they're doing this.

s130
00:11:43.760 --> 00:11:46.800
Um, and the details tell you what the job really is.

s131
00:11:46.800 --> 00:11:58.399
The first version of their reviewer uh, would run eight review passes over each diff uh, and then shuffle the order of the reviewers uh, to review the code again and again

s132
00:11:58.399 --> 00:12:03.040
uh, because the order in which it did those reviews changed the outcome of those reviews.

s133
00:12:03.040 --> 00:12:15.279
what they were doing was filtering for false positives because a reviewer, an automated reviewer that flags something as bad when it's actually good, uh, is going to get ignored.

s134
00:12:15.279 --> 00:12:17.680
Um, and it's not just cursor who's doing this.

s135
00:12:17.680 --> 00:12:18.959
There's research about it.

s136
00:12:18.959 --> 00:12:22.399
Uh, a team at PKing University tested the same idea independently.

s137
00:12:22.399 --> 00:12:26.000
Run several review passes, see keep what they agree on.

s138
00:12:26.000 --> 00:12:30.399
Uh, and they found that it review raised review quality by up to 44%.

s139
00:12:30.399 --> 00:12:38.639
Uh the multipass trick keeps getting rediscovered because uh false positives are the thing that kill a reviewer and it actually works.

s140
00:12:38.639 --> 00:12:42.240
So then cursor rebuilt uh their code reviewer.

s141
00:12:42.240 --> 00:12:46.800
Um so that the model reasons over the diff, calls tools and decides where to dig.

s142
00:12:46.800 --> 00:12:53.600
Um and my favorite detail from their rebuild uh was that they had to tell the model to be more suspicious of the code.

s143
00:12:53.600 --> 00:12:57.360
Uh the model tended to look at the code and say, "Well, that looks good to me, so ship it."

s144
00:12:57.360 --> 00:13:00.320
Which is exactly what a human would do in that situation.

s145
00:13:00.320 --> 00:13:03.120
uh they had to tell it don't trust the code by default.

s146
00:13:03.120 --> 00:13:05.200
Assume there is something wrong with it.

s147
00:13:05.200 --> 00:13:10.959
Um and somewhere in that sentence is a whole is a whole talk about what a good review actually is.

s148
00:13:10.959 --> 00:13:14.560
Uh it is about being suspicious by default.

s149
00:13:14.560 --> 00:13:19.920
Um the next thing that's happening is that review is starting to fuse with repair.

s150
00:13:19.920 --> 00:13:23.120
Cursor's reviewer now spawns a fix agent from its own findings.

s151
00:13:23.120 --> 00:13:24.880
So it doesn't just flag the bug.

s152
00:13:24.880 --> 00:13:29.760
uh it writes a patch uh and it hands you back uh a diff to approve.

s153
00:13:29.760 --> 00:13:36.320
Uh you approving that diff is obviously another code is another human in the loop where we don't want humans in the loop.

s154
00:13:36.320 --> 00:13:42.240
Um the next thing cursor wants to do is the reviewer running the code to prove its own bug report is real.

s155
00:13:42.240 --> 00:13:47.760
Um the line between reviewing and rewriting is getting very thin indeed.

s156
00:13:47.760 --> 00:13:51.760
Um and GitHub and cursor are by no means the only vendors getting into this game.

s157
00:13:51.760 --> 00:13:53.760
It is uh getting very crowded in there.

s158
00:13:53.760 --> 00:13:56.399
There's a ton of companies uh in the field.

s159
00:13:56.399 --> 00:14:02.320
Uh Code Rabbit is the largest dedicated reviewer has now reviewed over 13 million poll requests.

s160
00:14:02.320 --> 00:14:10.000
Uh Graptile builds a graph of your whole reposi of your whole repository so that the reviewer can see how a change lands in distant code.

s161
00:14:10.000 --> 00:14:16.560
Uh graphite builds its evaluation set from which of its own suggestions developers accept or reject.

s162
00:14:16.560 --> 00:14:27.519
Uh but the thing to notice uh about what every one of them is doing is that all of them are using the same metric as their definition of success which is is a human accepting my answer.

s163
00:14:27.519 --> 00:14:33.199
Uh cursor calls it the resolution rate and it has driven it from 52% to over 70%.

s164
00:14:33.199 --> 00:14:39.440
Um the reviewers are trained on human accept judgment every day at scale.

s165
00:14:39.440 --> 00:14:45.680
They are training their harnesses to get better at the definition of good as defined by human acceptance.

s166
00:14:45.680 --> 00:14:50.880
That is a preview of what the models are going to do except these companies have already shipped it.

s167
00:14:50.880 --> 00:14:59.040
So the status quo is you can generate code automatically, you can review the code automatically, but humans still need to review the the reviews.

s168
00:14:59.040 --> 00:15:01.120
Can you skip that part entirely?

s169
00:15:01.120 --> 00:15:03.920
Can you get the human entirely out of the loop?

s170
00:15:03.920 --> 00:15:08.320
Uh there are two prominent projects that I've that have tried so far that I've heard of.

s171
00:15:08.320 --> 00:15:15.440
Uh in February this year, Anthropics Nicholas Carini had 16 agents build a C compiler from scratch in Rust.

s172
00:15:15.440 --> 00:15:21.120
uh it was able to compile the Linux kernel uh across about 2,000 sessions with no human in the loop.

s173
00:15:21.120 --> 00:15:26.800
But if you read that experiment closely, uh it's true that there was no human in the loop.

s174
00:15:26.800 --> 00:15:30.959
Uh no human approving the code as it was written, but there was absolutely a human on the loop.

s175
00:15:30.959 --> 00:15:40.000
The system uh that reviewed the code, the system that checked whether the code was doing what it was supposed to do, all of that uh was written by a human.

s176
00:15:40.000 --> 00:15:43.680
Um the test harness, the feedback systems, all of that stuff.

s177
00:15:43.680 --> 00:15:48.320
Um it was automated testing with tests that took a human to write them.

s178
00:15:48.320 --> 00:15:57.759
Um Carini's own warning when he wrote about it was that it is easy to watch the tests pass and assume that the job is done uh and that it rarely is.

s179
00:15:57.920 --> 00:16:05.839
Another very widely publicized experiment which I al which I already mentioned briefly [clears throat] in passing was when bun ported its entire uh runtime from zig to rust.

s180
00:16:05.839 --> 00:16:09.279
That was about a million lines of code by agents in six days.

s181
00:16:09.279 --> 00:16:11.440
Obviously no human read that diff.

s182
00:16:11.440 --> 00:16:15.600
Um the gate for that experiment was the existing test suite.

s183
00:16:15.600 --> 00:16:18.639
99.8% of the test suite passed.

s184
00:16:18.639 --> 00:16:21.120
Um so the test did real work.

s185
00:16:21.120 --> 00:16:34.959
Uh a fun fact about that experiment is that the PR uh where they uh where the agents decided that the they were done with all of the Zig code and they deleted all of the Zig code in one giant PR was flagged by another robot as this is AI slop.

s186
00:16:34.959 --> 00:16:37.360
You can't possibly delete all of your code.

s187
00:16:37.360 --> 00:16:39.920
Uh which I thought was a fun aside.

s188
00:16:39.920 --> 00:16:43.600
Um, but there are some big caveats on that bun experiment.

s189
00:16:43.600 --> 00:16:49.519
Somebody looked carefully at the ported code and it has 13,044 unsafe blocks.

s190
00:16:49.519 --> 00:16:58.000
Uh, in a comparable human written uh, uh, Rush codebase of that size, uh, you would see about 74.

s191
00:16:58.000 --> 00:17:02.639
So, three orders of magnitude more unsafe memory unsafe blocks.

s192
00:17:02.639 --> 00:17:09.039
An unsafe block is a place where the author asserts rather than proves uh, that memory is being handled correctly.

s193
00:17:09.039 --> 00:17:12.799
So the test suite can certify behavior at the public interface.

s194
00:17:12.799 --> 00:17:18.640
Um it cannot certify 13,000 assertions that the test suite was never designed to look for.

s195
00:17:18.640 --> 00:17:21.439
So they took humans out of the loop for sure.

s196
00:17:21.439 --> 00:17:28.160
Uh but there's now no knowing what is lurking under the surface of their rust as a result.

s197
00:17:28.720 --> 00:17:34.480
So let's go back to OpenAI who have pushed this the first list because they show what skipping human review costs.

s198
00:17:34.480 --> 00:17:37.039
They didn't delete review, they moved it.

s199
00:17:37.039 --> 00:17:46.640
uh codeex reviews its own changes uh then calls in more agents to review those reviews um in a loop until every agent reviewer is satisfied.

s200
00:17:46.640 --> 00:17:56.960
OpenAI made Codeex bootable at every single change so that Codeex can actually run a copy of Codeex, look at it, look at the UI, see if the bug is being fixed.

s201
00:17:56.960 --> 00:18:00.559
Uh and they expose the whole logging stack to the agent.

s202
00:18:00.559 --> 00:18:08.640
Um, and a line from their writeup says exactly what the Cisco study said, which is that when something failed, the fix was almost never to try harder.

s203
00:18:08.640 --> 00:18:10.480
It didn't work sometimes.

s204
00:18:10.480 --> 00:18:18.240
Uh, and one detail that you'll recognize from your own week is that for a while on this project, they had to spend every Friday cleaning up AI slop.

s205
00:18:18.240 --> 00:18:20.960
Uh, by hand as humans.

s206
00:18:20.960 --> 00:18:29.760
Um, so that eventually didn't scale and so they trained agents to look for AI slop and get rid of the AI slop.

s207
00:18:30.320 --> 00:18:35.280
uh review didn't disappear is the lesson of this of of this experiment.

s208
00:18:35.280 --> 00:18:40.400
Uh it got rebuilt as a system and that system is built by humans.

s209
00:18:40.400 --> 00:18:43.039
So can you skip the human entirely?

s210
00:18:43.039 --> 00:18:47.360
Uh someone who tried it for real and then changed his mind is Dexter Horthy.

s211
00:18:47.360 --> 00:18:50.160
Uh he spent six months telling people not to review the code.

s212
00:18:50.160 --> 00:18:52.799
He famously did that at AIE last year.

s213
00:18:52.799 --> 00:18:56.240
Um he told people just ship, let the agent do its thing.

s214
00:18:56.240 --> 00:19:00.320
Uh and in March this year on stage uh he took that back.

s215
00:19:00.320 --> 00:19:02.480
Uh he said I was wrong.

s216
00:19:02.480 --> 00:19:03.600
Please please read the code.

s217
00:19:03.600 --> 00:19:05.520
We tried not reading the code for like six months.

s218
00:19:05.520 --> 00:19:06.880
It did not end well.

s219
00:19:06.880 --> 00:19:09.840
We had to rip out and replace large parts of that system.

s220
00:19:09.840 --> 00:19:10.880
That is not a benchmark.

s221
00:19:10.880 --> 00:19:13.440
That is somebody who ran this experiment for real.

s222
00:19:13.440 --> 00:19:18.480
Tried it with real code on a real system uh and retracted his remarks.

s223
00:19:18.480 --> 00:19:25.440
Uh OpenAI is running uh lived with the results um and reversed in public.

s224
00:19:25.440 --> 00:19:30.960
Uh so Sarah Quo uh in the same writeup that I mentioned earlier talked about why that happens.

s225
00:19:30.960 --> 00:19:35.440
Passing the test never told you that the change was the right change.

s226
00:19:35.440 --> 00:19:41.200
It never told you that this module exists because there are three external users of this module.

s227
00:19:41.200 --> 00:19:46.720
Uh it never told you that there's this cron job that nobody will admit to writing that relies on that module existing.

s228
00:19:46.720 --> 00:19:53.679
Um there is context outside of the test suite that the tests don't uh can't find.

s229
00:19:53.679 --> 00:20:00.960
So in everything that we've looked at so far, the human uh checkpoint is continuing to survive.

s230
00:20:00.960 --> 00:20:04.799
It is moving around uh but it is surviving in predictable places.

s231
00:20:04.799 --> 00:20:07.520
One is where correctness isn't cheaply checkable.

s232
00:20:07.520 --> 00:20:10.960
Another is where uh the blast radius is large.

s233
00:20:10.960 --> 00:20:21.200
In security conscious environments, every time you tell people, oh, we can just get rid of human review, you get an immediate no. Uh wherever someone has to put their name on the result.

s234
00:20:21.200 --> 00:20:24.559
Uh but what's happening is the human role isn't disappearing.

s235
00:20:24.559 --> 00:20:35.360
It is moving up the stack, possibly several levels up the stack from inspecting the code directly to designing and tuning the systems that inspect the code and designing the definition of good.

s236
00:20:35.360 --> 00:20:38.720
Which raises the obvious question, who reviews those systems?

s237
00:20:38.720 --> 00:20:43.120
If you've built a system that does your reviews for you, how do you do the meta review of your reviewer?

s238
00:20:43.120 --> 00:20:45.440
Um and the answer won't surprise you.

s239
00:20:45.440 --> 00:20:46.640
It is humans.

s240
00:20:46.640 --> 00:20:59.440
Uh, Anthropic ships an automated security reviewer and in its readme it has a huge caveat uh, which is this action is not hardened against prompt injection attacks uh, and should only be re used to review trusted PRs.

s241
00:20:59.440 --> 00:21:06.240
So, Anthropics code reviewer uh, can be talked out of its findings by the very thing that it is reviewing.

s242
00:21:06.240 --> 00:21:18.480
Um and that is a finding that has been reproduced in study in March this year reinforced uh that vulnerable code dressed up in an innocent commit message uh fooled an autonomous review agent in 88%

s243
00:21:18.480 --> 00:21:19.600
of attempts.

s244
00:21:19.600 --> 00:21:26.240
Uh the same attempts uh sent to a human reviewer uh passed only 35% of the time.

s245
00:21:26.240 --> 00:21:28.799
So you you take the human out of the loop.

s246
00:21:28.799 --> 00:21:33.200
Uh you don't just lose a reviewer, you lose the thing that was hard to fool.

s247
00:21:33.200 --> 00:21:37.120
So automated reviews fall for confidently framed bad code.

s248
00:21:37.120 --> 00:21:42.080
And confidently framed bad code is exactly the kind of code that agents are very good at producing.

s249
00:21:42.080 --> 00:21:44.799
They're very like this is good and I am ready.

s250
00:21:44.799 --> 00:21:48.559
Uh and they uh are wrong sometimes.

s251
00:21:48.559 --> 00:21:53.520
Um and the other problem is the field doesn't even agree yet on how to grade these graders.

s252
00:21:53.520 --> 00:21:56.559
Uh benchmark scaffolds have been caught leaking answers.

s253
00:21:56.559 --> 00:22:00.240
Researchers disagree on how to review quality at all.

s254
00:22:00.240 --> 00:22:06.480
um which leaves one reviewer that you can't automate and you can't skip which is production.

s255
00:22:06.480 --> 00:22:15.120
Uh once the premerge review is all machines watching what the code actually does becomes the last reviewer standing.

s256
00:22:15.120 --> 00:22:26.000
Um once the code ships the test results stops being the interesting thing the trajectory does what the system actually did step by step uh when it ran against the real world.

s257
00:22:26.000 --> 00:22:28.159
Uh I'm not going to give a pitch for a rise here.

s258
00:22:28.159 --> 00:22:30.480
there are enough pitches for a rise at this conference.

s259
00:22:30.480 --> 00:22:40.320
Uh but if you're shipping automatically reviewed code, then systems in production that review what it actually does in the wild become indispensable.

s260
00:22:40.559 --> 00:22:52.799
Um so after all that evidence, after all of that review of what the world is doing about automated code reviews, where I land is that code review isn't completely dead, but it is changing an enormous amount.

s261
00:22:52.799 --> 00:22:55.360
Uh it is being rebuilt as an engineered system.

s262
00:22:55.360 --> 00:23:03.520
Humans are moving from being the engine that drives a code review uh reading code line by line uh to its pilots.

s263
00:23:03.520 --> 00:23:06.960
Uh and given the numbers that we opened with that is probably the right trade.

s264
00:23:06.960 --> 00:23:15.440
Every layer of that system, the benchmark, the classifier, the rubric, the test suite, the eval is itself unreed until somebody decides that that is their job.

s265
00:23:15.440 --> 00:23:20.159
Um and the teams that win the next few years won't be the ones that generate the most code.

s266
00:23:20.159 --> 00:23:25.520
They'll be the ones who can say with evidence why they trust what they shipped.

s267
00:23:25.520 --> 00:23:31.919
Uh and I open by promising you that I would give you with something practical that you could walk away with something that you can do today.

s268
00:23:31.919 --> 00:23:34.880
Uh and that is to stop reviewing PRs.

s269
00:23:34.880 --> 00:23:38.000
Um it is the wrong level of abstraction for 2026.

s270
00:23:38.000 --> 00:23:44.559
Your human judgment is extremely valuable, but it can be made to scale much further than it is scaling right now.

s271
00:23:44.559 --> 00:23:51.520
Uh pour your precious time into building uh a reliable review harness.

s272
00:23:51.520 --> 00:23:59.039
codify your definitions of good, your company context, your domain knowledge, and then uh crank up the agents to work with that.

s273
00:23:59.039 --> 00:24:07.919
You can go much faster than one-third faster uh if you concentrate your efforts higher up the stack of reviewers, rules, and evals.

s274
00:24:07.919 --> 00:24:17.360
Uh I hope this look at what the industry is doing today has helped you what to helped you decide what you should do and what to expect next.

s275
00:24:17.360 --> 00:24:21.200
Uh and thank you so much for your time and attention.

s276
00:24:21.976 --> 00:24:23.976
[applause]