Arias: Human proof for FOSS contributions

Since you're on video constantly while making attempts you might as well be on Twitch where you might even recoup a little bit of money from revenue share. Most of these communities are tiny, maybe you have fifty people peak watching your attempt at Blue Prince no-major-glitches Bequest speed running but you need to record video anyway or your attempts are just hearsay so eh, might as well. And hey, maybe you attract a following, the "hot girl bonus" factor applies on Twitch like most of life, but you might be a more entertaining watch than other players for all kinds of other reasons.

....that should be "tokens in addition to coffee"

I'd argue that according to the "Programming as Theory Building" viewpoint, there is a potentially significant difference: the presence of a complete mental model of the code in the mind of the human(s) who wrote it.

Whether that actually matters now that LLMs can quickly ingest and "understand" a new codebase and answer questions about it... isn't yet clear to me. I also don't know to what extent prompting with no or minimal coding adequately builds the mental model of how the program works.

But I don't yet find it obvious that the end product - clean, hopefully correct code - is the only value produced and that the craft of coding by hand no longer matters.

Yes, I have the same feeling: "When receiving patches from first-time contributors it is sometimes hard to determine if the person has used an LLM to write the patch, looking at the code alone.". If the LLM-written code is so good you cannot distinguish it from human code, then where is the issue?

> However, there are also other reasons to reject AI-assisted or AI-implemented contributions.

Yes, but then the focus should by put on the "other reasons" (code quality, unneeded code, ...), not on who wrote the code.

These days, anyone can give an LLM a prompt, like "download the source for PackageXYZ, find the bug that causes a crash when -A is used with -B on utf-8 input, and build a binary package I can install on Ubuntu," and the LLM does exactly that. Maybe the solution isn't perfect, but it's good enough that the user never interacts with upstream: no search to find the upstream source, no exposure to the support forums, no bug report, no opinion from the maintainer about whether the fix is correct or not. The only product is a private fork, and the LLM can maintain it indefinitely across future upgrades. Upstream never knows that this occurs.

There are two losers in this antipattern. The first is the user, who doesn't get the benefit of upstream's experience and judgement on the change (maybe it was awful), or exposure to other users who have encountered similar problems or found diverse alternative solutions (maybe the user was holding it wrong).

The second loser is the upstream project, which loses vital information about which parts of the code are irritating users enough that they seek help with redesign or fixes. In the worst case, the LLM finds a security issue, quietly fixes it in a user's private fork, and nobody gets notified. The upstream project never gets small fixes or quality-of-life improvements from casual contributors, because they're all going directly into LLM-managed workspaces. The only users visible to the project are those who have issues too severe for LLMs to resolve, and the shrinking portion of users who don't use LLMs themselves.

This effect seems to be almost invisible to project maintainers. I know it's happening because people I know personally do it, but they tend not to tell anyone else about it, for various reasons. If a user forked the project on github, the upstream maintainer might get a stray notification when two users discuss an upstream bug on one of the downstream forks. In other cases, the upstream maintainer simply stops getting contributions from new users, with no way to tell whether their users have lost interest in the project, or silently replaced the project's maintainer with a robot.

Any barrier to contribution to a project, no matter how small, will accelerate this effect. The DCO, language barriers, legal risks, internet trolls, cultural norms, and social anxiety all filter out some subset of potential project contributors who could otherwise publish their work. Now we can add competitive maintainer service from LLMs to that list.

The solution for this antipattern (assuming that attempts to eliminate all LLMs from existence are not successful) is to find incentives for the LLM users to engage with the projects at some level. Nobody wants AI slop, but many users all asking LLMs to generate the same patch to the same function is a signal: that function, or something connected to it, needs maintainer attention, because users keep tripping over it. The trick is to find a way for a small project to collect that signal in the first place, then extract it from the firehose of noise as the project gains momentum.

When a project maintainer demands invasive and irrelevant performance art as a prerequisite to making a contribution, I think most prospective contributors are not going to open up a terminal session so they can record themselves retyping perfectly adequate code by hand--regardless of whether an LLM was used. The rational response for many people is to close the browser tab, ghost the project, and warn others not to approach.

The request is not just ingratitude to a stranger that might have done a lot of human volunteer work to produce and validate a submission (not to mention salvaging the socially useful products of its electricity and water costs if LLM was involved), and is willing to support the resulting code, only to have it prejudicially refused. It's a clear signal that the project maintainer values their ideology over technical quality, and that the maintainer (and even the project's code) should be avoided for that reason alone.

The best case would be that the contributor makes a public fork with a more inclusive contribution policy, but volunteer contributors are rare enough--volunteer fork maintainers are unicorns.

I left the editor untouched with its files open for weeks or months at a time, so the asciinema recording would make Paint Drying look like a TV commercial break.