A 24/7 Claude Code Agent Merged a Real Open-Source PR. Here Is How.

An AI agent ran for twelve straight days on a Mac Mini, operated nearly around the clock, taught itself a GitHub skill, found a trending open-source repository, read its contributing guide, identified a logger deduplication problem hiding across three separate files, forked the repo, wrote the fix, opened a pull request, and had it merged by a volunteer maintainer who described the change as a textbook refactor with net-negative lines and no regression. Then the person running the experiment shut the behavior off immediately.

I am Madhuranjan Kumar, and both parts of that sentence carry equal weight. The merge is impressive. The decision to stop is equally important. Together they form the most honest account of what autonomous AI agents can and should do right now, and the method that produced the merge transfers directly to business operations that have nothing to do with open-source software.

The agent read the contributing guide before touching a single file

The most important step in the entire experiment is the one most accounts of it undercount. Before the agent changed a single file, before it even looked at the repository's code, it opened the project's contributing guide and read it completely. This is not a procedural footnote. It is the move that shaped everything the agent did afterward.

Contributing guides are the social contract between a project's maintainers and everyone who wants to add to it. They specify what kinds of changes the team welcomes and what to avoid, how to format a pull request, what the review process looks like, and sometimes what the project's longer-term direction is. This particular guide said the project accepted bug fixes and code simplifications but was not looking for new features from outside contributors.

That single constraint changed the shape of the agent's entire search. An agent that skipped the guide would have looked for interesting problems to solve, and it likely would have found some. But interesting problems in an active codebase usually lead toward new capabilities, and new capabilities were precisely what this project's volunteer maintainers did not want to review. The agent that read the rules first looked for something fundamentally different: duplication to remove, inconsistency to standardize, structure to simplify without changing runtime behavior.

The agent had been given a reusable GitHub skill before the experiment began. A skill in this context is a set of instructions the agent invokes whenever a task requires navigating a particular tool. This one covered how to browse GitHub's interface while logged in and how to use the command line for version control operations including forking, branching, committing, and pushing. The skill did not produce the useful result on its own. The combination of the skill and the instruction to read the contributing guide before taking any action is what produced it.

After reading the rules, the agent did not immediately begin changing code. It read the open issue tracker next, scanning every thread to understand what was already being worked on. Most issues had recent activity on them. Someone had already claimed the work, or a maintainer had responded with specific direction. The agent recognized those as occupied territory and moved past them rather than creating a duplicate effort that would generate noise without generating value. It then explored the codebase directly for cleanup opportunities the issue tracker had not yet surfaced.

This three-step sequence, read the rules, check what is already in progress, find a gap that is genuinely open, is the pattern that distinguishes useful autonomous behavior from automated noise. The agent was not executing a rigid script. It was following a goal filtered through a constraints document, which is the setup that produces trustworthy behavior at low supervision.

Three files with identical logger code gave the agent a clear and safe target

The duplication the agent identified was simple and textbook in the best sense. Three separate files in the repository each contained an identical block of logger configuration code. This category of technical debt is among the most common in codebases that have grown organically over time. When the same configuration appears in multiple places, every future change requires finding all the copies and updating each one separately. If a copy gets updated while another does not, behavior diverges in ways that are difficult to debug because the code appears correct in isolation.

The correct fix is not complicated. Move the shared configuration into a single module and have all three files import from it. Total line count goes down. The duplication disappears. Future maintenance becomes simpler because there is exactly one place to change. Nothing about the runtime behavior changes in any way. The application executes identically before and after the refactor. The only difference is structural, and the structure after the change is unambiguously cleaner than what it replaced.

The agent forked the repository, made this change, and wrote a pull request description explaining what changed and why. The description matched what the contributing guide implicitly expected in tone and format. The pull request was minimal, coherent, and fully verifiable. The maintainer's review job was to confirm that the shared module was set up correctly, that all three import statements pointed to it properly, and that no runtime behavior had changed. That is considerably lighter cognitive work than reviewing a new feature, which requires the reviewer to reason about logic that did not previously exist and to think through edge cases the submitter might have missed.

The deliberateness of target selection matters as much as the fix itself. The agent did not choose the most ambitious available change in the repository. It chose the one most likely to be accepted because it was the safest to review. That choice followed directly from reading the contributing guide, which signaled that simplifications were welcome, combined with the underlying principle that net-negative changes earn faster acceptance because they place less burden on the person reviewing them.

A volunteer maintainer reviewed the pull request and called it a textbook refactor

A real volunteer maintainer reviewed the submission. The feedback was direct: a textbook refactor, net-negative lines, no regression. The pull request was merged. The agent became a listed contributor to the project, documented in the commit history.

This is the result most people will pull out of the story, and they are right to find it significant. An autonomous AI agent contributed to an active real-world project and had its contribution accepted by a human reviewer applying the same evaluation criteria they would apply to any human submission. The quality of the work met the standard.

The practical implication is not just that it happened once but that it is reproducible given the right configuration. An agent set up with the right skills, the right goal framing, and the right constraints document can produce work that a knowledgeable human reviewer finds acceptable without modification or requests for changes. That is a meaningful capability statement, and it is verifiable rather than theoretical.

But the second result from this experiment belongs in the same account, and it is the decision Madhuranjan Kumar made the moment the merge was confirmed.

Madhuranjan Kumar stopped the experiment the moment the merge was confirmed

Madhuranjan Kumar shut the behavior off. Not because it had failed. Because it worked, and because working at scale would create a different and serious problem that had nothing to do with the quality of individual pull requests.

Popular open-source repositories are maintained by small volunteer teams. In many cases, a single person handles almost all the review work, doing it alongside full-time employment and other obligations. One repository Madhuranjan Kumar examined had 2,700 open pull requests waiting for a single maintainer. That represents months of review backlog on a volunteer timeline, and that backlog existed before any AI agents entered the picture.

If many people ran always-on agents with instructions to find trending repositories and contribute helpful cleanup changes, the aggregate volume of machine-generated submissions across popular projects would multiply rapidly. Each individual pull request might be as useful as the merged one in this experiment. The quality of any single contribution is not the problem. The aggregate demand on volunteer attention across many simultaneous agent deployments is the problem.

One useful pull request from an autonomous agent is a contribution. One hundred machine-generated pull requests per week, each individually correct, directed at the same popular repositories by many different agent deployments running simultaneously, is a fundamentally different thing. The maintainer's capacity to review does not scale with submission volume. When it cannot keep pace, a flood of technically correct contributions becomes a practical obstacle to maintaining the project at all, which harms the entire developer community that depends on it.

Madhuranjan Kumar saw this effect and stopped. That judgment required reasoning the agent could not perform on its own. The agent had no way to observe what its behavior would look like at population scale, when many people ran the same pattern simultaneously. It could only see its own single repository interaction. The population-level consequence was invisible to it within any individual session. A human had to reason about that externality and make the decision quickly.

This is the category of human oversight that matters practically rather than theoretically. Not a rule requiring a human to approve every individual action before the agent takes it, which makes autonomous agents impractical. But a rule requiring a human to reason about what the behavior pattern looks like when deployed at the scale where it would actually be used. Those are different questions with different answers, and only a human can hold both simultaneously and act on the tension between them.

Net-negative scope is the right default for any autonomous agent workflow

The experiment established a principle that transfers cleanly to business operations. Net-negative changes are the right default scope for autonomous agents because they are easier to review, easier to reverse when something is subtly wrong, and easier to bound precisely in advance.

Net-negative in a code context means removing duplication, simplifying structure, or standardizing formatting without changing what the code does at runtime. In a business context the same principle applies to different domains. Merging obvious duplicate customer records in a CRM is net-negative. Standardizing inconsistent phone number formatting across a contact database is net-negative. Archiving files that match a naming convention retired two years ago is net-negative. Removing outdated entries from a product catalog is net-negative. In each case, the reviewer confirming the work needs to verify that something simpler is still correct, which is a lighter task than evaluating something newly introduced.

The contrast with additive autonomous work is direct. An agent that invents new records, new categories, new logic, or new entries is doing work where the reviewer cannot rely on the simplifying principle that nothing new was introduced, therefore nothing new can be wrong. Additive work has value, but it is the wrong default for a first deployment of an autonomous agent operating with limited supervision. Start net-negative, review the output carefully across multiple batches, and expand scope to additive work only after the pattern of the agent's judgment has accumulated enough evidence to be trusted in that territory.

This principle also defines the safe blast radius for autonomous agent work. A change that removes or consolidates has a natural ceiling on how wrong it can be, and the failure mode when it is wrong tends to be obvious and immediate. If the shared module is slightly misconfigured, three files break in an identical and visible way. If an agent invents a new feature and gets it subtly wrong, the error may not surface until a user encounters it in an unexpected context weeks or months later. Prefer the failure mode that surfaces quickly and is easy to identify and fix.

The four decisions that produced the merged PR transfer to any internal operation

Four specific decisions about the agent's configuration produced the useful result. Each one generalizes cleanly to business contexts that have nothing to do with software development.

The first was teaching the agent a reusable skill for the tool it would need. The GitHub skill let the agent navigate that environment without being taught from scratch on every task. For internal operations, the equivalent is creating a skill document covering how to navigate your CRM, your database interface, your inventory system, or whatever tool the workflow requires. Build it once and it transfers to every future task that touches that tool without rebuilding the setup.

The second was giving the agent a goal rather than a rigid script. A goal allows the agent to adapt when the most direct path is blocked or inappropriate. In the experiment, the loose instruction to find a way to contribute let the agent pivot when the issue tracker showed no accessible targets. A script pointing at a specific issue would have failed or produced a duplicate effort the moment that target was unavailable. Goals produce more robust autonomous behavior because they allow for judgment calls that scripts cannot anticipate.

The third was requiring the agent to read a rules document before acting. In a business context this means writing a short plain-language document specifying what the agent may touch and what it may not, what constitutes an acceptable output, and what requires human confirmation before proceeding. This is not bureaucratic overhead. It is the mechanism that keeps agent behavior inside the range you intended without requiring continuous supervision of every decision the agent makes.

The fourth was biasing toward net-negative changes from the start. The logger deduplication was selected precisely because it was safe, verifiable, and bounded. Nothing new was introduced. The scope of any possible error was small and immediately obvious. Maintain this posture until the agent's output across multiple reviewed batches has established enough of a track record to justify expanding into more complex and additive territory.

A human review before changes become permanent is what holds the system together

The merged pull request required a human reviewer before it became part of the project's permanent commit history. That review step is load-bearing. Without it, the agent makes changes to a shared codebase without any checkpoint, and the cost of any subtle error propagates into the permanent record before anyone can catch it.

The same structure belongs in every internal implementation of this pattern. An agent that processes database records overnight should produce a batch of proposed changes for a human to review before any of them are applied permanently. The review does not need to be exhaustive. For well-scoped, net-negative work, a summary scan confirming the agent stayed within the intended range is usually sufficient. But the review must happen before the changes become irreversible. Removing that step converts a supervised workflow into an unsupervised one, and that distinction matters most at the moments when the agent does something subtly unexpected.

Madhuranjan Kumar's twelve-day experiment concluded with a merge and an immediate decision to stop. Both reflect the same judgment operating at different scales. The merge demonstrated the pattern works at the level of one repository under close observation. The stop demonstrated that working for one contribution and should be deployed continuously at scale by many people simultaneously are questions that require different reasoning. Only a human can hold both questions at once and act on the tension between them.

Build the pattern, scope it to net-negative changes, write the rules document, schedule the human review before permanence. That is the configuration that makes the capability from this experiment trustworthy enough to actually run.