ESLint's Payout Program Ended Over AI-Generated Code

ESLint has ended its paid contributor program. The announcement does not have the shape of a security advisory, but it has the shape of one in fact: it tells us that the mechanism that made open source maintainable — human review — is failing under AI-generated volume.

ESLint paid outside contributors $24,680 in 2025. Across 2022 to 2025 the project paid $51,180 — meaningful money, by small open-source standards, enough to convert some contributors into core maintainers. The program ended because a polished pull request stopped proving anything. Maintainers who invested their time in reviewing could no longer tell who they were reviewing for.

The structural numbers make the point. GitHub’s 2026 October report says more than 40% of platform pull requests started with an AI agent’s first draft by September, up from 17% in March. A Linux Foundation study in October found that 59% of surveyed maintainers reported growing AI-associated contribution volume. The situation escalated: people Zakas called “AI monitors” began examining outside pull requests and payment reports, publicly accusing some contributors of undisclosed AI use, and Zakas said he received private messages warning him about specific accounts suspected of AI submissions. He wrote that it “took the joy out of the contributor pool.”

The security angle is not that ESLint was attacked. It is that ESLint is what many security teams implicitly trust — the linter wedge between a developer’s keyboard and production. ESLint, and its failure mode, are a warning about supply-chain integrity for the whole class of CI-and-compile dependencies.

Three things worry me about this pattern.

First, maintainer signal degradation. A merged pull request used to signal: a person invested effort and likely understood the change. That is the entire basis of voluntary code review. When that stops being true, the cost curve for catching issues shifts from review to brute-force scanner gating.

Second, disclosure-path erosion in neighboring projects. curl shut its bug bounty in January after low-quality, often AI-generated, vulnerability reports overwhelmed maintainers, ending financial rewards and dropping the HackerOne recommendation; in July, curl suspended vulnerability reporting entirely for a month. ESLint still allows AI-assisted contributions, but they do not qualify for payment and must disclose their use. Security teams that file vulnerability reports through HackerOne or similar platforms should expect the same migration pressure elsewhere — and verify where each project in the toolchain actually wants reports routed.

Third, the unrecognized downstream. ESLint ships in CI pipelines for JS and TS projects worldwide. A compromised or sabotaged linter release reaches a much larger blast radius than any single framework release would. If review capacity collapses in ESLint specifically — the project needs to remain one of open source’s best-executed security-critical components, given its position in CI — the fallback mitigation is not perfect static analysis; it is vendoring, sign-off, and explicit review of linter upgrades.

What this does not tell us — and the announcement does not claim otherwise — is that AI code is uniquely bad code. The threat is not necessarily malicious code; it is unreviewable code. When nobody can reliably review, we get silence, not scrutiny. Your review policy, not the linter, is the actual control. Check whether your intake process can still answer: why this change, why now, why this reviewer.