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.
I published a practical comparison of Python packages for A/B test analysis: tea-tasting, Pingouin, statsmodels, and SciPy.
Instead of choosing a single "best" tool, I break down where each package fits and how much manual work is needed for production-style experiment reporting.
Includes code examples and a feature matrix across power analysis, ratio metrics, relative effect CIs, CUPED, multiple testing correction, and working aggregated statistics for efficiency.
I was thinking about the labor market congestion problem and came up with a solution that is often used in service marketplaces: pay to apply. Then I asked myself what this solution has that AI doesn't. That’s how I arrived at the analogy that prices act as model weights: they encode market information. An important difference: prices incorporate signals from dispersed, hard-to-observe data that an AI/ML model may not access.
P.S. Paying to apply may sound provocative and require thoughtful consideration and careful testing. Payments can be made with platform-issued virtual points, available in a limited supply. But here, I focus on why price signals may address this problem better than AI-based screening.
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.