AI didn’t just speed up writing software. It inverted the economics of open source — and made review, not code, the scarce resource.
For a growing share of contributions, it’s now easier to re-generate a pull request from scratch than to review the one someone sent us. That’s a strange thing to say out loud, but it captures something real that’s happening to open source in the age of coding agents, and it’s forcing us to rethink processes we’ve taken for granted for a decade.
The old bargain #
Open source ran on a simple trade. Writing code was a scarce, expensive skill. When someone showed up with a working patch, they were handing you hours of that scarce resource for free. Reviewing it took time, sure, but review was cheaper than authorship. The contributor did the hard part.
That bargain is inverted now. Generating code is cheap and fast, but judgment isn’t. So a contribution that used to save maintainer time can now cost it, because reviewing a plausible-looking AI-generated diff can take longer than writing the change yourself.
And the diffs are very plausible, which is the trap. A polished PR description, a clean screenshot, a confident summary of what was tested — all of it is easy to produce and hard to verify. We’ve had PRs where the description said it was tested, with a nice screenshot, and then the actual code was building queries against a data warehouse the contributor almost certainly couldn’t run locally. The presentation was flawless. Whether it worked was anyone’s guess.
What review actually costs now #
When code was expensive, “does this diff look reasonable?” was a good enough filter. Now it isn’t, and the reasons are worth naming:
Local coherence, global blindness. An agent solves the one case in front of it. It doesn’t know that the CLI change also needs to land in the VS Code extension, or that a one-line “fix” is a hack that papers over the real problem.Plausibility is free. Every AI PR looks like it might be fine. That’s exactly why auto-closing them with another bot doesn’t work. There’s no model with good enough judgment to tell a genuine improvement from a well-dressed dead end.Staleness compounds. In a fast-moving repo, a PR left open for a few days needs rebasing, and the rebase-and-fix work can dwarf the original change.Security hides in the noise. When volume goes up, the sketchy PR — the one quietly trying to weaken something — is easier to miss.
Faros AI’s research on teams adopting AI tools found review time climbing sharply as PR count and size grew. That’s the same dynamic, just inside your own org: more output, less throughput, unless review scales with it.
What’s still worth a lot #
None of this means contributions are worthless. The valuable part just moved.
The signal we actually trust now is evidence that a human sat with the change: tested it themselves, tried the edge cases, understood how it fits the wider product. A contributor who has done that repeatedly earns trust, and their PRs get merged. A first-time contributor who opens eight PRs in a day is sending the opposite signal.
What saves maintainer time is no longer the code itself. It’s the intent behind it, the proof it works, and a clear sense of how it fits. The PR is the least interesting artifact in that list.
What this changes about process #
We’re still figuring this out — genuinely inventing what open source looks like when code is cheap. A few directions we’re leaning into:
Issue-first, not PR-first. Pitch the intent before writing the diff. It’s a lot cheaper for everyone to align on “do we even want this, and how should it work” before someone burns effort on an implementation we won’t merge.Be honest about source-available vs. open source. There’s a real difference between “you can read and fork this” and “we’ll shepherd every contribution to merge.” We have a company built around the product; pretending otherwise just leads to contributors feeling ghosted.Enforce the minimum bar with automation, not human nagging. Requiring a linked issue, tests, or validation shouldn’t cost a maintainer their afternoon. Machines can hold that line.But keep humans on judgment. Deciding whether a change is worth having — whether it fits the product, whether the quality is there — is exactly the thing agents are bad at. That stays with us.Communicate like a person. The one thing that’s not negotiable: if you pick up a review, you own it to the end, whether that’s merge, close, or hand-off. A clearly bot-written brush-off is worse than a direct “no, not right now.” If someone put in the work, they deserve a real answer, fast.
Why not just use our own agent? #
There’s a version of this that ends with “so why not just point our own agent at the good issues instead of waiting for contributors?” It’s a fair question, and the honest answer is that sometimes we should. The case for a human community isn’t that it’s cheaper anymore, because it often isn’t. It’s that some changes span multiple systems or need eyes on something visual that bots still get lost in, and that a healthy community is worth something to the brand and the product even when it costs time.
But the strategy only works if we’re extremely clear about what we want, and we stop pretending the old bargain still holds. Code got cheap. Review didn’t. Build your process around the resource that’s actually scarce.