Beim Code-Review ging es nie um den Code, sagt Designer Matt Ström-Awn

Markus Seyfferth

Autor Dr. Web

27. Okt. 2026

3 Min. Lesezeit

Matt Ström-Awn, der bis 2024 Designteams bei Stripe leitete, hält das klassische Code-Review für die falsche Prüfung. Menschen sollen stattdessen die laufende Software testen. Banken und Versicherer in der EU dürfen die unabhängige Freigabe trotzdem nicht streichen.

Ein Klick · kostenlosDr. Web bei Google bevorzugenMarkieren Sie drweb.de als bevorzugte Quelle. Dann sehen Sie unsere Artikel öfter unter den Top-Meldungen.Jetzt hinzufügen

Eine Milliarde Commits, also gespeicherte Codeänderungen, verzeichnete GitHub im Jahr 2025, Anfang April 2026 zählte die Plattform rund 275 Millionen pro Woche, meldete GitHub-COO Kyle Daigle.^[2] Für Matt Ström-Awn ist das Review damit zum Engpass geworden, sein Essay vom 25. Oktober stellt die Prüfung infrage.^[1]

Auf einen Blick

Das Wichtigste in Kürze

Prüfer bewerten nach Ström-Awn, ob der Code gut aussieht, nicht, ob die Software funktioniert.
KI-Werkzeuge sollen den Code verbessern, Menschen das Verhalten der laufenden Software prüfen.
In Googles DORA-Studie nutzen 90 % der Befragten KI, die Software läuft nach Änderungen weiterhin weniger stabil.
Finanzunternehmen in der EU müssen jede Softwareänderung unabhängig genehmigen lassen.

Was prüft ein Code-Review eigentlich?

Blaue Gießkanne mit Aufkleber „Geprüft“ und Lupe davor auf weißem Grund — Code-Reviews prüfen meist oberflächlich die Codequalität, nicht ob die Software funktioniert wie gewünscht

Ein Code-Review beantwortet nach Ström-Awns Analyse meist die leichtere Frage, ob der Code gut aussieht, und nicht die schwerere, ob die Software das gewünschte Ergebnis liefert.

Die Psychologie nennt diesen Tausch Attributsubstitution. Prüfer greifen zu Faustregeln wie dem vorzeitigen Beenden einer Funktion oder zu ihrem Bauchgefühl bei verdächtigem Code, etwa bei tiefer Verschachtelung. Als Gegenbeispiel nennt Ström-Awn das Spiel Undertale: Fast alle Dialoge stecken in einer einzigen riesigen Fallunterscheidung im Code, trotzdem zählt der Titel zu den beliebtesten Spielen des Jahrzehnts.

Ström-Awn führte bei Stripe das Designteam für Designsysteme und schreibt beim W3C an der Spezifikation für Design Tokens mit, also für einheitliche Gestaltungswerte wie Farben und Abstände.^[3] Seine These ergänzt die Debatte über Code-Reviews am Limit, in der Thoughtworks-Technikchefin Rachel Laycock im September vor bloßem Beschleunigen warnte.

Was soll an die Stelle des Code-Reviews treten?

Ström-Awn will KI-Werkzeuge den Code verbessern lassen und menschliche Prüfer auf die laufende Software ansetzen, möglichst im Live-Betrieb. Den Einwand, die KI kontrolliere sich dann selbst, hält der frühere Stripe-Designer für zweitrangig.

Absichern sollen den Weg Feature-Flags, mit denen Teams eine neue Funktion per Schalter abstellen, dazu die schrittweise Auslieferung an wenige Nutzer und lückenlose Überwachung im Betrieb. Ausnahmen sieht der Essay dort, wo Menschenleben oder große Summen auf dem Spiel stehen, etwa bei der Auszahlung von Steuererstattungen oder bei Waymos Robotaxis.

Googles DORA-Studie 2025 beschreibt das Stabilitätsproblem dahinter: 90 % der Befragten nutzen KI bei der Arbeit, mit dem KI-Einsatz liefern Teams mehr Änderungen aus, aber die Software läuft danach weniger stabil.^[4] 30 % vertrauen KI-generiertem Code wenig oder gar nicht. Der Umfrage State of Devs 2026 zufolge stammen im Median 63 % des Codes aus KI-Werkzeugen. Wie wenig ein Blick auf den Code verrät, zeigte im Oktober ein KI-Agent, der nur eine von 16 möglichen Ansichten einer Bedienoberfläche sah.

Code-Review neu verteilt: Wer prüft was?

Matt Ström-Awns Vorschlag neben den Pflichten für Finanzunternehmen in der EU

Der Druck in Zahlen

275 Mio.

Codeänderungen (Commits) pro Woche auf GitHub im April 2026, im ganzen Jahr 2025 waren es 1 Mrd.

90 %

der Befragten in Googles DORA-Studie 2025 nutzen KI bei der Arbeit

30 %

vertrauen KI-generiertem Code wenig oder gar nicht

Die Prüfung neu verteilt

Prüfgegenstand

Vorschlag Ström-Awn

Finanzunternehmen in der EU

Stil und offensichtliche Fehler

KI-Prüfer und Prüfprogramme für den Codestil

erlaubt, ersetzt keine Freigabe

Verhalten der Software

Menschen testen unter echten Bedingungen

kontrollierte Tests vorgeschrieben

Rückweg bei Fehlern

Feature-Flags, schrittweise Auslieferung

Ausweichverfahren vorgeschrieben

Freigabe

nach dem Test im Betrieb

unabhängig von der Umsetzung

Ein Code-Review, das Einrückungen bemängelt und den Live-Betrieb nie sieht, prüft die Verpackung statt der Ware.
Michael Dobler, Herausgeber Dr. Web

Was heißt das für Teams in Deutschland?

Banken, Versicherer und Zahlungsdienstleister müssen Änderungen an Software weiterhin unabhängig freigeben lassen: Die EU-Verordnung über die digitale Betriebsstabilität, ebenfalls DORA abgekürzt, schreibt das seit Januar 2025 vor.

Die Delegierte Verordnung (EU) 2024/1774 verlangt in Artikel 17 getrennte Zuständigkeiten für Genehmigung und Umsetzung, kontrollierte Tests, Qualitätssicherung und ein Ausweichverfahren für gescheiterte Änderungen.^[5] Zeilenweises Codelesen schreibt der Artikel nicht vor. Feature-Flags passen deshalb zu Ström-Awns Ansatz, ersetzen aber die unabhängige Freigabe nicht.

Agenturen und Mittelständler ohne diese Pflicht können den Vorschlag an einem Projekt testen: Stilfragen übernehmen Prüfprogramme für den Codestil und KI-Prüfer, ein Mensch klickt die Änderung in einer Testumgebung durch und gibt erst danach frei. Der Engpass heißt dann Verantwortung.