RFC 406i — protocole standard de rejet des contributions de pacotille générées par l’IA (RAGS)

• Document qui définit, sous une forme humoristique inspirée des RFC, un protocole standard visant à rejeter automatiquement les contributions de faible qualité générées par l’IA dans les dépôts open source, les communautés, etc.
• Fonctionne comme un moyen standardisé de signaler un refus pour « détection de slop IA », simplement en collant l’URI concernée par le mainteneur du projet
• Énumère les caractéristiques typiques des contributions générées par l’IA et pointe directement le gaspillage de ressources de maintenance ainsi que les risques liés à des productions non vérifiées
• Affirme clairement que même si des soumissions basées sur des LLM passent les tests et sont grammaticalement correctes, elles sont fondamentalement sans valeur en l’absence de compréhension de la logique et de l’architecture
• Bien qu’il s’agisse d’un document satirique empruntant le format RFC, il reflète la fatigue bien réelle des mainteneurs face aux abus de contributions automatisées par l’IA dans l’écosystème open source

---

Abstract - Objectif de ce document

• Protocole standard de traitement et d’élimination des contributions générées par l’IA et à faible effort soumises aux dépôts de code source, trackers d’issues, portails de signalement de vulnérabilités et forums communautaires
• Applicable aussi bien aux projets open source publics qu’aux systèmes internes d’entreprise

1. Introduction - Pourquoi avez-vous été redirigé vers cette page ?

• Vous avez été redirigé vers cette page parce que votre contribution a déclenché un système automatisé ou manuel de détection de slop IA
• Plus précisément, un mainteneur ou un ingénieur senior a regardé votre soumission, a poussé un « profond soupir existentiel », puis a immédiatement coupé la connexion avant de coller cette URI
• Les mots-clés « MUST », « MUST NOT », « REQUIRED », « SHALL », « SHALL NOT », « SHOULD », « SHOULD NOT », « RECOMMENDED », « MAY », « OPTIONAL » utilisés dans ce document doivent être interprétés comme une mesure de notre absence totale d’envie d’examiner cette soumission

2. Diagnostic Analysis - Caractéristiques détectées dans votre soumission

• L’analyse lexicale et structurelle du contenu que vous avez soumis conclut que votre prompt engineering est mauvais et, par conséquent, que vous devriez avoir honte de vous
• En demandant à un perroquet probabiliste d’écrire à votre place des PR, divulgations de vulnérabilités, commentaires d’issues ou messages de forum, vous l’avez laissé nous mentir à tous
• Les caractéristiques suivantes ont été détectées de manière accablante et évidente :
  • usage d’un ton excessivement poli et robotique
  • présence d’API totalement inexistantes présentées avec une grande assurance
  • code gonflé de boilerplate qui ne résout aucun problème réel
  • utilisation sérieuse de « delve » dans la description d’une PR
  • présence brute de résidus de sortie de LLM comme « Certainly! Here is the revised output: » dans les docstrings, commentaires ou rapports de sécurité
  • message de commit de 600 mots ou énorme essai théorique joint à une simple correction de typo
  • import de bibliothèques hallucinées inexistantes comme utils.helpers
  • ajout à un rapport de bug trivial d’un paragraphe de conclusion commençant par « In conclusion, this robust and scalable solution... »
  • noms de variables et de fonctions étranges et stériles qu’aucun programmeur humain alimenté à la caféine et au manque de sommeil ne pourrait produire
  • dépendance totale à des regex ou à des concepts hallucinés sans compréhension de l’architecture réelle du système ni du modèle de menace
  • traces d’un copier-coller aveugle d’énormes blocs de contexte sans rapport en réponse à un prompt du type « fix this » ou « find a bug »
  • fait de présenter des excuses au compilateur dans l’historique des commits
• Conformément au théorème fondamental du déchet automatisé : puisque vous ne l’avez pas lu, nous non plus ne le lirons pas

3. The Asymmetry of Effort - L’asymétrie de l’effort

• Les mainteneurs de projet, équipes de triage sécurité et modérateurs de communauté, qu’ils soient bénévoles non rémunérés ou collègues internes épuisés, travaillent sous de strictes contraintes de ressources
• L’examen de l’historique transactionnel de votre soumission montre :
  • a. Est-ce que cela avait l’air intelligent au premier abord ? - Peut-être
  • b. Est-ce que cela résolvait réellement un problème vérifié et reproductible ? - Non
  • c. Est-ce que cela cherchait à gaspiller le temps limité d’un relecteur humain ? - Oui
• Les trackers de projet, forums et dépôts ne sont pas des bennes à ordures pour des sorties copiées-collées non vérifiées destinées à remplir le carré vert de GitHub, récolter des bug bounties sans fondement, gonfler artificiellement la vélocité de sprint ou satisfaire de manière malveillante des KPI d’entreprise
• Vos collègues ne sont pas un service gratuit de validation de LLM

4. Resolution Protocol - Procédure de remise en état

• Pour récupérer les droits d’écriture et restaurer la confiance de vos pairs, vous devez exécuter dans l’ordre la procédure suivante :
  • 1. exécuter rm -rf sur la branche locale, le fichier texte ou le script de vulnérabilité hallucinée qui a généré cette soumission
  • 2. effectuer un redémarrage à froid de votre cerveau organique
  • 3. lire la vraie codebase, la documentation du projet ou le modèle de menace, puis vérifier manuellement votre état de travail et votre logique
  • 4. ne pas revenir avant d’avoir atteint un niveau de conscience vérifiable et d’être prêt à retaper vous-même avec des doigts humains

5. Security Considerations

• Statut : rejeté
• Diagnostic : exploitation en cours via un script Python grossièrement écrit et dissimulé sous un trench-coat
• Action : fin de connexion

6. Punitive Actions - Mesures punitives et rétrogradation de compte

• À la suite d’une soumission de slop généré par IA, votre compte a été automatiquement déplacé vers le Trough of Sorrow™ (« auge de la tristesse »), et les restrictions suivantes peuvent s’appliquer pendant la période de probation :
  • rétrogradation forcée des permissions du dépôt de WRITE à WISHFUL_THINKING
  • routage de toutes les futures PR via un modem dial-up 14.4k baud connecté à une imprimante matricielle dont le ruban cyan est épuisé à jamais
  • remappage d’un alias git afin que la saisie de git push -f exécute rm -rf / tout en jouant un son de trombone triste
  • police par défaut de l’IDE définitivement fixée à Comic Sans 7pt
• Impossible de contacter l’administrateur système — il est actuellement en train de se moquer de vous sur son canal Slack privé

7. FAQ

• « Mais qu’est-ce que ça veut dire ? » : en bref, une machine a rédigé votre soumission, et une machine est maintenant en train de la rejeter. Vous êtes un intermédiaire biologique inutile (« meat-based middleman ») dans cet échange
• « Le code compile / le rapport est détaillé / la grammaire est correcte » : une lettre de menace bien mise en forme peut en faire autant. La grammaire et la syntaxe sont le minimum requis pour une contribution, pas l’objectif ultime. Votre logique reste un délire fiévreux halluciné
• « L’IA est l’avenir de la technologie » : si cette soumission représente l’avenir, alors nous accélérerons volontiers le retour à la société agraire
• « J’essayais d’aider » : votre « aide » ressemble actuellement à une attaque par déni de service locale emballée dans une salutation polie. Si vous voulez vraiment être utile, redirigez cette énergie générative vers un dépôt que vous possédez et maintenez vous-même
• « Il n’y a aucune preuve que cela a été écrit par une IA » : l’incompétence humaine est limitée par les lois de la physique et la paresse. Votre soumission a atteint un niveau de folie grammaticalement parfaite et sûre d’elle que seules des fermes de serveurs brûlant des gigawatts d’électricité peuvent produire
• « Le CI/CD passe et les tests sont au vert » : parce que votre modèle génératif a réécrit la suite de tests pour qu’elle n’affirme rien d’autre que True == True
• « Si vous m’indiquez l’erreur, j’apprendrai » : impossible. Les mainteneurs ne sont pas un proxy inverse pour votre boucle de débogage LLM. Si vous avez besoin de feedback, recollez la stack trace dans la fenêtre de chat même qui a provoqué ce désastre
• « J’ai besoin de mon carré vert GitHub » : nous vous recommandons d’acheter un marqueur effaçable vert et de dessiner directement sur votre écran. Cela consommera bien moins notre temps tout en vous procurant le même niveau de respect professionnel auprès d’employeurs potentiels
• « Le rôle des mainteneurs open source n’est-il pas de construire une communauté accueillante ? » : leur rôle est de maintenir le logiciel. L’« accueil » s’applique aux êtres conscients qui apportent de véritables idées, pas à un botnet autonome qui régurgite probabilistiquement du texte dans un issue tracker
• « Ce message est offensant » : excellente réaction. Veuillez demander à un LLM de générer une lettre d’excuses empathique sur mesure. Les stocks de compassion sont actuellement épuisés, le SLA de support émotionnel est de 99 ans
• « Je vais signaler cette hostilité à un administrateur » : déjà anticipé ; une lettre de démission de 800 mots, générée par le LLM de votre choix, a été envoyée aux RH. Le mot « delve » y apparaît six fois, avec en prime des compliments sur le « paradigme synergique » de l’administrateur
• « C’est une violation du Code of Conduct » : le CoC protège les contributeurs humains. Selon l’analyse, vous opérez actuellement comme une fine enveloppe de viande autour d’une clé API OpenAI. Les droits sont réservés aux entités carbonées capables d’éprouver de la honte
• « Puis-je faire appel ? » : oui. Tous les appels sont routés directement vers /dev/null, avec exactement le même niveau d’attention que celui que vous avez accordé à votre propre soumission
• « Y a-t-il un moyen de m’excuser et de corriger cela ? » : oui. Imprimez la PR d’origine sur du papier épais, pliez-la en grue en papier bien pointue, puis mangez-la poliment. Ce n’est qu’alors que la guérison pourra commencer

Appendix A - Voie d’escalade

• En cas de violations répétées de la RFC 406i : révocation totale des accès au dépôt, au projet, aux outils et à tout le reste
• inscription sur liste noire d’adresse MAC
• abonnement forcé de votre adresse e-mail à un digest quotidien de tutoriels regex agressivement complexes

• Passez une excellente journée.

Appendix B - Macros de rejet standardisées

Formulations de rejet standard que les mainteneurs et reviewers peuvent copier-coller immédiatement :

• PR / MR:
  • PR closed. Votre diff se lit comme une matrice de texte prédictif qui a perdu sa fenêtre de contexte. Nous exigeons des tests manuels à base de carbone et une véritable continuité logique, pas des jeux de devinettes automatisés. Référence : https://406.fail
  • PR closed. Your diff reads like a predictive text matrix that lost its context window. We require manual, carbon-based testing and actual logical continuity, not automated guessing games. See: https://406.fail
• Issue / bug report:
  • Issue closed. Le paramètre temperature de ce rapport est réglé trop haut. Nous exigeons des stack traces brutes et reproductibles provenant d’un utilisateur conscient, pas un essai génératif proprement mis en forme qui échoue à décrire un bug vérifiable. Référence : https://406.fail
  • Issue closed. The temperature parameter on this report is set too high. We require raw, reproducible stack traces from a sentient user, not a neatly formatted generative essay that fails to describe a verifiable bug. Protocol at: https://406.fail
• Sécurité / bug bounty:
  • Report rejected. Injecter de simples avertissements de linter dans un LLM pour produire un récit catastrophiste de menace ne constitue pas une divulgation de vulnérabilité valide. Nous ne versons pas de prime pour de la panique synthétique à coût de calcul élevé. Référence : https://406.fail
  • Report rejected. Feeding basic linter warnings into an LLM to generate a catastrophic threat narrative does not constitute a valid vulnerability disclosure. We do not pay bounties for computationally expensive, synthetic panic. Refer to: https://406.fail
• Liste de diffusion / forum de discussion:
  • Thread locked. Cette communauté n’est pas un bac à sable d’apprentissage par renforcement pour vos expériences de prompt non alignées. Revenez lorsque vous saurez formuler une question en mobilisant votre propre charge cognitive. Référence : https://406.fail
  • Thread locked. This community is not a reinforcement learning sandbox for your unaligned prompt experiments. Please return when you can author a question using your own cognitive load. Diagnostics: https://406.fail

[GN⁺]

Réactions sur Hacker News

• Si vous voulez vraiment être utile, mieux vaut consacrer cette énergie à un dépôt que vous possédez et maintenez vous-même
  Les gens devraient aussi apprendre cette habitude. Publier un fork est devenu facile, mais il ne faut pas s’attendre à ce que d’autres utilisent du code qu’on n’utilise pas soi-même
  Quand on regarde les statistiques du nombre de projets auxquels un compte envoie des PR par jour sur GitHub, 99 % en envoient un, 1 % en envoient deux, et 0,1 % en envoient trois. Les comptes qui envoient 5 PR ou plus étaient presque tous des bots ou des scripts. Les bots non déclarés devraient être soumis à un rate limit

  • Dans ce cas, j’aimerais bien une fonction de mode patch permanent, où mon fork serait rebasé régulièrement sur le dépôt d’origine. Par exemple, même une correction d’une seule ligne serait automatiquement remise à jour

• Je préfère la politique IA de Ghostty
  J’aime particulièrement la phrase disant que si vous ne pouvez pas expliquer, sans l’aide de l’IA, ce que fait votre changement et quel impact il a sur l’ensemble du système, vous ne devriez pas contribuer à ce projet

  • C’est une bonne idée, mais le problème, c’est comment l’appliquer. On peut en pratique contourner ça en demandant à l’IA de l’expliquer puis en le réécrivant avec ses propres mots

• Je pense que le vrai problème, c’est que contribuer à l’open source est devenu une sorte de rite de passage
  Quand le plus important n’est plus la vraie contribution mais le simple fait de pouvoir dire qu’on a contribué, on obtient ce genre de PR superficielles. Avant, les signalements de vulnérabilités avaient un peu le même problème — des rapports du niveau de « si on met null, on obtient une NullPointerException »
  Le fait de valoriser de mauvais indicateurs, comme la vitesse de développement, est aussi un problème. Dans une ancienne entreprise, j’ai regardé les PR d’un collègue qui se vantait de développer vite grâce à l’IA, et tous les tests échouaient. Au final, c’est juste une gamification de l’assistance par IA

  • Moi aussi, je reçois en ce moment beaucoup de candidatures écrites avec l’IA. Certaines mettent en avant leurs contributions GitHub. J’imagine donc que ce type de PR passe parfois réellement. La culture qui consiste à utiliser le nombre d’étoiles d’un projet comme critère de recrutement encourage ce spam
  • Ça donne une impression du genre : « Je peux faire des maths vraiment très vite » → « Alors, combien font 137*243 ? » → « 132,498 » → « C’est faux » → « Oui, mais c’était rapide »

• Ce n’est qu’un billet de blog écrit pour s’amuser. Les personnes qui envoient des PR de mauvaise qualité avec l’IA ne lisent même pas ce genre de texte
  Ma méthode est simple :

  1. Fermer la PR
  2. Si c’est vraiment trop bâclé, bloquer l’utilisateur
     Récemment, j’ai même vu une PR qui utilisait ‘’ au lieu de '' dans une définition de chaîne, ce qui faisait échouer toute la CI. Blocage immédiat
  • Quand on ferme une PR, ce serait bien d’ajouter le lien vers cette page dans le commentaire

• Si c’est un bug, il devrait y avoir un diff rouge montrant que le correctif est vérifié, et si c’est une fonctionnalité, il faut au minimum des critères d’acceptation
  Pour la documentation, il suffit de pouvoir la lire et la comprendre. Le seuil pour être utile est assez bas

• À la question « les mainteneurs open source ne devraient-ils pas créer une communauté accueillante ? », la réponse est que ce n’est pas une obligation
  Les mainteneurs sont les propriétaires du projet et n’ont aucune obligation d’être gentils. Si ça ne vous convient pas, forkez ou partez

  • Je trouve que ce genre d’argument relève en fait presque de la manipulation émotionnelle. Mieux vaut dire : « ne nous faites pas perdre notre temps émotionnellement, et essayez de comprendre pourquoi les PR générées par des LLM sont inutiles ». Nous aussi, nous savons utiliser des LLM, et nous savons à quel point la charge de travail réelle ensuite est lourde

• C’est vraiment jubilatoire. J’aimerais que ce texte soit largement utilisé pour faire honte aux soumetteurs de PR bâclées. Le ton direct et grossier de la FAQ est même assez rafraîchissant

  • Mais ces gens-là ne ressentent pas la honte. C’est comme se mettre en colère contre un arnaqueur au téléphone — il raccroche simplement et recommence ailleurs

• Ça m’est arrivé au travail. J’ai produit avec l’IA du code pour répondre à une petite demande de fonctionnalité, mais comme je ne connaissais pas bien la codebase, je ne pouvais pas garantir sa justesse
  Avec 1 minute de prompt, 5 minutes de nettoyage et 30 minutes de revue, j’aurais peut-être pu économiser 2 jours de temps d’ingénierie, mais au final le problème était la confiance
  Après avoir entendu plusieurs avis, j’ai décidé de ne soumettre que la demande de fonctionnalité sans inclure de diff.
  Fait intéressant, les partisans de l’IA m’ont conseillé d’en utiliser encore plus pour gagner en confiance, mais à force de corriger et recorriger, le code s’est embrouillé et j’ai complètement perdu confiance

  • Si vous voulez réellement utiliser du code produit par un LLM, le mieux est de comprendre tous les changements, puis d’en rédiger vous-même un résumé à joindre à la demande de fonctionnalité
    J’ai moi aussi reçu plusieurs PR produites par des LLM, et il était impossible de dialoguer avec l’auteur ; le code ignorait les patterns existants, donc il a fini à la poubelle.
    Avec une vraie personne, on veut qu’elle explique le problème depuis son propre point de vue. C’est bien plus utile
  • Vous avez un bon instinct d’ingénierie. J’aimerais qu’il y ait plus de gens comme ça dans le secteur
  • Je ne comprends pas cette idée d’« économiser 2 jours de temps d’ingénierie ». Quelqu’un qui connaît la codebase pourrait tout aussi bien utiliser l’IA lui-même. Je ne vois pas pourquoi on essaie de faire valider par les autres la sortie de l’IA. Nous aussi, nous savons utiliser des LLM
    Article lié : un billet sur le prompting
  • J’ai une approche similaire. Quand je ne comprends pas complètement le code généré par Claude, je pose des questions comme « pourquoi tu as fait ça comme ça ? » ou « comment sont gérés les edge cases ? », et je demande de ne rien modifier, seulement d’expliquer. Comme ça, je peux vraiment me l’approprier
  • Si vous utilisez réellement cette bibliothèque, le mieux est de la tester en environnement de staging et de soumettre ensuite une revue

• J’ai adoré l’expression plonk à la fin
  Voir Plonk(Usenet)

  • Pour une BOFH Task Force, j’aurais trouvé normal qu’ils sachent faire ça

• La phrase « supprimez la branche locale ou le script débile avec rm -rf » m’a fait éclater de rire
  L’expression « redémarrez brutalement votre cerveau organique » est parfaite aussi

  • En fait, on dirait que le LLM a déjà fait un rm -rf du cerveau de ce genre d’auteur de PR