When Claude Handles Routine Maintenance, 388 PRs Shift the Bottleneck to Code Review

Preface

The most noteworthy change for developers is not that Claude opened 388 pull requests in a few weeks, nor that 180 of them were merged, but that the division of labor shifted: AI now performs routine inspection, reproduction, fixing, and PR creation, handing the final merge decision back to humans.

This moves team pressure from “who writes the code?” to “who reviews the code?”. When the generation side can produce a batch of changes in minutes, the main battle moves from code‑completion speed to task boundaries, verification methods, review cost, and merge responsibility.

AI Takes Over the Battlefield Cleanup First

Boris Cherny’s experiment is representative: Claude was tasked with maintaining a family of apps across iOS, Android, desktop, web, CLI, and Agent SDK, each with an independent routine whose progress was synced to a Slack thread.

The tasks are not “redesign a product”. They resemble a senior engineer’s weekly maintenance checklist:

Run the real app in a simulator, repeatedly click until it crashes, locate the cause, and submit a fix PR with reproduction steps.

Scan similar but not identical implementations and merge duplicated abstractions.

Clean dead code: delete unreachable code outright, add logging to uncertain sections for a day, then decide whether to delete.

Fix abstraction leaks, remove always‑passing tests, investigate flaky test failures.

Remove feature flags that have been fully rolled out from the code base.

The key insight is that AI excels at “verifiable” work: reproducible crashes, stable test failures, duplicate detection, and log‑driven checks. In contrast, judging whether an abstraction is elegant or a refactor worthwhile remains difficult for the model.

When Generation Gets Cheaper, Review Becomes Costlier

The first stage of AI‑assisted coding focuses on speed of writing. The second stage shifts the problem to stability of merges.

Data from Faros AI illustrate this shift: with high AI adoption, per‑person epic completion rose 66.2%, task throughput rose 33.7%, and PR merge rate rose 16.2%, while weekly deployments fell 11.7%.

More code enters review, but that does not automatically translate into more reliable production changes. Defect and rework metrics worsened: bug count per developer rose 54%, incidents per PR rose 242.7%, code deleted after merge rose 861%, and median time awaiting human review rose 441.5%.

These figures indicate that AI turns “writing code” from a scarce resource into a high‑output one, yet review, validation, and deployment decision‑making have not scaled accordingly. Introducing generation tools without redesigning the review process quickly overwhelms teams with AI‑generated PRs.

Routines Are the Core Asset of This Approach

The most valuable lesson from the experiment is not a specific prompt but the operational model of Routines.

A Routine is a “long‑running engineering prompt”: a one‑time configuration that specifies the task description, code repository, connectors, and trigger method, then runs automatically on a schedule, via API, or on GitHub events. It executes on Claude Code’s cloud infrastructure and does not require a continuously online local machine.

Boris’s practice: when a certain class of PR repeatedly fails, instead of fixing each failure individually, he revises the Routine that generates those results and observes the outcome over subsequent days. Thus prompts become versioned engineering assets, similar to CI configurations, deployment scripts, or alert rules.

This changes how teams use AI: ad‑hoc queries rely on personal expertise, but sustained maintenance requires versioned rules—task goals, allowed modification scope, verification commands, rollback procedures, log‑observation periods, PR templates, and reviewer assignments—all encoded in a Routine or its side‑constraints.

Where Claude Code Really Belongs

Claude Code’s strengths lie in cross‑file understanding, patch generation, command execution, error inspection, and iterative improvement. It fits best in existing repositories for tasks with clear boundaries and verifiable outcomes, such as test completion, type fixes, duplicate code consolidation, small‑scale refactoring, documentation sync, and script repairs.

To integrate it into a team workflow, start with low‑risk maintenance tasks rather than core business paths. Repository permissions should be layered: read‑only analysis, branch creation, test execution, PR creation, and deployment triggering as five distinct levels.

Official subscriptions pose payment and network hurdles for Chinese developers. Teams that only need to plug Claude or GPT models into their toolchain can use Code80 as a more convenient API gateway, focusing first on model integration and permission boundaries rather than full automation.

FAQ

Does this mean programmers only have a “merge” button left?

No. Programmers shift from writing every line to defining tasks, setting boundaries, reviewing results, and bearing deployment responsibility. Signing off is not a formality; it is the final engineering accountability.

Which tasks are best to hand over to an AI Routine first?

Prioritize tasks with clear acceptance criteria: crash reproduction, dead‑code cleanup, duplicate implementation merging, stable test failure investigation, documentation/code synchronization, and feature‑flag removal. Avoid architecture decisions, core permission logic, or complex performance optimizations initially.

With many AI‑generated PRs, how should Review change?

Introduce PR grading for AI output. Low‑risk mechanical changes go through a fast lane; high‑risk changes require a human owner review. PRs must include reproduction steps, verification commands, impact scope, and rollback plans; otherwise speed merely shifts cost.

How can a domestic team start trying this workflow?

Pick a non‑core repository, connect the model to a restricted branch that only creates PRs (no direct merges). Use the official channel or a proxy like Code80, and design logging, testing, and permission schemes first.