388 个 PR 的实践
Key Highlights
Boris Cherny shared on the X platform a fresh experiment in which he connected Claude directly into the day-to-day maintenance workflow of his own application. Simply put, he stopped keeping those repetitive, tedious engineering chores for himself and instead allowed Claude to take them over through a dedicated Slack channel. In just a few short weeks, this automated pipeline opened a total of 388 pull requests, and 180 of those were successfully merged into the main codebase after passing both Claude's own code review and a final human review. The scale of this output is striking because it shows a single engineer can now supervise a machine assistant that produces a steady stream of real, reviewable contributions rather than merely answering questions inside a chat window. The approach reframes what an AI coding partner is for, shifting it from a passive helper into an active maintainer that commits work without being asked each time. For readers who follow the AI coding tool space, this is one of the more concrete demonstrations yet of an agent operating continuously inside a live software project. It is also a useful data point for anyone trying to estimate how much routine engineering labor can realistically be delegated to models in 2026, and it hints at a near future where the typical repository quietly accumulates machine-generated maintenance commits.
What Happened and How It Worked
The entire workflow revolved around a single Slack channel. Boris configured Claude to run three categories of typical maintenance tasks in the background on a continuous basis: crash fuzzing, unification of duplicated code, and removal of dead code. Simply put, these are exactly the kinds of chores inside a code repository that tend to accumulate over time and that human engineers are most likely to neglect because they are low in visible reward. For each change, Claude packaged the work into an independent pull request, then performed its own first pass of code review before handing the result to Boris for a final human confirmation. When Claude occasionally made a mistake, Boris did not need to scrap everything and start over; he only needed to adjust the running routine, and the next day Claude would improve itself based on the previous round. This tight feedback loop is what makes the system practical, because it converts occasional model errors into a cheap, repeatable correction process rather than a blocker. The human role shrinks to setting direction and verifying outcomes, while the machine handles the grind of actually producing and reviewing the edits, which is the part most people least enjoy doing by hand.
Technical Details
The key to this approach is not how smart the model is in the abstract, but how small and how verifiable the tasks are made. Crash fuzzing can automatically surface crashes under boundary conditions and unusual inputs, duplicated-code unification meaningfully reduces long-term maintenance cost, and dead-code removal keeps the repository clean and easy to navigate. Boris observed that Claude usually gets the change right on the first attempt, which suggests that when tasks are structured and their goals are explicit, the model is already quite dependable on this class of engineering work. Smaller, well-scoped units also make review cheaper, since a human can glance at a focused diff and accept or reject it in seconds. The Slack channel acts as both a control surface and an audit trail, so every action the agent took is visible and reversible. In effect, the design trades cleverness for discipline: a modest model, pointed at narrow tasks with clear success criteria, can outperform a more capable model aimed at vague, open-ended goals that are hard to check automatically.
Comparison with Competitors
Compared with traditional CI pipelines where engineers hand-write scripts to periodically scan the codebase, letting a coding agent proactively submit changes in the form of pull requests fuses the two steps of "discovering a problem" and "fixing it on the spot" into one. Unlike relying purely on static tools such as Lint, Claude can understand duplication and redundancy at the level of meaning, so the edits it makes track closer to genuine engineering intent. Other AI coding assistants often stop at suggesting snippets or answering questions, whereas this setup pushes the agent all the way to opening and self-reviewing real pull requests. The difference is meaningful for teams because it changes the unit of work from "a suggestion I must implement" to "a contribution I must merely approve." That shift reduces the human's active effort while preserving the human's authority over what lands in the codebase, which is the balance most engineering leaders actually want.
Industry Impact and Use Cases
For small and mid-sized teams that are short on hands, this pattern of "using an agent as a junior maintenance worker" is quite attractive: it absorbs the most time-consuming busywork and frees human attention for architecture design and product creativity. At the same time it is a reminder that the auto-merge step still needs human oversight, and especially the code-review gate should not be skipped just because an AI is involved. The lesson generalizes beyond one engineer's app: any codebase with a steady tail of small, repetitive maintenance tasks is a candidate for the same treatment. We can expect more teams to experiment with always-on agents that quietly chip away at technical debt, provided they keep a human in the loop for final sign-off and treat the agent's output as a draft rather than a finished, trusted change.