Im ersten Artikel ging es darum, dass KI programmieren kann, wenn Verifikation billig ist. Kann ein Agent Tests ausführen, Fehler lesen und so lange iterieren, bis ein klares Übergabekriterium grün ist, funktioniert AI Coding überraschend gut.
Dieselbe Idee erklärt auch den Gegenfall. KI scheitert, wenn Verifikation teuer ist. Eine besonders teure Form davon ist Geschmack.
Damit meine ich nicht Tabs oder Spaces. Gemeint ist Engineering-Geschmack: Eleganz, Minimalismus, architektonisches Urteil und das Gespür dafür, welche Abstraktion zu viel ist. Eine Lösung kann technisch korrekt sein und trotzdem nicht in eine Codebase passen.
Viele sehr gute Entwickler sehen genau hier Slop. Damit liegen sie oft richtig. Die sinnvolle Schlussfolgerung lautet aber nicht, dass KI keinen Code schreiben kann.
KI hat Schwierigkeiten, wenn der Verifikator nur der implizite Geschmack eines Menschen ist.
Das Problem des versteckten Orakels
Vieles an Codequalität lässt sich gut prüfen. Besteht der Test? Sendet das Formular? Hat die API das erwartete Format? Stimmen Datenbank-Constraint und Modellvalidierung überein? Läuft der Browser-Test durch? Erlaubt der Linter den Import?
Solche Aufgaben passen zu einem Coding Agent. Sie sind nicht automatisch einfach, aber das Ziel ist sichtbar. Der Agent probiert etwas, führt den Check aus, sieht den Fehler und korrigiert ihn.
Andere Urteile sehen so aus:
- Diese Abstraktion ist unnötig.
- Die Lösung funktioniert, denkt aber anders als das Projekt.
- Dieses neue Konzept sollte gar nicht existieren.
- Der Code ist korrekt, aber unelegant.
- Fünf Zeilen weniger wären besser.
- Das fühlt sich nach Slop an.
Diese Aussagen können völlig berechtigt sein. Ihre Prüfung ist jedoch teuer, weil sie oft einen bestimmten Menschen mit viel Kontext braucht. Eine KI kann kein make maintainer-likes-this ausführen.
Wenn das Kriterium lautet, dass ein Maintainer es selbst genauso geschrieben hätte, ist dieser Mensch das Orakel. Er sitzt außerhalb des Loops. Der Agent muss raten, und manche dieser Versuche gehen sichtbar daneben.
Funktionierender Code ist nicht automatisch guter Code
KI-generierter Code kann alle Tests bestehen und trotzdem die falsche Abstraktion einführen. Er kann die aktuelle Aufgabe lösen und gleichzeitig die Codebase verschlechtern. Technische Korrektheit garantiert weder Stil noch langfristige Richtung.
Erfahrene Entwickler fragen deshalb nicht nur, ob etwas funktioniert. Sie fragen, ob diese Implementierung der richtige Ausdruck der Idee ist.
Das ist besonders schwer in Projekten mit einer klaren Ästhetik: wenige Abhängigkeiten, kleine Abstraktionen, keine unnötige Indirektion, direkte Lösungen, mechanisches Verständnis und eine bestimmte Dichte im Code.
Sind diese Regeln weder dokumentiert noch durch Beispiele oder Checks sichtbar, kann ein Modell sie nur annähern. Manchmal reicht das. Manchmal erkennt ein Maintainer die Lücke sofort.
Das tinygrad-Problem
Bei einer Codebase wie tinygrad kann ein Beitrag abgelehnt werden, obwohl er läuft. Vielleicht führt er eine zu allgemeine Abstraktion ein oder übersieht eine viel einfachere Formulierung. Im nüchternen Sinn ist er korrekt, im ästhetischen Sinn passt er nicht.
Genau dieses Urteil trennt oft eine großartige von einer mittelmäßigen Codebase. Es lässt sich aber nur schwer an einen Agenten auslagern. Styleguides, lokale Beispiele, Architekturtests und Regeln für minimale Änderungen helfen. Trotzdem bleibt eine Lücke zwischen „befolgt die geschriebenen Regeln“ und „entspricht der Lösung des besten Maintainers“. Diese Lücke ist Geschmack, und Geschmack ist teuer.
Warum CRUD einfacher ist
KI wirkt in gewöhnlicher Produktsoftware oft deutlich stärker als in hochspezialisierter Systemarbeit. Eine CRUD-Anwendung bietet bekannte Muster, gut beschreibbares Verhalten und relativ direkte Tests. Browser-Automatisierung prüft die Oberfläche, Assertions prüfen die Datenbank, Contract Tests prüfen die API.
Formular bauen, Tabelle ergänzen, Endpoint anlegen, Background Job schreiben, Eingaben validieren, E-Mail senden oder Stripe-Webhook verarbeiten: Das sind reale Aufgaben, aber ihre Form ist vertraut. Das Modell hat viele ähnliche Beispiele gesehen, und die Umgebung kann das Ergebnis häufig prüfen.
Anders sieht es bei einem reverse-engineerten USB-zu-eSATA-Treiber, einer seltenen Compileroptimierung, einer Tensoroperation in einem minimalistischen ML-Framework oder einem undokumentierten Protokoll aus dem Jahr 2007 aus. Es gibt weniger Trainingssignal, mehr unbekannte Bedingungen und weniger Beispiele. Manchmal ist zu Beginn nicht einmal klar, wie Erfolg aussieht.
Unbekannte Unbekannte
Reverse Engineering zeigt das Problem gut. Bei einem normalen Feature kennt man das Ziel: Eine Datei lässt sich hochladen, eine Zahlung wird gespeichert oder ein geplanter Job läuft.
Beim Reverse Engineering müssen die Bedingungen zuerst entdeckt werden. Man experimentiert, beobachtet Verhalten, formuliert Hypothesen und verwirft falsche Annahmen. Erst dabei wird sichtbar, wie das Problem überhaupt beschaffen ist.
KI kann dabei helfen. Sie kann Experimente automatisieren, Logs zusammenfassen, Hypothesen erzeugen und festhalten, was bereits probiert wurde. Der Loop ist aber nicht mehr einfach „Feature schreiben, Tests ausführen, Fehler beheben“. Es ist Forschung, und das Erfolgskriterium bewegt sich.
Deshalb reden Menschen in Debatten über AI Coding häufig aneinander vorbei. Eine Person baut ein SaaS-Feature, die andere untersucht ein seltenes Systemproblem mit unvollständigen Informationen. Beides heißt Programmieren, ist aber nicht dieselbe Arbeit.
Zwei entscheidende Achsen
Ich ordne Aufgaben inzwischen entlang zweier Fragen ein.
Erstens: Wie teuer ist die Verifikation? Kann der Agent das Ergebnis selbst günstig prüfen, oder braucht er ein menschliches Orakel?
Zweitens: Wie nah liegt die Aufgabe am Zentrum der Trainingsverteilung? Ist es ein häufiges Muster mit vielen Beispielen, oder ein seltenes Problem mit wenig verwertbarem Signal?
Am besten funktioniert AI Coding bei häufigen Aufgaben mit billiger Verifikation. Am schlechtesten bei seltenen Aufgaben mit teurer Verifikation. Ein Rails-CRUD-Feature und eine minimale Tensor-Compileroptimierung sind beides Code, stellen das Modell aber vor völlig andere Bedingungen.
Geschmack sichtbar machen
Ein Teil des Geschmacks bleibt menschlich. Trotzdem lässt sich mehr davon nach außen tragen:
- Unerwünschte Abhängigkeiten werden durch Checks verhindert.
- Der Agent zeigt den Diff und begründet jede geänderte Datei.
- Verbotene Abstraktionen werden dokumentiert.
- Architekturtests schützen Grenzen.
- Vor einer Änderung werden benachbarte Dateien und lokale Muster untersucht.
- Akzeptierte und abgelehnte Lösungen dienen als konkrete Beispiele.
Damit wird Geschmack nicht vollständig ausführbar. Aber jeder externalisierte Standard senkt die Kosten der Verifikation. Ziel ist nicht, der KI perfektes Urteil zuzuschreiben. Ziel ist, weniger Urteil als unsichtbares Bauchgefühl beim Menschen zu belassen.
Die ehrliche Mitte
KI erzeugt oft guten funktionierenden Code, wenn Aufgaben häufig und Prüfungen billig sind. Sie ist deutlich schwächer, wenn Exzellenz von verborgenem Geschmack, seltenem Kontext oder teurer Exploration abhängt.
Weder Pessimisten noch Optimisten müssen deshalb falsch liegen. Sie arbeiten oft in verschiedenen Umgebungen. Die nützliche Frage lautet nicht: Kann KI programmieren? Sondern: Welche Art von Code, in welcher Umgebung und mit welchem Verifikator?
Für wen das relevant ist
- Teams, deren Agenten sauberen, grünen Code liefern, der trotzdem falsch wirkt
- Maintainer anspruchsvoller Codebases, die KI-Beiträge regelmäßig ablehnen
- Engineering Leads, die Aufgaben sinnvoll zwischen Menschen und Agenten verteilen wollen
- Alle, die vermuten, dass beide Seiten der Slop-Debatte unterschiedliche Arbeit beschreiben
Häufige Fragen
Warum nennen erfahrene Entwickler funktionierenden KI-Code trotzdem Slop? Tests prüfen Funktion billig. Ob eine Abstraktion und der Stil zum Projekt passen, entscheidet oft impliziter menschlicher Geschmack. Der Agent kann dieses Urteil nicht selbst ausführen und muss raten.
Was unterscheidet funktionierenden von gutem Code? Funktionierender Code erledigt die Aufgabe und besteht Tests. Guter Code nutzt zusätzlich die richtige Abstraktion, folgt der Projektrichtung und verschlechtert die Codebase nicht.
Warum ist KI bei CRUD stärker als bei Systemarbeit? CRUD-Muster sind häufig und gut prüfbar. Seltene Systemprobleme bieten weniger Trainingssignal und verlangen oft teure Experimente oder spezielles Wissen.
Lässt sich Geschmack ausführbar machen? Nicht vollständig. Architekturtests, Dependency-Checks, Diff-Begründungen, Linter und Beispiele können aber viele versteckte Erwartungen sichtbar machen.
Welche zwei Achsen sind entscheidend? Die Kosten der Verifikation und die Nähe zur Trainingsverteilung. Häufige, billig prüfbare Aufgaben sind für Agenten am günstigsten.
Warum ist Reverse Engineering besonders schwierig? Das Erfolgskriterium steht oft nicht von Beginn an fest. Bedingungen müssen durch Experimente erst entdeckt werden. Dadurch wird Verifikation selbst zum Teil der Forschung.