Seit einiger Zeit stört mich die Debatte darüber, ob KI guten Code schreiben kann.
Sehr gute Softwareentwickler sagen, das funktioniere höchstens bei Prototypen, Wegwerfskripten oder kleinen Greenfield-Projekten. Sobald eine Codebase ernst wird, produziere KI vor allem Slop: oberflächlich funktionierende Software, die darunter langsam unwartbar wird. Ich verstehe, woher diese Einschätzung kommt.
Gleichzeitig sehe ich Einzelpersonen und kleine Teams, die echte Produkte mit überwiegend KI-generiertem Code ausliefern. Keine Demos, sondern Software mit Nutzern und Umsatz. Manche schreiben kaum noch selbst Code und lesen nicht mehr jede einzelne Zeile.
Ich gehöre eher zu dieser zweiten Gruppe. Zedl und Nodl (GitHub) sind in dieser Arbeitsweise entstanden. Manchmal geht Code für ein SaaS-Produkt mit zahlenden Kunden in Produktion, ohne dass ich jede Zeile gelesen oder jeden Pfad händisch ausprobiert habe.
Das bedeutet nicht, dass ich einer KI blind vertraue. Ich vertraue dem Prozess rund um die KI.
Die bessere Antwort auf die übliche Streitfrage lautet deshalb:
KI kann programmieren, wenn Verifikation billig ist.
Schlecht wird das Ergebnis, wenn Verifikation langsam, unscharf oder versteckt ist und nur durch menschliches Urteil funktioniert.
Die Kosten der Verifikation
Beim AI Coding dreht sich viel um den Loop. Ein Agent bearbeitet eine Aufgabe, führt Befehle aus, beobachtet das Ergebnis, korrigiert Fehler und arbeitet weiter, bis ein Ziel erreicht ist.
Früher sah die Schleife oft so aus:
- Ein Mensch schreibt einen Prompt.
- Die KI erzeugt Code.
- Der Mensch prüft das Ergebnis.
- Der Mensch findet einen Fehler und kopiert ihn zurück.
- Die KI versucht es erneut.
Das ist anstrengend, weil der teure Teil weiterhin beim Menschen liegt. Er liest den Code, klickt durch die Oberfläche, kopiert Stack Traces und entscheidet, ob die Aufgabe wirklich fertig ist. Die KI übernimmt das Tippen, aber nicht die Kosten der Prüfung.
Für ernsthafte Software ist das zu wenig. Die Kosten der Verifikation müssen stark sinken:
- Der Agent erstellt oder aktualisiert automatisierte Tests.
- Tests laufen nach jeder relevanten Änderung.
- Linter und statische Prüfungen erzwingen Regeln.
- Die Prüfungen sind schnell genug für häufige Wiederholungen.
- Der Agent sieht verständliche Fehlermeldungen selbst.
- Teure oder fragile Schnittstellen werden, wo sinnvoll, simuliert.
- Die Übergabe erfolgt erst, wenn alle relevanten Prüfungen grün sind.
Man sollte die KI nicht nur bitten, vorsichtig zu sein. Man sollte eine Umgebung bauen, in der Unachtsamkeit schnell sichtbar wird.
Beispiel: Weg von PostCSS
Ein Softwareentwickler in meinem Umfeld migrierte eine große Codebase weg von postcss. Obwohl der Agent ausdrücklich keine neuen Referenzen einführen sollte, baute er postcss an einer bereits bereinigten Stelle wieder ein. Der Fehler fiel im manuellen Review auf.
Die übliche Schlussfolgerung wäre: KI ist nicht vertrauenswürdig, deshalb muss ein Mensch alles lesen. Für mich ist das die falsche Lehre.
Nicht der Fehler ist das eigentliche Problem. Menschen machen ebenfalls Fehler. Problematisch ist, dass teure menschliche Aufmerksamkeit ihn finden musste. Die Regel „keine neuen postcss-Referenzen“ gehört nicht nur in einen Prompt oder in den Kopf eines Reviewers. Sie gehört in eine ausführbare Prüfung.
Ein Guard kann den Git-Diff untersuchen und scheitern, sobald eine neu hinzugefügte Zeile postcss enthält. Bestehende Referenzen dürfen während der Migration noch vorhanden sein. Entscheidend ist der neue Code.
Auch die Fehlermeldung muss konkret sein:
Datei X führt in Zeile N eine neue postcss-Referenz ein. Diese Migration verbietet neue Referenzen. Entferne sie, bevor du die Aufgabe abschließt.
Der Agent kann die Prüfung ausführen, den Fehler sehen, ihn korrigieren und erneut prüfen. Kein menschliches Nachfassen, keine Diskussion im Review, kein „Bitte nächstes Mal daran denken“.
Das ist billige Verifikation.
Prompts sind Wünsche, Checks sind Grenzen
Wenn eine KI etwas falsch macht, wird meist zuerst der Prompt erweitert: Verwende kein PostCSS. Beschädige keine bestehende Funktion. Arbeite produktionsreif. Sei vorsichtig.
Solche Anweisungen helfen, bleiben aber schwach. Ein Prompt ist ein Wunsch. Ein Check ist eine Grenze.
Was wichtig ist, sollte mit der Zeit aus dem Prompt in die Umgebung wandern:
- Verbotene Imports werden durch Linter oder Diff-Prüfungen erkannt.
- Datenbank-Constraints werden mit dem Anwendungsmodell abgeglichen.
- Zentrale Nutzerabläufe bekommen Browser-Tests.
- Locale-Keys werden zwischen Sprachen verglichen.
- Migrationen durchlaufen Sicherheitsprüfungen.
Der Agent wird nicht zuverlässig, weil er plötzlich ein moralisches Verhältnis zur Architektur entwickelt. Er wird zuverlässiger, weil Fehler billig erkannt werden und nicht unbemerkt übergeben werden können.
Ein eindeutiges Übergabekriterium
Der Agent braucht einen Befehl, der „fertig“ bedeutet. Bei uns ist das oft etwas wie:
make check
Der konkrete Name ist unwichtig. Dahinter müssen die Prüfungen liegen, die für das Projekt zählen: Tests, Linting, statische Analyse, Migrationssicherheit und projektspezifische Invarianten.
Der Agent muss keinen Code produzieren, der mich auf den ersten Blick beeindruckt. Seine Aufgabe ist, diesen Befehl grün zu bekommen. Ist er rot, arbeitet der Agent weiter. Ist er grün, kann die Arbeit übergeben werden.
Ein grüner Check macht nicht jede Änderung automatisch sicher. Die Stärke des Übergabekriteriums muss zum Risiko passen. Trotzdem gilt: Der Mensch sollte nicht der erste Verifikator sein.
Die eigentliche Frage
Kann KI programmieren? Manchmal erstaunlich gut, manchmal erschreckend schlecht. Der Unterschied liegt häufig nicht nur im Modell, sondern in der Arbeitsumgebung.
Eine vage Aufgabe ohne Tests, schnelle Rückmeldung und klare Grenzen produziert Slop. Ein klares Ziel mit ausführbaren Regeln, guten Fehlermeldungen und der Möglichkeit, selbstständig zu iterieren, kann brauchbaren Produktionscode hervorbringen.
Softwareentwicklung bestand schon immer auch darin, Systeme zu bauen, die Fehler auffangen. KI macht nur sichtbarer, wie teuer schlechte Verifikation ist.
Die Qualität von AI Coding wird weniger durch die Codegenerierung begrenzt als durch die Qualität der Verifikation rundherum. Deshalb braucht die Zukunft nicht nur bessere Modelle, sondern bessere Loops, Tests, Constraints und Übergabekriterien.
Für wen das relevant ist
- Teams, deren Coding Agents weiterhin ständig menschliche Betreuung brauchen
- Engineering Leads, die über „jede Zeile lesen“ hinauskommen wollen, ohne Qualität zu opfern
- Kleine Produktteams, die ein belastbares Arbeitsmodell statt weiterer Modell-Benchmarks brauchen
- Entwickler in Migrationen und großen Refactorings, bei denen Regressionen leicht entstehen
Häufige Fragen
Kann KI heute produktionsreifen Code schreiben? Manchmal ja. Entscheidend ist, ob der Agent seine Arbeit mit schnellen Tests, Lintern, Diff-Prüfungen und einem klaren Übergabekriterium selbst verifizieren kann.
Was bedeutet billige Verifikation konkret? Der Agent kann Prüfungen selbst ausführen, verständliche Fehler lesen, das Problem korrigieren und erneut testen. Manuelles Durchklicken und das Kopieren von Stack Traces sind dagegen teuer.
Warum sehen erfahrene Entwickler so viel KI-Slop? Oft arbeiten sie in Umgebungen, in denen Erfolg von implizitem Wissen, Geschmack oder langsamer manueller Prüfung abhängt. Dort kann der Agent den Loop nicht selbst schließen.
Wie verhindert man eine verbotene Abhängigkeit? Nicht nur über den Prompt. Ein Diff-Guard sollte bei neuen Imports scheitern und dem Agenten genau sagen, welche Zeile korrigiert werden muss.
Was ist ein Übergabekriterium? Ein einzelner Befehl wie make check, der alle relevanten Prüfungen ausführt. Erst wenn er grün ist, gilt die Arbeit als übergabefähig.
Wie nutzt ex-nihilo diesen Ansatz? Bei Zedl und Nodl werden Tests, statische Analysen, Migrationsprüfungen und projektspezifische Invarianten als ausführbare Checks formuliert.
Braucht es weiterhin menschliche Reviews? Ja. Menschen bleiben für Risiko, Architektur und nicht ausführbar formuliertes Urteil wichtig. Sie sollten nur nicht jede vorhersehbare Fehlerklasse als erste entdecken müssen.