YT YouTube2Text

YouTube2Text → Transcripts → How Anthropic Reviews 30,000 Claude Code Changes a Day

How Anthropic Reviews 30,000 Claude Code Changes a Day — Transcript

by Owain Lewis · 5,602 words · 820 segments · language en · Watch on YouTube

Open in transcriber Summarize with AI Download SRT/VTT

Full transcript

0:00Today we're talking about how the
0:00Anthropic team does code review [music]
0:02at scale on products like Claude Code.
0:04In just 4 months, the Anthropic team
0:05went from merging 2,500 changes per day
0:07[music] to over 30,000, which is a 12x
0:10increase. And obviously, the traditional
0:12ways [music] we do code review are going
0:14to really struggle to keep up with
0:15AI-generated code. In this video, I'm
0:17going to show you the six levels of AI
0:18code reviews that the Anthropic team are
0:20using. I'll give you some live demos so
0:22you [music] can see exactly how to apply
0:23these ideas in your own workflow when
0:25building with tools like Claude Code or
0:26Codex.
0:26>> [music]
0:27>> If you're new to the channel, my name's
0:28Owen. I've been a software engineer for
0:29the past 20 years and I work with
0:30hundreds of engineers every single day,
0:32and code review is definitely one of the
0:33things I see teams really struggling
0:35with right now. I'll link all of the
0:37resources from the video, including the
0:38prompts, in the description below. So,
0:40let's get into it.
0:41All right. So, this is the article we're
0:43going to look at today, which is how the
0:44Claude Code team [music] does code
0:46review. And what's really interesting is
0:4790% of Claude Code's own code base is
0:50written by AI. I guess that's not
0:51surprising, but at the level of scale
0:54Anthropic are at, having this much
0:57AI-generated code obviously causes
0:58problems. And this is the same for most
1:00of us right now, because the problem
1:02with AI-generated code is we're not
1:03writing it, and so we don't understand
1:05it in the same way we would understand
1:06it if we had written it ourselves by
1:08hand. And we need to figure out how to
1:10deal with the increasing volume of code
1:13and the fact that we're more detached
1:14from the code than we used to be. A
1:16really interesting idea that I'm seeing
1:18in software teams, and I've been
1:19thinking about a lot myself lately, is
1:20the theory of constraints. So, even
1:23though we're using AI to generate more
1:24code, what I'm seeing is the software
1:25teams in general aren't actually
1:27producing more output or moving any
1:29faster. And this is the theory of
1:31constraints in action.
1:32The theory of constraints says that your
1:34system only moves as fast as the slowest
1:37part of the process. And even if you
1:39generate loads of code, AI agents can
1:41write code in minutes,
1:42if you can't review that code, or it
1:44takes a long time to review the code,
1:46then you're not really going to get much
1:47of a gain in terms of your productivity
1:49or your overall output. And I'm seeing
1:51this a lot lately. So, human code review
1:53has always been very slow. It's not
1:56uncommon for a code review change in a
1:58traditional software team to take
1:59multiple days. People are busy. They
2:01also have to get acquainted with
2:03whatever the code change is. They don't
2:04have much background on it. So, it just
2:06takes a really long time to get code
2:07review done in general.
2:10But, now if we're producing even more
2:11code, this problem is only going to get
2:13much worse. And so, just using the same
2:16methods we've always done, it just
2:17doesn't really make sense anymore
2:18because we're not going to be able to
2:19keep up with the rate of AI-generated
2:21code. So, code review has always had two
2:23jobs. So, the first job is to find and
2:24fix bugs before they ship into
2:26production. This is obvious. Every time
2:28you make a code change, there's pretty
2:30much always something that can be
2:31improved or fixed. Humans make mistakes.
2:34AI agents make mistakes. You can never
2:36trust the first output. And review just
2:39really raises the quality bar within a
2:41team.
2:42The other reason we do code review is to
2:44gain a shared understanding of what's
2:46going on. So, as our agents write the
2:48code, we still want to know what they're
2:49doing, right? We still want to
2:50understand the code base. We still don't
2:52want to lose track or lose sight of the
2:53high-level understanding of what's
2:55actually going on within our software.
2:57There are some great ideas in this
2:59article. So, this first comment is
3:00really insightful. So, we often think
3:02about did a human read the code? But,
3:04that's not actually very useful. The
3:06interesting thing is what could go wrong
3:07with this change? And which check is the
3:10right one to catch it? Would it be an
3:11automated check? Would it be a human
3:13review? And when you think about code
3:15review, it's really important to know
3:16that code review isn't just one level.
3:19We have like different levels of risk
3:20for a code review. So, if you're making
3:22a documentation change, obviously the
3:23risk of that going wrong is very, very
3:25low. If you make a mistake and you merge
3:27it, it's kind of fine, right? It doesn't
3:29make a difference. So, the blast radius
3:30of that change is very, very low. But,
3:32if you're making a change to your
3:33database or your payment infrastructure,
3:35if you put a bug into production, that
3:37could cause like a massive outage.
3:39Customers could not be able to access
3:41your services or your systems. And
3:43obviously the blast radius of that
3:44change is way higher. So, you always
3:47want to think about code review at
3:48different levels of risk. You don't want
3:50to think about every code change as
3:51being the same. Human time and attention
3:53is always going to be a bottleneck when
3:54it comes to software development, so we
3:56only want to apply human review where
3:59it's really needed. And this this idea
4:01kind of shows up throughout the article.
4:04So, obviously human attention is
4:05limited. So, if AI agents are generating
4:07hundreds of code changes, we can't
4:09reasonably expect a human to review
4:10every single one of those changes
4:12because humans just don't have the time
4:14or the attention to do that. A really
4:16great thing about code review is you can
4:17measure how effective your code review
4:19process is very very easily. So, you can
4:22see how long it takes from getting the
4:24change opened to getting it merged. You
4:26can also measure things like how often
4:28does the change go wrong? So, what's the
4:30revert rate or the defect rate of a code
4:32change? This is a really easy way to
4:34measure the quality of your code review
4:36process. So, if you are in a team, I
4:38think it's really interesting right now
4:39to start measuring these things so that
4:41you can see how your process is
4:43improving as you start adopting AI.
4:45We're going to walk through the six
4:46steps that Anthropic are using to review
4:48their code. We'll go in depth on each of
4:50these. So, at a high level, they have a
4:52local review. So, before they even open
4:54a code change for review, they make sure
4:56that it's reviewed locally first. So,
4:58they run a bunch of automated checks.
4:59They do testing, build checks, linting
5:01checks, type checking, and then they're
5:03using AI agents to review the code with
5:05a fresh context window.
5:07Then once they open the change,
5:09they'll run again a bunch of static
5:11automated checks to find obvious errors.
5:14Then they do a Claude code review. So,
5:16they use an AI agent or multiple AI
5:18agents to review the code. They run a
5:20security review,
5:21and they have this risk-based approval.
5:24I really love this idea and we'll talk
5:25about it more
5:27later in the video. But this idea here
5:28is that we classify the change as low
5:31risk, medium risk, or high risk. So, a
5:32low risk change you could auto merge.
5:34And then a medium risk change, you'd
5:36have one person review, and then a high
5:37risk change, you'd have two people
5:39review. I think this is a really smart
5:40strategy. And then they also have a way
5:43of rolling out their changes to internal
5:45teams so they can get feedback. And they
5:47gradually roll out their changes, and
5:49then if they do deploy into production,
5:51they have a way of rolling back if there
5:53are any errors, because in reality, code
5:55review is not perfect. If it was, we
5:57wouldn't have bugs in production, so you
5:59still want to assume that code review is
6:01flawed. It's not a perfect process,
6:03right? All right, so step one is to do a
6:05local review. A lot of people are
6:06probably already doing this, but once
6:08you've had your agent write the code,
6:09you want to ask a sub agent or a fresh
6:11agent to review the code base. This
6:13could be using Claude, or it could be
6:15using another agent like Codex. So, if
6:17you're using Claude code, you could ask
6:19the Codex agent to review the code or
6:21vice versa. So, this is obviously a best
6:23practice, and if you're working with AI,
6:26you should always review the code. Even
6:27though AI is capable and smart, just
6:29like a human, the first time you write a
6:32piece of code, whether you're an AI
6:33agent or a human, chances are there's
6:36going to be a bug or something that can
6:37be improved, right? No AI agent writes
6:40perfect code the first time, and so this
6:41is why code review is so important.
6:44Boris, who's the creator of Claude code,
6:46has said that this process of doing like
6:48an iteration locally will make the final
6:51result two to three times better, and I
6:53think that makes sense to me, because
6:55every time I look at an AI-generated
6:56code change, there's always some kind of
6:59problem. If you ask a sub agent to
7:01review your code, chances are they're
7:03going to find a problem. So, I think
7:05this step is really, really important. A
7:07really interesting idea that they talk
7:08about here that I've been using myself
7:11is this idea of a review.md file. So,
7:14the concept here is that if you think
7:15about a code review, you're not really
7:17reviewing a general change. You're
7:20normally focusing on specific areas. So,
7:22if you're building a payments
7:23application, you probably want to pay a
7:25lot of attention to security, and, you
7:27know, making sure authorization and
7:30things like that are correct. If you're
7:31working on a web application, maybe you
7:33want to spend a lot of time reviewing
7:34the UI. Maybe you want to spend a lot of
7:36time looking at database performance.
7:38So, every different application or every
7:40every software application you work on,
7:42you're going to want to focus on
7:43slightly different things.
7:45And that's the idea behind this
7:46review.md file. You can create this
7:48file, ask your agents to read it, and
7:50then they will focus on specific things
7:52that you want them to focus on.
7:54So, this is an example of a review.md
7:56file. So, we can tell the agent what's
7:59important to us when it does the code
8:00review. So, we can say how to present
8:03the findings. We can say, you know,
8:06don't look at the linting or formatting.
8:09Don't look at these particular folders.
8:11You know, don't include email addresses
8:14or user information in logs. Pay
8:16specific attention to that. So, this is
8:18a really great way of just focusing your
8:20agent to look at particular things when
8:22it's doing the code review. Like I said,
8:24all you need to do is have this file
8:26in your codebase, and then you can ask
8:28your agents to reference or read that
8:29file. Here's an example from my own
8:31project. So, this is a project that I'm
8:33working on a software factory, and you
8:35can see here that we're focusing on how
8:36to do the code review. So, we're saying
8:38here to focus on classifying the changes
8:41as low-risk, or medium-risk, or
8:42high-risk. And we're giving some
8:44guidance about what these things mean.
8:46And then we're also just giving it just
8:48general guidance on what to pay
8:50attention to in this specific codebase.
8:53Okay, so the next step is to do an AI
8:55review on every pull request. So, the
8:57idea here is that once you push your
8:58code change up to something like GitHub,
9:00you run an automated code review. You
9:02get an AI agent to review your code.
9:04There are so many different ways to do
9:05this. You could use a tool like Code
9:07Rabbit or Griptile. You could also use
9:10Code itself, or CodeX, which is what I
9:12use, to just run a basically a basic
9:15review of your code change. So, what I
9:17want to show you now is the two commands
9:18that you can run inside Code Code
9:21that are worth remembering. So, the
9:22first command we're going to do is
9:24{slash} code review. So, this is
9:26obviously just going to do a code
9:27review.
9:28And then the other command we can also
9:30run as well to be aware of is the
9:32{slash} security review command within
9:34Code Code. So, if you type {slash}
9:36security review,
9:38you can you can actually focus it on
9:40particular files. So, for example,
9:42review this particular file or the
9:43uncommitted changes. You can pass in
9:46some additional context as you do the
9:47{slash} command
9:48>> [music]
9:48>> to maybe focus it on a particular area
9:50or particular topic.
9:52So, the code review agent has come back
9:53already and it's detected a bunch of
9:55errors.
9:56So, as you can see, I added a I added an
9:58SQL vulnerability just to see if it
10:00caught it. So, you can see here we have
10:01some serious issues. So, SQL injection,
10:04um no auth on this particular endpoint,
10:07and then we have correctness as well.
10:10So, things that we need to fix like
10:12logical errors. This thing is never
10:14checked. Um and then also quality as
10:17well. So,
10:20you can then just ask the agent to
10:22obviously just go through and fix those.
10:24You probably want to run this a couple
10:25of times. You probably want to go
10:26through, have the agent fix these
10:27things, and then run it again. You can
10:29also focus the code review on a
10:31particular topic. So, maybe you want to
10:32focus on, you know, review documentation
10:35or something.
10:36Uh you can kind of focus the review on
10:38different things depending on what
10:39you're doing. So, we're getting back the
10:41feedback now from the code review agent.
10:44You can see here it's giving pretty good
10:45feedback. So, we've got a nine out of 10
10:47confidence on the SQL injection.
10:49And you can see here description. So,
10:51this is a much more thorough review than
10:53the just general code review. You'll
10:54notice we did pick this up as well in
10:56the regular review, but this is
10:58obviously gone into much more detail.
11:00So, you can see here
11:01uh listening on the loopback at a
11:03predictable port.
11:05Uh it's giving us quite a lot of, you
11:06know, useful feedback here. So, we've
11:08got some recommendations on the SQL
11:10statements.
11:12There's another vulnerability here with
11:13path traversal. So, you can see this is
11:16really useful. You're getting more
11:17detail from the security review. It's
11:18finding It's going much more in-depth.
11:20>> [music]
11:20>> And the general code review is also
11:22catching a lot of these errors, but it's
11:23not going in quite as much depth. So, I
11:25recommend running both of those at the
11:27same time. So, one suggestion I have
11:29that might help you to always remember
11:31to do this because in reality we get
11:33tired, we forget to do things. So, what
11:36I recommend doing is becoming more
11:38systematic in your development process.
11:40And so, what I mean by this is moving to
11:41more of a factory mindset where we take
11:44a task, we run it through the same
11:45series of steps every time in a really
11:48repeatable way. So, this is an example
11:50of a factory plugin that I've been
11:52building. But, you can see here I have
11:54different agents for different steps of
11:55the process. We have a implementer agent
11:58which will take the code change and then
12:00write the code. But, then we also have a
12:02review agent.
12:04We have a security review agent.
12:06We have a UX review agent. So, you
12:09reviewing the browser, uh reviewing like
12:11what the web app looks like using
12:13browser testing and things like that.
12:15We also have a triage
12:17agent and we have a classifier agent
12:19that will change the risk level on the
12:21ticket. It will add a label to the
12:23GitHub issue,
12:24uh depending on what kind of change it
12:26is. And what you can do is you can
12:28combine all of these into some kind of
12:29sequence
12:30so that you can pretty much just give a
12:32single command, pass in a task, and then
12:34have the agent run through all of these
12:36different steps every single time. And
12:38this is moving to the factory mindset
12:40where you're no longer ad hoc prompting
12:42these agents. You're becoming much more
12:44rigorous and systematic about your
12:46development process. And I think this is
12:47the key to really getting the quality
12:50when it comes to AI agents. You don't
12:51need to make this complicated. I don't
12:53think you need that many skills. I don't
12:55have a complex setup. I don't think you
12:57need to install loads of different
12:58complex skills at all anymore. As agents
13:00get smarter, you can keep your setup
13:02pretty minimal. But, what you do want to
13:04have is the repeatability and the
13:05predictability in your workflow or your
13:07process. So, we can test out this idea
13:10of being more rigorous within our
13:12development process to make sure we
13:13always run a security review or we
13:15always run a code review every time we
13:17make a change, always review the linting
13:19and the tooling that we need. So, the
13:21way you can do that is to build some
13:22kind of factory system. So, this This a
13:25plugin that I've been building called
13:26software factory. This is just a bunch
13:28of code code sub agents essentially that
13:30are chained together. So you can see
13:32here we can do a review.
13:34And we can optionally pass in some
13:36information. So this is basically making
13:38your process more systematic. You can
13:41basically pass in a task and then have
13:43the agent do the same thing every single
13:45time. So this review command is
13:46combining multiple different things. So
13:48it's combining a regular code review,
13:50but it's also running a security review.
13:52So rather than having to type all of
13:53these individual commands, rather than
13:55having to remember to prompt in a
13:57certain way, you can just basically have
13:59a single command that will take your
14:01change and remember to do all of the
14:03right steps every single time. So this
14:04is just making your process really
14:06repeatable. You could even just do this
14:08at a higher level, which is what I tend
14:10to do where I just pass in a task and
14:12then have the factory just run the
14:14entire change through a series of steps.
14:17Planning, building, testing, reviewing,
14:20etc. So you can kind of do it that way.
14:22So this is the idea from the Anthropic
14:24article. We classify this as medium
14:26risk. So we need to get one human
14:28approval. Another way you can do this is
14:30to run the entire pipeline. So rather
14:31than just having one command to review
14:32your code, you can literally just take a
14:34task and then run it through all of the
14:36series of steps every single time. So
14:37I'm going to take this ticket. So what
14:39I'm going to do is type software
14:40factory.
14:42And I'm actually just going to pass in
14:44the specific ticket here. So we're going
14:45to do Neo
14:47345. Let's do 345.
14:50And so what we can do here is just
14:52basically work on a task. And we're
14:54going to hand this off to lots of
14:55different sub as we go. So we're going
14:57to triage the ticket.
14:59And then we're going to basically build
15:00or write the code. We're then going to
15:02review the code using all of these
15:04different sub agents and all of these
15:05different tactics that we've talked
15:06about. So again, all I'm doing here is
15:09just passing in the task. And because
15:11I've encoded the workflow into the
15:13software factory or into the system, I
15:15don't really have to think about these
15:16steps. I'm just making sure that I'm
15:18doing them every single time, which is
15:20the really important thing when it comes
15:22to this kind of thing, cuz as I said,
15:24you will you will forget to do a code
15:25review or you will forget to run the
15:27security review command. But when you do
15:29it this way, the agent is always
15:31following the right steps. It's always
15:33doing the right thing. It's always
15:34running the classifier. So this is kind
15:36of the approach that I've been moving to
15:37myself when it comes to agentic coding.
15:41One of the things I'm doing personally,
15:42and I really like this idea, is this
15:44notion of a triage. Again, this is a
15:46software factory idea. But what I'm
15:48doing is that I'm building this change.
15:50I'm writing out the entire spec.
15:53So I'm taking a very rough problem
15:56description, like a very vague input,
15:58and then I'm I'm using an agent to
16:00triage the the original request and
16:03break it out into more of a spec. So you
16:05can see here, this is a very detailed
16:07breakdown now. We've added labels, and
16:10we've basically done a spec. So this is
16:12where we're using the software factory
16:13approach of we're taking a task, we're
16:16getting the agent to write a fairly
16:17detailed specification that we can then
16:19review if we want to.
16:21We can then have the agent build the
16:22code. We can then run all of the
16:23automated checks, the code review, and
16:26there's also often
16:28things like these acceptance checks as
16:29well. So when you run your code review,
16:31it's really important to reference these
16:33checks. So in your original plan, we've
16:36got a bunch of cases that we also want
16:38to test for. So when we do the code
16:39review, this is something else you want
16:41to pay attention to. Does the code do
16:43what it's meant to do? Does the code
16:44actually meet all of the requirements?
16:46All of the different acceptance checks
16:48that you came up with when you
16:50originally decided to build this. So
16:51this is just a really useful thing to
16:52think about. Having these acceptance
16:54checks, when you do your code review
16:56process, make sure that you're
16:57referencing those acceptance criteria,
17:00and you're going to make sure that the
17:01code actually does what it's meant to
17:02do.
17:03The third step is to do a security
17:06review. So this is actually built into
17:08Claude code. There's a {slash} security
17:10review command that you can use. And the
17:13idea here is we want to catch any,
17:14obviously like security vulnerabilities
17:17within the code base. I would say you
17:19want to run this maybe periodically. You
17:21don't want to run this every single time
17:22you make a code change. I would also
17:24suggest automating this because in
17:26reality, most of us are going to forget
17:28to run this command. So, there's a good
17:30article on this. So, this is the
17:31automated security review command, but
17:33you're looking for things like SQL
17:36injection risk, cross-site scripting,
17:38authentication authorization flaws,
17:40insecure data handling, you know, lack
17:42of validation, and vulnerable
17:44dependencies. Step four is using
17:46deterministic automated checks, things
17:48like linting, type checking. If you're
17:51not familiar, these are tools that you
17:52can run that will find obvious errors in
17:54your code. They've been around forever,
17:56and most developers are already using
17:58these things. A great way to do this is
18:00to ask your agents to configure these
18:02for your particular language. Depending
18:04on what language you're using, there'll
18:06be different tooling. So, what I would
18:08do is when I start a project, I would
18:09ask the agent to set this up for me,
18:11both locally and then also on GitHub.
18:13The agent will configure it all for you.
18:15So, type checking, make sure your code
18:17builds correctly. There are language
18:19specific formatters and things like that
18:21that you can run just every time you
18:23make a code change essentially. Step
18:25number five is human approval scaled by
18:27risk. This is my favorite part of the
18:29whole article, and I think this is such
18:30a smart way to think about code review.
18:32So, they use a classifier to decide
18:35whether a code change is high risk, low
18:36risk, or medium risk. And this is really
18:39important because you always want to
18:40think about the blast radius of a
18:41change. You don't want to have multiple
18:43people reviewing a documentation change,
18:45for example, because that would be a
18:46massive waste of people's time. If it's
18:48a small trivial change, I think it makes
18:51sense for have the agents auto merge
18:53that change. You kind of want to trust
18:55the agents at some point. But if it's a
18:58medium risk change, like a large
18:59feature, you can get one person to
19:01review that change. If it's a higher
19:03risk code change, like a database change
19:05or an infrastructure change, which would
19:06have a much higher blast radius, then
19:08you can have two people review that
19:10change. I think this is a pragmatic and
19:13smart way to think about code review.
19:15They also make sure that whoever made
19:17the change is on the hook for it. So,
19:18even though AI agents are writing the
19:20code, obviously we're still responsible
19:22for making sure that the code change is
19:24high quality. Step number six is about
19:26gradual release. So, essentially what
19:28they'll do is they'll roll out their
19:29change to internal teams first. This
19:31gives them a way of getting feedback on
19:33issues before it goes out to the public.
19:35Step seven is about fast detection and
19:37fast rollback. The idea here is that
19:40code review is not perfect. It doesn't
19:42matter how good your agents are. Doesn't
19:44matter how good your setup is. You're
19:46never going to catch every single
19:47possible error in a code review, right?
19:49You can only find certain types of
19:51errors once you deploy your change into
19:53production. Things like memory leaks,
19:55performance issues, it's very hard to
19:57detect them just by looking at the code
19:59itself. So, you always want to assume
20:01that your code review process is not
20:03perfect. And so, what they do is if they
20:05roll out a change that has a problem,
20:07they can roll it back really really
20:08quickly. They also do a periodic, you
20:12know, on-call review. They do an
20:13incident review. This is good practice
20:15within the team. So, every week you'll
20:16get together, you'll look at the last
20:18week's code changes, find problematic
20:20areas, and then improve your process to
20:22catch those areas in future. The
20:24Anthropic team take this further by
20:26essentially using past mistakes where
20:29you've gone through a code review
20:30process, you haven't caught the error.
20:32So, what they'll do is they'll use these
20:33as evals or feedback for future
20:35reviewers. So, if they've made a
20:37database change that got through the
20:39code review process, but actually caused
20:41an error in production, they will use
20:43that as a test or kind of context for an
20:45agent to pay specific attention to that
20:48next time. It's really important that
20:49humans still stay in the loop,
20:51obviously. So, humans have context that
20:53AI agents don't. Personally, I am quite
20:55comfortable now auto merging certain
20:57types of change. And I think as AI
20:59agents get better, this is starting to
21:01make more sense. We have to trust the
21:03agents a little bit at some point. But,
21:05there's still times where you do need a
21:07human in the loop. Obviously, anything
21:09that's risky, humans often have a lot
21:11more context. They can spot things that
21:13the AI agents can't, but then equally AI
21:15agents will spot things that human
21:16humans can't. So, you always want to
21:18combine these two things. The other
21:20thing which I think is really important
21:21when it comes to code review is you
21:22still need to understand at a high level
21:24what's going on with your code. So, even
21:27though the agents are writing the code,
21:28you still want to understand what's
21:30going on, what the change is doing, what
21:31the impact is, and how it affects the
21:33overall architecture of your system. One
21:35thing you can do that will really help
21:36you when it comes to code review and
21:38code changes is to ask your agents to
21:40write you an explainer. So, you can get
21:42the agent to write a HTML page with a
21:44diagram, explain to you what the change
21:46is, and it can help you really
21:48understand what the code change is and
21:50what the potential risk is. So, this is
21:51a really great technique if you want to
21:53understand or more easily get a feel for
21:56what the agent is doing.
21:58So, what I'm going to do here is even
21:59though this code change is running, I'm
22:01going to see if Claude can do this in
22:02the background. So, I'm going to say,
22:03"Generate me a HTML explainer showing
22:07what this change is and include
22:11a diagram to help me understand it."
22:16So, we can just ask Claude to generate
22:17these HTML explainer docs. Very useful
22:20technique to understand, especially if
22:22you're working on a larger code change,
22:24and especially if you're context
22:25switching or coming back later on.
22:27Having the agent generate some kind of
22:29visual diagram help you kind of remember
22:32what the change is, help you understand
22:34it a bit more uh in depth. So, this is
22:36the explainer that it generated. You can
22:38see here, you can obviously customize
22:39this to make it easier to understand.
22:41Often, I find it quite hard to
22:43understand some of the output from these
22:45agents nowadays. They're not very good
22:47at explaining things.
22:49But you can see here, we've got
22:50diagrams. You can kind of see the
22:51process of what's going on, and you can
22:53see a way to recreate it, and it's
22:55giving you kind of a just a way to kind
22:57of understand the change in more depth,
22:59basically. So, this is just a really
23:01useful technique to help you walk
23:03through the code change, internalize
23:05what's going on, and just have a better
23:06understanding. So, this is a recap of
23:08what they suggest. So, before you open a
23:10code change, make sure that you run a
23:12bunch of, you know, automatic formatting
23:14and linting. You can use a Claude code
23:16hook for this, or you could just have a
23:19like a pre-hook with Git, so it
23:21automatically reviews before you push
23:22your change. Run the {slash} code review
23:24command and the {slash} security review
23:26command locally,
23:28or use a fresh sub-agent. I always use a
23:30fresh sub-agent. I think that's a much
23:32better practice. So, generally that's
23:34what I'm I'm doing. And then also add a
23:36review.md file
23:38to move any specific things you want to
23:40focus on with your code review. Anytime
23:42you find like persistent problems, put
23:44them into your review.md file, so that
23:46the agent can focus on those in future.
23:48Once you push your change, you want to
23:49make sure that you've got an AI
23:50reviewer. I'm using Code X, and I
23:52sometimes use Code Rabbit and other
23:53tools. There's loads of different
23:54options here. Graptile is another great
23:56one.
23:57Um make sure you tune your review.md
23:59file, automatically run security
24:01reviews, and match the review effort to
24:04the risk. Again, I think this is one of
24:06the main takeaways to remember when it
24:08comes to code review. You don't want to
24:10spend as much time on routine changes.
24:12You want to use human judgment for it
24:13where it's really important. Higher
24:15risk, more important, more significant
24:17changes. You don't want to waste your
24:19human time and attention on really
24:20trivial code changes. Finally, make sure
24:23after you've merged, obviously, you
24:24know, start learning from these changes.
24:27Learn from what fails in your code
24:28review. Learn from what didn't work in
24:30your code review process, and then
24:32continually refine and improve it. So,
24:33my final takeaway from this article is
24:35to make sure that you're using multiple
24:37levels of code review. You can check
24:39quality at many different levels, and
24:42quality comes from iteration.
24:44Even if you're the best developer in the
24:46world, you're still going to make
24:47mistakes. So, you always need to check
24:50your work. You always need to refine it
24:51and iterate. Quality always comes from
24:53iteration. And it's the The thing with
24:55AI agents. It doesn't matter how smart
24:57the AI agents get, you always need to
24:59review the code because chances are
25:01there's something that can be improved.
25:03No one ever gets it right on the first
25:04try. So, this iterative approach to
25:07review, refining, and improving your
25:09code changes is the way that you get
25:11quality at scale. So, verification,
25:14automated checking, AI review, human
25:17review when it's needed, and making sure
25:19that you've got a good process to
25:20continually improve, monitor, and
25:22measure your code review process. I do
25:25recommend measuring and improving your
25:27code review process over time.
25:29Thanks again for watching. If you've got
25:30any questions, do let me know. I'll link
25:32all of the resources and the prompts in
25:34the description below.
25:35Thanks again, and I'll see you in the
25:36next one. Take care.

About this transcript

This page contains the full transcript of How Anthropic Reviews 30,000 Claude Code Changes a Day by Owain Lewis, generated from the public captions YouTube serves with the video. The transcript has 5,602 words across 820 segments, with the original timestamps preserved so you can click any line to jump to that moment in the embedded player.

What you can do with it

Use the transcript to take notes, quote the speaker, build a study guide, generate a summary with ChatGPT or Claude via the YouTube Summary tool, or export it as a timed subtitle file with YouTube to SRT. You can also re-open it in the transcriber to choose a caption track available on the video.

Free YouTube transcript tool

YouTube2Text is a free YouTube transcript generator — no signup, no daily limit. Paste any YouTube link and get the full transcript instantly, with timestamps, click-to-jump, caption language selection, AI prompts for ChatGPT, Claude, and Gemini, and exports to TXT, SRT, VTT, or Markdown.