KI-generierter Code im Kundenprojekt: Warum er dieselben Qualitätsgates braucht
Kurz gesagt
Nein. KI-generierter Code erhält keine Sonderbehandlung — er braucht dieselben Qualitätsgates wie jeder andere Code: Verständnis, Review, Tests, Prüfung von Abhängigkeiten und Secrets sowie eine klar begrenzte Wirkung im Produktivsystem. Pauschale Produktivitätsversprechen zu KI-Coding sind nicht belastbar; eine kontrollierte Studie mit erfahrenen Entwicklern fand sogar längere Bearbeitungszeiten.
Der verbreitete Irrtum: „Das Modell kennt doch Best Practices"
In vielen Projekten mit KI-unterstützter Entwicklung entsteht schnell die Annahme, generierter Code brauche weniger Aufmerksamkeit als handgeschriebener — schließlich sei er ja auf Basis riesiger Codemengen trainiert. Diese Annahme ist falsch. Ein Modell erzeugt einen plausiblen Vorschlag, keine geprüfte, für den konkreten Kontext verantwortete Lösung. Ob der Vorschlag zur tatsächlichen Datenstruktur, den Berechtigungen und der bestehenden Architektur des Projekts passt, ist damit noch nicht geklärt. Die harte Annahmeregel lautet deshalb: Code oder Konfiguration, deren Wirkung niemand im Projekt erklären, testen und im Fehlerfall zurücknehmen kann, darf nicht allein deshalb produktiv gehen, weil eine KI ihn erzeugt hat.
Was die Studienlage tatsächlich zeigt
Die öffentliche Debatte um KI-gestützte Softwareentwicklung ist stark von Produktivitätsversprechen geprägt. Belastbar ist das nicht: Eine kontrollierte Studie mit erfahrenen Open-Source-Entwicklern kam in ihrem konkreten Setting sogar zu längeren Bearbeitungszeiten statt der erwarteten Beschleunigung. Das bedeutet nicht, dass KI-Unterstützung wertlos ist — es bedeutet, dass pauschale Aussagen wie „damit sind Sie doppelt so schnell" für ein einzelnes Projekt nichts wert sind. Wie stark sich Geschwindigkeit und Qualität tatsächlich verändern, hängt von Aufgabe, Erfahrung, Codebasis und Prüftiefe ab.
Die Qualitätsgates, die für jeden Code gelten
Unabhängig davon, ob ein Mensch oder ein Modell den ersten Entwurf geschrieben hat, gehören folgende Prüfungen vor jeden Merge in den Hauptzweig:
- Verständnis: Mindestens eine Person im Projekt kann erklären, was die Änderung tut und warum — nicht nur, dass sie „funktioniert hat"
- Review durch eine kompetente Person: Ein zweites Augenpaar prüft Logik, Fehlerbehandlung und Seiteneffekte, unabhängig davon, wer den Code geschrieben hat
- Tests: Automatisierte Tests decken den geänderten Pfad ab, nicht nur den Idealfall
- Abhängigkeitsprüfung: Neue Bibliotheken oder Pakete werden auf Herkunft, Pflegezustand und bekannte Schwachstellen geprüft, bevor sie in die Lieferkette gelangen
- Secrets-Prüfung: Zugangsdaten, API-Schlüssel oder Tokens landen nicht versehentlich im Code oder in der Versionshistorie
- Begrenzte Wirkung: Änderungen mit weitreichender Wirkung — etwa an Berechtigungen, Zahlungslogik oder Datenmigrationen — laufen zuerst in einer isolierten Umgebung
Zwei riskante Muster in der Praxis
Zwei Situationen tauchen in Projekten mit KI-unterstützter Entwicklung besonders häufig auf und sollten als Warnsignal gelten: KI-generierte Änderungen werden wegen des Zeitgewinns ohne Review gemergt, weil der Entwurf „auf den ersten Blick gut aussah". Und: Eine KI-generierte Datenmigration wird ohne Test auf die reale Datenverteilung ausgeführt — funktionierender Testdatensatz ist nicht dasselbe wie funktionierende Produktivdatenbank. Beide Muster verlagern das Risiko unbemerkt in den Produktivbetrieb, wo Fehler deutlich teurer werden als im Review.
Wofür KI-Unterstützung sinnvoll bleibt
Das bedeutet nicht, KI-Unterstützung beim Programmieren grundsätzlich zu vermeiden. Für Boilerplate-Code, erste Prototypen, Testdatengenerierung oder das Erklären fremden Codes kann sie echten Nutzen bringen. Die Grenze verläuft nicht bei der Frage „Mensch oder KI", sondern bei der Frage, ob am Ende eine Person im Projekt die Verantwortung für die Wirkung im Betrieb tatsächlich tragen kann — mit Verständnis, Tests und einem funktionierenden Weg zurück, falls etwas schiefgeht.