25-35% of new code in large organizations is now AI-assisted. github copilot writes ~20% of a developer's daily output. cursor and windsurf are rewriting entire architectures.

everyone's shipping faster.

but someone has to review that code. someone has to maintain it. someone has to debug it at 3am.

and those people are burning out.

i spent two weeks talking to open source maintainers, digging through github discussions, and reading security research.

here's what's actually happening.

the 12x problem

i tracked the time breakdown on a typical AI-generated pull request that got rejected:

who	action	time
contributor	generate PR with AI	25 min
maintainer	read and understand PR	25 min
maintainer	write feedback, request changes	15 min
contributor	regenerate entire PR (ignore feedback)	3 min
maintainer	re-review (weird wording) completely different code	30 min
maintainer	close PR, write explanation	15 min

(this obvi is a hypothesis)

contributor total: 7 minutes
maintainer total: 85 minutes

ratio: 12x

this is Brandolini's Law weaponized: "The amount of energy needed to refute bullshit is an order of magnitude bigger than that needed to produce it."

one maintainer told me he's stopped reviewing PRs entirely:

"i can't tell anymore which ones are real contributions and which are someone farming github activity for their linkedin."

the pattern

the same sequence keeps appearing:

contributor submits AI-generated PR
maintainer reviews, requests specific changes
contributor feeds feedback to AI, gets completely rewritten code
maintainer has to review from scratch
repeat until maintainer gives up

a maintainer on a popular obsidian plugin described it:

"the PR ignored the API docs, broke the contribution guidelines, and rewrote parts of the codebase for no reason. i spent two hours on it. the contributor had never written a plugin before and bragged about generating it in under five minutes."

the contributor got a linkedin post. the maintainer got nothing.

the resume laundering pipeline

this is what's actually happening:

generate PR in 5 minutes
screenshot the "Open" status
post on linkedin: "Just contributed to [popular project]! #opensource #AI"
PR gets rejected
doesn't matter — screenshot already posted
add "open source contributor" to resume

cost: a few dollars in API tokens, 7 minutes, 1 linkedin post
reward: credibility badge, hiring signal
who pays: the maintainer. always the maintainer.

one contractor shared this:

"we just pruned 100k lines out of a 220k line codebase after firing someone who was vibe coding everything. they seemed switched on in meetings. turned out they were running live conversations through LLMs."

that's 45% of the codebase. removed.

the new dunning-kruger

a comment from one of the reddit threads nailed it:

"It's a new kind of dunning-kruger. People use their ability in the thing to judge the AI's ability in the thing. But they don't know the thing well at all, so they think the AI did the thing well."

before AI: you had to know enough to write bad code
after AI: you don't even have to know enough to recognize bad code

the contributors submitting these PRs genuinely believe they're helping. they can't tell the difference between "code that compiles" and "code that belongs in this project."

it gets worse: synthetic vulnerabilities

the maintainer burnout problem is bad. the security problem is worse.

radware's threat intelligence team analyzed over 500,000 code samples and coined a term: "synthetic vulnerabilities" — security flaws that only appear in AI-generated code.

here's what they found:

1. AI errors are different from human errors

human mistakes tend to be low-to-medium severity — typos, minor logic flaws, a missing null check. messy but catchable.

AI mistakes are disproportionately high-severity: injection flaws, authentication bypasses, catastrophic failure modes. the code is syntactically perfect and passes the eye test. but it fails catastrophically on adversarial inputs.

2. the hallucinated abstraction problem

this is the scariest part.

LLMs don't just write bad code. they invent entirely new "mini-frameworks" that look sophisticated but are fundamentally broken.

example from the study: an LLM asked to help filter database records generated a clean, PEP-8 compliant "SQL builder" function. modern f-strings. clear variable names. looked professional.

it was a textbook SQL injection vulnerability. no escaping. no prepared statements. no validation.

the developer accepted it because it worked functionally. they didn't realize the AI had replaced a battle-tested library with a fragile, hallucinated utility.

radware calls this the "abstraction hallucination multiplier" — the AI invents helper functions that simply don't exist or are non-functional placeholders. traditional security tools don't catch it because the function call is valid syntax, even if the implementation is broken.

3. the ouroboros effect

LLMs learn from code published online. more and more of that code is now AI-generated. so:

AI generates flawed code
flawed code gets published to github/stackoverflow
next-generation LLMs train on that flawed code
models become experts at reproducing their own statistical flaws

the security baseline of all generated code is permanently declining. radware calls it "poisoning the well."

4. attackers are already exploiting this

the study found attackers are using "AI-fingerprinting" — hunting for unique code signatures that only LLMs produce.

when thousands of developers use the same prompt, they get the same vulnerable boilerplate. one exploit works on thousands of unrelated systems.

even worse: "slopsquatting." attackers monitor LLM output for hallucinated package names (packages that don't exist). then they register those names on npm/pypi with malicious payloads.

developer gets a dependency error. runs npm install hallucinated-package. installs the attacker's payload.

this is happening now.

linus can vibe code. you probably can't.

when linus torvalds uses AI to help with linux kernel development, that's not "vibe coding." that's 30+ years of context, taste, and architecture sense — amplified.

AI multiplies what you already know.

10 years of experience × AI = 10x output
0 years of experience × AI = 10x slop

the output looks the same at first glance. the difference shows up when someone else has to maintain it.

or review it.

or debug it at 3am.

or defend it against an attacker who knows exactly what the LLM got wrong.

what this means for your SaaS

if you're building a product, this matters more than you think.

1. your dependencies are maintained by volunteers

those volunteers are burning out. AI-generated PRs are accelerating it.

when left-pad disappeared in 2016, it broke thousands of builds. the next left-pad won't disappear because someone unpublished it. it'll disappear because the maintainer quietly walked away after reviewing their 50th slop PR.

2. your AI-assisted hires might be hollow

that "open source contributor" on the resume? might be rejected PRs and linkedin screenshots.

that impressive take-home project? might be AI-generated slop they can't explain.

new interview question: "walk me through a bug you personally debugged in this code."

3. your codebase is already accumulating debt

the contractor story — 100k lines pruned — is happening everywhere. quietly. the code works today. the debt compounds tomorrow.

cory doctorow called it: "Tech Debt at Scale."

4. your security surface just expanded

if your team is using AI to write code, you now have synthetic vulnerabilities. the question is how many, and whether your security tools can even detect them.

traditional SAST tools miss hallucinated abstractions. they see valid function calls, not broken implementations.

radware's conclusion: "we must stop acting as passive consumers of AI-generated code and transition into security auditors."

what actually works

talked to maintainers and engineering leads who haven't burned out yet.

for open source maintainers:

disclosure checkbox: "Was this PR generated with AI assistance? If yes, describe what you personally reviewed and tested."
issue-first policy: no PR without a linked issue that was discussed first. kills drive-by "improvements."
close faster: stop explaining. if it looks like slop, close immediately. your time is worth more than their feelings.

for hiring managers:

debug interviews: give them their own submitted code with a bug injected. watch them find it.
explain-the-trade-off: "why did you use X instead of Y here?" vibe coders can't answer this.
check the PRs: if they claim open source contributions, look at whether they were merged.

for founders:

audit your AI-written code: not whether it works. whether someone else can maintain it. whether it has synthetic vulnerabilities.
watch for the pattern: fast output, can't explain decisions, every review comment triggers a complete rewrite.
build review culture: the cost of catching slop early is 10x cheaper than pruning 100k lines later.
update your security tooling: if you're not scanning for hallucinated abstractions, you're not scanning for AI vulnerabilities.

the uncomfortable truth

AI-assisted coding works great for:

personal projects
prototypes
learning
throwaway scripts
experienced developers who can review what they generate

AI-assisted coding destroys:

collaborative codebases (when contributors can't review their own output)
open source projects (when maintainers bear the review cost)
anything someone else has to debug
anything that needs to be secure

the problem isn't AI. the problem is the 12x cost asymmetry.

you save 7 minutes. the maintainer loses 85.

the bottom line

the developers who thrive won't be the ones who generate the most code. they'll be the ones who can tell the difference between code that compiles and code that belongs.

taste scales. slop doesn't.

sources:

radware threat intelligence: synthetic vulnerabilities
cory doctorow on "tech debt at scale"
maintainer interviews and reddit/HN discussions

what are you seeing? maintainers — how are you handling the review load? founders — have you caught AI-generated slop in your codebase?

irony, adding an ai-gen image myself:

#CaseStudy #VibeCoding

Programming