Claude opened 388 maintenance PRs in weeks: AI coding takes on the backlog

On August 14, 2026, Claude Code lead Boris Cherny shared an experiment that had already been running for several weeks.

Instead of asking whether Claude could build another application from scratch, he placed it in one of the least glamorous and most frequently postponed parts of software development: routine maintenance.

Claude received tasks from a Slack channel, ran crash fuzzing, consolidated duplicate code, removed dead code, and packaged its changes as pull requests. Over several weeks it created 388 PRs. Of those, 180 were merged after Claude Code Review and human review.

These figures describe Boris's own workflow; they are not a performance guarantee from Anthropic. Nor do 388 PRs mean 388 successful fixes. The 180 merged PRs represent about 46% of the total. The remaining PRs may still have been under review, unnecessary, duplicated by other work, or below the merge threshold. The original post did not provide a detailed breakdown.

Even with those limits, the experiment matters. AI coding has usually happened while a developer watches a chat window: a person requests a change, the agent edits code, and the person follows up. Boris pushed the workflow one step further. The team defined recurring tasks, acceptance criteria, and permission boundaries; Claude ran them on a schedule; engineers reviewed only the results that reached the approval gate.

What changed was Claude's position in the team

Asking Claude to write one function produces a bounded result. Maintenance has no natural endpoint.

Repositories change every day. New duplicate logic appears, retired features leave dead code behind, dependency upgrades introduce compatibility problems, and tests drift away from the product. Human teams routinely postpone this work.

Boris's setup looks more like a continuously running maintenance pipeline:

Slack / GitHub / schedules identify maintenance work
                         ↓
Claude analyzes the issue in a restricted repository and environment
                         ↓
It edits code and runs tests, type checks, or reproduction scripts
                         ↓
It opens a PR with evidence, impact scope, and rollback notes
                         ↓
Claude Code Review performs the first review pass
                         ↓
An engineer merges, returns, or closes the PR

Humans still plan and approve; the agent executes.

Anthropic observed a similar division of labor in a separate study of roughly 400,000 Claude Code sessions. In a typical session, people made about 70% of planning decisions while Claude made about 80% of execution decisions. These percentages are not a fixed formula, but they help explain why maintenance is a good agent workload: people define what to inspect and what qualifies for merging; Claude performs the search, editing, and verification.

Maintenance tasks that fit Claude well

The ability to open PRs does not make every engineering task suitable for automation. Initial tasks should have four properties: a clear scope, machine-verifiable results, reversible changes, and limited impact if they fail.

1. Duplicate-code cleanup

An agent can scan for similar implementations, determine whether they can share a utility, and list every replaced location in the PR.

Acceptance criteria are relatively clear: tests pass, public interfaces remain stable, and duplication decreases. The main risk is that business logic that looks similar may not share the same semantics. Start inside one module rather than abstracting across domains.

2. Dead code and obsolete configuration

Retired feature flags, unreferenced functions, legacy settings, and deprecated scripts are strong candidates for periodic checks.

The agent must inspect static references, dynamic loading, and deployment configuration. A single text search is not enough. Each PR should state which entry points were checked so reviewers can assess reflection, plugin, and runtime-call risks.

3. Regression tests and failure attribution

When a bug has stable reproduction steps and a clear expected result, an agent can add a regression test before changing the implementation.

For intermittent failures, it can aggregate repeated runs, environment details, and stack traces, then open an investigation report instead of editing production code. The crash-fuzzing work Boris described fits this category.

4. Documentation synchronization

Documentation often falls behind when API parameters, environment variables, or CLI commands change. An agent can inspect README files, examples, and migration notes whenever code changes.

Anthropic's 2026 AI Agent report says Doctolib embedded Claude Code in CI using headless mode so code changes could trigger documentation updates. It also built a centrally managed repository of prompts, commands, and subagents instead of asking every engineer to configure the workflow independently.

5. Low-risk dependency updates

Patch releases, lockfile updates, and well-defined security fixes can enter the candidate queue. The agent should run the full test suite and separately summarize changelog items relevant to the project.

Major framework migrations, database-driver upgrades, and authentication dependencies are poor first unattended tasks. They require migration design and staged validation.

6. CI, lint, and type-error repair

Formatting, typing, and reproducible CI failures have natural machine acceptance criteria. An agent can read the failure log, locate the change, and rerun the checks.

Claude Code also offers PR auto-fix capabilities for CI failures and review feedback when the repair path is clear. Automated repair should never bypass existing branch protection or required checks.

Three permission levels work better than “manual or fully automatic”

Teams often begin at one of two extremes. Requiring confirmation at every step creates approval fatigue. Granting write access and automatic merging makes a single mistake potentially expensive.

A safer approach divides work by impact:

Permission level	What the agent may do	Typical work	Human role
Green	Read, analyze, run read-only checks, create reports	Duplication reports, test gaps, dependency inventories	Decide whether editing should begin
Yellow	Create branches, edit code, run tests, open PRs	Dead-code cleanup, documentation sync, lint fixes	Review before every merge
Red	Propose only; no direct execution	Data migrations, permissions, billing logic, production configuration	Design, implement, and perform two-person review

Use only green tasks in the first week. After outputs become stable, promote one or two tightly specified tasks to yellow. Claude can analyze red tasks, but it should not receive production write access.

A reusable maintenance Routine needs six elements

Claude Code Routines can run in Anthropic-managed cloud environments on schedules, API requests, or GitHub events. Because they run autonomously, their task descriptions cannot depend on asking a person for missing details halfway through.

# Task
Inspect src/payments for unreferenced internal functions that have no calls
in the last 30 days and no dynamic-registration marker.

# Allowed scope
- Read and modify only src/payments and tests/payments
- Run unit tests, type checks, and static-reference analysis
- Create only claude/* branches and pull requests

# Prohibited operations
- Do not change database schemas, permission policies, or payment state machines
- Do not access production, real secrets, or customer data
- Do not merge automatically or push directly to main

# Acceptance criteria
- Full unit test suite passes
- Type checks and lint pass
- Every deletion lists static, dynamic-loading, and config-registration checks
- Public interfaces remain unchanged

# Failure handling
- If evidence is insufficient, stop editing and produce an investigation report
- If tests are flaky, retain logs and state the reproduction count
- Change no more than five files per run; split larger work into separate PRs

# Every PR must explain
- Why the change is needed
- Which files changed
- Which validations ran
- What uncertainty remains
- How to roll back

Failure handling is the most frequently omitted section. When an unattended agent encounters ambiguity, guessing forward is dangerous. Allowing it to stop and submit an investigation report often saves more review time than forcing it to produce code.

PR count measures activity, not quality

The number 388 is memorable—and dangerous as a target. If an agent is evaluated on weekly PR volume, it may split changes artificially or produce low-value cleanup.

Track at least four additional metrics:

Metric	Calculation	What it reveals
Effective acceptance rate	Valid merged PRs / reviewed PRs	Whether the discovered work was worth doing
First-pass rate	Merged PRs requiring no rework / merged PRs	Whether instructions and validation were sufficient
Human review time	Median time from review start to decision	Whether the agent reduced human work
Rollback and incident rate	Merged PRs rolled back or linked to incidents / merged PRs	Whether automation shifted risk into production

Also track duplicate PRs, no-change PRs, inadequate testing, and out-of-scope edits. Each points directly to a Routine rule that needs improvement.

Boris said Claude completed many changes in one pass. When a routine performed poorly, he changed the rules so the next day's run could incorporate what the team learned. The system—not just the prompt—must keep improving.

A seven-day pilot

You do not need to reproduce 388 PRs. One repository, one task type, and one week are enough to expose most workflow problems.

Day 1 — Choose the task. Start with documentation sync, lint repair, or test-gap reporting. Avoid production permissions and data structures.

Day 2 — Establish a baseline. Complete one example manually and record time, checks, and common omissions. This becomes the agent's acceptance standard.

Day 3 — Generate reports only. Do not allow edits yet. Check accuracy, duplication, and false positives.

Day 4 — Permit branches and PRs. Restrict directories, file counts, and command allowlists. Do not permit merges.

Day 5 — Add machine gates. Require unit tests, type checks, lint, security scans, and relevant regression scripts.

Day 6 — Measure human cost. Record reviewer time. Fast PR creation is not useful if review becomes slower.

Day 7 — Change only one or two rules. Fix the most common false positive or scope violation before expanding frequency or repository coverage.

Do not mix Claude Code Routines with a self-hosted API agent

Choose the execution environment first.

Claude Code Routines are an Anthropic-managed capability. They can bind repositories, connectors, and triggers and continue running while a developer's computer is off. Anthropic also warns that Routines run autonomously and connected tools may perform writes, so branch-push permissions and network access should follow least privilege.

Teams that need direct control over scheduling, containers, model routing, budgets, and logs can build a maintenance service with an Agent SDK or model API:

GitHub / CI / scheduler
        ↓
Self-hosted orchestration and permission policy
        ↓
Model API access layer
        ↓
Isolated execution environment
        ↓
Tests, code review, and human-approved merge

In the second path, Code0 is a multi-model API gateway in the model-access layer. One key can access 300+ models while centralizing the Base URL, model switching, request records, and cost management. Use the models and interface capabilities currently shown in the console.

API endpoint: Primary API with U.S. CN2 GIA acceleration: https://code0.ai

Applications moving from an older endpoint generally update the request address while retaining the rest of their configuration. Still rerun authentication, streaming, tool-use, timeout, and retry tests in a non-production environment. A domain-only change does not remove the need for regression testing.

Code0 cannot replace GitHub branch protection, execution sandboxes, code tests, or human review. Model access controls the entry point; engineering gates determine whether code is safe to merge.

The reusable lesson behind 388 PRs

Boris's experiment did not prove that AI can independently run a software project. The 180 merged PRs show that agent output still requires selection.

It demonstrates a more realistic path: developers turn repetitive, verifiable maintenance tasks into Routines; agents scan, edit, validate, and submit; code review and engineers guard the merge boundary; operating data improves the rules.

New features still need product judgment and architecture. But the recurring backlog items that are individually easy and perpetually postponed are ready for an agent's first pass.

FAQ

Does 388 PRs mean Claude successfully fixed 388 problems?

No. Claude created 388 PRs; 180 were merged after Claude Code Review and human review. The original post did not classify the rest as pending, closed, duplicated, or failed, so 388 is not a success count and 180/388 is not a model-accuracy score.

Which projects should try automated maintenance first?

Projects with good tests, clear branch protection, isolated execution, and repetitive maintenance work are easier starting points. Legacy systems with limited tests, production-data dependencies, or extensive dynamic behavior should improve validation before permitting automated edits.

Can the agent merge PRs automatically?

It can be configured to do so, but this is not recommended during an initial pilot. First observe effective acceptance, rollback rate, and human review time. Any later auto-merge scope should remain low risk and retain required CI, branch protection, and rollback mechanisms.

Does Claude Code Review replace human code review?

No. It uses multiple agents to inspect logic bugs, security issues, edge cases, and regression risks, then validates and deduplicates candidate findings. Anthropic's documentation states that its findings do not automatically approve or block a PR. Project members still own business logic, product impact, and release decisions.

Do teams still need their own cost and call monitoring with Code0?

Yes. Platform records help expose model calls and usage, but the project should also record task ID, repository, runtime, token use, failure reason, and final merge outcome. Only by linking model cost to delivered results can a team decide whether a Routine is worth running long term.

Should every maintenance task use the same model?

No. Reporting, classification, and simple static checks can use lower-cost models. Cross-file analysis, complex test repair, and code review may justify stronger reasoning models. Compare candidates on the same real tasks using effective acceptance, rework, and total cost per merged PR.

References

Third-party platform disclaimer: Code0 is an independent third-party multi-model API aggregation service and is not affiliated with Anthropic, GitHub, or any other platform mentioned here. Models, pricing, quotas, regional availability, and interface compatibility are subject to the Code0 console and the relevant model provider's current rules. Test with limited traffic in an isolated environment before production use and comply with applicable service terms, code-security requirements, and data policies.

Note: The figures of 388 created PRs and 180 merged PRs come from Boris Cherny's public account of his personal workflow around August 14, 2026. Results will vary with repository quality, test coverage, task design, model choice, permissions, and review processes.