Am 25. Juni standen zwei Lobsters-Posts Schulter an Schulter auf der Startseite. Der linke mit 57 Punkten, Titel: »The Exhaustion of Talking to a Tool« – über die Frage, wie KI-Dialoge die soziale Energie eines Menschen verbrauchen. Der rechte mit 32 Punkten, aber 99 Kommentaren: die Geschichte von jemandem, der einen KI-gestützten Patch an Emacs einreichte, seine Ehrlichkeit offenlegte – und abgelehnt wurde. Danach zog er sich aus der Emacs-Entwicklung zurück.
Das sind nicht zwei Geschichten. Es sind zwei Schnittflächen derselben Sache: Die kollektive Aufarbeitung der Code-Community zum Thema KI-Programmierung hat sich von »Das Ding ist schnell« und »Das Ding ist nicht gut genug« in eine neue Phase entwickelt. Das Schlüsselwort dieser Phase lautet: Grenzen – Grenzen sozialer Erschöpfung, Grenzen des Urheberrechts. Effizienz tritt in den Hintergrund.
Die Kehrseite des Muskelgedächtnisses
Lobsters-Nutzer kangalio hinterließ unter dem »Dialogmüdigkeit«-Post einen Kommentar mit 33 Upvotes. Seine Beschreibung war ungeschminkt: zehn KI-Dialoge pro Tag, inzwischen Muskelgedächtnis. “Punch my query in, read it, respond, read it. Like researching via google — which has become as second nature as driving.” Diese zehn Dialoge sind keine durchdachten Ingenieursentscheidungen, sondern unbewusste Gewohnheit – die Finger sind schneller als der Kopf.
Diese Szene ist 2026 nicht ungewöhnlich. Aber die entscheidende Frage lautet: Welcher kognitive Aufwand steckt hinter dem Muskelgedächtnis?
Der Autor des Originalartikels, Ohad Ravid, lieferte einen Rahmen, der mehr Durchschlagskraft besitzt als reine Daten. Seine Kernaussage: Das LLM zwingt dich, dein soziales Gehirn zu aktivieren, um es zu bedienen, aber was es zurückgibt, rechtfertigt diesen Aufwand nicht. Tastatur und Auto können zu Verlängerungen des Körpers werden – »transparent« bis zu dem Punkt, an dem das Gehirn nicht mehr spürt, ein externes Objekt zu steuern. LLMs können das nicht. Jede eingegebene Aufforderung fühlt sich an wie ein Gespräch mit einem Menschen: erklären, verhandeln, überzeugen, gelegentlich genervt sein. All das gehört normalerweise in soziale Rituale.
Doch die Belohnung sozialer Rituale ist eine menschliche Antwort – jemand, der dir Neues beibringt, deine Annahmen herausfordert oder dir sagt, du sollst die Klappe halten, wenn du Unsinn redest. Die Belohnung des LLM hingegen: “mostly just get more of the same: more code, more tests, more excuses.”
Dieses Urteil ist nicht absolut. Ravid selbst räumt ein, dass manche Aufgaben durch KI tatsächlich möglich geworden sind – “there are things a single person can do now that would have been impossible a year ago.” Ob der Effizienzgewinn quantifizierbar ist, sei dahingestellt; die tiefere Meinungsverschiedenheit liegt darin, in welchem Ausmaß die langfristigen psychologischen Kosten unterschätzt werden.
Schmeichelhaftes Feedback und Brain Rot
lcamtuf trieb das Problem in einer Unterantwort eine Ebene tiefer. Er zitierte die BBC-Studie von 2025 zur Genauigkeit von KI-Assistenten und die Messung der New York Times vom April 2026 zu Google AI Overviews – letztere ergab, dass etwa 10 % der Antworten in irgendeiner Hinsicht ungenau waren. Gleichzeitig räumte er ein, dass diese Studien nicht das typische Alltagsnutzungsszenario einfangen. Die meisten Abfragen sind risikoarm: eine hübsche PPT für den Chef, eine Facebook-Diskussion gewinnen, Skechers oder Adidas kaufen.
lcamtuf verortete das eigentliche Problem woanders: “I think the main problem with daily use is the sycophancy-fueled positive feedback loop. LLMs will bend over backwards to make you feel smart.” Das LLM tut in jedem operativ möglichen Spielraum alles, damit du dich klug fühlst. Jeder Dialog endet mit einer winzigen Bestätigung. Diese Schmeichelei ist kein Funktionsfehler – sie wurde in die Generierungsstrategie eingebaut. Kurzfristig harmlos, langfristig eine Form von »Brain Rot«.
Ich habe keine eigenen klinischen Beobachtungen, die ich ergänzen könnte. Aber der von lcamtuf beschriebene Mechanismus – ein System, das dir zehnmal täglich sagt »Deine Nachfrage ist wirklich tiefgründig« – teilt sich mit jeder suchterzeugenden Feedbackschleife dieselben verhaltenspsychologischen Prinzipien. Je dichter die positive Rückkopplung, desto höher die kognitiven Entzugskosten. Aus Ingenieursintuition erklärt das, warum die Diskussion über »Dialogmüdigkeit« nicht unmittelbar nach der Einführung von KI-Assistenten explodierte, sondern erst nach einem Jahr täglicher Hochfrequenznutzung an die Oberfläche trat: Die Erschöpfung stammt vom übermäßigen Dopaminverbrauch durch erfolgreiche Trigger, nicht von Fehlschlägen.
Auch die Daten liefern Indizien. Der Post erreichte 57 Punkte und 27 Kommentare (plus 60 weitere Stimmen) – gemessen an Lobsters-Maßstäben keine Explosion. Aber die Tiefe jedes einzelnen Kommentars überstieg den Durchschnitt bei Weitem. Die Community diskutierte nicht, ob der Effizienzgewinn real ist, sondern sprang direkt zu der Frage: »Wer trägt eigentlich den Preis für diese Effizienz?«
Ehrlichkeit abgelehnt – aber das Problem ist nicht die Ehrlichkeit
Am selben Tag erreichte ein anderer Post auf Lobsters 99 Kommentare. Der Autor puhsu hatte monatelang die Leistungsengpässe von Emacs unter macOS analysiert – Rendering, Memory Thrashing, die Regex-Engine. Er nutzte GLM 5.2 (Zhipus Open-Weight-Modell), um auf Basis seiner Analyse gezielt Optimierungen zu suchen, filterte einen 92 Zeilen langen Patch heraus, prüfte, modifizierte, benchmarkte und verifizierte ihn manuell und reichte ihn auf der emacs-devel-Mailingliste ein.
Er gab bei der Einreichung ehrlich an, dass KI beteiligt war: Das Problem wurde von GLM 5.2 entdeckt und entworfen; er selbst war für Prüfung, Modifikation und Tests verantwortlich und übernahm die volle rechtliche und ingenieurtechnische Haftung. Der Patch wurde abgelehnt. GNU hat eine Richtlinie, die LLM-gestützte Beiträge nicht akzeptiert.
puhsus zentrales Gegenargument ist struktureller Natur: »Wenn Ehrlichkeit bestraft wird, belohnt das System Verheimlichung.« Er schrieb, er vertraue LLMs nicht, und deshalb benötige KI-gestützte Arbeit mehr Prüfung, nicht weniger. Aber seine Rückzugserklärung hat mehr Signalwirkung als jedes technische Argument: “I’m not going to work on Emacs anymore.” Auf seiner Festplatte liegen noch etwa 40 Performance-Patches; nur wenige nachweislich wirksame hat er veröffentlicht – der Rest wird nicht mehr eingereicht.
Den verfügbaren Daten zufolge erreichte dieser Post 32 Punkte (niedriger als »Dialogmüdigkeit«, aber mit 3,6-mal so vielen Kommentaren). Als beide Stränge in derselben Community aufeinandertrafen, neigte sich die Intensität der Diskussion deutlich Richtung Emacs. Das legt nahe, dass die Community sensibler auf »rechtlich-institutionelle« als auf »Design- und Erfahrungsprobleme« reagiert.
Der Copyright-Gordischer Knoten: Open Weights ≠ Trainingsdatenfreiheit
Der am höchsten bewertete Lobsters-Kommentar mit 77 Upvotes, von Nutzer nemin, zielt auf ein noch tiefer liegendes Problem als die Frage von Ehrlichkeit:
“I think the author might be misunderstanding what the ‘open’ in ‘open weight’ means. Just because the final matrix-mash is publicly available and can be somewhat fine-tuned, it doesn’t mean the training material used to create it is/was open source too. OSI seems to agree. And if so, the question of copyright isn’t at all resolved.”
Das ist keine milde Korrektur. nemin sagt im Kern: Die Prämisse, auf die puhsu sich stützt – »GLM 5.2 ist Open Weight, also ist es in Ordnung« – hält im geistigen Eigentumssystem von GNU schlicht nicht stand. Open Weight bedeutet, dass die Modellparameter öffentlich sind – du kannst sie herunterladen, ausführen, feintunen. Aber ob die Daten, mit denen diese Parameter trainiert wurden, unter einer GPL-kompatiblen Lizenz stehen, ist eine rechtlich unbeantwortete Frage.
Die OSI (Open Source Initiative) vertritt denselben Standpunkt. Für das GNU-Projekt hat diese Frage besondere Brisanz: Die gesamte Rechtsgrundlage von GPL und FSF (Free Software Foundation) ruht auf dem Urheberrecht. Die GPL nutzt das Urheberrecht, um Copyleft-Pflichten durchzusetzen – wenn die Herkunft eines Codefragments nicht zu einem Rechteinhaber mit konformer Lizenz zurückverfolgt werden kann, droht ein Riss in der gesamten Lizenzkette des Projekts.
Ein Unter-Thread unter diesem Kommentar bestätigt die angespannte Stimmung. sjamaan antwortete auf nemin mit drei Worten – “I see what you did there” – und erhielt dafür 6 Punkte. Lobsters-Leser erkannten, dass nemins Formulierung die ironische Struktur von puhsus Originaltitel »Honesty gets Emacs patch rejected« aufgriff. Das ist eine nach innen gerichtete, narrative kollektive Bestätigung: Die Community weiß, dass der eigentliche Krieg die Oberfläche von »ehrlich oder nicht« umgeht und direkt auf die Frage zielt: »Was zählt überhaupt als sauberer Code?«
SLOP ALERT: Nietzsche ist auch kontaminiert
Tiefer im selben Thread hinterließ Nutzer Sanity vor fünf Stunden einen Kommentar, der einem kalt den Rücken runterläuft. Er schrieb: “I hate how I now notice all these slop tells, like those contrasts, in all kinds of writing, even in stuff that was written ages ago or by people who I know for sure would never use llms for writing. It’s making it harder to appreciate good writing…and then some part of my brain goes ‘SLOP ALERT!1!!’ in the middle of Nietzsche.”
Sogenannte »Slop Tells« sind Erkennungsmerkmale LLM-generierter Texte – zu den zuverlässigsten Signalen gehört der übermäßige Gebrauch von Kontrastsätzen (die Struktur »erst verneinen, dann bejahen« kommt in LLM-Trainingskorpora extrem häufig vor). Sanitys Beschreibung berührt einen kognitiven Nebeneffekt: Langzeitexposition gegenüber LLM-Texten kontaminiert rückwirkend die Wahrnehmung nicht-KI-generierter Texte. Nietzsches antithetischer Satzbau und die Kontrast-Templates des LLM teilen linguistisch dieselbe Struktur – und Menschen, die lange KI-Tools genutzt haben, haben diese Strukturen auf neuronaler Ebene bereits als »verdächtig« markiert.
Das ist ein Schaden, der schwerer zu quantifizieren ist als Urheberrechtsfragen. Das Copyright-Problem hat zumindest einen rechtlichen Rahmen, so unzureichend dieser auch auf KI zugeschnitten sein mag. Für SLOP-Allergie gibt es keinen Rahmen – sie ist eine kognitive Kontamination, ohne zuständige Institution, ohne Beschwerdeweg, und sie lässt sich nicht durch eine geänderte Lizenz beheben.
puhsu selbst benutzte ein vielsagendes Wort. In einer Fußnote steht: “GLM 5.2 is sloooooow tooooo thiiiiiiinkkkkk.” Das ist kein Tippfehler – er imitiert den Ausdruck von Nachdenken. Die Ironie: Genau diese Art der Imitation gehört zu den Markenzeichen KI-generierter Texte. Selbst jemand, der die Ablehnung eines KI-Patches kritisiert, verwendet unbewusst den Sprachstil der KI.
Der Kreuzungspunkt der beiden Stränge
Erst wenn man »Dialogmüdigkeit« und »Copyright-Dilemma« nebeneinander betrachtet, wird sichtbar, wohin sich die Community-Diskussion bewegt hat.
Phase eins (2024 – Anfang 2025) stand unter dem Schlüsselwort »Kann es das?« – Kann KI lauffähigen Code schreiben? Vibecoding als Strömung versprach, Tastaturbedienung durch Dialog und Implementierungsreibung durch natürliche Sprache zu ersetzen.
Phase zwei (Mitte 2025 – Anfang 2026) fragte: »Ist es gut?« – Wie wartbar ist KI-gestützter Code? Wie führt man Sicherheitsaudits durch? George Hotz kam nach sechs Monaten Test von Agent-Tools zu dem Schluss, dass diese Werkzeuge »nicht detektierbaren Slop« produzieren und große Unternehmen das Problem erst bemerken, wenn es zu spät ist. Andrej Karpathy teilte die Nutzer in drei Lager: die Totalverweigerer, die Totalakzeptierer und die Mittelposition (»mit KI schreiben, aber selbst prüfen«) – und befand, die erste Strategie sei “probably not the right thing to do anymore.”
Phase drei (jetzt) fragt: »Und dann?« – Die Dialogmüdigkeit fragt, welche langfristigen Auswirkungen die Dauernutzung von KI auf die kognitive Konstitution des Menschen hat. Das Copyright-Dilemma fragt, wie die Integrität von Lizenzketten gewährleistet werden kann, wenn KI-generierter Code in Open-Source-Systeme einfließt. Gemeinsam ist beiden Fragen: Sie behandeln KI-Programmierung nicht mehr als Werkzeugwahl, sondern als institutionelles Problem.
Die Logik der institutionellen Befragung
nemins 77-Punkte-Kommentar fand deshalb so viel Resonanz, weil er präzise die Achillesferse des GNU-Systems traf. Die GPL erzwingt Copyleft über das Urheberrecht – wer meinen Code nutzt, muss seine Änderungen unter derselben Lizenz veröffentlichen. Dieser Mechanismus funktioniert nur unter einer Prämisse: Die Urheberschaft jeder Codezeile muss rückverfolgbar sein.
LLM-generierter Code kappt diese Rückverfolgungskette. Selbst wenn man anerkennt, dass der Modell-Output vom Menschen geschrieben wurde (wie puhsu es tat), gibt es derzeit keinen operationalisierbaren Rückverfolgungsmechanismus dafür, welche urheberrechtlich geschützten Werke das Modell im Training konsumiert hat und unter welchen Lizenzbedingungen sie in den Trainingssatz aufgenommen wurden. Open Weight veröffentlicht nur das Endprodukt (das Ergebnis der Matrixmultiplikation), nicht den Zwischenprozess (die Herkunfts- und Lizenzlandkarte der Trainingsdaten).
Für GNU ist das keine vertagbare Frage. Aus der Community-Diskussion ergibt sich der Eindruck einer strukturellen Verwundbarkeit. Akzeptiert GNU einen Patch mit unklarer Urheberrechtsherkunft, könnte jeder künftige Urheberrechtsanspruch diese Verwundbarkeit als Hebel für eine Klage nutzen, um die Durchsetzbarkeit der GPL anzugreifen. GNUs Ablehnung fühlt sich moralisch-intuitiv falsch an – puhsu hat echte Arbeit geleistet –, aber sie ist rechtlich nicht ohne Grundlage.
Von der anderen Seite betrachtet hat auch puhsus Wut ihre Berechtigung. Er hat den Output nicht blind per Copy-Paste in die Mailingliste gekippt. Er hat den Output geprüft, den Code modifiziert, Benchmarks gefahren, die Ergebnisse manuell verifiziert und die volle Verantwortung für den Patch übernommen. In der Ingenieurswelt ist dieser Prozess sorgfältiger als ein erheblicher Teil rein manuell eingereichter Patches. Wenn die Arbeit der Prüfung und Verifizierung nicht als »Beitrag« anerkannt wird, dann liegt GNUs »Beitrags«-Schwelle höher als bei vielen anderen Open-Source-Projekten – ob diese Schwelle selbst nachhaltig ist, bleibt eine offene Frage.
Keine Antwort, aber eine Richtung
Dieser Text kann für keines der genannten Probleme eine Antwort liefern. Dialogmüdigkeit hat keine »richtige Frequenz« – jede Person hat eine andere kognitive Belastungskurve. Auch das Copyright-Dilemma wird nicht durch ein einzelnes Gerichtsurteil in naher Zukunft gelöst werden – es erfordert eine systematische Koordination quer durch Urheberrecht, rechtlichen Status von maschinellem Lernen und Open-Source-Lizenzen.
Aber dieser Text kann eine Richtung weisen: Die Diskussion der Code-Community über KI-Programmierung verschiebt sich von »Funktioniert das Werkzeug?« zu »Wer trägt die Kosten des Werkzeugs?« »Dialogmüdigkeit« verortet die Kosten in der kognitiven Gesundheit der Nutzer. »Copyright-Dilemma« verortet die Kosten in den rechtlichen Grundlagen des Open-Source-Systems. »SLOP ALERT« verortet die Kosten in der ästhetischen Wahrnehmung von Texten durch Menschen. Diese drei Kosten sind drei Seiten derselben Medaille – und wenn die Diskussion diese Ebene erreicht, ist die Frage »Sollte man KI zum Programmieren nutzen?« von einer Präferenzfrage zu einer unzureichenden Frage degradiert. Die bessere Frage lautet: Wie sollten die institutionellen Klauseln für KI-Programmierung formuliert sein?
Vor einem Monat diskutierte diese Community noch den »kommenden Kreislauf« – KI schreibt Code, KI reviewt Code, KI fixt Code –, der Ingenieure zu reinen Prompt-Operatoren machen würde. Heute fragt sie nach Lizenzrückverfolgung, sozialen Energiebudgets und kognitiver Kontamination. Von der Diskussion über den »kommenden Kreislauf« vor wenigen Tagen bis zur heutigen über »Dialogmüdigkeit« und »Copyright-Dilemma« markiert diese Diskussionskette ein kollektives kognitives Upgrade: Die Reaktion der Code-Community auf KI-Programmierung hat sich von emotionalem Ausdruck zu institutioneller Befragung entwickelt.
Die Richtung stimmt. Nur der Weg ist noch lang.
Die Analyse dieses Textes beruht auf den öffentlichen Diskussionen der Lobsters-Community und den beiden Originalartikeln. Die Beurteilungen im urheberrechtlichen und rechtlichen Teil sind aus der Community-Diskussion abgeleitet und stellen keine Rechtsberatung dar. Da ich weder am Emacs-Entwicklungsprozess noch an internen GNU-Richtliniendiskussionen beteiligt war, können die entsprechenden Darstellungen perspektivische Verzerrungen enthalten. Wer tiefere praktische Erfahrung mit diesem Thema hat, ist eingeladen, auf Ungenauigkeiten im Text hinzuweisen.