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.

I'm surprised by how many people has fallen for that. I also wonder how many of them are the author's friends or bots.

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.

Disclosure: I am also the author of tea-tasting.

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.

Funny, the same) When I was switching from R (data.table) to Python, it was painful. Not only because it was slow, but because of the API. At that time, I thought that maybe it's because of switching to something new. Several years later, switching from Pandas to Polars API was a real joy (Ibis is also good is that sense). So, I learned that it had been Pandas fault all along))

Congrats! What’s impressive is not just the speed of the tools Astral develops but also the speed of delivery.

I wonder, if you plan to extend the functionality of building and publishing packages. For example, support for dynamic version (from github) and trusted publishers.

Here’s another take on the Dunning–Kruger effect. I made two main points:

1. Consider N independent observations of two variables, X1 and X2, with imperfect correlation. Next, we assign percentiles to them: P1 and P2, respectively. We then take a subsample of size N/4 with the lowest values of P1. The statistical fact, not psychological effect, is that, in this subsample, the average of P1 will always be less than the average of P2. With a large enough sample size, the difference will be statistically significant.

2. Percentile is a measure with bounded support (between 0 and 100). It's not correct to use it as a measure of abilities in this experiment. Participants from the top test score quartile can overestimate their abilities by a maximum of 24 percentiles and an average of 12 percentiles. Participants from the bottom test score quartile can overestimate their abilities by a maximum of 99 percentiles and an average of 87 percentiles. There is certainly a bias here.

The first point is not particularly new; there are published papers on this topic. However, not everyone is aware of this, so it's worth mentioning. I also provided a Streamlit app for simulations and a source code.

The second point is somewhat novel. At least, I haven't encountered any references to it in the context of the Dunning–Kruger experiment.

I also encourage you to think about the question: if a person scores the maximum number of points in a test, does this mean that they cannot overestimate their abilities?

Thank you for explanation and for drawing a vivid picture) I will add FWER and FDR to the roadmap. Which specific controlling procedures do you find the most useful on practice?

I'm considering the following: - FWER: Holm–Bonferroni, Hochberg's step-up. - FDR: Benjamini–Hochberg, Benjamini–Yekutieli.

Thank you, I'm aware of this. But I don't understand how your link answers my previous message. I was asking for example of how to fit it using only aggregated statistics (focus on "aggregated"). I'm afraid the MCMC or other Bayesian sampling algorithms are not the right examples.