THE AI PASCAL’S WAGER by Ploum on 2026-10-01 https://ploum.net/2026-10-01-pascal_wager.html Should you accept contributions generated by LLMs in your Open Source ===================================================================== project? ======== Let’s put aside for a moment all the ethical/ecological/societal considerations about the use of generated code (also known as "slop" if you don’t like it and "vibecode" if you do) in open source projects and consider it from a simple, practical, pragmatic point of view. There are basically three potential positions: 1. Mostly accepting LLMs as neutral tools that contributors could use (with safeguards or not, with policy of human reviewing or not). 2. Finding a compromise or choosing not to do anything, issuing some "not yes, not no" guidelines. This is now known as the "Debian AI policy". 3. Strongly rejecting LLMs (with potential exceptions that have major safeguards). The middle ground (position 2) may seem like the most rational position to take. It is also the default. Let’s wait and not decide too quickly! But what we can learn from Debian is that nobody is really happy with it. If we think about it from a longer-term perspective, we can infer that the middle-ground position is unsustainable. LLM generated contributions will eventually slip in despite some guardrails such as "human review is mandatory". The longer a project stays in the "middle ground", the more ineluctable the slop infection becomes. Which is to say: not choosing or trying to choose a middle ground is basically full support of generated code, but slower. It is effectively choosing position 1 (pro-AI) without being explicit about it. It is either naive or hypocritical. Instead of letting the world choose for you, I believe that each open source project is now facing a strong choice that has to be made urgently. Accept AI-generated contributions or not. This is not easy. Both choices will alienate some part of the community and some key contributors. That’s sad, but a project cannot please everyone. Now, contributors may argue whether pro-vibecode or anti-slop is better from a philosophical, ethical or pragmatic point of view. Nobody can decide what is best for a project but its key community members. Let’s try to think from a generic strategical point of view. What will be the effects of both positions on the project? Adopting AI =========== PROS: * More contributions and less time spent developing annoying stuff. While every study on the subject tends to conclude that using LLMs is actually slower than writing code yourself, let’s admit that advantage. CONS: * Alienate a part of the community that rejects vibecoded software. In some FLOSS circles, that may include very influential users. * Developing your project become increasingly dependent of on expensive and completely proprietary software over which you have no control. So, in the short term, adopting AI mostly alienates some community members and abandons your independence in order to improve some (perceived) productivity. Rejecting AI ============ PROS: * Strong support from the “ethical” part of the community (see the growing number of anti-AI software lists) * Nothing changes. CONS: * Alienate some contributors who really want to use AI. When you think about it, contributors who are completely turned away by the fact that they can’t use LLMs are probably contributors you don’t want in your project, even if you have a Debian-like “moderate use of AI” position. People who don’t want to contribute without LLMs are probably not able to review and understand the code by themselves (or they will lose that ability soon enough). To illustrate this, see the number of Pull Requests on Github were the author admits "not having the knowledge to test their own code". So refusing contributions from those people is probably more of an advantage than a disadvantage. More importantly, rejecting AI will not alienate any users. Nobody in the world is saying "I’m refusing to use this software because it was made by humans". The longer-term perspective =========================== One of the main problems with using generated code is that we still don’t know what impact it could have in the long term. What will the codebase look like when each contribution is less and less understood by humans? What if AI assistants become suddenly too expensive to use and nobody understand the architecture anymore? What if huge portions of your code are, in fact, copy-pasted from another project using a different incompatible license? Cory Doctorow compares slop to asbestos: it looks nice, shiny and it is easy to put it everywhere. But if you ever need to regain control or remove the slop, it will take years of work, at best. Your own version of Pascal’s wager ================================== While mass marketing is trying to instil a Fear of Missing Out hysteria, the most rational and pragmatic approach is to strongly reject all AI- generated contributions to your projects. For now. Someday, we might realise that LLMs are doing good in the world, that they are evolving toward ethical, reliable, sustainable solutions, and that people who use them are happier (try to read that sentence again without rolling your eyes). If that really happens, you could always change your AI policy. It will cost you nothing. But if you let the slop in now, you may regret it forever… You may be forced to abandon your project. On the other hand, if you refuse AI-generated contributions to your project right now, the worst very hypothetical regret you could ever have is "I should probably have done it sooner". The conclusion is simple: If you are AI-agnostic, the pragmatic course of action is to strongly refuse any AI-generated contribution to your project. Picture of a Pascaline by Rama https://commons.wikimedia.org/wiki/File:Pascaline-CnAM_823-1-IMG_6513.JPG