[e10v_me]

In one of my previous posts, I discussed congestion in the job market caused by the surge of AI tools that scrape job descriptions and auto-apply to jobs. Since that post, another problem has emerged: progress in the capabilities of coding agents has caused a sharp rise in vibe-coded pull requests in open source repositories on GitHub. This problem can also be framed as a matching market congestion problem.

I became familiar with the problem while working in a services marketplace and solving matching-market-related problems there. That gave me direct practical experience with the typical issues. In this post, I want to share that experience and knowledge.

I explore the services marketplace, a dating platform, job search, and open source contribution through the lens of matching market design and identify a common pattern: lowering search and application costs leads to more applications, resulting in less effective matching due to reviewer overload.

I argue that just automating application screening and review with AI doesn't fully resolve the problem. In some cases, it makes it even worse by creating a self-reinforcing feedback loop: more applications → more automated filtering → even more applications. AI automation tools lack private information about applicant fit and intent.

As an alternative, I propose to redesign incentives so applicants bear more of the cost of low-value submissions and use their private knowledge to apply more carefully. The proposed solution is a reputation-credit-based system for GitHub-like platforms: non-transferable reputation credits are earned through valuable contributions and debited through low-quality pull requests and issues.

[metravod]

These are essentially Pigouvian taxes; frankly, I think they'll only serve to create a barrier for junior developers. I'm a supporter of stricter documentation requirements—ADRs, tests, and so on. And of course, the institution of reputation—contribution to the community will become increasingly important.

[e10v_me]

> I think they'll only serve to create a barrier for junior developers.

I proposed some ideas how to lower entry barriers: https://e10v.me/matching-markets-congestion/#entry-barriers-...

> I'm a supporter of stricter documentation requirements—ADRs, tests, and so on.

But what would you do if there were a lot of incoming PRs and your capacity was not enough to review if they conform to requirements?

I see more comments from projects' members that they just start banning people or closing incoming PRs. I'm not sure that helps junior developers.

[metravod]

Yes, these are sound ideas, but such a system needs to undergo a number of balancing iterations.

As for the huge number of PRs, it's an arms race. The slew of generated PRs needs to be responded to with similar automated tools—and I'm not just talking about generation, but also about deterministic checks, and with them, raising the requirements for PR formatting.

Plus, you can create a funnel of checks—from new community members to more experienced ones—which will give them the opportunity to prove themselves and build their reputation.