Verschiebt KI den Aufwand nur ins Code-Review?
Unter Entwicklern liest man gerade oft einen Satz, der nüchtern und erfahren klingt:
„Mit KI verschiebt sich der Aufwand nur. Was beim Schreiben gespart wird, kostet hinterher das Review. Schneller wird dadurch nichts.“
Der Satz hat einen wahren Kern. Er beschreibt aber keine Grenze der KI, sondern die Grenze einer Arbeitsweise: der, in der ein Mensch jede Zeile liest.
Die Beobachtung stimmt
Faros AI hat 2025 die Daten von rund 10.000 Entwicklern aus über 1.200 Teams ausgewertet. Teams, die viel mit KI arbeiten, erledigen 21 % mehr Aufgaben und führen 98 % mehr Änderungen in den Code zusammen. Diese Änderungen sind im Schnitt aber 154 % größer, und das Review dauert 91 % länger. Auf Ebene des ganzen Unternehmens fand die Studie keinen messbaren Zusammenhang mehr zwischen KI-Einsatz und Ergebnis. Der zusätzliche Code staut sich vor dem Review.
Dazu kommt, dass KI-Code genau gelesen werden will. In der Entwicklerumfrage von Stack Overflow 2025 ist das häufigste Ärgernis, genannt von 66 % der Befragten, eine KI-Lösung, die „fast richtig, aber eben nicht ganz“ ist. Solche Fehler sieht man nicht beim Überfliegen.
Wer das erlebt, zieht einen naheliegenden Schluss: KI bringt nichts, solange jemand alles prüfen muss. Der Denkfehler steckt im Wort „alles“.
Jede Zeile lesen war nie der beste Fehlerfilter
Code-Reviews gelten als wichtigste Qualitätssicherung in der Softwareentwicklung. Die Forschung sieht das nüchterner. Alberto Bacchelli und Christian Bird haben bei Microsoft untersucht, was Reviews tatsächlich leisten. Ihr Ergebnis: Es geht in Reviews weniger um Fehler als erwartet. Ihr Hauptnutzen liegt woanders, im Wissensaustausch, im gemeinsamen Verständnis des Codes und in besseren Lösungsideen.
Auch die Aufmerksamkeit hat Grenzen. Nach einer bekannten Untersuchung bei Cisco, die SmartBear veröffentlicht hat, sollte man in einer Sitzung nicht mehr als 200 bis 400 Zeilen prüfen und nicht länger als eine Stunde. Wer schneller liest als etwa 500 Zeilen pro Stunde, findet deutlich weniger Fehler.
Legt man das neben die Zahlen von Faros, wird das Problem sichtbar: Die Änderungen werden größer, und die Prüfmethode, die für sie gewählt wird, ist bei großen Änderungen am schwächsten. Wer KI-Code Zeile für Zeile liest, kombiniert die größte Menge mit dem schwächsten Filter.
Das heißt nicht, dass Lesen wertlos ist. Wissen verteilen und Strukturen verstehen bleibt wichtig. Lesen sollte aber nicht die Stelle sein, an der Fehler aufgehalten werden.
Prüfen als System statt Lesen als Pflicht
Der DORA-Report 2025 von Google beschreibt KI als Verstärker: Sie repariert kein Team, sie verstärkt, was schon da ist. Ohne robuste Kontrollsysteme wie starke automatisierte Tests, saubere Versionsverwaltung und schnelle Rückmeldung führt mehr Änderungsvolumen laut Report zu Instabilität.
Die Antwort auf mehr Code ist also nicht mehr Lesen, sondern ein System, das prüft. Der Fehlerforscher James Reason hat dafür das Bild der Schweizer Käsescheiben geprägt: Jede Schutzschicht hat Löcher, auch das menschliche Lesen. Ein Fehler kommt nur durch, wenn die Löcher mehrerer Schichten zufällig übereinanderliegen. Sicherheit entsteht durch mehrere Schichten, nicht durch eine perfekte.
Bei uns sehen diese Schichten so aus:
- Vorher festlegen, was richtig ist. Jedes Ticket bekommt vor dem Bau Szenarien, und zu jedem Szenario gehört ein automatischer Test. Der Test muss vor der Änderung fehlschlagen, sonst prüft er nichts.
- Maschinen prüfen, was Maschinen gut prüfen. Bauen, schnelle Tests und Sicherheitsprüfung laufen bei jeder Änderung, Tests im Browser und gegen eine echte Datenbank vor jeder Auslieferung. Was rot ist, kommt nicht weiter.
- Eine zweite KI liest gegen den Auftrag. Ein Modell eines anderen Anbieters prüft jede Änderung gegen Auftrag und Szenarien. Es hat andere blinde Flecken als das Modell, das gebaut hat.
- Menschen prüfen das Ergebnis. Abgenommen wird auf einer Testumgebung, an der laufenden Anwendung, nicht am Quelltext.
- Lesen mit Ziel statt Lesen aus Pflicht. Ab und zu lassen wir uns von der KI durch den Code führen, auf hoher Ebene: Was hat sich an der Struktur verändert, wo gibt es neue Abhängigkeiten, welche Stellen sind ungewöhnlich? In die Tiefe gehen wir nur dort, wo etwas auffällt.
Wie das im Alltag aussieht, beschreiben wir ausführlich unter Agentic Engineering.
Der eigentliche Hebel: Jeder Fund wird zur Regel
Auch ein System verhindert nicht jeden Fehler. Entscheidend ist, was nach einem Fund passiert. In klassischen Reviews wird er korrigiert, und beim nächsten Mal findet ihn wieder jemand, oder eben nicht. Das Kapitel über Postmortems im SRE-Buch von Google bringt es auf den Punkt: Menschen kann man nicht „reparieren“, aber man kann Systeme und Prozesse so verbessern, dass sie Menschen zu den richtigen Entscheidungen verhelfen.
Ein Beispiel aus unserer Arbeit: Beim Testen eines Kundenprojekts entstand eine Excel-Liste mit Fehlern und Testfällen. Sie war lang, aber kaum etwas darin war schwerwiegend. Der größte Teil waren mittlere und kleine Punkte, viele davon Randfälle: eine leere Liste, eine ungewöhnliche Eingabe, eine Ansicht, die auf dem Tablet anders umbricht als am Rechner.
Wir haben die Liste nicht nur abgearbeitet, sondern auswerten lassen: Welche Arten von Fehlern sind das, und an welcher Stelle im Prozess hätte man sie verhindern können? Die Antwort war eindeutig. Die meisten Punkte waren Fälle, an die bei der Planung niemand gedacht hatte.
Seitdem gehört zu jeder Ticketplanung eine Pflichtliste mit Randfällen: leere Zustände, große Mengen, ungewöhnliche Eingaben, Fehlerpfade, Rollen und Rechte, Datenkonsistenz, Darstellung auf Handy und Tablet und Vorgänge im Hintergrund. Für jeden Punkt steht fest, welcher Test ihn abdeckt oder warum er für dieses Ticket nicht zutrifft.
Das kostet je Ticket ein paar Minuten. Dafür zahlt es auf jedes künftige Ticket in jedem Projekt ein, nicht nur auf das, in dem die Fehler aufgefallen sind. Ein Prüfer, der denselben Randfall zum zehnten Mal findet, hat neunmal umsonst gesucht. Ein System, das ihn nach dem ersten Fund verlangt, muss ihn nicht mehr suchen.
Zwei Arten zu prüfen
| Merkmal | Jede Zeile lesen | Prüfen als System |
|---|---|---|
| Wer prüft | ein Mensch, Zeile für Zeile | Tests, eine zweite KI und ein Mensch am Ergebnis |
| Wo der Mensch hinschaut | überall ein wenig | gezielt dort, wo es riskant ist |
| Was ein Fund bewirkt | eine Korrektur | eine Regel für alle künftigen Tickets |
| Was mehr Code bedeutet | eine längere Warteschlange vor dem Review | mehr automatische Prüfläufe |
Was das für Sie heißt
Der Satz „KI verschiebt den Aufwand nur ins Review“ ist eine ehrliche Beschreibung, solange das Review der einzige Filter ist. Dann wird es tatsächlich nicht schneller. Ein Naturgesetz ist er nicht.
Wenn Ihr Team oder Ihr Dienstleister so argumentiert, lohnen sich zwei Fragen: Was prüfen bei Ihnen Maschinen, bevor ein Mensch hinschaut? Und was passiert mit einem Fehler, nachdem er korrigiert ist? Lautet die Antwort auf die erste „wenig“ und auf die zweite „nichts“, liegt der Engpass nicht an der KI, sondern an der Arbeitsweise.
Sie wollen wissen, wie das in Ihrem Projekt aussehen kann? Sprechen Sie uns an. Mehr zu unserem Vorgehen: Was ist Agentic Development? und Aufwand zu groß, Nutzen unbekannt.
Quellen
- Faros AI (2025): The AI Productivity Paradox Report 2025.
- DORA (2025): State of AI-assisted Software Development und Ankündigung bei Google Cloud.
- Stack Overflow (2025): Developer Survey 2025, Kapitel KI.
- Bacchelli, A. & Bird, C. (2013): Expectations, Outcomes, and Challenges of Modern Code Review. ICSE 2013.
- SmartBear: Best Practices for Peer Code Review (Cisco-Studie).
- Beyer, B. et al. (2016): Site Reliability Engineering, Kapitel „Postmortem Culture“.
- Reason, J. (2000): Human error: models and management. BMJ 320.