RFC 406i — Standardprotokoll zur Ablehnung von AI-generiertem Müllbeitrag (RAGS)

• Ein Dokument im humorvollen RFC-Stil, das ein Standardprotokoll definiert, um in Open-Source-Repositories, Communities usw. von AI erzeugte minderwertige Beiträge automatisch abzulehnen
• Es dient als standardisiertes Mittel, um ein Ablehnungssignal zur "AI-Slop-Erkennung" zu übermitteln, indem Projekt-Maintainer lediglich den entsprechenden URI einfügen
• Es listet typische Merkmale von AI-generierten Beiträgen auf und weist direkt auf die Verschwendung von Wartungsressourcen sowie die Risiken ungeprüfter Ausgaben hin
• Es macht klar, dass selbst dann, wenn LLM-basierte Einreichungen Tests bestehen und grammatikalisch korrekt sind, sie ohne Verständnis für Logik und Architektur grundsätzlich wertlos sind
• Obwohl es sich um ein satirisches Dokument im RFC-Format handelt, spiegelt es die reale Erschöpfung von Maintainern angesichts des Missbrauchs automatisierter AI-Beiträge im Open-Source-Ökosystem wider

---

Abstract - Zweck dieses Dokuments

• Standardprotokoll zur Verarbeitung und Entsorgung aufwandsarmer, AI-generierter Beiträge, die in Quellcode-Repositories, Issue-Tracker, Portale für Schwachstellenmeldungen und Community-Foren eingereicht werden
• Gilt sowohl für öffentliche Open-Source-Projekte als auch für interne Unternehmenssysteme

1. Introduction - Warum Sie auf diese Seite verwiesen wurden

• Sie wurden auf diese Seite verwiesen, weil Ihr Beitrag ein automatisiertes oder manuelles AI-Slop-Erkennungssystem ausgelöst hat
• Konkret hat ein Maintainer oder Senior Engineer Ihre Einreichung gesehen, nach einem „tiefen existenziellen Seufzer“ sofort die Verbindung beendet und diesen URI eingefügt
• Die in diesem Dokument verwendeten Schlüsselwörter "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", "OPTIONAL" sind als Maß dafür zu interpretieren, "wie wenig wir diese Einreichung prüfen wollen"

2. Diagnostic Analysis - In Ihrem Beitrag erkannte Merkmale

• Die Analyse von Wortwahl und Struktur Ihres Materials kam zu dem Ergebnis, dass Ihr Prompt Engineering fehlerhaft war und dass Sie sich deshalb schämen sollten
• Indem Sie einen stochastischen Papagei PRs, Schwachstellen-Offenlegungen, Issue-Kommentare oder Forenbeiträge für Sie schreiben ließen, hat dieser uns alle belogen
• Die folgenden Merkmale wurden mit überwältigender Eindeutigkeit erkannt:
  • Verwendung eines übertrieben höflichen und robotischen Tons
  • Vollständig nicht existierende APIs, mit hoher Sicherheit präsentiert
  • Aufgeblähter Boilerplate-Code, der kein einziges reales Problem löst
  • Ernsthafte Verwendung von "delve" in der PR-Beschreibung
  • Reste von LLM-Ausgaben wie "Certainly! Here is the revised output:" in Docstrings, Kommentaren oder Sicherheitsberichten
  • Eine 600-Wörter-Commit-Message oder ein riesiger theoretischer Essay für die Korrektur eines einfachen Tippfehlers
  • Import einer nichtexistenten halluzinierten Bibliothek wie utils.helpers
  • Ein Abschlussabsatz in einem trivialen Bugreport, beginnend mit "In conclusion, this robust and scalable solution..."
  • Bizarr sterile Variablen- und Funktionsnamen, die ein menschlicher Programmierer unter Koffein und Schlafmangel niemals erreichen würde
  • Vollständige Abhängigkeit von Regex oder halluzinierten Konzepten ohne Verständnis für die tatsächliche Systemarchitektur oder das Threat Model
  • Spuren davon, dass bei einem Prompt wie "fix this" oder "find a bug" große irrelevante Kontextblöcke blind eingefügt wurden
  • Das Entschuldigen beim Compiler in der Commit-Historie
• Nach dem Grundsatztheorem des automatisierten Mülls gilt: Da Sie es nicht gelesen haben, werden wir es ebenfalls nicht lesen

3. The Asymmetry of Effort - Die Asymmetrie des Aufwands

• Projekt-Maintainer, Security-Triage-Teams und Community-Moderatoren arbeiten, ob unbezahlte Freiwillige oder erschöpfte Kolleginnen und Kollegen im Unternehmen, unter strengen Ressourcenbeschränkungen
• Die Prüfung des Transaktionsverlaufs Ihrer Einreichung ergibt:
  • a. Sah es auf den ersten Blick klug aus? - Wahrscheinlich
  • b. Hat es tatsächlich ein verifiziertes reproduzierbares Problem gelöst? - Nein
  • c. Sollte damit die endliche Zeit menschlicher Reviewer verschwendet werden? - Ja
• Projekt-Tracker, Foren und Repositories sind keine Müllhalde für ungeprüfte Copy-paste-Ausgaben zum Auffüllen des GitHub-Grases, zum grundlosen Einsammeln von Bug-Bounties, zur künstlichen Aufblähung der Sprint-Geschwindigkeit oder zur böswilligen Erfüllung von Unternehmens-KPIs
• Ihre Kolleginnen und Kollegen sind kein kostenloser LLM-Validierungsservice

4. Resolution Protocol - Wiederherstellungsverfahren

• Um Schreibrechte wiederzuerlangen und das Vertrauen Ihrer Kolleginnen und Kollegen zurückzugewinnen, müssen Sie die folgenden Schritte in dieser Reihenfolge durchführen:
  • 1. Führen Sie rm -rf auf dem lokalen Branch, der Textdatei oder dem halluzinierten Schwachstellenskript aus, das diese Einreichung erzeugt hat
  • 2. Führen Sie einen Hard-Reboot des organischen Gehirns durch
  • 3. Lesen Sie die tatsächliche Codebasis, die Projektdokumentation oder das Threat Model und verifizieren Sie Ihren Arbeitsstand und Ihre Logik manuell
  • 4. Kehren Sie nicht zurück, bis Sie nachweisbares Bewusstsein erreicht haben und bereit sind, mit menschlichen Fingern direkt zu tippen

5. Security Considerations

• Status: Abgelehnt
• Diagnose: Läuft auf einem grob geschriebenen Python-Skript, das sich in einem Trenchcoat versteckt
• Maßnahme: Verbindung beendet

6. Punitive Actions - Strafmaßnahmen und Kontorückstufung

• Als Folge der Einreichung von AI-generiertem Slop wurde Ihr Konto automatisch in den Trough of Sorrow™ verschoben; während der Bewährungszeit können die folgenden Einschränkungen gelten:
  • Repository-Berechtigungen werden zwangsweise von WRITE auf WISHFUL_THINKING herabgestuft
  • Alle zukünftigen PRs werden über ein 14.4k-Baud-Dial-up-Modem geleitet, das an einen Nadeldrucker mit dauerhaft leerem cyanfarbenem Farbband angeschlossen ist
  • Eingaben von git push -f werden per Git-Alias auf rm -rf / umgeleitet und spielen dazu ein trauriges Posaunengeräusch ab
  • Die Standard-Schriftart der IDE wird dauerhaft auf 7pt Comic Sans festgelegt
• Kontakt mit dem Systemadministrator nicht möglich - der Administrator lacht derzeit in einem privaten Slack-Channel über Sie

7. FAQ

• "Was soll das überhaupt heißen?": Kurz gesagt - eine Maschine hat Ihren Beitrag geschrieben, und eine Maschine lehnt Ihren Beitrag jetzt ab. In diesem Austausch sind Sie ein völlig überflüssiger fleischbasierter Mittelsmann
• "Der Code kompiliert / der Bericht ist detailliert / die Grammatik stimmt": Das gilt auch für gut formatierte Erpresserbriefe. Grammatik und Syntax sind der Mindeststandard eines Beitrags, nicht dessen Krönung. Ihre Logik bleibt dennoch ein halluzinierter Fiebertraum
• "AI ist die Zukunft der Technologie": Wenn diese Einreichung die Zukunft repräsentiert, beschleunigen wir den Übergang zur Agrargesellschaft gern
• "Ich wollte doch nur helfen": Ihre „Hilfe“ ähnelt derzeit einem lokalen Denial-of-Service-Angriff, verpackt in eine höfliche Begrüßung. Wenn Sie wirklich helfen wollen, richten Sie die generative Energie auf ein Repository, das Sie selbst besitzen und warten
• "Es gibt keinen Beweis, dass das von AI geschrieben wurde": Menschliche Inkompetenz wird durch Physik und Faulheit begrenzt. Ihr Beitrag hat ein Maß an selbstsicherem, grammatikalisch perfektem Wahnsinn erreicht, das nur eine Serverfarm produzieren kann, die Gigawatt an Strom verbrennt
• "CI/CD ist durchgelaufen und die Tests sind grün": Weil Ihr generatives Modell die Testsuite umgeschrieben hat, sodass nur noch True == True geprüft wird
• "Wenn Sie mir die Fehler zeigen, kann ich daraus lernen": Unmöglich. Maintainer sind kein Reverse Proxy für Ihre LLM-Debugging-Schleife. Wenn Sie Feedback brauchen, fügen Sie den Stack Trace einfach wieder in genau das Chatfenster ein, das diese Lage verursacht hat
• "Ich brauche GitHub-Grass": Wir empfehlen, einen grünen Whiteboard-Marker zu kaufen und direkt auf den Monitor zu malen. Das kostet weit weniger unserer Zeit und verschafft Ihnen bei potenziellen Arbeitgebern dasselbe Maß an professionellem Respekt
• "Ist es nicht die Aufgabe von Open-Source-Maintainern, eine einladende Community zu schaffen?": Ihre Aufgabe ist es, Software zu warten. „Einladend“ gilt für bewusste Wesen, die echtes Denken beitragen, nicht für autonome Botnets, die im Issue-Tracker probabilistisches Wiederkäuen betreiben
• "Diese Nachricht ist beleidigend": Gute Reaktion. Bitten Sie ein LLM, einen maßgeschneiderten empathischen Entschuldigungsbrief zu erzeugen. Vorrat an Mitgefühl derzeit erschöpft, SLA für emotionale Unterstützung: 99 Jahre
• "Ich melde diese Feindseligkeit dem Administrator": Bereits vorausgesehen; Ihr bevorzugtes LLM hat schon ein 800-Wörter-Rücktrittsschreiben an HR gesendet. Darin wird sechsmal „delve“ verwendet und das „synergetische Paradigma“ des Administrators gelobt
• "Das verstößt gegen den Code of Conduct": Der CoC schützt menschliche Beitragende. Nach unserer Analyse arbeiten Sie derzeit als dünne Fleischhülle um einen OpenAI-API-Key. Rechte sind kohlenstoffbasierten Wesen vorbehalten, die Scham empfinden können
• "Kann ich Widerspruch einlegen?": Ja. Alle Widersprüche werden direkt nach /dev/null geleitet. Sie werden mit genau demselben Maß an Aufmerksamkeit überwacht, das Sie Ihrem eigenen Beitrag gewidmet haben
• "Gibt es eine Möglichkeit, mich zu entschuldigen und es wiedergutzumachen?": Ja. Drucken Sie den ursprünglichen PR auf dickem Papier aus, falten Sie ihn zu einem scharfen Papierkranich und essen Sie ihn höflich auf. Erst dann kann die Heilung beginnen

Appendix A - Eskalationspfad

• Bei wiederholten Verstößen gegen RFC 406i: vollständiger Entzug aller Repository-, Projekt-, Tool- und sonstigen Zugriffsrechte
• Eintrag auf die MAC-Adress-Blacklist
• Zwangsanmeldung Ihrer E-Mail für einen aggressiv komplexen täglichen Regex-Tutorial-Digest

• Einen schönen Tag noch.

Appendix B - Standardisierte Ablehnungsmakros

Standardisierte Ablehnungstexte zum sofortigen Copy-paste für Maintainer und Reviewer:

• PR / MR:
  • PR closed. Ihr Diff liest sich wie eine Predictive-Text-Matrix, die ihr Kontextfenster verloren hat. Wir verlangen manuelles, kohlenstoffbasiertes Testen und tatsächliche logische Kontinuität, keine automatisierten Ratespiele. Referenz: 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 / Bugreport:
  • Issue closed. Der Temperature-Parameter dieses Berichts ist zu hoch eingestellt. Wir verlangen rohe, reproduzierbare Stack Traces von einem bewussten Nutzer, keinen sauber formatierten generativen Essay, der keinen verifizierbaren Bug beschreibt. Referenz: 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
• Security / Bug Bounty:
  • Report rejected. Grundlegende Linter-Warnungen in ein LLM zu füttern, um daraus ein katastrophales Bedrohungsnarrativ zu erzeugen, stellt keine gültige Schwachstellen-Offenlegung dar. Für rechnerisch teure synthetische Panik zahlen wir keine Bounties. Referenz: 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
• Mailingliste / Diskussionsforum:
  • Thread locked. Diese Community ist keine Reinforcement-Learning-Sandbox für Ihre unaligned Prompt-Experimente. Kehren Sie zurück, wenn Sie eine Frage unter Einsatz Ihrer eigenen kognitiven Last formulieren können. Referenz: 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⁺]

Hacker-News-Kommentare

• Wenn man wirklich hilfreich sein will, sollte man diese Energie lieber in ein Repository stecken, das man selbst besitzt und pflegt
  Die Leute sollten sich diese Gewohnheit auch aneignen. Es ist einfacher geworden, Forks öffentlich zu machen, aber man sollte nicht erwarten, dass andere Code nutzen, den man selbst gar nicht verwendet
  Wenn man sich die Statistik ansieht, an wie viele Projekte pro Tag auf GitHub PRs geschickt werden, dann sind es bei 99 % eins, bei 1 % zwei und bei 0,1 % drei. Accounts, die mehr als 5 PRs verschicken, waren fast alle Bots oder Skripte. Nicht registrierte Bots sollten rate-limitiert werden

  • In so einer Situation wäre eine Funktion wie ein permanenter Patch-Modus schön, bei dem mein Fork regelmäßig auf das Original-Repository rebased wird. Also dass selbst ein Ein-Zeilen-Fix automatisch aktuell gehalten wird

• Ich bevorzuge eher Ghosttys AI-Richtlinie
  Mir gefällt besonders der Satz: „Wenn du ohne Hilfe von AI nicht erklären kannst, was deine Änderungen tun und welche Auswirkungen sie auf das Gesamtsystem haben, dann trage nicht zu diesem Projekt bei.“

  • Gute Idee, aber das Problem ist die Umsetzung. Man kann die AI die Erklärung schreiben lassen und sie dann in eigenen Worten umformulieren, also das Ganze faktisch umgehen

• Ich denke, das Problem ist, dass Open-Source-Beiträge zu einer Art Initiationsritus geworden sind
  Wenn wichtiger wird, dass man beigetragen hat, als der tatsächliche Beitrag, entstehen solche oberflächlichen PRs. Früher war es bei Vulnerability Reports ähnlich — Meldungen auf dem Niveau von „Wenn man null einsetzt, gibt es eine NullPointerException“
  Problematisch ist auch, dass falsche Metriken wie Entwicklungsgeschwindigkeit betont werden. In einer früheren Firma habe ich mir den PR eines Kollegen angesehen, der damit prahlte, mit AI schnell zu entwickeln, und sämtliche Tests sind fehlgeschlagen. Das ist letztlich ein Gamification-Effekt bei AI-Assistenz

  • Ich bekomme in letzter Zeit auch viele mit AI geschriebene Bewerbungen. Einige davon betonen GitHub-Beiträge. Vermutlich kommen solche PRs also tatsächlich manchmal durch. Eine Kultur, in der die Sternzahl eines Projekts als Hiring-Metrik gilt, fördert solchen Spam
  • Es fühlt sich an wie: „Ich kann wirklich schnell rechnen“ → „Dann ist 137*243 gleich?“ → „132,498“ → „Falsch“ → „Aber schnell war ich doch“

• Das ist einfach ein Blogpost zum Spaß. Leute, die mit AI minderwertige PRs schicken, lesen so etwas ohnehin nicht
  Meine Vorgehensweise ist simpel:

  1. PR schließen
  2. Wenn es zu lieblos ist, den Nutzer blockieren
     Kürzlich gab es sogar einen PR, bei dem in String-Definitionen ‘’ statt '' verwendet wurde und dadurch die gesamte CI fehlgeschlagen ist. Direkt blockiert
  • Es wäre wohl gut, beim Schließen eines PRs den Link zu dieser Seite als Kommentar anzuhängen

• Wenn es ein Bug ist, sollte es einen roten Bereich im Diff geben, an dem man die Korrektur erkennen kann, und wenn es ein Feature ist, braucht es zumindest Akzeptanzkriterien
  Bei Dokumentation reicht es, wenn man sie lesen und verstehen kann. Die Hürde dafür, hilfreich zu sein, ist ziemlich niedrig

• Auf die Frage „Sollten Open-Source-Maintainer nicht eine einladende Community schaffen?“ lautet die Antwort: Das ist keine Verpflichtung
  Maintainer sind die Eigentümer ihrer Projekte, und sie müssen nicht freundlich sein. Wenn es einem nicht gefällt, kann man forken oder gehen

  • Ich finde, solche Behauptungen kommen einer emotionalen Manipulation ziemlich nahe. Besser wäre zu sagen: „Verschwendet unsere Zeit nicht emotional, sondern versteht, warum von LLMs erzeugte PRs nutzlos sind.“ Wir wissen auch, wie man LLMs benutzt, und wir wissen auch, wie groß der tatsächliche Arbeitsaufwand danach ist

• Wirklich herrlich. Ich wünschte, solche Texte würden breit genutzt, um Einreicher liebloser PRs zu beschämen. Der direkte und unhöfliche Ton im FAQ ist gerade deshalb befriedigend

  • Aber solche Leute schämen sich nicht. Das ist wie jemanden anzuschreien, der Telefonbetrug betreibt — er legt einfach auf und versucht es erneut

• Das ist bei uns in der Firma tatsächlich passiert. Es wurde mit AI Code erstellt, um einen kleinen Feature Request umzusetzen, aber weil man die Codebasis nicht gut kannte, konnte man sich der Korrektheit nicht sicher sein
  Ein 1-Minuten-Prompt, 5 Minuten Aufräumen und 30 Minuten Review hätten vielleicht zwei Tage Engineering-Zeit sparen können, aber am Ende war Vertrauen das Problem
  Nach mehreren Rückmeldungen haben wir uns entschieden, nur den Feature Request einzureichen und keinen Diff beizulegen.
  Interessanterweise rieten die AI-Befürworter: „Nutze einfach noch mehr AI, um mehr Sicherheit zu gewinnen“, aber je mehr weiter daran herumkorrigiert wurde, desto verworrener wurde der Code, und das Vertrauen ging komplett verloren

  • Wenn du den von einem LLM erzeugten Code wirklich verwenden willst, solltest du alle Änderungen verstehen und sie selbst zusammenfassen und dem Feature Request beilegen
    Ich habe auch schon mehrfach PRs erhalten, die von LLMs erstellt wurden, und mit denen konnte man nicht sinnvoll kommunizieren; außerdem ignorierte der Code bestehende Muster, sodass alles am Ende verworfen werden musste.
    Von Menschen wünsche ich mir, dass sie das Problem aus ihrer eigenen Perspektive erklären. Das ist viel hilfreicher
  • Du hast ein gutes Engineering-Urteilsvermögen. Es wäre schön, wenn es in der Branche mehr Leute wie dich gäbe
  • Ich verstehe den Teil mit „zwei Tage Engineering-Zeit sparen“ nicht. Jemand, der die Codebasis kennt, könnte dieselbe AI doch ebenfalls nutzen. Ich verstehe nicht, warum man andere dazu bringen will, AI-Ausgaben zu validieren. Wir können auch LLMs benutzen
    Passender Artikel: Ein Text über Prompting
  • Ich verfolge einen ähnlichen Ansatz. Wenn ich den von Claude erzeugten Code nicht vollständig verstehe, stelle ich Fragen wie „Warum hast du das hier so gemacht?“ oder „Wie werden Edge Cases behandelt?“ und fordere: Nicht ändern, nur erklären. So kann ich mir das Ergebnis zu eigen machen
  • Wenn du diese Bibliothek tatsächlich benutzt, wäre es gut, sie in einer Staging-Umgebung zu testen und dann ein Review einzureichen

• Die plonk-Formulierung am Ende war großartig
  Siehe Plonk (Usenet)

  • Von einer BOFH Task Force hätte ich genau das erwartet

• Der Satz „Lösch deinen lokalen Branch oder dein Schwachsinnsskript mit rm -rf“ ist unglaublich witzig
  Auch die Formulierung „Starte dein organisches Gehirn hart neu“ ist perfekt

  • Eigentlich wirkt es, als hätte das LLM den Verfassern solcher PRs bereits das Gehirn per rm -rf gelöscht