# AI Slop Is Not Just an Open Source Problem

> Low-quality AI pull requests are already exhausting open-source maintainers. Internal engineering teams face the same capacity problem when generated volume grows faster than verification, ownership, and durable value.

- Published: 2026-11-04
- Canonical: https://www.gitdotme.com/blog-ai-slop-is-not-just-an-open-source-problem

AI has made it dramatically easier to submit code.

It has not made human attention equally abundant.

That imbalance is now visible in open source. Linux Foundation Research reported that maintainers estimate 25% of incoming pull requests are low-quality “AI slop.” Among large projects, the estimate rises to 31%.

The same research found that 59% of maintainers are seeing contribution volume grow. GitHub’s 2026 Octoverse adds another signal: by September, more than 40% of pull requests started with an agent’s first draft, up from 17% in March.

More people can contribute. More changes can be proposed. More work can begin.

But every contribution still creates a verification obligation for someone.

This is why AI slop is not only an open-source moderation problem. It is an engineering capacity problem—and internal software teams are exposed to the same mechanism.

## “AI slop” should describe a workflow failure, not a code origin

Not every AI-assisted contribution is low quality.

A carefully scoped change produced with AI, understood by its author, tested against the correct behavior, reviewed with relevant context, and maintained after merge may be excellent engineering work.

A human-written change can also be redundant, poorly understood, lightly tested, and expensive to maintain.

The useful distinction is not human code versus AI code.

It is whether the contributor retained responsibility for the result—or transferred the cost of understanding, verification, and repair to someone else.

| Contribution pattern | Immediate appearance | Cost transferred downstream |
| --- | --- | --- |
| AI-assisted change with clear ownership | Faster implementation | Low, when intent and verification are preserved |
| Large generated PR with weak context | High visible output | Reviewer attention and reconstruction work |
| Passing change that duplicates existing logic | Apparently correct | Future maintenance and inconsistency |
| Quickly merged change that is soon rewritten | Short-term velocity | Rework and lost engineering effort |
| Unverified generated contribution | Cheap to submit | Expensive for maintainers and reviewers to reject |

The problem begins when generation is nearly free but validation remains scarce.

## Open source is exposing the capacity mismatch first

Open-source maintainers operate under unusually visible constraints.

They often review contributions from people they do not know, without a shared organizational context, while balancing maintenance work that is rarely reflected in the incoming contributor’s cost.

Generative AI lowers the effort required to create a pull request. That can expand participation and help contributors work more efficiently. The Linux Foundation study reports meaningful time savings across open-source tasks and finds that maintainers recognize AI’s ability to lower barriers to entry.

But lowering the cost of submission does not lower the cost of deciding whether a change belongs.

Maintainers still need to determine:

- Does the change solve a real problem?
- Does it fit the architecture?
- Does it duplicate existing behavior?
- Are the tests meaningful or merely green?
- Does the author understand the implementation?
- Who will maintain the change after merge?
- Is reviewing this contribution a better use of scarce time than existing roadmap or reliability work?

When contribution volume grows faster than verification capacity, a project can become more active while becoming harder to maintain.

## Internal engineering teams have the same problem

Private repositories do not call it AI slop.

The symptoms appear under more familiar names:

- oversized pull requests,
- reviewer overload,
- repeated rewrites,
- duplicated abstractions,
- shallow ownership,
- generated tests that confirm the implementation rather than the requirement,
- documentation that looks complete but does not match the system,
- and features that disappear shortly after release.

Organizational boundaries can hide the cost.

A pull request may be merged because the author is a colleague. A deadline may make weak verification appear acceptable. High commit or PR volume may be interpreted as productivity. Rework may be recorded under a new task rather than connected to the original change.

The workflow can therefore look successful at every visible checkpoint:

| Visible checkpoint | What it confirms | What it does not confirm |
| --- | --- | --- |
| Code was generated quickly | Low implementation time | Correct problem selection |
| Tests passed | Tested conditions passed | Requirement coverage or maintainability |
| Pull request was approved | Someone accepted the change | Deep understanding or long-term ownership |
| Change was deployed | Software reached production | Durable value |
| Team shipped more changes | Throughput increased | Net engineering capacity improved |

Merge is an operational decision. It is not long-term evidence of value.

## Output volume can consume capacity while appearing productive

AI changes the economics of proposing work.

When a developer can create several implementations in the time previously required for one, the organization receives more candidate output. But candidates are not free after they are generated.

Someone must read them, test them, integrate them, observe them in production, answer questions about them, and maintain them when the surrounding system changes.

This creates an important distinction:

**Generation capacity is not engineering capacity.**

Engineering capacity is the organization’s ability to convert ideas into reliable, maintainable software without creating disproportionate downstream work.

A team can increase generated code while reducing net capacity if:

- review queues grow,
- senior engineers spend more time reconstructing intent,
- rework consumes the time saved during implementation,
- generated code creates overlapping ways to solve the same problem,
- or short-lived changes repeatedly replace one another.

Counting commits, pull requests, changed lines, or AI-generated code can reward the input side of this imbalance.

The scarce resource is increasingly not the ability to produce another draft.

It is the ability to determine which drafts deserve to become part of the system.

## Passing review is only the beginning of the evidence

Pre-merge controls remain essential.

Teams need tests, static analysis, security checks, architectural review, contributor policies, and clear disclosure rules. Open-source projects also need contribution boundaries that put testing and explanation responsibilities on the submitter rather than the maintainer.

But pre-merge verification cannot answer every important question.

Some outcomes become visible only after the change joins the codebase:

- Was the contribution preserved?
- Was it heavily rewritten?
- Did later work repeatedly repair it?
- Did it trigger additional refactoring?
- Did it create durable functionality?
- Did the author’s apparent AI acceleration survive contact with the rest of the system?

This is the difference between acceptance evidence and outcome evidence.

| Evidence layer | Core question | Typical signals |
| --- | --- | --- |
| Before merge | Is the change acceptable now? | Tests, review, security and policy checks |
| At merge | Is someone accountable for this decision? | Ownership, approval and traceability |
| After merge | Did the change create durable value? | Rework, refactoring, survival and realized effort |
| Across time | Is AI improving net engineering capacity? | AI Leverage combined with downstream outcomes |

Teams need all four layers.

## Measure the cost that moves downstream

A useful AI measurement system should not punish teams for using AI or treat every generated line as suspicious.

It should make transferred cost visible.

GitMe approaches this by connecting AI-related output with several downstream signals:

- **AI Leverage** shows how AI changes modeled engineering output. It can be examined by developer, project, and repository.
- **Real Effort Value (REV)** estimates the engineering effort represented by the work rather than counting lines or commits.
- **Rework and refactoring signals** show whether later activity repeatedly repairs, replaces, or restructures earlier contributions.
- **Effort Survival Cohort** shows how much modeled engineering effort remains active over time.

None of these signals should be interpreted alone.

| Observed pattern | Possible interpretation | Better leadership response |
| --- | --- | --- |
| High AI Leverage, strong survival, limited rework | AI is supporting durable output | Identify and share the effective practice |
| High AI Leverage, short survival, rising rework | Visible acceleration may be transferring cost | Inspect task choice, review depth, and ownership |
| Moderate AI Leverage, strong durable value | Deliberate use may outperform maximum use | Preserve context-sensitive judgment |
| Low adoption with recurring manual toil | There may be a capability or workflow opportunity | Offer training and remove adoption barriers |
| Different outcomes across repositories | Context may matter more than individual behavior | Compare architecture, test maturity, and work type |

This is not a developer leaderboard.

It is a way to locate where AI use is creating leverage, where it is creating verification debt, and where teams need better context, coaching, or safeguards.

## Governance should follow the contribution through time

A practical response to AI slop requires more than a stricter review checklist.

The contribution must remain accountable from generation through maintenance.

### 1. Define what contributors still own

AI assistance should not transfer responsibility away from the person submitting the change.

The contributor should be able to explain:

- the problem being solved,
- why the selected approach fits the codebase,
- which alternatives were considered,
- what the tests actually establish,
- and where the change is most likely to fail.

### 2. Make verification proportional to uncertainty

Not every AI-assisted change requires the same process.

A narrow documentation correction and a cross-service authorization change should not receive identical scrutiny. Verification should reflect blast radius, novelty, reversibility, and the team’s familiarity with the affected system.

### 3. Protect reviewer attention

Generated volume should not be allowed to consume unlimited human review capacity.

Teams can use smaller changes, explicit context, contributor self-review, automated checks, ownership routing, and limits on concurrent agent work. The objective is not to slow useful automation. It is to keep the verification queue from becoming the hidden bottleneck.

### 4. Observe what happens after merge

A contribution policy can tell teams what should happen.

Repository history shows what actually happened.

Review post-merge rework, refactoring, survival, and realized value by developer, project, and repository. Use the data to find patterns—not to assign simplistic blame.

### 5. Turn strong outcomes into shared capability

When one developer or team achieves high AI Leverage with durable results, study the workflow behind it.

The advantage may come from better task decomposition, stronger repository context, more disciplined testing, smaller changes, or knowing when not to use AI.

Those practices can be taught.

## The goal is not less AI-generated code

The answer to low-quality AI contributions is not to return to manual typing as a virtue.

AI can reduce repetitive work, expand participation, help developers navigate unfamiliar systems, and accelerate many well-scoped tasks. The same Linux Foundation research raising the AI-slop concern also reports substantial time savings.

The goal is to prevent cheap generation from creating expensive verification and maintenance.

That requires engineering organizations to stop asking only:

“How much more did we produce with AI?”

And start asking:

- How much of that work was worth reviewing?
- How much was worth merging?
- How much remained useful?
- How much required repair?
- Which teams converted AI assistance into durable engineering value?
- Which workflows merely moved cost to someone else?

Open source is making the problem visible because maintainers can see the queue filling up.

Internal teams should not wait for the same cost to appear as reviewer burnout, technical debt, and shrinking ownership.

AI slop is not defined by who—or what—typed the code.

It is what happens when an organization scales generation without scaling accountability, verification, and evidence of durable value.

---

## Related GitMe Reading

- [AI Speedup Is Not AI Value](https://www.gitdotme.com/blog-ai-speedup-is-not-ai-value)
- [Code Review Alone Cannot Govern AI-Generated Software](https://www.gitdotme.com/blog-code-review-alone-cannot-govern-ai-generated-software)
- [When AI Reviews AI, Who Owns the Merge?](https://www.gitdotme.com/blog-when-ai-reviews-ai-who-owns-the-merge)
- [AI Adoption Should Leave No Developer Behind](https://www.gitdotme.com/blog-ai-adoption-should-leave-no-developer-behind)

## Sources

- [Linux Foundation Research — Navigating Open Source Software Development in the Generative AI Era](https://www.linuxfoundation.org/research/oss-development-gen-ai-era-2026)
- [Linux Foundation — New Research Survey on Generative AI and AI Slop in Open Source](https://www.linuxfoundation.org/press/new-lf-research-survey-shows-generative-ai-cuts-open-source-coding-time-in-half-but-25-of-incoming-pull-requests-are-considered-ai-slop)
- [GitHub Octoverse 2026 — Developers Build With Agents](https://github.blog/news-insights/octoverse/octoverse-commits-pushes-reach-new-highs-in-2026-as-developers-build-with-agents/)
- [DORA — Balancing AI Tensions: Moving From AI Adoption to Effective SDLC Use](https://dora.dev/insights/balancing-ai-tensions/)
- [GitHub — Your Contributors Are AI-First Now. Is Your Project?](https://github.blog/open-source/maintainers/your-contributors-are-ai-first-now-is-your-project/)
- [Anthropic — How AI Assistance Impacts the Formation of Coding Skills](https://www.anthropic.com/research/AI-assistance-coding-skills)

---