All 388 PRs are fully AI-authored, 180 of which have already been merged. The father of Claude says the only remaining task for programmers is to sign off.
388 PRs were submitted, 180 of which have been merged.
All these lines of code were written entirely by AI.
Boris Cherny, the father of Claude, recently posted this set of figures on X. They come from a "strange experiment" he has been running for the past few weeks: letting Claude take over the daily maintenance of his own app.
He said that based on some early signs, this approach might actually work.
The experiment was conducted in a Slack channel named "proj-claude-maintains-apps".
In this channel, Claude Tag runs a set of routine tasks every day covering six environments: iOS, Android, desktop, Web, CLI, and Agent SDK. Each line has an independent routine, and the progress of each is posted to the top-level thread of the channel separately.
Just like a real colleague, it doesn't wait for others to assign tasks, it "shows up for work" on its own at the scheduled time, identifies problems, modifies code, submits PRs, and then waits for human review.
This closed loop of regularly identifying problems, submitting modifications, undergoing reviews, and adjusting task rules based on feedback has been running inside Anthropic for several weeks.
All that engineers need to do is click a button to decide whether to merge the PR or not.
Claude Goes to Work Every Day, Handling All the Grunt Work
What kinds of tasks did Boris assign to Claude? Let's look at the list first.
Crash Inspection.
Open the app in the simulator and click around randomly until it crashes, then locate the cause, create a fix PR, and attach reproduction steps and a truth table to each PR.
Boris also specifically added a note in Claude's original instructions: the running instance must be the real app, no fake stand-ins are allowed to cut corners.
Duplicate Abstraction Merging. Scan the codebase for implementations that look similar but are not exactly the same, and submit PRs to merge them into a unified version.
Dead Code Cleanup. This task requires the most proficiency: code that can be statically confirmed to be unreachable is deleted directly; for code that is only "suspected" to be unreachable, add a log entry to observe it for one day, and delete it the next day after confirming no one has accessed it.
Abstraction Leak Fixing. It will fix any exposed layers that should not have been leaked out.
Other tasks include: clearing tests that always pass no matter how they are run, finding out the root cause of flaky tests that sometimes pass and sometimes fail, removing full rollout switches from the codebase, and deciding whether to release or delete forgotten internal features based on their usage volume.
Adding a log to observe for a day before deletion is the kind of experienced judgment that only veteran engineers have.
Scanning through the entire list, none of the 11 tasks taken over by Claude are about "building something new".
All of them are the kind of tasks that people are usually most reluctant to do, that bring no performance rewards after completion, and that no one will urge you to finish even if you delay them to the next quarter.
Code Writing Gets Cheaper, Code Review Gets More Expensive
A team gets 388 AI-generated PRs in a few weeks, who will review them?
Anthropic gave a figure in its Code Review announcement in March this year: over the past year, the company's per capita code output has increased by 200%, and code review has consequently become a bottleneck.
Moreover, this is not a problem exclusive to Anthropic.
Engineering data platform Faros AI released a report in 2026, based on two years of telemetry data covering 22,000 developers and more than 4,000 teams.
Faros AI The Acceleration Whiplash: Under high AI adoption, per capita epic completion volume increased by 66.2%, while the number of weekly deployments decreased by 11.7%.
The output side has indeed grown: the number of epics completed per capita increased by 66.2%, task throughput increased by 33.7%, and the PR merge rate increased by 16.2%.
However, the number of actual weekly deployments to production decreased by 11.7%.
More PRs are merged, but fewer are released. The entire middle link is blocked at the review stage.
The cost has to be borne by developers.
The number of bugs per developer increased by 54%;
Online incidents corresponding to each PR increased by 242.7%; the proportion of code that was merged and then deleted increased by 861%; the average size of PRs increased by 51.3%;
The most critical issue is the waiting time.
The median waiting time for a reviewer to process a PR increased by 441.5%, and 31% more PRs were merged without going through any review at all.
Putting all these numbers together, this is a developer's typical day: press a button to generate thousands of lines of code in five minutes; then spend the entire afternoon reading these thousands of lines line by line.
The code writing part has been taken over by AI, but the code reading part still has to be done by developers.
Code Review is designed to solve this problem. Anthropic has released a set of data on effects and costs:
Before deployment, only 16% of PRs can get substantial review comments, and this figure rises to 54% after deployment.
84% of large PRs with more than 1000 lines can be found with an average of 7.5 issues; for small changes under 50 lines, this proportion drops to 31%, with an average of 0.5 issues.
Fewer than 1% of the findings marked by engineers are "false positives".
Reviewing one PR takes an average of 20 minutes, consuming 15 to 25 dollars worth of tokens.
The announcement also mentions that this system does not approve PRs, approval is the responsibility of humans.
The boundary it sets is: AI can actively find problems, modify code, and create PRs, no human approval is required throughout the whole process. But every change stays in the PR, whether it is merged into the main branch and deployed online, the final confirmation click must be done by a human.
Boris wrote in his post about the next step: find ways to reduce the merging cost of this kind of mechanical changes.
What he wants to reduce is the merging cost, because the bottleneck is no longer on the generation side.
What Boris is Fixing is Not PRs, But Routines
Let's take a look at how this system is built, the division of labor for the three components is very clear.
Claude Tag is the entry point. It resides in the Slack channel, responds when mentioned, and also actively takes on tasks within the scope of permitted permissions and instructions.
Anthropic just upgraded it on August 13, allowing it to judge when to take action and when to stay still based on the full context of the entire channel.
Routines are the execution layer.
This is a feature launched on April 14: configure prompts, code repositories and connectors once, then run on a schedule, be triggered by API calls, or start automatically in response to GitHub events.
It runs on Claude Code's cloud infrastructure and does not depend on local devices.
Operating mechanism of Claude Code Routines: three triggering methods of scheduled execution, API call and GitHub event, running in the cloud.
Claude Code Review is the review layer, and humans are the approval layer.
These four layers are connected in series to form that channel that automatically starts work every morning.
But the most valuable part to learn is Boris's tuning method.
When a certain type of PR keeps failing to pass review, he does not modify those failed PRs one by one, instead he goes back to modify the Routine that generates them, then observes the performance in the following days.
Sometimes it takes several consecutive days of tuning for a certain type of task to become stable.
In one sentence: don't fix the results, fix the rules.
Prompts are no longer one-time inputs here, but a set of assets that require long-term operation and maintenance: write, launch, observe, iterate, which is no different from maintaining an online service.
This is also the reason why this system can run more and more smoothly.
Every adjustment is precipitated into the rules, and there will be fewer unreasonable PRs in the batch generated the next day.
If You Want to Replicate It, You Have to Pass These Barriers First
The tool layer is publicly available.
Routines are open to Pro, Max, Team and Enterprise users: 5 for Pro per day, 15 for Max, 25 for Team and Enterprise. You can create it with a few clicks in claude.ai/code, or type /schedule in the CLI.
But the real thresholds lie elsewhere:
To what extent are you willing to grant repository permissions, whether your test coverage is sufficient to support this practice, whether you have a simulator environment that can run real devices, whether you can afford the cost of token consumption for each review, and the hardest part: whether someone is willing to press the merge button for a PR submitted by AI.
Also this month, the Rust project just set rules for AI contributions: AI-generated code must be notified in advance, cannot touch critical paths, must have sufficient tests, and must truthfully disclose that large models are used; critical changes involving soundness are strongly not recommended to be generated by large models.
The most important rule is that maintainers are not obliged to review AI-submitted PRs, and can close them directly.
The individual developers can also copy this rule from Boris's experiment: first hand over the type of tasks with the clearest acceptance criteria to AI.
Tasks whose correctness can be verified are well within AI's current capabilities: whether the operation can crash the app, whether two pieces of code implement the same logic, whether this test will never fail, all these can be verified on the spot.
Tasks where it's hard to define what counts as "done correctly" are still beyond AI's capabilities: "is this abstraction layer over-designed", "is this refactoring direction correct", the acceptance criteria for these depend entirely on personal preference and cannot be written into prompts.
So the first batch of tasks it takes over are not creation work, but cleaning work.
The generation side already has sufficient production capacity, what is missing is the review side: who reviews first, what content is duplicated, and who signs off in the end.
The value of engineers is also measured by a new set of metrics: in the past it was about how fast you can write code, now it's about how fast you can review code.
References:
https://x.com/bcherny/status/2088014489438621990?utm_source=chatgpt.com
https://pages.faros.ai/hubfs/AI_Engineering_Report_2026_The_Acceleration_Whiplash_Faros.pdf
https://blog.rust-lang.org/inside-rust/2026/08/05/rust-langrust-is-adopting-an-llm-policy/
This article is from the WeChat official account "AI Era", author: ASI Revelation, authorized for release by 36Kr.