Wie halten wir bei PR-Reviews im Zeitalter von KI Schritt?

1. Jeden PR auf eine Sache begrenzen

Der schnellste Weg, Review-Dynamik abzuwürgen, ist ein PR, der drei Dinge auf einmal tut. Reviewer sollten nicht im Kopf auseinanderdröseln müssen, welche Änderungen zum Bugfix gehören und welche zu dem Refactoring, das du hineingeschmuggelt hast.

• Ein Bugfix, ein Feld, eine Funktion – nicht alle drei im selben PR.

• Ein fokussierter PR mit etwa ~1.000 Zeilen, der ein klares Problem löst, ist okay. Ein PR mit 300 Zeilen und drei Themen ist es nicht. Wenn du deutlich über 1.000 Zeilen liegst, ist das ein starkes Signal zum Aufteilen.

• Nutze gestapelte PRs für größere Änderungen.

• Mach vor dem Öffnen den Bauchcheck: Kann jemand das in einem Rutsch reviewen? Tut es genau eine Sache? Würdest du es mergen?

2. Fordere Review erst an, wenn es wirklich fertig ist

Drafts gibt es nicht ohne Grund. Einen PR aus dem Draft zu holen, ist ein Signal an das Team, dass du deine Hausaufgaben gemacht hast und dass sich jemand anders dafür Zeit nehmen sollte. Wenn dieses Signal unzuverlässig ist, bricht das ganze Review-System zusammen.

Nimm den Draft erst weg, wenn du bei allem hier Ja sagen kannst:

• Du hast ein Self-Review gemacht

• Alle Tests laufen durch, einschließlich e2e

• Null ungelöste Kommentare (Devin eingeschlossen)

• Du hast es lokal für UI/UX-Änderungen getestet

• Für Änderungen, die durch automatisierte Tests abgedeckt werden können, hast du verifiziert, dass sie zu 100 % abgedeckt sind

• Alle CI-Jobs sind grün (außer den nervigen Vercel-Previews)

Wenn bei irgendetwas nein herauskommt, lass ihn als Draft. Drafts, die Review anfordern, verschmutzen die Warteschlange und verzögern PRs, die wirklich bereit sind.

3. Begrenze deine offenen PRs auf 5 (Drafts zählen mit)

Offene PRs sind Bestand. Sie bringen Kontextwechsel-Kosten, das Risiko von Merge-Konflikten und Review-Schulden mit sich. Wenn du mehr als fünf gleichzeitig offen hast, stimmt die Rechnung nicht mehr. Du produzierst schneller, als das Team aufnehmen kann.

Wenn du 5 PRs offen hast, Draft und nicht Draft zusammen, fang nichts Neues an. Geh stattdessen die PRs deiner Teamkollegen reviewen oder bring deine älteren Arbeiten zu Ende.

4. Gib deiner PR-Beschreibung eine menschliche Stimme

Die Beschreibung muss nicht komplett von dir geschrieben sein. KI ist okay für die Struktur und das Zusammenfassen des Diffs. Das Problem bei dem, was wir gerade sehen, sind die massiven KI-generierten Beschreibungen, die wie eine generische Checkliste wirken, mit der sich niemand wirklich beschäftigt hat. Ihnen fehlt der menschliche Anteil, den ein Reviewer tatsächlich braucht.

• Eine einzeilige Notiz der Autorin oder des Autors zum gewählten Kompromiss oder dazu, warum dieser Fix gerade jetzt wichtig ist, bringt mehr als ein langes Block mit "Key Review Points" / "Human Review Checklist".

• Wenn du Code shipst, der noch nirgendwo genutzt wird, sag warum.

• Wenn KI die Beschreibung entworfen hat, kürze sie und ergänze den Kontext, den nur du hast.

5. Beweise, dass der Fix funktioniert

Ein PR, der sagt "behebt Bug X", ohne Beweise zu liefern, bittet den Reviewer darum, es einfach zu glauben. Mach das nicht zu seiner Aufgabe.

• Screenshots, Screenaufnahmen, Dashboards vorher/nachher, alles, was zeigt, dass der Bug tot ist und sonst nichts kaputtgegangen ist.

• Funktionales QA ist für UX/UI-Änderungen verpflichtend, nicht optional.

6. SQL- und Performance-Änderungen brauchen echte Validierung

Code-Review allein kann nicht bestätigen, dass ein Query-Rewrite unter Produktionslast hält. Einen Query-Diff zu lesen und zu sagen "sieht richtig aus" ist keine Validierung. Für PRs, die Query-Pfade oder Rewrites betreffen:

• EXPLAIN ANALYZE auf einem produktionsähnlichen Datensatz

• Latenzwerte vor/nachher oder Screenshots aus dem Dashboard

• Ausrollung hinter einem Feature-Flag für riskante Änderungen

7. KI ist ein Beschleuniger, kein Gehirn

KI kann Code schnell generieren. Sie kann nicht entscheiden, ob dieser Code überhaupt existieren sollte. Das Denken muss weiterhin von dir kommen.

• Erst designen. Den Ansatz skizzieren, die Edge Cases durchdenken, eine kurze Notiz schreiben, dann prompten.

• Nachdem der Agent generiert hat, lies es wirklich. Self-Review findet Prisma-Calls an der falschen Stelle, ignorierte Agent-Richtlinien, fragile Struktur usw.

• Bevor du öffnest, frag dich: Was berührt das? Gibt es Auswirkungen auf Nutzer? Performance- oder Sicherheitsfolgen? Wie groß ist der Schaden, wenn es falsch ist?

8. Validiere Security-PRs, bevor du sie öffnest

Bestätige, dass die Schwachstelle tatsächlich auf unsere Nutzung des Codes zutrifft. "Fix vulnerability X"-PRs, die sensible Pfade berühren, können mehr Risiko einführen als der ursprüngliche Bericht.

9. Route PRs an die richtige reviewende Person

Die falsche reviewende Person kostet zwei Leute Zeit: die Person, die kein sinnvolles Feedback geben kann, und die Autorin oder den Autor, der auf die zweite Runde mit der richtigen Person warten muss.

• Domänenlastige PRs (Salesforce/CRM-Routing, Team-Profil-Migrationen usw.) gehören zur Domänenverantwortung und nicht zu Foundation, die einfach nur eine von KI generierte Test-Suite abnickt.

• Änderungen an Kern-/Foundation-Pfaden (Query-Infrastruktur, hasTeamAccess usw.) verdienen vor dem Öffnen des PRs eine kurze Abstimmung mit dem verantwortlichen Team.

10. Architekturgespräche finden früh statt

Dreimal dieselbe Stelle zu flicken ist ein Signal, kein Zufall. Wenn du schon wieder um dieselbe Einschränkung herumarbeitest, ist der richtige Schritt ein Gespräch und möglicherweise ein Rewrite, nicht noch ein Patch.

Sprich vor der Implementierung mit Foundation/Head of Engineering. So sind die Infra-Module zusammengekommen, und Konsistenz verstärkt sich mit der Zeit.

11. Leichterer Weg für triviale Fixes

Nicht alles braucht Foundation-Review. Wir sollten unsere Review-Kapazität dort einsetzen, wo sie am meisten zählt.

Toast-Anpassungen, Button-Größen, mechanische Umbenennungen, Textänderungen, Mainline-Features – das kann durch KI-Review und/oder Reviews auf Team-Ebene laufen. Heb Foundation-Review für Änderungen auf, die es wirklich brauchen.

12. Öffne keine PRs im Namen anderer

Wenn Engineer X die Arbeit macht, öffnet Engineer X auch den PR. Sonst landen Kommentare bei der falschen Person, Fragen bleiben unbeantwortet und der PR stockt.