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? 1000 "PRs" a day on a TUI to wrap a while loop? I'm not going to be a reductionist here so I'm going to cut it off there, I'm positive that the complexity of handling multiple terminal emulators is something that needs some handling (even if doing their own rendering engine was a self made problem). Yes I've vibe coded my own harness from scratch without writing any of it, I still know how it works.

I'm also not sure that they addressed point 2 in any actual capacity? They say "the system verifies itself" which is cool and is something that automated testing has done for decades, but they eschew the mental model of how the system works as a whole and prefer instead to have the LLM focus and summarize a slice of the system when they need to know about it or ask for it. But.... That's not knowledge? That's just search a la google? And thus seems to be subject to the same problems where the quality of your search dictates the quality of your knowledge that you surface at any given time?

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's attention goes where the risk is

> The eval grows with every incident, and every change to the reviewer is scored against all of it.

At 30k commits a day, is there anything that can meaningfully be called review?

Before all came to this, I've been promoting reviews at $dayjob not as gatekeeping but as method to exchange information and build more team spirit. We are an internal service team working by "projects", which makes us a very disjointed team with barely any communication. (Part of it is also German work culture.)

And now this. Suffice to say, my efforts did not bear fruit. I feel more isolated than ever before.

Mfw tui needs a billion prs per day.

Opus 5.5 is obviously stellar but come on what are you doing lol

> Low - Docs, copy, internal-only features, additive changes behind a flag

> None required once automated review and security checks are green

How anybody can let an LLM write docs and not even read them is pure insanity.

And so the wildly unprofitable AI company explains how it token maxes it's code and review process.

Authors should really try and view this article from the perspective of someone who has to think about cost to use the models.

How is the ability of a human to understand the code via hands-on familiarity not a direct dependency of their ability to do manual code review? I don't get it. Having claude write an explainer (something I do a lot!) doesn't get you to the point where you can confidently assess a complex diff. And you've funneled your priors on what the diff says and does through the same system that already reviewed and approved it. This article isn't bad but it doesn't give enough weight to the human context-building part of the problem.

What I’m more worried about is feature identification and how to monitor them. How can you get the product to the next level?

Honestly I’m not worried about code anymore in my codebase I’ve not had bug problems for a while and incidents get fixed automatically.

I monitor new features with an agent who checks recordings.

Most actually good features need still 20-30 iterations to design the userflow to actually be interactive, but then there is also another challenge to translate usage patterns into features and how to present functionality with the least amount of friction as possible.

How to efficiently run monitors without wasting your token spends. A best 'monitor' best practice would be nice.

Still this article was very helpful and gave me a lot of new ideas.

> Security gets its own automated review too. ... You either fix it or close the thread with a short reason, which is how you clear a false positive.

I hope this is only for low-risk false positives. Dismissing a critical finding as a false positive should still involve AppSec.

You could improve revert rates while simultaneously introducing more security vulnerabilities.

And the linked "claude-code-security-review" explicitly states in the README

> This action is not hardened against prompt injection attacks

That's a significant limitation for an AI security review control, no?

All good ideas, I have been doing something similar for half a year. The most important thing is to reduce bugs and ensure the code does what you wanted. Writing code tests, logging, interacting with the running app are essential. For intent realignment I like to have the agent re-read all user messages posted in that project. It only takes a few minutes even on a 10,000 message project. Then use this fresh derivation of user intent to check code and tests. For long spans of work I prefer to generate a todo list which remains as a document in the project. Each closed gate tracks feedback from the agent on what happened. This task file is also reviewed twice - once before implementation and once after. So the formula is - review agents - tests - user message logs.

I'm somewhat surprised they would say Claude is writing 90% of their code at this point. Did they get tired of reporting new milestones, or has there been a plateau?

It looks like they are specifically optimizing for incidents/reverts and shipping faster

> The goal hasn't changed: less human time per change, and no more reverts than before.

Is this Goodhart's law in action? Less reverts and less incidents was measured and became the target. Is this then still a good measure? I guess Revenue is a more direct measure, but we don't have access to that one.

Here I am still unable to stop myself from doing line-by-line code review. I notice too many things (redundant code, duplicate code, overly complex architecture, etc.) by doing it that I feel it would be careless not to.

FWIW, Pangram identifies several sections as 100% AI-written.

Poorly I'm afraid, given how many new bugs make their way to the claude code CLI every update.

what are people using for automated code review these days? the claude code review product originally mentioned it cost "$15-25 per review" (which is absurd), but it seems like they've removed that from their docs with the launch yesterday. we've looked at various products in the space (coderabbit, greptile, etc.) but have gripes with each.

honestly i'm thinking it might be easier (and cheaper) to launch our own agent from GH webhooks and trigger `/code-review`..

That explains why the UI keeps changing.

How is this a proper product? Every time you open the desktop app the buttons may be on a completely random place

Well, that explains the Github repo with 5000 issues, maybe about a third of which are random regressions of previous behavior.

Claude Code is great, but do you really push that much (new) code every day?

Remind me to invest more in the clouds they are burning those tokens in.

I wonder how they maintain the quality of tests for such a massive codebase and frequent commits.

everything is shipped with auto reviews behind a flag. then you need a human approver to launch

good model

If the entire body of this article isn't just an "LGTM" then I know they're lying.

And yet they can't fix the janky bugs when you scroll or show/hide chain of though, commands executed, configuring plug-ins from the options menu etc.

30 thousand changes merged per day? no. like just no. what are we doing? I'm trying to understand

That's a shockingly low number.

90% ?

A random twitter said that, 6 month ago, it was 100% !

DECLINE ! SELL THE STOCK OPTIONS ! (wait, there are none, confused!)

Anthropic's solution to anything is to simply burn more tokens. Because of course.

Anyway, flagging as misinformation.

Title is: How the Claude Code team does code review