KI macht Code Review erst schlechter, bevor sie die Auslieferung besser macht. Genau das wollen viel zu viele Teams immer noch nicht zugeben. KI-generierte PRs werden mehr als 2,5-mal so oft wie von Menschen geschriebene abgelehnt oder müssen deutlich überarbeitet werden, und sie warten mehr als 5-mal so lange, bis sich überhaupt jemand das Review vornimmt. Der State of Code Survey 2026 von SonarSource ergab außerdem, dass 96 % der Devs der funktionalen Korrektheit von KI-generiertem Code nicht voll vertrauen. Diese Vertrauenslücke ist der Engpass.

Hier wird der Gegenwind gegen Spec-driven Development vom Mai 2026 interessant. Ja, Leute nennen es „Wasserfall mit Markdown“, eine „Token verbrennende Zeremonie“ und eine Produktivitätsfalle. Manche Kritik ist berechtigt. GitHub Spec Kit kann eine Menge Dateien erzeugen. Kiro, OpenSpec, Traycer, Vibe Kanban und BMAD gehen alle Kompromisse ein. Simon Willison macht sich stark für praktische Review-Gewohnheiten. Birgitta Böckelers Einteilung in spec-first, spec-anchored und spec-as-source ist nützlich, weil sie schlanke Disziplin von aufgeblähtem Ritual trennt. Addy Osmanis Spec-Format mit sechs Abschnitten ist aus demselben Grund nützlich. Es gibt dir genug Struktur, um gegen etwas Konkretes zu reviewen.

Wenn du wissen willst, wie du KI-generierte PRs prüfst, ohne dein Team auszubremsen, halte es einfach. Verankere das Review in der Spec. Automatisiere die Basis-Checks vor dem menschlichen Review. Arbeite mit Vertrauensstufen, damit du gründliche Aufmerksamkeit nur dort investierst, wo es darauf ankommt.

Inhalt

Der neue Engpass, den KI schafft

Früher war das Schreiben von Code der Engpass. Heute ist es das Review von Code, dem du nicht traust.

Eine Infografik, die zeigt, dass KI Code schneller erzeugt, das menschliche Review und die Auslieferung aber verlangsamt.

KI spuckt mehr Code aus, als ein kleines Team sicher prüfen kann. Schlimmer noch: KI-gestützte PRs kommen beim ersten Review auf eine Akzeptanzrate von 32,7 %, gegenüber 84,4 % bei PRs von Menschen, und sie sind ungefähr 1,5- bis 1,8-mal so groß wie PRs ohne KI-Hilfe. Außerdem liegen sie etwa 1.000 Minuten statt 200 Minuten in der Warteschlange, bevor das Review beginnt, so die verifizierten Umfragedaten oben. Das ist keine Beschleunigung. Das ist ein Backlog mit besserem Branding.

Praxisregel: Wenn dein KI-Output bei Menschen landet, bevor CI, Linting, Tests und grundlegende Security-Checks gelaufen sind, ist dein Review-Prozess kaputt.

Dasselbe Fehlermuster siehst du auch in Content-Workflows. Wenn Arbeit ins Review geht, bevor sie die Mindestanforderungen erfüllt, wird die Freigabe zum Engpass. Der Leitfaden von PostPulse zur Content-Freigabe macht denselben Punkt in einem anderen Bereich. Fehlende Disziplin am Anfang bremst alles, was danach kommt.

Reviews an der Spec verankern, nicht am Code

Wenn du zuerst den Diff öffnest, hast du dir das Review schon schwerer gemacht.

Jemand prüft konzentriert mit einer Lupe die Akzeptanzkriterien auf einem Whiteboard, um die Softwarequalität sicherzustellen.

Fang bei der Absicht an. Prüf danach die Umsetzung. Ein zentrales Fehlermuster ist Intent Drift, also das Abdriften von der eigentlichen Absicht durch unterspezifizierte Prompts. Die Lösung sind präzise Specs mit EARS-Akzeptanzkriterien und ein Commit, der auf die Spec zurückverweist, etwa feat(auth): magic link, refs specs/004-magic-link/spec.md, wie diese Analyse zu Spec-driven Development erklärt.

Was du vergleichst

Nimm die Spec als maßgebliche Quelle. Nicht die PR-Beschreibung. Nicht die Erklärung des Agents.

  • Akzeptanzkriterien: Erfüllt die Änderung das geforderte Verhalten?
  • Scope-Grenzen: Hat der Agent zusätzliche „hilfreiche“ Arbeit eingebaut, um die du nicht gebeten hast?
  • Validierungsszenarien: Decken die Tests die Fälle ab, die laut Spec wichtig sind?

Addy Osmanis Spec-Format mit sechs Abschnitten hilft hier, weil es die Grundlagen an einem Ort bündelt. Wenn deine Specs schwach sind, behebe das zuerst. Dieser Leitfaden zu KI-tauglichen Product Spec Sheets ist eine solide Referenz dafür, sie reviewbar statt aufgebläht zu halten.

Prüf gegen die Spec, nicht gegen die Geschichte, die dir der Code erzählen will.

Auch das ADR-Muster aus dem Claude-Code-Thread über Architecture Decision Records zählt. Wenn der PR die Architektur ändert, halte die Entscheidung fest. Vergrab sie nicht in Kommentaren.

Alle Basis-Qualitätschecks automatisieren

Kein Mensch sollte Zeit damit verschwenden, etwas zu finden, das eine Maschine in Sekunden ablehnen kann.

Ein Diagramm des automatisierten Pull-Request-Gatekeeper-Workflows, von der Einreichung bis zum menschlichen Code Review.

Bevor jemand eine Zeile liest, sollte der PR Folgendes bestehen:

  • Linting und Formatierung
  • Typprüfungen
  • Unit- und Integrationstests
  • SAST und Secret Detection
  • Schwellenwerte für Coverage und Komplexität

Teams, die Basis-Checks vor dem menschlichen Review automatisieren, berichten von einer um 68 % kürzeren Durchlaufzeit bei PR-Reviews, ohne bei ihren Code-Quality-Standards Abstriche zu machen, so der Beitrag von Codacy zum KI-PR-Engpass.

Wenn du eine verständliche Auffrischung zu den Grundlagen der Testautomatisierung brauchst, lohnt sich ein Blick in diesen Leitfaden zu automatisierten Tests.

Die Sorge, die in Threads über KI immer wieder auftaucht, ist simpel: Agents überspringen Best Practices. Genau diese Angst zeigte sich in der Reddit-Diskussion darüber, dass gute Praktiken verloren gehen. Die Antwort sind nicht mehr Meetings. Die Antwort sind harte Gates.

Kombiniere deinen Gatekeeper bei sicherheitskritischen Änderungen mit einem manuellen Audit als fester Gewohnheit. Dieser Beitrag zum Security-Audit beim Vibe Coding behandelt die Art von Problemen, die im Diff harmlos aussehen und später trotzdem hochgehen.

Ein kurzes visuelles Beispiel hilft:

Vertrauensstufen für das menschliche Review

Nicht jeder PR verdient dieselbe Aufmerksamkeit. Wer so tut, als wäre es anders, treibt Teams in den Burnout.

Eine Infografik zu einem gestuften Review-System für Pull Requests mit drei Review-Ebenen für Software-Engineering-Teams.

Stufe 1

Prüf jede Zeile, wenn KI Identität, Zugriff oder Zustand berührt. Fachleute raten, solchen Code standardmäßig als Hochrisiko zu behandeln. Außerdem versäumen es 82 % der KI-Testsuites, Edge Cases zu validieren. Testdateien brauchen also gezielte Skepsis statt blindem Vertrauen, wie dieser Leitfaden zum Review KI-generierter PRs festhält.

Stufe 2

Bei mittlerem Risiko reichen Stichproben. UI-Komponenten, CRUD-Boilerplate, Adapter-Code, interne Tools. Prüf die Struktur, sieh dir ein paar Dateien gründlich an, vergewissere dich, dass die Tests wirklich Logik abdecken, und mach weiter.

Stufe 3

Änderungen mit geringem Risiko überfliegst du und gibst sie frei. Docs. Generierte Dateien. Triviales Aufräumen in der Config. Dependency-Updates mit klarem Scope.

Verlang Belege statt Erklärungen. Grüne Tests, reproduzierbare Edge Cases und der Nachweis, dass Regeln wirklich durchgesetzt werden, zählen mehr als eine selbstbewusste PR-Zusammenfassung.

So bleibt die Aufmerksamkeit der Erfahrensten dort, wo sie hingehört. Architektur. Datenfluss. Geschäftslogik. Fehlerfälle.

Dein Playbook für das Self-Review

Wenn du allein arbeitest, machst du das Review selbst. Dann mach es auch richtig.

Geh vor dem Merge diese Checkliste durch:

Check Frage
KI-Gate bestanden Sind CI, Lint, Tests und Security-Checks durchgelaufen, bevor du mit dem Review angefangen hast?
Passt zur Spec Erfüllt der PR die Akzeptanzkriterien und bleibt er im Scope?
Vertrauensstufe Ist das Arbeit der Stufe 1, 2 oder 3? Prüfst du in der richtigen Tiefe?
Testqualität Belegen die Tests Verhalten, oder spiegeln sie nur die Implementierung?
Risiko-Scan Bringt die Änderung neue Dependencies, Auth-Logik, Zustandsänderungen oder Architektur-Drift mit?
Wartungskosten Verstehst du diesen Code in einem Monat noch, ohne das Modell fragen zu müssen, was es gemeint hat?

Wenn der PR einen Bug behebt, schreib oder aktualisiere zuerst den Bug-Report. Eine saubere Issue-Beschreibung macht das Self-Review weniger schwammig. Dieses Bug-Report-Template hilft, die Messlatte für die Abnahme sichtbar zu halten.

Spec-driven Development ohne Zeremonie ist simpel. Halte die Spec kurz. Halte den PR klein. Halte die automatischen Checks streng. Prüf vollständig, wo der mögliche Schaden real ist. Beim Rest reichen Stichproben. So reviewst du KI-generierte PRs, ohne selbst zur Vollzeit-Putzkraft zu werden.

In Tekk.coach ist der Abgleich mit der Spec eingebaut: Die Loops schreiben die Spec aus dem, was sich in deinem Code geändert hat (oder du schreibst sie selbst), und ein PR mit Closes TEK-123 schließt die Spec erst ab, wenn er mit erledigter Checkliste gemergt wird.

Teil des Leitfadens zu Spec-driven Development – ein ehrliches Playbook dafür, mit KI-Coding-Agents auszuliefern. Die andere Hälfte ist Loop Engineering: An der Spec erkennt ein Loop, dass er fertig ist.