Ich wurde von r/rust wegen KI-Nutzung gebannt. Reden wir darüber.
Letzte Woche habe ich mein Projekt bei r/rust gepostet. Es wurde innerhalb von Minuten automatisch entfernt — nicht wegen Spam, nicht wegen Eigenwerbung, sondern weil ein Moderator mein Repository überflogen hatte und zu dem Schluss kam, es sei "KI-Schrott."
Der Beweis? Eine CLAUDE.md-Datei im Wurzelverzeichnis des Repos.
Diese Datei existiert, weil ich Claude Code als Teil meines Entwicklungs-Workflows nutze. Ich war transparent darüber. Und genau diese Transparenz hat mich auf die Abschussliste gebracht.
Die Ironie: Hätte ich die Datei einfach vor dem Posten gelöscht, hätte es niemand bemerkt. Der Code wäre derselbe gewesen. Das Projekt wäre dasselbe gewesen. Der einzige Unterschied wäre gewesen, dass ich weniger ehrlich gewesen wäre.
Das hier ist kein Beitrag, um mich über Reddit-Moderatoren zu beschweren. Sie sind Freiwillige, die mit einer echten Flut von KI-generierten Projekten ohne Substanz zu kämpfen haben. Das verstehe ich. Aber dieses Erlebnis hat etwas offengelegt, das die Entwickler-Community noch nicht durchdacht hat — und das ist wichtig.
Das Projekt
Etwas Kontext: Ich baue Perry, einen Compiler, der TypeScript in native Binärdateien übersetzt. Kein V8, kein Electron, keine Runtime. Der kompilierte Code ruft Plattform-APIs direkt auf — AppKit unter macOS, UIKit unter iOS, Android Views unter Android, GTK4 unter Linux, Win32 unter Windows.
Pry ist die erste App, die damit gebaut wurde — ein JSON-Viewer, der jetzt im Apple App Store und bei Google Play erhältlich ist. Das Projekt ist bewusst klein gehalten. Der Punkt ist nicht der JSON-Viewer. Der Punkt ist zu beweisen, dass der Compiler in der Produktion funktioniert — plattformübergreifend, in echten App Stores.
Ich habe Pry bei r/rust gepostet, weil Perrys Compiler in Rust geschrieben ist. Schien die richtige Zielgruppe zu sein.
Was "KI-unterstützt" wirklich bedeutet
Die Nachricht des Moderators war höflich. Er sagte, mein Projekt zeige "alle Anzeichen dafür, dass LLMs zum Generieren von Code oder Text eingesetzt wurden" und bat mich zu erklären, was generiert wurde und was nicht.
Faire Frage. Hier ist die ehrliche Antwort:
Ich nutze KI-Tools so wie ich jedes andere Tool in meinem Workflow nutze. Ich habe Perrys Architektur entworfen — die Kompilierungs-Pipeline, das Mapping des Typsystems, wie TypeScript auf nativen Plattformaufrufen für fünf Betriebssysteme abgebildet wird. Das sind Monate des Denkens, Prototypings, Verwerfens und Neustartens. Kein LLM hat das für mich getan. Kein LLM kann das, zumindest nicht heute.
Wo KI hilft, ist bei der Implementierung. Sobald ich weiß, was ich bauen will, kann KI mir helfen, es schneller zu schreiben. Es ist eine bessere Autovervollständigung. Manchmal deutlich besser. Aber die Richtung, die Entscheidungen, das "Was" und "Warum" — das stammt von mir.
Das ist die Unterscheidung, die im aktuellen Diskurs verloren geht: Es gibt einen gewaltigen Unterschied zwischen KI-erstellt und KI-unterstützt.
Das Spektrum, über das niemand spricht
Im Moment behandelt die Entwickler-Community KI-Nutzung als binäre Entscheidung. Man hat entweder "KI genutzt" oder nicht. Aber das ist so, als würde man fragen, ob man "das Internet genutzt hat", um etwas zu bauen. Natürlich hat man das. Die Frage ist, wie.
Hier ist das tatsächliche Spektrum:
KI-erstellt: Jemand tippt "Bau mir einen Rust-Compiler" in ChatGPT, schiebt den Output auf GitHub und postet es als eigenes Projekt. Die Person hat nichts beigetragen außer dem Prompt. Das ist es, was r/rust zu filtern versucht — und das zu Recht.
KI-unterstützte Implementierung: Ein Entwickler mit tiefem Fachwissen nutzt KI, um das Coding zu beschleunigen. Er entwirft das System, trifft die Designentscheidungen, überprüft jede Zeile und debuggt die schwierigen Probleme. Die KI ist ein Kraftmultiplikator, nicht die Kraft selbst.
KI als Dokumentations-/Testhilfe: KI nutzen, um READMEs zu schreiben, Testfälle zu generieren oder Commit-Nachrichten zu verbessern. Das macht praktisch jeder.
Das sind grundlegend verschiedene Dinge. Sie gleichzusetzen ist so, als würde man sagen, jemand der einen Taschenrechner in einer Prüfung benutzt hat und jemand, der die Prüfung von einer anderen Person schreiben ließ, haben beide "betrogen."
Unterdessen in der echten Welt
Während r/rust diskutiert, ob mein Projekt zu sehr von KI "kontaminiert" ist, um darüber zu posten, passiert in der Industrie folgendes:
Anthropics eigener CPO, Mike Krieger, hat öffentlich erklärt, dass 90–95 % von Claude Code von Claude Code selbst geschrieben wird. Das ist Anthropics wichtigstes Entwicklerwerkzeug — das sich größtenteils selbst schreibt. Unternehmensweit werden bei Anthropic 70–90 % des gesamten Codes von KI generiert. Der Erfinder von Claude Code, Boris Cherny, sagt, er habe seit Monaten keine einzige Codezeile mehr von Hand getippt und liefere Hunderte von Pull Requests, die vollständig von KI geschrieben werden.
OpenClaw — der Open-Source-KI-Assistent mit 247.000 GitHub-Sternen — begrüßt ausdrücklich "KI/vibe-codierte PRs" in seinen Beitragsrichtlinien. Es ist eines der am schnellsten wachsenden Open-Source-Projekte der Geschichte, und niemand verlangt von den Mitwirkenden, zu beweisen, dass sie jedes Zeichen von Hand getippt haben.
Microsoft berichtet, dass etwa 30 % seines Codes KI-generiert ist. Salesforce nennt ähnliche Zahlen. Ein OpenAI-Forscher erklärte öffentlich, dass 100 % ihres Codes mittlerweile KI-geschrieben ist.
Das ist kein Randverhalten. So wird Software gerade gebaut — bei den Unternehmen, die die wichtigsten Tools der Branche entwickeln. Die Frage ist nicht, ob Entwickler KI nutzen — sie ist, ob wir so tun werden, als ob sie es nicht täten.
Die Ehrlichkeitsstrafe
Was mich am meisten stört: Das aktuelle System bestraft Transparenz.
Hätte ich CLAUDE.md aus meinem Repo entfernt, "mit Liebe handgefertigt" ins README geschrieben und KI nie erwähnt — mein Beitrag wäre immer noch auf r/rust. Der Code würde sich nicht ändern. Die Qualität würde sich nicht ändern. Das Einzige, was sich ändern würde, wäre, dass ich weniger ehrlich wäre.
Wir bauen versehentlich eine Kultur auf, in der der kluge Schachzug darin besteht, seine Tools zu verstecken. Das ist rückwärts. Wir sollten Entwickler ermutigen, offen über ihre Workflows zu sein, anstatt sie dafür zu bestrafen.
Was ich mir stattdessen wünsche
Ich habe keine perfekte Lösung. Content-Moderation ist schwierig, und die Flut wirklich substanzloser KI-Projekte ist real. Aber hier sind einige Dinge, die helfen könnten:
Beurteile das Ergebnis, nicht die Tools. Funktioniert das Projekt? Ist die Architektur solide? Versteht der Entwickler seinen eigenen Code? Das sind die Fragen, auf die es ankommt. Eine CLAUDE.md-Datei sagt nichts über Qualität aus.
Frag nach den schwierigen Teilen. Wenn ein Moderator nicht sicher ist, ob ein Projekt KI-Schrott ist, soll er den Entwickler bitten, die nicht offensichtlichen Entscheidungen zu erklären. Jemand, der sich zu einem Projekt durchgeprompted hat, kann nicht erklären, warum er einen Ansatz gegenüber einem anderen gewählt hat. Jemand, der ein System entworfen hat, kann stundenlang über Abwägungen reden.
Erkenn, dass sich die Grenze weiter verschieben wird. In fünf Jahren wird es, KI-Tools nicht bei der Entwicklung zu nutzen, so sein wie 2015 kein Stack Overflow zu verwenden — theoretisch möglich, aber seltsam. Communities brauchen Richtlinien, die mit der Zeit altern können.
Weitermachen
Ich werde Perry weiter bauen. Ich werde weiterhin KI-Tools einsetzen, wo sie helfen. Und ich werde weiterhin transparent darüber sein, auch wenn diese Transparenz mich einen Reddit-Beitrag kostet.
Der Compiler funktioniert. Die Apps sind in den App Stores. Der Quellcode ist offen für jeden, der ihn lesen, kritisieren oder davon lernen möchte. Das sollte das sein, was zählt.
Wenn du Pry ausprobieren möchtest: App Store | Google Play | Quellcode
Wenn du über Perrys Compiler-Architektur sprechen möchtest, gehe ich gerne in die Tiefe. Das ist der Teil, den ich wirklich interessant finde.
Ralph Küpper ist Gründer und CEO der Skelpo GmbH, einem Softwareentwicklungsunternehmen mit Sitz in Deutschland. Er entwickelt seit 18 Jahren Software und arbeitet derzeit an Perry, einem TypeScript-zu-Native-Compiler.