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 und 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 gefehlt hat keine Cache-Schicht. Das eigentliche Problem 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 überzeugende Lösung für das falsche Problem produzieren, schneller und überzeugender als je zuvor.
Das Problem ist, dass das Ergebnis 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 recht 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. So funktioniert probabilistische Textgenerierung: Sie optimiert auf Plausibilität. Korrektheit ist dabei nicht das Ziel. 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.
Ob das Ergebnis das Problem löst, interessiert dann nicht mehr. Es geht nur noch um die angebliche Macht des Werkzeugs. Das Tool kann Rust und TypeScript. Den Code hat es in zehn Sekunden geschrieben. Es hat Hunderte Millionen oder Milliarden Parameter. Also muss das Ergebnis gut sein.
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 mischen sich selbstverursachte intellektuelle Unredlichkeit, irrationaler Glaube und Vorführung fürs Publikum. Bewertet wird das Ergebnis danach, ob es Eindruck macht. Ob es das Problem löst, spielt dabei keine Rolle.
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.
Das Modell hat es nicht. Es 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.”
Deshalb stoßen unzureichende Anweisungen auf keinen Widerstand. Sie erzeugen jedes Mal eine polierte Antwort. 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
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 und wie ein sauberer API-Endpunkt gebaut ist. KI kann das Lernen beschleunigen.
Das funktioniert aber nur dann, wenn die Person aktiv versteht, warum der Vorschlag so aussieht, wie er aussieht. Sie muss ihn lesen, prüfen und verändern, das Werkzeug also als Lehrer benutzen und nicht als Ghostwriter. Der Vorschlag ist nützlich als Ausgangspunkt, solange er ein Ausgangspunkt bleibt.
Das Problem beginnt an der Grenze zwischen Verstehen und Abnicken. 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, ist auch dafür verantwortlich.
Aber was passiert, wenn die Ketten länger werden? Etwa wenn ein Agent an Sub-Agenten delegiert, die selbst entscheiden, und 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?
So satirisch die Frage klingt, das Problem dahinter ist ernst. 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 viel leichter, Ergebnisse zu produzieren, für die man gerade stehen muss, ohne sie zu durchdringen.
"But it has electrolytes" ist kein Argument, weder für Pflanzennahrung noch für Softwarearchitektur. Wie mächtig das Werkzeug ist, tut dabei nichts zur Sache. 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, ohne es zu ersetzen.
Der Unterschied zwischen gutem und schlechtem Handwerk lag schon immer darin, zu wissen, wann und wie man das Werkzeug benutzt und wann man es wieder aus der Hand legt.
Pflanzen brauchen Wasser. Keine Elektrolyte.