Boris Cherny is testing whether Claude can handle routine software maintenance through a dedicated Claude maintenance workflow managed in Slack. The system runs daily routines across iOS, Android, desktop, web, CLI, and Agent SDK codebases, opening pull requests for engineers to review.
The workflow operates from a Slack channel named proj-claude-maintains-apps. Among the routines are:
- Crash fuzzer: Opens real apps in simulators, taps through them without mocks, identifies crashes, investigates their root causes, and proposes fixes.
- Dup unifier: Finds similar but divergent abstractions and consolidates them.
- Dead-code remover: Deletes probably unreachable code, while adding logging to questionable cases before removing them in a later run.
- Logic bugfixer: Models difficult business logic to identify and fix edge cases.
- Logic simplifier: Reworks convoluted business logic.
- Flaky-test fixer: Investigates the causes of unreliable continuous-integration tests.
- Useless-test pruner: Removes tests that cannot fail.
- Shipped-feature inliner: Removes flags from features that are fully shipped.
- Abstraction improver and abstraction police: Simplifies over-engineered abstractions and addresses layering violations.
- Ant-only shipper: Ships or deletes forgotten internal-only features based on usage.
According to Cherny, the routines opened 388 PRs across the repositories over several weeks. Of those, 180 were merged after Claude Code Review and human review. That leaves 208 PRs that had not been merged at the time of his post, although Cherny clarified that many had simply not been reviewed yet. He estimated that roughly one in 50 generated changes was noise, with the routine responsible tuned afterward.
Cherny characterizes the proposed changes as generally small and self-contained, supported by extensive testing. He claims Claude usually produces a correct PR on its first attempt. When it does not, the routine’s instructions are adjusted for subsequent runs, sometimes over several days.
The crash-fuzzing workflow has additional requirements intended to make its findings testable. Cherny’s prompt asks for separate daily routines for iOS, Android, and desktop apps, each running the real application end to end. Every resulting PR must run /verify, include a reproduction and truth table, and receive progress updates in a top-level Fuzzer thread in Slack.
lets start new daily routines for crash fuzzing ios, android, and desktop apps e2e. make routines for each that use workflows to run the real apps (no mocks) and fuzz them to trigger crashes, then put up fix prs for those crashes. each pr must run /verify and post a repro and truth table to the pr. post updates in a new top level Fuzzer thread in this channel
Cherny later provided the prompt as an example of how little detailed instruction he believes modern models require for these tasks. He also maintains that agent-based work complements conventional static tooling: dead code can sometimes be identified by tools such as Knip, but the routine is intended to cover cases that are not statically analyzable.
The model choice varies by task. Cherny states that Opus handles most of the routines, while Fable is reserved for a few difficult ones. He also claims Sonnet could handle many of the jobs, provided engineers spend more time auditing PRs, refining prompts, and adding checks and guardrails.
Human review remains part of the process. Cherny described the merged changes as having gone through both Claude Code Review and human review, and noted that the team is considering ways to make mechanical changes easier to merge without removing those checks.
The results are Cherny’s account of an internal experiment rather than an independently verified assessment of the resulting code or applications. Still, the workflow points toward a relatively narrow use of coding agents: recurring maintenance tasks that produce small, reviewable changes, rather than unsupervised changes to major product features.
Source: X
