The team describes a workflow where every PR gets a Claude-generated review first, but humans still make final decisions. The explicit framing is that AI handles the mechanical surface-level pass so humans can focus on architectural judgment, intent, and approach — not that AI replaces review entirely.
By submitting this writeup to HN where it earned 282 points, the submitter surfaced it as a workflow document worth attention. The high engagement (259 comments) suggests the community found the augmentation framing — rather than a replacement pitch — the newsworthy angle.
The post deliberately avoids headline metrics like 'caught X% more bugs' and instead specifies exactly where the model fails: architectural judgment, cross-file reasoning, and anything requiring context outside the diff. This candor from a team dogfooding their own product is positioned as more valuable than vendor-style benchmark marketing.
For auth, billing, and model-serving code, the team mandates human review and explicitly treats Claude's output as advisory only. This carve-out acknowledges that even a well-functioning AI reviewer shouldn't be trusted as a gate on high-stakes changes where the cost of a miss is disproportionate.
The team behind Claude Code — Anthropic's own CLI-based coding agent — published a writeup of how they run code review internally. The short version: every pull request gets a Claude-generated review before a human looks at it, and the human reviewer treats that output as a first pass, not a verdict. The post is less a product pitch than a workflow document, which is why it hit the HN front page with 282 points and spent most of the day there.
The setup, as described: PRs trigger an automated Claude review that comments inline on the diff. It flags style issues, probable bugs, missing tests, and anything that looks inconsistent with nearby code. The human reviewer then opens the PR, reads Claude's comments, and does their own pass — usually faster, because the obvious stuff is already surfaced. For sensitive paths (auth, billing, anything touching the model-serving layer), a human review is mandatory and Claude's output is treated as advisory only.
There are no magic benchmark numbers in the post. No "we caught 40% more bugs" line. The team is specific about what the model is good at — surface-level consistency, test gaps, obvious logic errors — and specific about where it still faceplants: architectural judgment, cross-file reasoning about intent, and anything requiring context that isn't in the diff.
Most writeups about AI code review come from vendors selling AI code review. This one comes from a team that ships a product, has deadlines, and has to live with the consequences of their own tooling. That makes the honest parts more useful than another benchmark table.
The practical insight: Claude Code's team doesn't use AI review to replace human review — they use it to change what human review is for. The human stops being the person who notices you forgot a semicolon or that your test file is missing an edge case. The human becomes the person who decides whether the approach is right, whether the abstraction is going to bite you in six months, and whether the change actually belongs in this codebase at all. That's a better use of a senior engineer's time, and it's also the kind of judgment the model is still bad at.
The HN discussion zeroed in on two things. First, the question of whether the model's review becomes a crutch — if the human reviewer trusts the AI pass too much, they stop looking for the things the AI misses. Several commenters pointed out that this is the same failure mode as over-trusting a linter, just with higher stakes. The team's answer, implicit in the post: assign specific humans to specific risk categories and don't let the AI pre-pass count for those.
Second, the discussion of what the model actually catches. The post is refreshingly concrete here. Claude is reportedly good at: spotting when a new function duplicates logic that already exists in the repo, flagging missing null checks in languages that let you get away with it, noticing when a test file was added but doesn't actually assert anything meaningful, and catching import drift. It's reportedly bad at: understanding why a weird-looking piece of code is weird on purpose, reasoning about concurrency, and anything that depends on knowing what a user is trying to do rather than what the code is doing.
That split — tactical competence, strategic blindness — is probably the most accurate description of frontier model coding ability anyone has published this year. It matches what most practitioners are seeing in their own tooling, and it's a useful corrective to both the "AI will replace engineers" and "AI review is useless" camps.
If you're thinking about adding AI review to your own PR flow, the Anthropic writeup is close to a reference implementation. The specific moves worth copying:
Run the AI pass first, not last. A review bot that comments after a human has already approved is just noise. One that comments before the human reviewer opens the PR actually reduces human load, because the obvious items are already addressed by the time a person shows up.
Scope what the model is allowed to be authoritative about. Style, test coverage, obvious bugs — fine. Architecture, security, API contracts — advisory only, and name the humans who have to sign off. This is the part most teams skip, and it's the part that keeps the AI pass from becoming a rubber stamp.
Measure the right thing. The team doesn't claim they're catching more bugs. They claim their human reviewers are spending time on higher-value feedback. If you're going to A/B this at your org, measure review latency and the quality of the human comments, not the raw count of issues flagged.
One caveat the post doesn't address but your legal team will: a lot of orgs can't send proprietary code to a third-party model without careful contracting. Anthropic can run Claude on Claude's own repo because it's Anthropic. Your mileage will vary, and the self-hosted or VPC-deployed version of this workflow is still awkward for most teams.
The interesting question is whether the next generation of coding models can start crossing the tactical/strategic line — reasoning about intent, catching the subtle architectural problem, understanding why a piece of code is the way it is. The Anthropic team's own writeup suggests they're not there yet, which is both honest and informative. For now, the right mental model for AI code review is a very fast, very thorough, slightly literal-minded junior engineer who should never be the last pair of eyes on anything that matters. That's genuinely useful. It's also not the pitch you usually hear.
This is like one of Google’s infrastructure blog. Google scale things are only relevant and appropriate for them. We had lots of bitter lessons from smaller engineering teams following the process with the justification that “this is how Google does it”.Similarly, Anthropic can afford to do this bec
I saw someone say the other day (in response to another blog post being well written) that Anthropic employees have a rule against using AI for writing/external comms? That seems clearly not the case here, normal people don't write like this:> Most of the path is automated; a person
No human can stay on par with 30k pull requests per day ... they simply don't have control on what's going on and rely on AI itself to do the job.PS: I really want to know what is the churn rate (and the cost per LOC) here. My gut is saying the cost per LOC is insane, and they are basicall
Anthropic has amazing models. But they should really stop commenting on software practices. Most of what they say seem out of touch with what's happening in software shops. A lot of it seems hype driven. And the entire message looks to be written by AI.
Top 10 dev stories every morning at 8am UTC. AI-curated. Retro terminal HTML email.
No wonder most people at Anthropic believe our jobs are in jeopardy, they've already made a system wherein the machines are treating them like pets.I really don't get the tendency here from Anthropic to describe what's most likely churn? A high pressure amount of changes/PRs a da