What vibe coding owes the commons it runs on

The curl project runs inside more software than almost anything else alive. Phones, cars, routers, payment terminals, the build tooling that ships other tooling. In 2026 the project did something that should make every operator building with AI stop for a second: it shut down its public bug bounty program, and named the reason plainly. The reports had stopped being worth reading. A rising share of them were AI-generated, confident, well-formatted, and wrong, and triaging the noise was costing the maintainers more than the real bugs were worth. This is the bill for vibe coding arriving at an address most people never think about: the maintainers of the projects underneath the stack.

The framing matters, so it is worth being precise about it. The maintainer did not say AI is bad, or that the people filing reports were acting in bad faith. The complaint was narrower and worse than that. Generation got cheap. Review did not. The gap between the two flooded a shared resource until it broke. A bug bounty is a commons. It runs on the quiet assumption that writing a report costs enough effort to keep the signal-to-noise ratio survivable. Vibe coded submissions broke that assumption. Anyone can now produce a plausible, tidy, entirely fictional vulnerability report in seconds, and the human on the other end still has to read every single one before deciding it is junk.

the real mechanism is a bandwidth mismatch

Strip the outrage and what is left is an arithmetic problem. AI lowered the cost of producing output by orders of magnitude. It did not lower the cost of verifying that output by anything close to the same factor. A person still has to read the report, reproduce the claim, and make a call. When the production rate climbs and the review rate holds flat, the queue grows without bound, and eventually the people maintaining the commons do the only rational thing left: they close the door.

This is the same shape as a thousand smaller failures happening quietly inside individual projects every day. An AI coding agent emits a thousand lines in a minute. Reviewing a thousand lines properly still takes what it always took. Teams that lean into the generation speed without scaling the review discipline do not feel the debt at first. They feel it later, when something that compiled and passed its tests turns out to do the wrong thing in production software, and nobody on the team can explain why, because nobody actually read it.

we cut our own review gates, so I owe an account

I want to be honest about something, because the curl story points a finger straight at a decision made on this very project.

VibeKoded's content pipeline used to require three separate operator reviews before a post went live. A few weeks ago that dropped to one. Not one review before. One revert after. Posts now draft, pass through an SEO pass and a revision pass, and ship to production with no human reading them in between. The only human checkpoint left is a revert command, sitting there in case something lands wrong.

Read in the worst light, that is exactly the move that broke curl's bounty queue: reduce the review checkpoints, trust the output, let volume win. So here is the account of why it is not the same thing.

The review gates that got removed were redundant with a mechanical layer that never gets tired. A pre-commit hook reads every staged post for the things a human reviewer was nominally checking: forbidden names, vendor names in the wrong surfaces, the banned constructions, the metadata contract. A schema validator refuses any post whose frontmatter does not satisfy the lead-gen invariants. These checks run on every commit, deterministically, at a cost that does not climb when volume climbs. That is the whole difference. The human gate scaled badly, in the exact way curl's reviewers scaled badly. The mechanical gate does not scale badly, because it does not scale at all in the dimension that hurts. We did not remove review. We moved it to a layer whose cost stays flat as throughput rises. When the enforcement actually gets skipped instead of relocated, the result is ugly, and I wrote up one of those days in what happens when the build skips enforcement.

when reducing review is discipline, and when it is negligence

That gives a usable rule, and it is most of the methodology in one line. You can safely reduce a review step only when something cheaper and more reliable already covers what that step was checking. Reduce it for any other reason and you are just pushing the cost downstream, onto a teammate, onto a maintainer, onto the project your code happens to depend on.

The test is mechanical, which is the point. For every review gate you want to remove, name the specific failure it catches. Then ask whether a hook, a validator, a type checker, a test, or a spec already catches that exact failure deterministically. If yes, the human gate was ceremony, and dropping it is a real win. If no, the gate was doing actual work, and removing it is how you become the person flooding someone else's queue.

This is what spec-first AI orchestration actually buys. The spec is the written contract the agent builds against, so review has something objective to measure against instead of a vibe that drifts between prompts. The gates are the mechanical layer that checks the contract on every change. SpecMesh, the discipline this whole project runs on, is that idea applied recursively: capture the spec before the build, encode the invariants as checks, and let the checks carry the review load a human cannot carry at AI speed. A vibe-coded project shipped this way still moves fast at the surface while a layer underneath measures what the surface produced. The speed is real. So is the review. They just live in different places. If you want the version of this that lives down at the code level, there is a full walkthrough of how to audit AI-generated code before you ship it.

when the workflow keeps collapsing

If your AI coding workflow keeps falling apart past the prototype, or you are scaling generation faster than you can review what comes out of it, that gap is the thing to fix before it ships something you cannot take back. Send the current workflow and the point where it tends to break. VibeKoded can scope a working-session review of where your review load is hiding, a spec-first rebuild of the orchestration layer, or a standing gate setup that carries the review at machine speed, so your team is not the bottleneck and the projects you depend on are not the dumping ground. Work with VibeKoded.

The commons only holds if the cost of contributing stays honest. Vibe coding does not have to mean offloading your review onto everyone downstream. It can mean building the layer that does the reading, so the speed is yours and the bill is not someone else's.