GenAI in Softwareengineering: Reviewt KI-Code nicht. Verifiziert ihn.
Code-Reviews waren schon immer ein Plausibilitätscheck – kein Korrektheitscheck. Bei menschlichem Code ging das meistens gut. Bei KI-generiertem Code geht es systematisch schief. In einem unserer Migrationsprojekte portierte die KI eine C++-Codebasis nach .NET – 6.200 Zeilen gewachsener Code, 29 Features. Die KI reviewte ihr eigenes Ergebnis. Drei dedizierte Review-Durchläufe. Null Fehler. Erst der Test gegen die Originaldaten zeigte: zehn Fehler. Wenn selbst fokussierte, systematische Prüfung an plausiblem Code scheitert – was bedeutet das für den Pull Request, der freitagnachmittags zwischen zwei Meetings durchgewunken wird?
Das eigentliche Problem: Review war noch nie genug
Seien wir ehrlich: Code-Reviews waren schon vor der KI ein Engpass. Pull Requests mit zwanzig geänderten Dateien wurden aus Zeitdruck oberflächlich geprüft. Sieht der Code sauber aus? Irgendwas offensichtlich Falsches? Approve. Das funktionierte leidlich, weil menschlich geschriebener Code genug Unregelmäßigkeiten hat, um verdächtige Stellen sichtbar zu machen.
KI-generierter Code beseitigt genau diese Unregelmäßigkeiten. Er ist syntaktisch sauber, folgt Konventionen, hat vernünftige Variablennamen. Genau die Signale, auf die erfahrene Reviewer sich verlassen – „sieht sauber aus” – sind bei KI-Code immer gegeben. Unabhängig davon, ob die Logik stimmt.
Sie kennen das Gefühl: Der Code sieht gut aus, das Review war sauber – und trotzdem meldet sich ein Unbehagen. Bei KI-generiertem Code hat dieses Unbehagen einen Grund. Der Code ist plausibel – er wurde von einem Modell erzeugt, das auf Plausibilität optimiert ist. Genau das Signal, auf das Review vertraut, ist bei KI-Code wertlos.
KI-gestützte Entwicklung produziert nicht nur plausibleren Code – sie produziert mehr davon.
Und jetzt kommt der zweite Effekt: KI-gestützte Entwicklung produziert nicht nur plausibleren Code – sie produziert mehr davon. Deutlich mehr, deutlich schneller. Dasselbe Gate, das vorher schon überlastet war, soll jetzt ein Vielfaches an Output prüfen. Das skaliert nicht. Was als Effizienzgewinn beginnt, schlägt am Ende auf Anwendungsstabilität, Customer Experience und Cybersecurity durch – die Bereiche, in denen Reviews schon vorher die schwächste Verteidigungslinie waren. Sie war schon vor der KI die Schwachstelle. Jetzt wird sie unhaltbar.
Die Fehler liegen dort, wo kein Review hinschaut.
In unserem Portierungsprojekt waren die zehn Fehler keine offensichtlichen Bugs. Es waren Sonderfälle: Verhaltensweisen, die nirgends dokumentiert waren und sich nur im Zusammenspiel mit echten Daten zeigten. Genau die Art von Fehlern, die kein Review findet – weil sie nur sichtbar werden, wenn man das Ergebnis gegen die Realität laufen lässt.
Qualität an die Ränder verschieben
Die Lösung ist nicht besseres Review. Die Lösung ist, Qualität dorthin zu verschieben, wo sie wirkt: an den Anfang und ans Ende des Prozesses. Die Mitte – das Review als Qualitätsgate – wird ersetzt durch Verifikation.
Am Anfang:
Entscheiden, was gebaut wird – und es der KI erklären
Wenn KI-Agenten in Stunden umsetzen, was früher Wochen dauerte, verschiebt sich die wertvollste Arbeit: weg vom Wie, hin zum Was. Was bauen wir? Welche Regeln gelten? Welche Ergebnisse muss das System produzieren?
Vor der C++-Portierung wurde nicht sofort Code geschrieben. Zuerst entstand ein Domain-Wissen-Dokument. Die KI musste verstehen, wie das alte System funktioniert, welche Regeln gelten und welche Ergebnisse am Ende gleich bleiben müssen. Erst danach wurde gebaut. Das Ergebnis: 24 von 29 Features waren auf Anhieb korrekt – nicht weil das Modell besser war, sondern weil es wusste, was es bauen soll. Die restlichen fünf? Genau die Randfälle, die erst im Test gegen echte Daten sichtbar wurden.
Viele Teams investieren Zeit in Prompt-Vorlagen und Formulierungsvarianten. Das ist nicht falsch – aber es ist nicht der stärkste Hebel. Eine einzige gute Kontext-Datei im Repository, die dem Agenten Architektur, Konventionen und fachliche Begriffe erklärt, bringt mehr als zehn verfeinerte Prompts. Sie wird versioniert, von allen genutzt und wächst mit dem Projekt.
Am Ende:
Gegen die Realität prüfen, nicht gegen Plausibilität
Tests gegen echte Daten. Linter gegen dokumentierte Regeln. Automatisierte Läufe gegen das tatsächliche Verhalten des Originalsystems. Das ist der Punkt, an dem die zehn Fehler sichtbar wurden – nicht im Review, sondern im Abgleich mit der Wirklichkeit.
Der stärkste Ansatz verbindet Anfang und Ende: Vor der Agentenarbeit definieren, was das Ergebnis leisten muss, und das direkt in automatisierte Tests übersetzen. Dann baut der Agent – und die Tests sagen sofort, ob es stimmt. Kein nachträgliches Review-Hoffen, sondern ein klares Ja oder Nein.
Einfacher Einstieg: Drei bis vier Tests manuell als Vorlage schreiben, dann weitere Tests mit KI erzeugen lassen. Niedrigschwellig, direkt verifizierbar, begrenzt das Risiko.
Dazwischen:
Jeder Fehler verbessert das System
Jeder Fehler wird zur Frage: Was hat in der Arbeitsumgebung gefehlt? Welche Regel? Welcher Test? Welches Beispiel? Die Antwort fließt als neue Regel, neuer Test oder bessere Dokumentation zurück ins Repository.
In einem Projekt wuchs die Kontext-Datei über vier Wochen auf zwölf Regeln – die drei häufigsten Korrekturen kamen danach nicht mehr vor. Nicht weil das Modell ein anderes war. Sondern weil es in einer reiferen Umgebung arbeitete.
Das ist der Unterschied zwischen einem Tool, das Code produziert, und einem System, das mit jedem Durchlauf besseren Code produziert.
Fazit
Review gibt euch ein Gefühl. Verifikation gibt euch einen Beweis. Bei KI-generiertem Code ist der Unterschied existenziell.
Ein Gefühl ist keine Qualität – und genau das macht Review gefährlich: Es erzeugt Vertrauen, wo Skepsis angebracht wäre. Die Antwort ist nicht, mehr oder besser zu reviewen. Die Antwort ist, Qualität an die Ränder zu verschieben: Am Anfang entscheiden und dokumentieren, was gebaut werden soll. Am Ende automatisiert verifizieren, ob es stimmt. Dazwischen lernen.
Die Frage ist nicht, ob Ihr Team KI-Tools einsetzt. Die Frage ist, ob es ein System hat, das Review durch Verifikation ersetzt.
Wo steht Ihr Team?
Comma Soft bietet ein kompaktes Assessment an, das in wenigen Tagen Klarheit schafft: Wie gut ist Ihre aktuelle Qualitätssicherung auf KI-generierten Code vorbereitet? Wo liegen die größten Lücken? Sie erhalten eine Übersicht über die kritischen Schwachstellen und einen priorisierten Maßnahmenkatalog, mit dem Sie sie schnell und nachhaltig beheben.