---
title: "AI makes GitHub contributions cheap. The credit still stays visible"
locale: "en"
url: "https://irz.fr/en/articles/ai-contribution-credit-maintainer-en"
markdown_url: "https://irz.fr/en/articles/ai-contribution-credit-maintainer-en.md"
category: "ai"
tags: ["open source", "maintainers", "GitHub", "AI contributions", "pull requests"]
published_at: "2026-08-28T09:07:00.000Z"
author: "Hugo Marchal"
translation: "https://irz.fr/fr/articles/ia-contribution-credit-mainteneur-fr.md"
---

# AI makes GitHub contributions cheap. The credit still stays visible

A pull request can take minutes to generate and still demand real review work. Projects are therefore filtering less for whether code exists and more for evidence that a human actually owns it.

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](https://docs.github.com/en/account-and-profile/concepts/contributions-on-your-profile)

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](https://neilalexander.dev/2026/06/30/flooding-contributions.html)

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.[1](https://neilalexander.dev/2026/06/30/flooding-contributions.html)[2](https://docs.github.com/en/account-and-profile/concepts/contributions-on-your-profile)

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 `TODO`s, produce patches and prepare descriptions; the contributor gains several opportunities to display activity, while each maintainer simply receives another item to inspect.

> **One PR creates two different ledgers**
> Diagram showing one pull request creating visible credit for a contributor and validation cost for a maintainer
> - SAME DIFF, DIFFERENT BALANCE SHEETS
> - CONTRIBUTOR
> - visible activity
public credit
portfolio
> - MAINTAINER
> - understand
review · tests
future ownership
> - AI mainly cuts the cost on the left. The right side remains human.
> The value of a contribution to its author and its cost to a project are different quantities. Agents make that gap much wider.

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](https://neilalexander.dev/2026/06/30/flooding-contributions.html)

The first half is independently visible in the product: GitHub deliberately builds profiles around contribution graphs, activity, pull requests and issues.[2](https://docs.github.com/en/account-and-profile/concepts/contributions-on-your-profile) 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](https://neilalexander.dev/2026/06/30/flooding-contributions.html)

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](https://curl.se/dev/contribute.html)

## 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](https://github.com/pytorch/pytorch/blob/main/AI_POLICY.md)

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](https://github.com/RustPython/.github/blob/main/AI_POLICY.md)

These rules no longer verify only **the output**. They ask for evidence about **the process of ownership**.

> **The new filter is not only code**
> - state when and how AI participated: Disclosure
> - be able to explain and defend the change: Understanding
> - actually test what the agent proposes: Verification
> - remain the person answering during review: Responsibility
> Examples: PyTorch and RustPython. Projects do not require every line to be typed by hand; they require a human to own the change.

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](https://github.com/orgs/community/discussions/187038)

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](https://github.com/orgs/community/discussions/187038)

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.[3](https://github.com/pytorch/pytorch/blob/main/AI_POLICY.md)[4](https://github.com/RustPython/.github/blob/main/AI_POLICY.md)

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](https://neilalexander.dev/2026/06/30/flooding-contributions.html)

> **When patches become abundant, admission becomes a product**
> Funnel showing discovery, justification, review and merge, with human cost increasing as a contribution moves forward
> - HUMAN COST RISES AS THE CONTRIBUTION MOVES FORWARD
> - 1 · FIND · agent, human, search
> - 2 · JUSTIFY · why this change?
> - 3 · REVIEW · context + tests
> - 4 · MERGE · ownership
> An agent can make step one nearly free. Projects therefore move the filter toward justification, understanding and sometimes access to the PR queue itself.

## 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](https://docs.github.com/en/account-and-profile/concepts/contributions-on-your-profile) 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.

## References

1. [Neil Alexander, Please stop flooding our projects with AI slop to furnish your CV, 30 June 2026](https://neilalexander.dev/2026/06/30/flooding-contributions.html)
2. [GitHub Docs, Contributions on your profile](https://docs.github.com/en/account-and-profile/concepts/contributions-on-your-profile)
3. [PyTorch, AI Policy](https://github.com/pytorch/pytorch/blob/main/AI_POLICY.md)
4. [RustPython, AI usage policy](https://github.com/RustPython/.github/blob/main/AI_POLICY.md)
5. [curl, Contribute to the curl project](https://curl.se/dev/contribute.html)
6. [GitHub Community, new repository settings to configure pull request access, 13 February 2026](https://github.com/orgs/community/discussions/187038)