An open-source contribution produces two things at once: it may improve a project while also improving the profile of the person who signs it.
GitHub makes the second effect highly visible: profiles contain a yearly contribution graph, detailed contribution activity, proposed pull requests, opened issues and information about the repositories where a user is most active.2
For a long time, producing that signal required roughly the same work as producing the contribution: understand a project, find a problem, write a change, test it and stay through review. Coding agents break that symmetry because they cut the cost of manufacturing a patch much more aggressively than the cost of accepting one.
Neil Alexander, a nats-server maintainer and author of several open-source networking projects, describes receiving three near-simultaneous pull requests from a contributor with almost no recent GitHub-wide activity. The patches corrected spelling and grammar in comments. Claude had made the edits, handled visible parts of the submission and left its co-authorship in the commit trailers.1
The corrections were valid, yet Alexander closed them anyway because the problem had moved beyond diff quality into the economics of the gesture.
Two payoffs
For the person opening a pull request, an accepted contribution can create public credit: repository presence, profile activity, a visible PR and sometimes material that later appears in a résumé or portfolio.12
For the project, value exists only when the change is worth more than the cost of absorbing it.
Those quantities differed before LLMs and can now diverge much more sharply, particularly when a change is trivial but validating it is not.
An agent can scan repositories, find typos, warnings or TODOs, produce patches and prepare descriptions; the contributor gains several opportunities to display activity, while each maintainer simply receives another item to inspect.
That asymmetry explains why a technically correct PR can still be unwanted. A cosmetic edit may be almost worthless to the project while producing exactly the public signal its author wanted.
Green résumé
Alexander describes successful open-source contributions as a kind of currency. He notes that recruiters and employers may inspect GitHub activity and suspects that some new AI-generated submissions primarily manufacture the appearance of participation.1
The first half is independently visible in the product: GitHub deliberately builds profiles around contribution graphs, activity, pull requests and issues.2 The second half remains a maintainer's observation rather than a measurement of the hiring market. It would be wrong to infer that most AI pull requests are résumé farming, or that GitHub activity routinely determines hiring decisions.
His example nevertheless exposes a simple incentive: if public credit stays visible while production cost falls, manufacturing the signal becomes more attractive.
The same logic reaches security reports. Alexander says he has received more reports that appear AI-generated, often accompanied by proposed fixes. Because CVEs can credit reporters, he wonders whether some submissions seek recognition as much as remediation.1
No published count supports a percentage here. curl nevertheless describes the operational problem from another direction: fabricated or pasted AI security reports consume priority investigation time, displace real work, and can lead to immediate bans for users who submit made-up reports.5
Prove ownership
The interesting response from projects is not a blanket ban on AI.
PyTorch explicitly allows AI tools but requires generated material to be disclosed, accompanied by human commentary explaining its relevance, and owned by somebody who understands the implementation. The project does not accept fully autonomous contributions without meaningful human involvement.3
RustPython goes further on traceability: every use of AI must be disclosed, including an Assisted-by trailer in commits. Pull requests may be closed when code appears insufficiently reviewed, AI use was hidden, or the contributor cannot actually test the change.4
These rules no longer verify only the output. They ask for evidence about the process of ownership.
Previously, a clean patch and green tests could often support the assumption that a contributor understood their work; that assumption becomes weaker when the entire patch, test changes and PR description can be generated without deep reading.
The scarce signal therefore becomes: does somebody know why this PR exists and will they answer for it?
Close the gate
Some teams now prefer to move the filter ahead of review rather than pay that verification cost one submission at a time.
Since February 2026, GitHub offers two repository settings that would have sounded odd under the classic open-source ideal: disable pull requests entirely or restrict them to collaborators.6
This is not an anti-AI feature. GitHub presents it as a general way for maintainers to choose how a public repository accepts contributions.6
It still changes the economics. Instead of allowing anyone to create a unit of work that maintainers must later triage, a project can put an entry cost before the PR: prior discussion, an approved issue, an invitation or an existing relationship.
Canario took the extreme route by closing its source to reduce maintenance cost. This is different: code can stay visible and forkable, while the review queue itself becomes restricted.
Expensive queue
The scarce resource is no longer the patch itself, which is becoming abundant, but review time, project knowledge and the authority to decide what somebody may have to maintain five years from now.
A contribution system now has to avoid two opposite errors, both of which become expensive as incoming volume rises.
The first is treating all AI assistance as illegitimate. PyTorch and RustPython show that projects can accept generative tools when the author understands, verifies and owns what they send.34
The second is assuming that a correct diff always justifies review cost. Alexander's three text fixes were correct; he closed them because they improved the project too little to justify the social transaction they triggered.1
Change metric
For contributors, the consequence is probably healthy: the strongest portfolio is unlikely to be the one containing the most green squares.
A hard-to-fake contribution leaves other traces: an issue understood before the patch, discussion showing reasoning, tests the author can explain, a change followed after merge, repeated presence in the same project.
Those are exactly the things mass automation produces poorly because they require accumulated context rather than a one-off diff.
For maintainers, the task becomes making those signals visible before spending review time: require a prior issue for certain changes, close PRs without a clear motivation, demand disclosure and real testing, or temporarily restrict access when incoming volume exceeds the team's capacity.
GitHub will keep showing activity because activity is useful,2 while agents force everyone to stop confusing visible activity with value transferred to the project.
Open source never promised a résumé point for every correct diff. Now that a diff can cost almost nothing to manufacture, that distinction is becoming impossible to ignore.