AI Slop Is Not a Content Problem. It Is a Verification-Cost Problem.

As a simple heuristic — not a statistical model — a recipient's workload can be approximated as:

If submission volume doubles while verification time remains roughly constant, the receiving system needs roughly twice the review capacity.

AI can change the first term very quickly.

It does not automatically change the second.

Some validation can be automated. But in many high-value settings somebody still has to determine:

• whether the claim concerns the actual target;
• whether the source exists;
• whether the quotation is accurate;
• whether the vulnerability reproduces;
• whether the code does what the contributor says;
• whether a legal authority supports the proposition attributed to it;
• whether a submission is genuinely new or a semantic rewrite;
• whether the conclusion exceeds the evidence.

Those tasks consume time, attention and expertise.

And those costs can be externalised onto the receiver.

Security makes verification-cost transfer unusually visible because triage is a discrete queue.

Bugcrowd reported in March 2026 that its triage queues had grown by more than 334% over three weeks even after excluding legitimate traditional-hacker workflows.1 HackerOne later described a 100%+ surge in report volume and stressed that the new volume contained both valuable findings and low-value or unverifiable work.3

That combination matters more than either headline alone: cheap generation can increase signal and noise simultaneously. The specialised report-quality response is covered in Proof Beats Prose, while the researcher's professional role is covered in The Ethical Hacker After Generative AI.

curl is useful here as a chronology, not as proof of a universal industry trend.

Daniel Stenberg ended curl's monetary bug bounty in January 2026 while vulnerability disclosure continued; the project later returned to HackerOne as a private reporting channel without monetary rewards.45 By April, Stenberg described a “high-quality chaos” phase in which report quality had improved while volume remained very high.6

The lesson for this pillar is narrow: better AI does not necessarily remove the review bottleneck; it can replace obvious junk with a larger stream of plausible or valid work that still requires assessment.

The 2026 preprint “AI Slop is DDoSing Open Source” analyses 294 repositories and more than two million pull requests and issues.7

The authors use AI-DDoS to describe a denial-of-service-like effect in which plausible but low-quality AI-generated contributions consume community review capacity.

Their analysis reports that PR volume increased in 2025 while the merge rate for one-time contributors fell by 18.18% relative to the modelled counterfactual.7

Three qualifications are necessary.

First, this is a preprint, not a universal finding about all open source.

Second, AI-DDoS is the authors' analytical term. It should not automatically be treated as a network-DDoS incident or a legal classification.

Third, the problem is not “AI code is bad code”.

The deeper issue is that contributors can generate more units of plausible work than maintainers can carefully evaluate.

The economics are the same.

The word review sounds deceptively cheap.

For a vulnerability report, validation may mean:

For a pull request:

For a legal filing:

This is why polished formatting can become dangerous.

It can reduce the perceived need for checking without reducing the actual verification burden.

The Courts and Tribunals Judiciary of England and Wales updated its AI guidance in October 2025, warning about incorrect, incomplete and misleading information, AI hallucinations and confidentiality risks.8

The guidance also reinforces personal responsibility for material produced in a judicial office holder's name.

US courts have been making the same point to filers.

A March 2026 notice from the U.S. Bankruptcy Court for the Central District of California tells users to verify every cited case, statute, rule, quotation and factual proposition before filing, regardless of whether AI assisted the drafting.9

There is no need to turn this into a dramatic claim that “AI is breaking the courts”.

A narrower observation is enough:

Professionally formatted legal language does not reduce the filer's obligation to verify, and inaccurate material creates real checking work for courts and opposing parties.

That is the same verification-cost model.

Latvia's amended Iesniegumu likums took effect on 1 March 2026.10

Among other changes, it provides that where a large number of substantively similar, non-individual submissions would require disproportionate institutional resources to answer individually, an institution may under the statutory conditions issue one common public response. It also permits an application to be left unexamined where the right to submit applications is exercised in bad faith.10

There is no basis for saying those amendments were enacted because of AI.

They are technology-neutral.

What they show is broader: institutions already need mechanisms for cases in which individual processing cost becomes disproportionate to the informational value of repeated submissions.

Generative AI can intensify that asymmetry.

The harder future case is not one thousand identical messages.

It is one thousand semantically similar but textually unique messages.

Traditional deduplication becomes less effective.

This matters for public consultations too.

AI can help a person:

• understand a difficult proposal;
• express an opinion more clearly;
• overcome a language barrier;
• organise supporting arguments;
• identify inconsistencies;
• participate in a process they might otherwise avoid.

Those are genuine benefits.

But it does not follow that:

1,000 automated textual variants = 1,000 independent human judgments.

An institution may need to distinguish between:

• unique evidence;
• repeated arguments;
• independent positions;
• coordinated campaigns;
• machine-generated semantic variants;
• genuinely individual circumstances.

That is not an argument against AI-assisted civic participation.

It is an argument against confusing the number of text artefacts with the amount of new information.

When professionally structured prose was expensive to produce, presentation itself carried some quality signal.

Not a perfect one, but a signal.

That signal is weaker now.

AI can cheaply generate:

• clean structure;
• FAQs;
• comparison tables;
• executive summaries;
• professional terminology;
• confident tone;
• long reference lists.

So the value of professional publishing shifts toward things that are harder to imitate synthetically:

• primary sources;
• original data;
• explicit methodology;
• dated observations;
• reproducible experiments;
• first-hand case studies;
• claim-to-source mapping;
• visible uncertainty and correction.

That is also why What Does an AI Benchmark Score Actually Prove? treats the score as only one element of an evidence package. A percentage without model identity, dataset provenance, evaluation configuration and claim boundaries is much weaker evidence.

Formatting is getting cheap. Provenance is becoming more valuable.

The central failure mode looks like this:

The sender keeps the cheap part.

The receiver inherits the expensive part.

I call this verification-cost transfer.

That is an analytical term, not a standard economic category.

It is useful because it explains what bug bounty, OSS review, legal filings and administrative submissions have in common.

The problem is not merely that incorrect information exists.

The problem is who pays to discover that it is incorrect.

Any human-reviewed system has finite checking capacity.

Call it a verification budget.

It may consist of:

• triager hours;
• maintainer attention;
• judicial and clerk time;
• civil-service capacity;
• editorial review;
• security-operations analyst time.

Once incoming claims exceed that budget, the system has to adapt.

It may:

• let queues grow;
• reduce review depth;
• impose rate limits;
• use reputation signals;
• require stronger evidence;
• accept fewer submissions;
• sample;
• automate low-risk preflight checks;
• close channels.

Every option has side effects.

This is the most important counterargument.

An open-source project can reduce workload by making contributions harder for newcomers.

It can also lose future maintainers.

A bounty program can reduce noise by trusting only established researchers.

It can also lose new talent and unusual attack perspectives.

A public institution can aggressively consolidate submissions.

It can also miss a genuinely individual fact.

An editor can reject all AI-assisted writing.

They can also reject excellent work.

The 2026 OSS preprint explicitly describes this as a sustainability problem: low-effort defensive strategies may protect review capacity in the short term while making openness harder to sustain.7

The design objective should therefore not be:

make submission expensive for everyone.

A better objective is:

make it harder to externalise unverified work onto others while keeping legitimate, high-quality participation accessible.

A receiving system can require some checking before submission.

In bug bounty:

• reproduction steps;
• minimal PoC;
• target/version;
• demonstrated impact;
• researcher attestation.

In open source:

• tests;
• lint/build results;
• a clear issue description;
• explanation of why the patch fixes the problem;
• contributor confirmation that they understand the change.

In legal work:

• verified authorities;
• accurate quotations;
• traceable sources.

In public administration:

• structured fields;
• topic classification;
• mechanisms for substantively identical submissions;
• authentication where proportionate and lawful.

In publishing:

• claim/source mapping;
• observation dates;
• methodology;
• primary sources;
• correction history.

This does not say “do not use AI”.

It says:

Do your share of the verification before transferring the work to somebody else.

Recipients can also reduce verification cost.

Many checks are good automation targets:

• required fields;
• CVSS syntax;
• reachable URLs;
• duplicate candidates;
• near-duplicate clustering;
• test/build results;
• citation existence;
• exposed secrets;
• submission rate;
• file format.

But automated preflight is not the same thing as automated truth.

Whether a vulnerability is exploitable, a legal argument is material, or an administrative submission contains an individual circumstance often still requires contextual judgment.

Automate the checks that can be cheap and reproducible.

Reserve scarce human attention for the decisions that actually require it.

In May 2026, Bugcrowd expanded identity-verification and submission-throttling controls for parts of its Managed Bug Bounty environment.2

That is understandable capacity management.

Identity does not prove a finding.

Reputation can improve triage priority, but it is not evidence either.

A healthier distinction is:

not:

Otherwise an anti-slop control becomes a gatekeeping mechanism.

The tempting response is:

“Detect AI-generated text.”

That is too narrow.

A high-quality AI-assisted contribution can be completely valid.

A low-quality human contribution creates the same verification cost.

And generation origin does not tell us whether a claim is true.

More useful questions are:

• Is the claim verifiable?
• Is evidence attached?
• Is the source identifiable?
• Is somebody accountable?
• Can mistakes be corrected or appealed?
• Is the volume proportionate?
• Does each submission contain genuinely new information?

That is harder than AI / not AI.

It also addresses the actual system risk.

Any system that relies on external claims needs to design more than intake.

It needs a verification architecture.

I would ask seven questions:

1. What must the submitter verify before submission?
2. What minimum evidence must accompany the claim?
3. What can be checked cheaply by automation?
4. What still requires human judgment?
5. How is work prioritised when volume exceeds capacity?
6. How are false positives and bad decisions corrected?
7. How do controls avoid excluding legitimate newcomers?

This is not a formal standard.

It is a practical design test.

AI slop is not interesting because the internet contains more mediocre prose.

It matters because generative AI changes the cost structure.

Producing:

• a claim;
• a vulnerability report;
• a patch;
• a legal argument;
• an administrative submission;
• a “research” summary;
• a benchmark interpretation

is getting cheaper.

Checking whether it is correct often still requires scarce human expertise.

The mature AI-governance question is therefore not:

“Was this generated by AI?”

It is:

“Who is responsible for verifying this claim, and who pays for the error?”

If the answer is systematically “the receiver”, pressure grows to narrow access, add heavier filtering or close some channels.

Sources were checked on 25 September 2026. Bugcrowd and HackerOne volume figures are platform-reported observations, not representative statistics for the entire industry. AI Slop is DDoSing Open Source is a preprint as of this date; its “AI-DDoS” terminology is not presented here as a generally accepted legal or cybersecurity-incident classification. “Verification-cost problem”, “verification-cost transfer”, “verification budget” and “verification architecture” are analytical working terms used by the author.

This article analyses AI systems, verification economics and professional workflows. It is not individual legal advice.