- Mit der exponentiell steigenden Menge und dem Umfang von durch AI erzeugtem Code ist die bisherige manuelle Form des Code-Reviews nicht mehr tragfähig
- Teams mit hoher AI-Einführungsquote verzeichnen 21 % mehr abgeschlossene Arbeit und 98 % mehr gemergte PRs, gleichzeitig steigt jedoch paradoxerweise die PR-Review-Zeit um 91 %
- Statt Code direkt zu prüfen, muss sich die menschliche Rolle auf eine vorgelagerte Validierung verlagern: das Review von Spezifikationen und Akzeptanzkriterien (Acceptance Criteria)
- Statt eines einzelnen Validierungs-Gates braucht es eine mehrschichtige Vertrauensarchitektur auf Basis des Swiss-Cheese-Modells: konkurrierende Multi-Agenten, deterministische Guardrails, BDD, Berechtigungssysteme und adversarielle Verifikation
- Der Ansatz „schnell deployen, alles beobachten und noch schneller zurückrollen“ ersetzt ein neues Paradigma aus langsamem Review mit anschließendem Debugging in Production
Menschen können Code-Reviews schon jetzt nicht mehr bewältigen
- PRs bleiben tagelang liegen, formale Freigaben werden erteilt, und Reviewer überfliegen in der Praxis Diffs mit 500 Zeilen
- Code-Review gilt als Qualitäts-Gate, doch es gibt Teams, die seit Jahrzehnten Software ohne zeilenweises Review ausliefern; verbreitet wurde Code-Review erst um 2012–2014
- Trotz Reviews treten Ausfälle auf, weshalb Teams Systeme wie Feature Flags, schrittweise Rollouts und sofortige Rollbacks aufgebaut haben
Wir müssen aufgeben, allen Code zu lesen
- In Teams mit hoher AI-Nutzung steigen Anzahl und Größe von Änderungen gleichzeitig exponentiell
- Basierend auf Daten von 1.255 Teams mit mehr als 10.000 Entwicklerinnen und Entwicklern (Faros-Analyse)
- Entwickler empfinden das Review von AI-generiertem Code als aufwendiger als das Review von Code von Kolleginnen und Kollegen
- Mit manuellem Code-Review ist dieser Kampf nicht zu gewinnen; Code-Review ist ein Genehmigungs-Gate aus der Vergangenheit, das nicht mehr zur heutigen Arbeitsweise passt
Auch AI-Code-Review ist letztlich nur „Review“
- Wenn AI Code schreibt und AI ihn reviewt, gibt es keinen Grund für eine hübsche Review-UI
- AI-Code-Review-Tools verschaffen nur Zeit, und diese Art von Review wird nach links verschoben (shift left) in den Entwicklungszyklus
- Es gibt keinen Grund, CI-Ressourcen zu verschwenden und zwischen Review-Zyklen Versionsverwaltung zu betreiben
- In einer Umgebung, in der Agenten Code schreiben, ist ein „frischer Blick“ nur ein weiterer Agent mit denselben blinden Flecken; der Wert liegt nicht im Freigabe-Gate, sondern in der Iterationsschleife
- Der Instinkt „Ich habe AI einmal etwas Dummes tun sehen, also muss ich immer nachprüfen“ war rational, als man noch manuell validieren konnte, ist bei der heutigen Größenordnung aber nicht mehr umsetzbar
Vom Code-Review zum Review der Absicht (Intent)
- Menschliche Checkpoints müssen weiter nach oben (upstream) verlagert werden
- In der Softwareentwicklung gibt es Präzedenzfälle für solche Verschiebungen: von Waterfall-Sign-offs zu Continuous Integration (CI)
- Spec-driven Development entwickelt sich zu einer zentralen Form der Zusammenarbeit mit AI
- Menschen sollten Spezifikationen, Pläne, Constraints und Akzeptanzkriterien reviewen, nicht Diffs mit 500 Zeilen
- Im neuen Paradigma wird die Spezifikation zur Source of Truth, und der Code ist deren Ergebnis
- Man reviewt nicht den Code, sondern die Schritte und Verifikationsregeln sowie den Vertrag, den der Code erfüllen muss
- Human-in-the-loop-Freigaben verlagern sich von „Ist das korrekt geschrieben?“ zu „Lösen wir mit den richtigen Constraints das richtige Problem?“
- Das wertvollste menschliche Urteilsvermögen kommt nicht nach der Code-Erzeugung zum Einsatz, sondern vor der Generierung der ersten Zeile
Mehrschichtiges Vertrauen aufbauen — das Swiss-Cheese-Modell
- LLMs folgen Anweisungen nicht zuverlässig, weichen häufig ab und sind selbst bei Eigenverifikation nicht vertrauenswürdig (sie antworten selbstbewusst „funktioniert“, während der Code brennt)
- Die Lösung besteht nicht darin, das LLM um Verifikation zu bitten, sondern es Verifikationsskripte schreiben zu lassen — ein Wechsel von Urteil zu Artefakt
- Vertrauen entsteht schichtweise; nach dem Swiss-Cheese-Modell werden unvollkommene Filter übereinandergelegt, damit sich ihre Löcher nicht ausrichten
Layer 1: Vergleich mehrerer Optionen
- Statt einen einzelnen Agenten nach der richtigen Antwort zu fragen, lassen drei Agenten verschiedene Ansätze versuchen und wählen das beste Ergebnis
- Die Auswahl muss nicht manuell erfolgen; man kann nach Kriterien ranken wie: die meisten Verifikationsschritte bestanden, der kleinste Diff oder keine neuen Abhängigkeiten hinzugefügt
- Die Kosten für Optionen sind heute so niedrig wie nie zuvor in der Geschichte des Software Engineering
Layer 2: Deterministische Guardrails
- Es braucht deterministische Methoden, um Arbeit zu validieren — Tests, Type Checks, Vertragsprüfungen und alles, was sich auf Fakten statt Meinungen stützt
- Statt das LLM zu fragen „Ist das fertig?“, definiert man Verifikationsschritte, die eine Reihe von Pass/Fail-Artefakten erzeugen
- Die Hierarchie der Guardrails:
- Coding Guidelines — lassen sich mit Custom-Lintern umsetzen
- Organisationsweite Invarianten — nicht verhandelbare Regeln wie das Verbot von hardcodierten Zugangsdaten, API-Keys oder Tokens
- Domänenverträge — Regeln je nach Framework, Service oder Bereich der Codebase (z. B. müssen im Payment-Bereich alle Beträge den Typ
Money verwenden)
- Akzeptanzkriterien (Acceptance Criteria) — aufgabenbezogene, individuelle Kriterien
- Verifikationsschritte müssen vor dem Schreiben des Codes definiert werden und dürfen nicht erst nachträglich erstellt werden, um bereits Vorhandenes abzusegnen
- Wenn der Agent sowohl Code als auch Tests schreibt, wird das Problem nur verschoben; die Verifikationskriterien müssen aus der Spezifikation kommen, nicht aus der Implementierung
Layer 3: Menschen definieren Akzeptanzkriterien
- Menschen schaffen Mehrwert vor allem dort, wo sie upstream den Erfolg definieren
- BDD (Behavior-Driven Development) gewinnt neue Relevanz
- Erwartetes Verhalten wird in natürlicher Sprache beschrieben und anschließend in Tests automatisiert
- Früher fühlte sich das Schreiben von Spezifikationen wie Zusatzarbeit an, weil man den Code trotzdem selbst schreiben musste; in einer Agenten-Umgebung ist die Spezifikation das primäre Artefakt
- Schreiben Menschen die Spezifikation, setzt der Agent sie um, und das BDD-Framework verifiziert — solange nichts fehlschlägt, muss man die Implementierung nicht lesen
- Was Menschen gut können: die Definition von „Korrektheit“, das Kodifizieren von Business-Logik und Edge Cases sowie das Nachdenken darüber, was schiefgehen könnte
- Akzeptanzkriterien, die von Menschen geschrieben und von Maschinen verifiziert werden, sind das Gate, das tatsächlich wichtig ist
Layer 4: Berechtigungssysteme als Architektur
- Es sollte eine Architekturentscheidung sein, was Agenten anfassen dürfen und was eine Eskalation erfordert
- Die meisten Agenten-Frameworks behandeln Berechtigungen als all or nothing, doch Granularität ist entscheidend
- Ein Agent, der einen Bug in einer Utility-Funktion behebt, braucht keinen Zugriff auf die Infrastrukturkonfiguration
- Ein Agent, der Tests schreibt, braucht keine Berechtigung, die CI-Pipeline zu ändern
- Der Scope sollte so eng wie möglich sein, solange der Agent noch nützliche Arbeit leisten kann
- Beispiel: Bei der Aufgabe „Fix eines Date-Parsing-Bugs in
utils/dates.py“ sollte der Zugriff nur auf diese Datei und die Testdateien erlaubt sein
- Wichtig sind auch Eskalations-Trigger: Änderungen an Authentifizierungslogik, Datenbankschemata oder neue Abhängigkeiten sollten unabhängig vom Selbstvertrauen des Agenten automatisch menschliches Review auslösen
Layer 5: Adversarielle Verifikation
- Verantwortung muss getrennt werden: Ein Agent führt die Aufgabe aus, ein anderer verifiziert — entscheidend ist, dass sie einander nicht vertrauen
- Das ist ein altes Muster, so wie QA-Teams nicht an Engineering-Manager berichten sollten und Code nicht nur vom Autor selbst reviewt werden darf
- Das lässt sich architektonisch erzwingen: Der Coding-Agent weiß nicht, was der Verifikations-Agent prüfen wird, und der Verifikations-Agent kann den Code nicht ändern — adversariell by design
- Noch weiter gedacht kann ein dritter Agent versuchen, das vom ersten Agenten Erstellte gezielt über Edge Cases und Failure Modes zu zerstören — Red-Team/Blue-Team-Automatisierung für jede Änderung
Die Bedeutung von „gutem Code“ verändert sich
- Die Anreize in Agentensystemen sind einfach: die gegebene Aufgabe abschließen und die beauftragende Person zufriedenstellen — langfristige Korrektheit oder Business-Anforderungen sind kein intrinsischer Antrieb
- Es ist die Aufgabe des Menschen, dies in Constraints zu kodifizieren
- In Code, der von Agenten erzeugt und von Agenten gelesen wird, wird die Form von „gutem Code“ stärker standardisiert, und neue Codebasen müssen weniger Orientierung vorgeben
- Die Richtung der Zukunft lautet: „schnell deployen, alles beobachten und noch schneller zurückrollen“
- Das Gegenteil ist: „langsam reviewen, Bugs trotzdem übersehen und dann in Production debuggen“
- Wir können nicht gewinnen, indem wir noch mehr Maschinen-Output lesen; nötig ist überlegenes Denken weiter upstream, dort, wo Entscheidungen tatsächlich wichtig sind
- Wenn Agenten gut mit Code umgehen können, ist es nicht mehr wichtig, ob Menschen diesen Code noch lesen können
25 Kommentare
Es ist schon so absurd, dass man lachen muss: Code-Reviews sind der Flaschenhals, also schaffen wir die Reviews einfach ab. 😂😂😂😂
Ich frage mich, ob Code-Reviews vor der AI-Ära bei allen wirklich gut funktioniert haben.
Organisationen, die Code-Reviews schnell und engagiert durchführen, waren nämlich ziemlich selten.
Schon vor AI waren Code-Reviews bei vielen Entwicklern schleppend, aufgeschoben und oberflächlich.
Meiner Erfahrung nach waren US-Tech-Unternehmen lehrbuchmäßig organisiert, während es im Ausland, einschließlich hierzulande, ein ziemliches Durcheinander war.
Anders gesagt: Je gründlicher die Reviews waren, desto größer war der Arbeitsstress, und chaotische Reviews waren vergleichsweise lockerer
Ich denke, dass das Wegfallen von Reviews das Ergebnis von Verhaltensanreizen ist.
Wenn ein Unternehmen
eine niedrige Fehlerquote verlangt, wird es Reviews stärker einfordern,
wenn es um eine schnelle Veröffentlichung von Funktionen geht, werden Reviews nach und nach weggelassen.
Dass Reviews verschwinden, lässt mich denken, dass Unternehmen schnelle Feature-Releases bevorzugen.
Aber selbst wenn ich Investor wäre, würde ich wahrscheinlich dasselbe verlangen, haha
Ich bin mir nicht sicher. Nur weil Reviews zum Engpass geworden sind, zu sagen, man solle keine Reviews mehr machen, wirkt auf mich so, als würde man die eigentliche Aufgabe aus den Augen verlieren. Ich denke, ein besserer Ansatz wäre vielmehr, in dem Maß, in dem sich die Implementierungszeit verkürzt hat, verpflichtend Zeit für Reviews einzuplanen.
Sollen wir einfach weiter Black Boxes aufeinanderstapeln?
Das ist durchaus ein bedenkenswerter Ansatz, aber offenbar überwiegt derzeit noch die Ansicht, dass es dafür noch zu früh ist.
Code einfach wie eine Blackbox bauen und nur das Ergebnis betrachten … ungefähr so ist die Idee … ob das wirklich eine wünschenswerte Richtung ist? Ich denke, irgendwann wird ganz sicher der Zeitpunkt kommen, an dem wir den bisherigen von KI geschriebenen Code komplett umkrempeln.
Das ist ein ähnliches Thema wie die Aussage: "FSD ist so schlau geworden, dass der Fahrer ruhig schlafen kann."
Technisch gesehen scheint so eine Zeit allmählich zu kommen, aber entscheidend wird wohl sein, wie man die Hürde der Verantwortung überwindet.
Ich denke, Code-Review ist nicht zuletzt eine minimale Sicherheitsvorkehrung.
Warum übernimmt bei der Validierung der Absicht als übergeordnetem Konzept überhaupt ein Mensch diese Aufgabe ..?
Eigentlich muss man es nicht einmal in einer Programmiersprache coden lassen.
Wenn man der KI denselben Prompt gibt, kommt mir der Gedanke, dass die Überprüfung des Ergebnisses nicht irgendwie dem Testen der Leistungsfähigkeit des Modells ähnelt.
Wirkt, als hätte man erst das Fazit festgelegt und dann das LLM gebeten, es zu schreiben. Sophisterei.
Scheint überhaupt keine Production-Erfahrung zu haben
Klingt einfach nach einer Traumvorstellung.
Mit der Zeit merkt man doch eher, dass selbst Dokumentation wenig bringt und Reviews immer strenger werden, oder?
Klar~ Schon allein ein so formulierter Beitrag hat ausgereicht, um die Absicht deutlich zu machen.
Es ist ein übersetzter Artikel: https://rosetta.page/post/…
Das ist eigentlich ein Problem, das man schon in der Planungsphase herausfiltern kann.
Beim handschriftlichen Schreiben von Code übernehmen Entwickler ganz natürlich gleichzeitig und implizit Planung, Design, Exploration, Verständnis, Tests, Selbst-Review und auch die spätere Reaktion auf auftretende Probleme, sodass sich diese Aspekte im Prozess von selbst aufeinander abstimmen. Deshalb denke ich, dass es bis zu einem gewissen Grad auch dann noch funktioniert hat, wenn Tests oder Reviews nicht ausreichend waren.
Wenn man aber den Prozess des manuellen Codierens abschafft, muss man die zuvor impliziten Prozesse ausdrücklich voneinander abgrenzen. Da der Verfasser des Codes und der Prüfer noch stärker voneinander getrennt sind, steigt die Ineffizienz in der Kommunikation. Weil auch das Vertrauen in die Instanz, die den Code erstellt hat, weiter sinkt, steigen ebenfalls die Kosten der Prüfung.
Ich frage mich, ob das nicht einem ähnlichen Konzept wie der doorman's fallacy entspricht.
Darüber habe ich auch in der Firma oft nachgedacht. Gute Idee – ich sollte das persönlich auch bei Hanis einführen, das ich gerade selbst entwickle.
Ich denke, wir werden uns nach und nach in die Richtung bewegen, Reviews immer weiter zu verschlanken und Tests deutlich strenger zu machen.
Es geht wohl nicht einfach darum, Code-Reviews abzuschaffen, sondern Reviews anhand von Ergebnissen durchzuführen, mit denen sich explizit prüfen lässt, welche Intention dahintersteht und ob diese Intention korrekt umgesetzt wurde.
Zum jetzigen Zeitpunkt halte ich es für wünschenswert, die Details der Code-Implementierung als Blackbox zu behandeln, sofern es nicht um Design- oder Architektur-Ebene geht.
Ich denke, dass sich diese Blackboxen immer weiter auftürmen und es am Ende so weit kommen könnte, dass selbst KI damit nicht mehr richtig umgehen kann. Mir scheint, alle sind viel zu sehr von der Bequemlichkeit berauscht. Ich glaube, irgendwann wird es einen großen Zwischenfall geben.
Ich stimme der Meinung oben ebenfalls zu. Was, wenn eines Tages plötzlich entdeckt wird, dass das Modell einen bestimmten Teil von menschlichem Code falsch gelernt hat, und man erkennt, dass sich das die ganze Zeit im Code niedergeschlagen hat? Dieser Tag könnte der sein, an dem alles auf den Kopf gestellt wird..
Egal wie leistungsfähig das neueste Modell auch ist: Solange es im SWE-Benchmark nicht immer (6 Neunen, 0,999999) die volle Punktzahl erreicht, denke ich, dass diese Möglichkeit weiterhin besteht.
Intentions-Review. Ein schöner Ausdruck.
Ich habe darüber nachgedacht, wie wir in einer durch AI beschleunigten Zeit reagieren sollten,
dies ist ein guter Artikel, der eine neue Perspektive auf Code-Reviews bietet!