Skip to content

Getting an AI-Written Patch Into the Queue

For developers contributing AI-assisted code to open-source projects, producing a reviewable patch and qualifying to submit it are separate tasks, governed by different kinds of contribution rules.

Rust’s rules for AI-written code ask for something a coding agent cannot supply on its own: a willing reviewer. Under the experimental contribution policy covering the programming language’s main repository and specified teams, new contributors’ nontrivial generated changes require disclosure, an agreed reviewer, non-critical scope, thorough testing and understanding by author and reviewer. A preliminary pull request—a proposed code change—can precede that agreement, but the policy discourages this route.

For someone using AI to contribute to another project, this changes what it means to get the work ready. Code quality is one question; agreement to spend time reviewing it is another. Better generation does not, by itself, supply that agreement. Rust’s rule makes the relationship part of preparation, rather than something the finished patch can establish afterward.

An October 26 preprint reviewed 50 documents from 31 sources about changing software collaboration. Restricting submissions was its most frequently adopted response; only editor-maker Zed reported replacing pull requests. The collection was nonrepresentative, and no reviewed measurements tested whether mechanisms improved review.

Different ways into the queue

Ghostty, a terminal application, requires a maintainer’s vouch (endorsement) before code pull requests. AI-written code remains permitted with unaided understanding.

In July’s discussion, contributor joshka reported a prepared fix but withheld the pull request while awaiting a vouch. Mitchell Hashimoto replied in August that it was fixed on the main development branch. That patch’s authorship and integration route remain unverified.

The prerequisite is not an absolute ban: rtgibbons disclosed agent assistance and received approval on October 27. That establishes admission, not patch acceptance.

LLVM, a compiler project, encourages newcomers to begin with small contributions they understand. It permits human-reviewed AI assistance but bars it on designated beginner tasks to preserve learning. Permission can depend on the purpose of an assignment, not just a contributor’s record.

Rules for a crowded queue

GitHub’s June contribution-control announcement describes a limit on how many requests someone without write access can have open, with a bypass list for trusted contributors. At the limit, the person must close a request or have one merged before opening another. This rations outstanding submissions; it does not assess whether the next patch is correct.

GitHub added automatic exemptions on October 28. A maintainer can set a minimum account age or a minimum number of requests previously merged in that repository; meeting either enabled condition exempts a contributor from the cap. An old account need not have contributed to this particular project, whereas a previously merged patch records participation there. These are ways to choose who may exceed a submission limit, not substitutes for reviewing what they submit.

The treatment of unfinished work makes the choice clearer. GitHub added an option to count draft requests in October, after initially exempting them. Marking a change as unfinished need not keep it outside a project’s submission limit. GitHub presents this as a response to clutter, notifications and automated test runs from repository spam—not as a measured improvement in reviewing code.

What the project is agreeing to take on

Ladybird’s June announcement ended public code submissions to the browser project, including patch submissions through other channels. Maintainers would introduce changes themselves. Andreas Kling tied the decision to security and responsibility for future maintenance, while saying the team used AI itself. Bug reports, testing and design discussion remained welcome. This is a narrower invitation to participate, not an invitation to send a better patch.

In Rust’s policy announcement, Jynn Nelson described contributors relaying review comments to a model and pasting its answers back. The maintainer wanted the contributor’s judgment, not another machine response. Nelson also argued that publishing rules made previously inconsistent moderation more legible to newcomers. This is an attributed account of the problem and the intended remedy, not evidence that the remedy worked.

Replacing the review interface does not settle the invitation either. Zed reports reviewing agent work in separate conversational threads, with revisions incorporated into the original thread, while keeping GitHub contributions for its editor. The vendor account documents arrangements, not a measured advantage. Easier collaboration among an existing team does not automatically provide an entry route for a stranger.

Rust’s policy suggests pushing work to a personal fork and sharing a link with a prospective reviewer before opening the request. That gives preparation a concrete destination: not just a patch ready to send, but a person willing to examine it.

Sources

Understand How People and Agents Work Together.

Practical essays, experiments, and lessons from building software for people and agents.

Occasional emails, sent when there is something worth reading. Free to subscribe. Unsubscribe at any time.