Wie viel Review braucht KI-Code? Risiko und Tempo abwägen

KI-Softwareentwicklung · 7 min

Illustration: Waage mit Blitz und Schild als Abwägung zwischen Tempo und Risiko

Ihr Entwickler zeigt Ihnen eine Funktion, die vor einer halben Stunde noch nicht existierte. Auf dem Bildschirm sieht sie fertig aus. Das Formular speichert, die Liste aktualisiert sich, nichts hakt. Am selben Nachmittag kommen drei weitere Änderungen dieser Größe. Spätestens bei der vierten steht die Frage im Raum, wie genau jemand hinschauen muss.

Beim KI-Coding verschiebt sich der Engpass vom Schreiben zum Prüfen. Hier geht es um die Folgefrage: Wie verteilen Sie knappe Prüfzeit, damit das Risiko sinkt und das Tempo bleibt?

Der Zielkonflikt: Tempo gegen Risiko

Zwei Fehlerbilder sind verbreitet. Im ersten wird alles mit derselben Sorgfalt kontrolliert, jede Zeile, jeder Datensatz, jeder Entwurf. Das senkt zwar das Risiko übersehener Fehler, aber das Prüfen wird zum neuen Engpass, und die KI-Ersparnis verschwindet. Im zweiten geht der Output ungeprüft in Produktion. Das ist schnell, bis plausibel aussehender, aber falscher Code eine Geschäftsregel verletzt oder Daten beschädigt. Beide kommen aus derselben Annahme, dass Prüfen eine feste Größe ist.

Prüftiefe ist aber keine feste Größe, sondern eine Frage der Schadenshöhe.

Warum Vollprüfung die KI-Ersparnis auffrisst

Wenn KI ein Vielfaches an Code und Entwürfen liefert und Sie alles gleich gründlich prüfen, ist netto wenig gewonnen; die Warteschlange ist nur vom Schreiben zum Review gewandert. Erschwerend kommt hinzu, dass urteilsabhängiges Prüfen erfahrene Leute braucht, also die knappste Ressource im Team. Dass Misstrauen allein nichts löst, zeigt der vendor-nahe DORA-Bericht von Google aus 2025, in dem 30 % von fast 5.000 Befragten KI-generiertem Code wenig oder gar nicht vertrauen, der aber weiterhin einen negativen Zusammenhang mit der Auslieferungsstabilität findet. Wer pauschal alles prüft, verbraucht teure Aufmerksamkeit dort, wo ein Fehler harmlos wäre. Diese Rechnung gilt für menschliche Aufmerksamkeit, nicht für Prüfungen, die eine Maschine übernimmt.

Risiko bestimmt den Prüfaufwand

Die entscheidende Frage lautet: Welche Beobachtung reicht aus, um dieses Ergebnis freizugeben? Gehen Sie den Weg vom Ergebnis zur Folge rückwärts.

Was verlässt den Entwurf und wird von einem Menschen oder einem anderen System tatsächlich verwendet?
Welches sichtbare Artefakt beweist, dass das Ergebnis die vereinbarte Aufgabe erfüllt?
Welche Entscheidung oder Datenänderung folgt, sobald jemand das Ergebnis akzeptiert?
Wer kann den Ablauf vor der nächsten Folge stoppen und die letzte Änderung untersuchen?

Warum diese Beweise nötig sind, zeigt eine Beobachtungsstudie von Tang und Kollegen über 20.574 reale Sitzungen mit Coding-Agenten. In 22,58 % der erfassten Fehlanpassungen berichtete der Agent seinen eigenen Stand falsch, etwa indem er eine Arbeit als abgeschlossen meldete. Die Daten stammen von freiwillig protokollierten Sitzungen früher Nutzer und messen nur Fehlanpassungen, auf die Entwickler sichtbar reagierten. Sie belegen deshalb keine allgemeine Fehlerquote. Für den Review-Rahmen reicht der engere Befund: Die Abschlussmeldung des Agenten ist eine Behauptung, kein Prüfnachweis.

Was Maschinen prüfen, was Menschen prüfen

So viel Prüfung wie möglich gehört in die Maschine. Typen, automatisierte Tests und Pipelines prüfen bei jeder Änderung festgelegte Eigenschaften und bekannte Regeln; für jeden weiteren KI-Vorschlag laufen sie erneut. Das sichtbare Ergebnis gehört daneben: ein Testprotokoll, eine Vorschau, ein Vergleich der geänderten Daten oder ein anderer Nachweis, den jemand öffnen kann. In der Studie brauchten 91,49 % der sichtbar gelösten Fehlanpassungen einen ausdrücklichen Widerspruch des Entwicklers; nur 2,99 % korrigierte der Agent selbst. Der Auftrag muss daher das prüfbare Artefakt nennen. Diese Maschinenschicht reicht heute weiter als Typen und Tests: Ein zweiter Agent kann ein Ergebnis vollständig und unabhängig aus den Rohdaten nachrechnen, eine Gründlichkeit, die immer möglich war und menschlich nie bezahlbar. Wie man solche harten Grenzen setzt, beschreibt Wie Sie beim KI-Coding die Kontrolle behalten.

Eine Regel aus unserer eigenen Arbeit am DATEV-Export für MAFU-SHERPA: Wo dem System Kontext fehlt, prüft ein Mensch im richtigen Maß mit, nicht überall gleich. Dort laufen die Formatprüfungen automatisch, und die Frage, ob eine Buchung fachlich stimmt, bleibt beim Menschen vor dem Import. Menschliches Urteil bleibt dem vorbehalten, was keine Maschine entscheiden kann, also ob der Code das fachlich richtige Problem löst und was ein Fehler für den Betrieb bedeutet. Denselben Maßstab legt das Generative-KI-Profil des NIST-Rahmenwerks für KI-Risiken an, das seit Juli 2024 festhält, dass verschiedene Anwendungen unterschiedlich viel Aufsicht und Prüfung verdienen.

Ein abgestufter Review-Rahmen

Niedriges Risiko: automatische Prüfungen plus Stichprobe.
Mittleres Risiko: automatische Prüfungen plus gezieltes Review der kritischen Pfade und eine benannte Freigabe.
Hohes Risiko: vollständiges Review mit vorab definierten Akzeptanzkriterien, Probelauf und expliziter Freigabe.

Nehmen Sie für alle drei Stufen dieselbe Meldung des Agenten: „Der Export ist fertig.“ Beim automatisierten DATEV-Export für MAFU-SHERPA ist das der Moment, in dem die fertige Datei bereitliegt und die transformierten Daten vor dem Import geprüft werden können. Bei niedrigem Risiko öffnen Sie die erzeugte Datei und prüfen eine Stichprobe. Bei mittlerem Risiko läuft zusätzlich ein Vergleich mit einem bekannten Beispieldatensatz, und eine benannte Person sieht die Abweichungen. Bei hohem Risiko, etwa vor einem Buchhaltungsimport, gehören ein vollständiger Probelauf, vorab festgelegte Summen und eine ausdrückliche Freigabe dazu. Die Meldung bleibt dieselbe; das verlangte Beweisstück ändert sich.

Damit das trägt, müssen Aufgaben klein und klar geschnitten sein; kleine Einheiten lassen sich schneller prüfen als große, vage Aufträge. Woran das fertige Ergebnis erkennbar sein soll, gehört vorher aufgeschrieben, und den Rahmen dafür liefert Akzeptanzkriterien für KI-Aufgaben.

Fünf Fragen an Ihren Entwickler oder Dienstleister

Sie müssen keinen Code lesen können, um zu erkennen, ob Prüfzeit geplant oder nur versprochen wird. Diese Fragen machen den Aufwand und den Nachweis sichtbar.

Wie verteilen Sie die verfügbare Prüfzeit auf niedrige, mittlere und hohe Risiken, und wer legt die Stufe fest?
Welches Artefakt muss am Ende vorliegen, damit „fertig“ überprüfbar ist?
Welche bekannten Fehler findet die Automatik, und welche Entscheidung bleibt ausdrücklich bei einem Menschen?
Zeigen Sie eine Änderung, bei der die Prüftiefe wegen des Risikos erhöht oder gesenkt wurde.
Welcher zuletzt entdeckte Fehler hat die Checkliste, den Test oder das Freigabekriterium verändert?

Die letzte Frage beantworten wir für uns selbst so. Am 1. September 2026 hat ein zweiter Agent in unserem eigenen Code einen Fehler gefunden, den unsere eigene Messung übersehen hatte, weil für die Messung genau die Animation abgeschaltet war, die kaputt ging. Seither muss bei uns jeder neue Test einmal rot gewesen sein, bevor er zählt. Dass der Prüfer dabei nicht derselbe sein darf wie der Autor, steht im Vier-Augen-Prinzip für KI-Agenten.

Was das für die Kosten bedeutet

Prüfen ist eine Versicherung. Sinnvoll wird der Aufwand, wenn Sie die Prüfkosten gegen die Folgekosten stellen, etwa gegen eine falsche Rechnung oder ungeprüften Code, der jahrelang gewartet werden muss. Risikobasiertes Review lenkt teures menschliches Urteil dorthin, wo ein Fehler weh tut. Wie sich das über die Jahre rechnet, steht in Was kostet Individualsoftware?.

Der Kosteneffekt entsteht nicht dadurch, dass Review verschwindet. Er entsteht, wenn automatische Nachweise wiederholt laufen und menschliche Aufmerksamkeit vorab für die wenigen Entscheidungen reserviert wird, die keine Maschine treffen kann. Reviewzeit gehört deshalb in die Schätzung der Aufgabe und nicht in einen Restposten nach der Entwicklung.

Muss bei KI-Code wirklich jede Zeile geprüft werden?

Nein. Legen Sie vor der Aufgabe fest, welches Beweisstück zur Risikostufe gehört. Bei niedrigem Risiko reichen automatische Prüfungen und eine Stichprobe. Mittleres Risiko verlangt einen gezielten Vergleich und eine benannte Freigabe. Hohes Risiko braucht einen vollständigen Probelauf mit vorab festgelegten Kriterien. So wird nicht jede Zeile gleich behandelt, aber jede Freigabe nachvollziehbar.

Woran erkenne ich, ob mein Dienstleister genug prüft?

Fragen Sie nach dem Ergebnis der letzten Prüfung, nicht nach einer Qualitätszusage. Zeigen lassen sollten Sie sich ein Testprotokoll, einen Datenvergleich oder eine Vorschau und die Entscheidung, die daraus folgte. Ebenso wichtig ist die Frage, welcher entdeckte Fehler zuletzt einen Test oder ein Freigabekriterium verändert hat. Eine konkrete Antwort zeigt, dass der Prozess lernt.

Frisst das Prüfen die Zeitersparnis der KI wieder auf?

Nur, wenn alles gleich gründlich geprüft wird. Automatische Prüfungen werden einmal geschrieben und laufen danach für jeden weiteren Vorschlag mit. Menschliches Urteil bleibt den riskanten Fällen vorbehalten. So bleibt das Tempo dort erhalten, wo das Risiko gering ist.

Kann man das Prüfen nicht der KI überlassen?

Automatische Prüfungen können festgelegte Eigenschaften und bekannte Regeln prüfen. Die Abschlussmeldung eines Agenten ist trotzdem kein Nachweis: In einer Beobachtungsstudie zu realen Coding-Agent-Sitzungen wurden nur 2,99 % der sichtbar gelösten Fehlanpassungen vom Agenten selbst korrigiert. Ob eine Änderung fachlich passt, braucht deshalb vorab festgelegte Kriterien und eine benannte Person, die das Ergebnis prüft.

Beginnen Sie jede KI-Aufgabe mit einem Satz, den man später prüfen kann: „Fertig ist die Arbeit, wenn dieses Artefakt diese Bedingung erfüllt.“ Erst danach lässt sich entscheiden, wie viel automatische und menschliche Prüfung dafür nötig ist.

Wenn Sie diese Stufen für einen echten Ablauf festlegen wollen, sprechen wir über den konkreten Ablauf.