A contributor opened a PR to the Zettlr project adding RTL support. +16,555 lines. −1,510 lines. When the maintainer asked them to explain the changes, they couldn’t. When asked for small, reviewable commits the response was: “just pick what you want from the pile.”

Months of back-and-forth followed. The maintainer, Hendrik Erz, eventually wrote a post called Vibe Coding: The Final Form of Hyper-Individualism. He wasn’t being dramatic. He was describing what it feels like to get code from someone who doesn’t understand it.

This is everywhere now. It’s not about whether AI is good or bad at coding. The real problem is that the open source contribution system was already fragile. Vibe coding just broke it faster.

so what do the numbers say? An analysis of 40.3 million GitHub PRs found AI agents in 14.9% of PRs by late 2025. That stat alone isn’t the issue. What matters is what comes next: almost 70% of AI-authored review feedback goes unresolved.

That’s not helping. That’s noise with a nice commit message.

tldr; maintainers hit pauseTldraw paused external contributions in January 2026. The reason? Vibe-coded PRs made reviews impossible. Reading code is already hard. Reading code someone generated but can’t explain is archaeology, not review.

Curl and Django also changed policies. Daniel Stenberg banned AI-generated security reports after none of them found real bugs. Django closes unverified AI output without reply.

These aren’t anti-AI moves. They’re self-care.

keep it human, not agent-to-agent A maintainer (st0012.dev) suggested a simple rule: Keep PRs and conversations human-to-human. Let contributors use AI privately to help write and test. But don’t let an AI agent talk directly to maintainers. Maintainer ↔ contributor ↔ contributor’s agent. Not maintainer ↔ agent.

That puts responsibility back on people.

why the volunteer model is fraying Open source used to assume contributors cared. They used the software or wanted to learn or wanted a resume line. So they read the code they submitted and could explain it.

Vibe coding broke that. Now someone can generate a big PR in 20 minutes without reading the codebase. They get the dopamine hit of “I contributed.” The maintainer gets the debugging, security holes, and the teaching bill.

Maintainers were already burned out. A 2023 survey showed many thought about quitting. Hours were undercounted. Funding was patchy. Users who never helped felt entitled.

Hector Martin resigned as Asahi Linux lead because of burnout and abuse. That was before vibe-coded PRs became normal.

Vibe coding didn’t create the problem. It made it worse, faster.

a simple fix: money = accountability bounty.new is built on one idea: when money is on the line, people act differently.

How it works:

Maintainers create a bounty for work they actually need. Set the price. Funds sit in Stripe until you approve a submission.
Contributors pick a bounty, submit a PR, and register it. If you merge, the payment releases. If you ask for changes, they iterate. If you reject it, you get refunded.

The crucial bit: payment happens only after a human maintainer reviews and approves the code. Not for opening a PR. Not for commit counts. For shipping something a real person decided was merge-worthy.

A vibe coder can still open a PR. But if they can’t explain or fix issues, they don’t get paid. The maintainer can close the PR like before — except they weren’t reviewing it for free. And someone who did the work right gets the bounty.

how this actually feels day-to-day Create a bounty on bounty.new. It syncs with GitHub. A bot comments on the issue with the amount and instructions. Contributors submit via PR like normal, then comment /submit to register.

You review. Ask for changes. Contributor updates. You comment /approve and merge. Payment comes out of our platform account.

No new platform to learn. No weird workflow. It all stays in GitHub.

why this matters beyond vibe coding

The vibe coding problem is real, but it's a symptom. The deeper issue is that open source contributions scaled faster than open source sustainability. Projects that matter to millions of people are maintained by a handful of exhausted volunteers who get nothing but entitlement from most of their users.

Bounties don't fix every problem with open source funding. They fix one specific thing: they make individual contributions sustainable.

If you're a maintainer drowning in your backlog, you can post bounties on the issues that actually matter. You pay for results, not effort. You maintain control over what gets merged.

If you're a developer who wants to contribute but also wants to get paid, you can find work that matches your skills. You don't need to beg for freelance contracts or compete on Upwork. The work is already scoped. The pay is already set. You just need to ship code good enough to get approved.

the tradeoff

This model won't work for everything. Some contributions are exploratory. Some are tiny fixes that aren't worth the overhead of a bounty. Some maintainers prefer pure volunteer energy for community reasons.

But for the issues that rot in backlogs because nobody has time - the features that would make the project better but never bubble up the priority list - bounties offer something the current system doesn't: a reason for skilled people to show up and do the work well.

That's what vibe coding destroyed: the implicit trust that a contribution came from someone who cared about the outcome. Bounties rebuild that trust through a simpler mechanism. You care because you're getting paid. You do good work because good work is what gets approved.

If you maintain a project and you're tired of reviewing garbage PRs, post a bounty. Set the price at what the work is worth to you. Get real contributions from people who understand the code they're submitting.

If you're a developer who wants to contribute and get paid, browse the open bounties. Find something you can ship. Submit work you're proud of.

The vibe coding flood isn't going to stop. But your project doesn't have to drown in it. Start your first bounty on bounty.new →

Blog

Combatting vibe-coded contributions in open source projects