Eine Szene aus Idiocracy geht mir seit Jahren nicht aus dem Kopf. Darin gießen Menschen ihre Pflanzen mit einem Sportgetränk namens “Brawndo” statt mit Wasser. Fragt man sie warum, kommt immer dieselbe Antwort: “But it’s got electrolytes!” Niemand weiß, was Elektrolyte sind. Niemand versteht, warum Pflanzen Wasser brauchen. Aber der Satz klingt überzeugend. Wenn man ihn oft genug hört, wird er irgendwann zur Wahrheit.
An diese Szene musste ich denken, als ich diesen Kommentar in einer Hacker-News-Diskussion gelesen habe:
“LLMs empower those without the domain knowledge or experience to identify if the output actually solves the problem. I have seen multiple colleagues deliver a lot of stuff that looks fancy but doesn’t actually solve the prescribed problem at all. It’s mostly just furniture around the problem.”
Furniture around the problem. Besser kann man es kaum sagen.
Das Möbelproblem
Ich sehe dieses Muster seit Monaten. Im Alltag, in Open-Source-Projekten, in Pull Requests. Jemand bekommt eine Aufgabe wie: “Implementiere eine Cache-Schicht für die API.” Was zurückkommt, sieht beeindruckend aus: Redis-Integration, TTL-Konfiguration, Cache-Invalidierung, Monitoring-Dashboards, Performance-Metriken, Tests, Dokumentation, sauber zusammengebaut.
Nur löst es das eigentliche Problem nicht. Denn das eigentliche Problem war nicht die fehlende Cache-Schicht. Es war eine N+1-Query im ORM, die pro Request 200 Datenbankabfragen ausgelöst hat. Der Cache kaschiert das Symptom. Die Ursache bleibt genau da, wo sie war.
Ohne Fachwissen sieht man den Unterschied nicht. Mit KI-Werkzeugen kann man heute eine sehr überzeugende Lösung für das falsche Problem produzieren. Schneller und überzeugender als je zuvor.
Das Problem ist nicht, dass das Ergebnis schlecht aussieht. Das Problem ist, dass es gut aussieht. Gut genug, dass niemand mehr fragt, ob es das richtige Problem löst. Je besser die KI wird, desto schwerer wird es, Substanz von Dekoration zu trennen.
Wie das Denken kippt
Der Hacker-News-Kommentator benennt noch ein zweites Phänomen. Ich halte es für fast noch gefährlicher:
“The second major problem is corrupting reasoning outright. I see people approaching LLMs as an exploratory process and letting the LLM guide the reasoning.”
Wenn man ein LLM als Denkwerkzeug für ein unscharf beschriebenes Problem benutzt, passiert etwas Heimtückisches: Das Modell zieht die Überlegungen langsam in eine andere Richtung. Es schlägt Wege vor, die plausibel klingen, aber nicht wirklich zum Problem passen. Es liefert Lösungen, die elegant wirken, aber Annahmen einschmuggeln, nach denen niemand gefragt und die niemand geprüft hat.
Weil das Modell so flüssig argumentiert, merkt man oft zu spät, wann man aufgehört hat, das ursprüngliche Problem zu lösen, und angefangen hat, dem Modell hinterherzulaufen.
Das ist kein Fehler im Modell. Das ist die Natur probabilistischer Textgenerierung. Sie optimiert auf Plausibilität, nicht auf Korrektheit. Plausibilität ist aber ein miserabler Kompass, wenn Präzision gefragt ist.
In einer anderen Hacker-News-Diskussion hat es jemand gut auf den Punkt gebracht: KI ist kein Kollege. Sie ist ein Exoskelett. Sie verstärkt das, was schon da ist. Wenn man weiß, wohin man will, kommt man schneller ans Ziel. Wenn man es nicht weiß, läuft man schneller in die falsche Richtung. Mit mehr Kraft und weniger Kontrolle.
Das Elektrolyt-Argument
Am meisten beunruhigt mich, wie leicht Kritik an KI-generiertem Output beiseitegeschoben wird. Der Kommentator beschreibt das perfekt:
“And the retort when I have to evaluate what they have done is ‘but it’s so powerful’. I stopped listening. It’s a pure faith argument without any critical reasoning.”
“But it’s so powerful.” Das sind die Elektrolyte unserer Branche.
Es geht dann nicht mehr darum, ob das Ergebnis das Problem löst. Es geht nur noch um die angebliche Macht des Werkzeugs. Das Tool kann Rust und TypeScript. Das Tool hat den Code in zehn Sekunden geschrieben. Das Tool hat Hunderte Millionen oder Milliarden Parameter. Also muss das Ergebnis gut sein.
Das ist kein Argument. Das ist Techno-Animismus: der Glaube, dass ein hinreichend mächtiges System automatisch richtige Ergebnisse produziert, und dass die Komplexität des Werkzeugs schon irgendwie die Qualität des Outputs garantiert.
Hier kommt eine spezielle Mischung zusammen: selbstverursachte intellektuelle Unredlichkeit, irrationaler Glaube und Vorführung fürs Publikum. Das Ergebnis wird nicht danach bewertet, ob es das Problem löst, sondern danach, ob es Eindruck macht.
Wenn das Ergebnis Unsinn ist
Je länger ich mit KI-Coding-Agenten arbeite, desto klarer wird mir ein Punkt:
Wenn das Ergebnis Unsinn ist, hat der Mensch das Problem trotzdem.
Nicht das Modell. Das Modell tut genau das, wofür es gebaut wurde: plausiblen Text aus dem Input erzeugen, den es bekommt. Wenn der Input unvollständig, mehrdeutig, fachlich falsch oder einfach zu dünn ist, dann spiegelt der Output genau das wider. Aus schlechtem Input wird dann eben eleganter Müll.
Ein LLM ist darauf trainiert, hilfreich zu sein. Es ist nicht darauf trainiert, einem zu sagen: “Deine Frage ist schlecht gestellt. Du hast das Problem nicht verstanden. Geh zurück und denk noch mal nach.”
Genau deshalb erzeugen unzureichende Anweisungen keinen Widerstand. Sie erzeugen eine polierte Antwort. Immer. Und genau das macht diese Systeme für Menschen gefährlich, die nicht zuverlässig zwischen “sieht gut aus” und “löst das Problem” unterscheiden können.
Das Exoskelett-Gegenargument
Es gibt hier ein starkes Gegenargument, und das verdient eine ehrliche Antwort.
Natürlich gibt es Junior-Entwickler, die durch Copilot-Vorschläge Muster lernen, denen sie sonst vielleicht monatelang nicht begegnet wären. Sie sehen, wie ein Repository Pattern aussieht, wie Dependency Injection strukturiert wird, wie ein sauberer API-Endpunkt gebaut ist. KI kann Lernen ganz real beschleunigen.
Das funktioniert aber nur dann, wenn die Person aktiv versteht, warum der Vorschlag so aussieht, wie er aussieht. Wenn sie ihn liest, hinterfragt, verändert. Wenn sie das Werkzeug als Lehrer benutzt und nicht als Ghostwriter. Der Vorschlag ist nützlich als Ausgangspunkt, solange er ein Ausgangspunkt bleibt.
Das Problem beginnt dort, wo Verstehen endet und Abnicken beginnt. KI-Werkzeuge sind so gebaut, dass diese Grenze fast unsichtbar wird. Es gibt keinen Moment, in dem das Tool sagt: “Hier hast du aufgehört zu denken.” Der Output sieht gleich aus, ganz egal, ob der Mensch ihn verstanden hat oder nicht.
Die Frage nach Verantwortung
Wenn man diesen Gedanken zu Ende verfolgt, landet man bei einer Frage, um die sich die Branche noch immer drückt:
Wenn der Mensch die Anweisungen gibt und das Modell den Code schreibt, wer trägt dann die Verantwortung, wenn dieser Code Schaden anrichtet?
Heute ist die Antwort klar: der Mensch. Wer Code in Produktion bringt, besitzt auch die Verantwortung dafür.
Aber was passiert, wenn die Ketten länger werden? Wenn ein Agent an Sub-Agenten delegiert, die eigene Entscheidungen treffen? Wenn der Mensch am Anfang der Kette das Ergebnis im Detail gar nicht mehr rekonstruieren kann?
Eine zugespitzte, aber nicht absurde Zukunftsfrage wäre diese: Wenn wir eines Tages AGI haben und sich ein konkretes Ergebnis keinem klar identifizierbaren menschlichen Autor mehr zuordnen lässt, wer bekommt dann die gerichtliche Verfügung? AGI, Datacenter Oregon, Stockwerk 5, Rack #10202?
Die Frage klingt satirisch. Das Problem dahinter ist es nicht. Verantwortung verschwindet nicht einfach, nur weil Verständnis verschwindet. Sie wird dann nur verantwortungslos ausgeübt. Wer Code in Produktion bringt, bleibt verantwortlich, ob er ihn verstanden hat oder nicht. KI-Werkzeuge machen es nur sehr viel leichter, Ergebnisse zu produzieren, für die man gerade stehen muss, ohne sie wirklich zu durchdringen.
"But it has electrolytes" ist kein Argument. Nicht für Pflanzennahrung und nicht für Softwarearchitektur. Die Frage ist nicht, wie mächtig das Werkzeug ist. Die Frage ist, ob man das Problem verstanden hat, bevor man zum Werkzeug gegriffen hat.
Was bleibt
Ich bin nicht gegen KI-Werkzeuge. Ich nutze sie jeden Tag. Aber ich nutze sie als das, was sie sind: Werkzeuge, die mein Verständnis umsetzen, nicht Werkzeuge, die es ersetzen.
Der Unterschied zwischen einem guten und einem schlechten Handwerker lag noch nie im Werkzeug. Er lag darin, zu wissen, wann man es benutzt, wie man es benutzt und wann man es wieder aus der Hand legt.
Pflanzen brauchen Wasser. Keine Elektrolyte.