So machen wir Codeprüfungen – nach dem Vorbild des Claude-Code-Teams

Anthropic hat kürzlich beschrieben, wie das Claude-Code-Team Code prüft: How the Claude Code team does code review. Das Ziel lässt sich in einem Satz zusammenfassen: so wenig menschliche Prüfzeit wie möglich aufwenden, ohne dass Reverts oder Störungen zunehmen. Die Prüfung ist nicht mehr ein einzelnes Tor vor dem Mergen. Automatische Prüfungen laufen durchgehend mit, und menschliche Aufmerksamkeit fließt nur in die riskanten Teile.

Das hat uns angesprochen. Wir sind ein Engineering-Team von gut zehn Leuten und arbeiten seit über einem Jahr auf genau dasselbe hin: menschliche Arbeit dort einsetzen, wo sie wirklich gebraucht wird, und den Rest der KI überlassen. Unser Werkzeug dafür ist HeyDeer, der KI-Dienst für Codeprüfungen, den wir selbst entwickelt haben. Im Folgenden stellen wir unseren Ansatz dem Artikel von Anthropic gegenüber und erklären, warum HeyDeer so gestaltet ist.

1. Warum Menschen nicht mehr jede Zeile prüfen können

Laut Anthropic schreibt Claude rund 90 % des Codes von Claude Code, und die Zahl der gemergten PRs hat sich innerhalb weniger Monate mehr als verdoppelt. Bei uns verlief es ähnlich.

Früher haben wir bei Codeprüfungen einen strengen Maßstab angelegt: Jemand las jede Zeile sorgfältig und überlegte, ob es eine bessere Lösung gäbe. Denn schlechter Code, der einmal in der Codebasis gelandet ist, lässt sich nur schwer wieder entfernen.

Zur Zeit von Opus 4.1 schrieb KI bereits 70 bis 80 % unseres Codes, und die PRs, die auf GitHub auf eine Prüfung warteten, stapelten sich immer weiter. Wir kamen allmählich nicht mehr hinterher. Heute, mit Opus 5.5, sind die Modelle so leistungsfähig, dass Engineers vor allem Ziele vorgeben und die Umsetzung Coding-Agenten überlassen – KI schreibt nahezu 100 % unseres Codes. Würden Menschen weiterhin jede Zeile prüfen, wären sie der langsamste Schritt im ganzen Prozess.

Gleichzeitig ist die zeilenweise Prüfung weniger wert als früher. Die Code-Smells, die uns früher am meisten Sorgen machten, kann KI leicht beseitigen, sodass Menschen sie nicht mehr Zeile für Zeile aufspüren müssen. Wie wir das machen, erklären wir in einem eigenen Beitrag.

Die Frage lautet also nicht mehr „Wie können Menschen schneller prüfen?“, sondern:

1. Welche Änderungen muss sich wirklich ein Mensch ansehen?
2. Wie halten wir bei allen anderen die Qualität hoch?

Schauen wir uns beide Fragen nacheinander an.

2. Welche Änderungen einen Menschen brauchen: Einstufung nach Risiko

Anthropics Antwort ist menschliche Genehmigung nach Risiko: Ein Klassifikator bestimmt die Risikostufe anhand der Änderung selbst, nicht danach, wer sie geschrieben hat. Änderungen mit niedrigem Risiko brauchen keine menschliche Genehmigung, sobald die automatischen Prüfungen bestanden sind; bei mittlerem Risiko genehmigt eine Person, bei hohem Risiko zwei.

HeyDeer funktioniert genauso. Jede Prüfung stuft das Risiko des PRs ein (niedrig, mittel oder hoch) und begründet die Einstufung. In der Einstellung PRs, die HeyDeer genehmigen darf legst du fest, bei welchen Risikostufen HeyDeer genehmigen darf.

Niedriges und mittleres Risiko: HeyDeer genehmigt

Unser Team hat „PRs mit niedrigem und mittlerem Risiko“ gewählt: Solange ein PR kein hohes Risiko hat und HeyDeers vollständige Prüfung keine Probleme findet, genehmigt HeyDeer ihn, und der PR wird automatisch in main gemergt.

So arbeiten wir seit 8 Monaten, und kein einziges Mal hat gemergter fehlerhafter Code unseren Produktivdienst lahmgelegt.

Hohes Risiko: Menschen beurteilen die Richtung, HeyDeer kümmert sich um die Details

PRs mit hohem Risiko brauchen weiterhin die Genehmigung eines weiteren Engineers. Doch dessen Rolle hat sich verändert: Statt Zeile für Zeile nach Fehlern zu suchen, beurteilt er mit Abstand, ob Ansatz und Richtung des PRs stimmen. Das deckt sich mit den Stellen, an denen Anthropics Artikel Menschen beteiligt lässt: bei der Entscheidung, ob etwas überhaupt gebaut werden soll, bei der Prüfung der Architektur und beim Lesen der Belege hinter einer Änderung. Die Feinheiten kannst du HeyDeer überlassen.

Damit Menschen schneller finden, worauf es ankommt, bietet HeyDeer einen Rundgang:

• Er gruppiert zusammengehörige Änderungen, markiert jede Gruppe als Pflichtlektüre, Lesen empfohlen oder Überfliegen und listet Änderungen abseits des Hauptpfads unter Sonstige auf, jeweils mit dem Grund, warum sie dabei sind. So siehst du auf einen Blick, was du überspringen kannst, und richtest deine Aufmerksamkeit auf die wichtigsten Teile.
• Er nennt die Risikostufe des PRs samt Begründung, damit du weißt, was du sorgfältig bestätigen solltest.

Prüfer lesen nicht mehr von der ersten bis zur letzten Datei. Sie gehen direkt zu den wenigen Stellen, die am meisten menschliches Urteilsvermögen erfordern.

3. Hohe Qualität, wo kein Mensch hinschaut

Dass KI die meisten PRs genehmigt, funktioniert nur, wenn man sich auf ihre Prüfung verlassen kann: Sie muss finden, was da ist, ohne Menschen mit Rauschen zu überschütten. HeyDeer ist auf beides ausgelegt und lässt sich von jedem Team an seine Art der Prüfung anpassen.

Präzise: Mehrere Modelle prüfen und kontrollieren sich gegenseitig

Bei Anthropics KI-Prüfung suchen mehrere Agenten parallel nach Bugs, dann stimmen andere Agenten über jeden Befund ab, und nur die bestätigten werden veröffentlicht.

HeyDeer geht noch weiter: Modelle verschiedener Anbieter prüfen jede Änderung und kontrollieren sich gegenseitig. Ein einzelnes Modell übersieht leicht Probleme und meldet leicht falsche, und mehrere Instanzen desselben Modells machen meist dieselben Fehler. Unterschiedliche Modelle haben unterschiedliche blinde Flecken. Deshalb findet die gegenseitige Prüfung spürbar mehr Probleme, und der Abgleich filtert einen Großteil des Rauschens und der Fehlalarme heraus.

Weniger Rauschen schont auch die menschliche Aufmerksamkeit. Bei zu vielen Fehlalarmen kommen Menschen nicht mehr hinterher und hören irgendwann auf zu lesen. Überlässt man stattdessen alles einem Coding-Agenten, folgt er Fehlalarmen womöglich blind und bläht die Codebasis auf. Die Prüfung der KI zu überlassen, funktioniert nur, wenn ihre Ergebnisse präzise sind.

Gründlich: Repository-Prüfungen setzen Teamkonventionen durch

Anthropics Ansatz: Wenn derselbe Prüfkommentar immer wieder auftaucht, behebst du das Problem an der Quelle – in Skills, Lint-Regeln, CLAUDE.md oder REVIEW.md.

Unserer Erfahrung nach tun sich allgemeine Prüfwerkzeuge mit den Anforderungen einer bestimmten Codebasis schwer: wie Button-Beschriftungen großgeschrieben werden, welchen Ton Oberflächentexte haben, welche Konventionen das Team für React befolgt und so weiter. In AGENTS.md oder einem Skill festgehalten, leiten diese Konventionen Coding-Agenten beim Schreiben von Code an. Bei einer vollständigen Codeprüfung gehen sie in einem großen Kontext jedoch leicht unter und werden übersehen.

Genau dafür gibt es HeyDeers Repository-Prüfungen. Schreib die Anforderungen, die geprüft werden sollen, in einfacher Sprache in .agents/checks. HeyDeer gibt jeder Prüfung einen eigenen Prüfer, der jeden PR, der passende Dateien ändert, anhand genau dieser einen Anforderung prüft – so geht nichts verloren.

Anpassbar: ein Feedback-Umfang, der zur Prüfpraxis deines Teams passt

Teams erwarten unterschiedliches Feedback von einer Prüfung, deshalb bietet HeyDeer die Einstellung Feedback-Umfang:

• Kompakt: für Teams, die weiterhin vor allem auf menschliche Prüfung setzen, etwa im Finanzbereich. Es bleiben nur die wichtigen Probleme übrig, damit Menschen ihre Zeit dort einsetzen, wo es am meisten zählt.
• Ausgewogen (die Voreinstellung) oder Ausführlich: für Teams, die den Großteil von Prüfung und Behebung Coding-Agenten oder HeyDeer überlassen. Kleine Probleme zu beheben kostet KI fast nichts, also werden auch Kleinigkeiten erledigt.

4. Nach der Prüfung: Der Autopilot behebt, bis der PR fertig ist

Sobald die Prüfung Probleme findet, muss sie noch jemand beheben. Wenn ein Engineer in jeder Runde zurückkommen muss, um die Kommentare zu lesen, einen Agenten um Änderungen zu bitten und auf die nächste Prüfung zu warten, ist seine Aufmerksamkeit weiterhin gebunden.

Anthropics Artikel spricht offen ein sehr reales Problem an: KI-Prüfungen können nicht zum Abschluss kommen. Einer ihrer PRs durchlief über Nacht mehr als fünfzig Runden aus Prüfung und Behebung. Rund 59 % dessen, was der Prüfer immer wieder bemängelte, war Code, der schon bei seinem ersten Durchgang vorhanden war: Jede Runde fand keine neuen Bugs, sondern nur ein paar weitere alte. Inzwischen hat Anthropic eine Reihe von Verbesserungen umgesetzt, etwa die Zahl der Runden zu begrenzen, nach den ersten Durchgängen nur noch neue Änderungen zu prüfen und bereits veröffentlichte Befunde nicht zu wiederholen.

Bei HeyDeer war es von Anfang an ein Designziel, dass Prüfungen zum Abschluss kommen. Findet HeyDeer eine Reihe kleiner Probleme, kannst du sie an den Autopilot übergeben: Er behebt, was offen ist, pusht in den Branch des PRs und prüft seine eigenen Änderungen – so lange, bis der PR bereit zum Mergen ist oder eine Frage einen Menschen braucht. Bei uns sind die meisten PRs nach zwei Runden fertig, komplexere nach drei. Der Autopilot läuft höchstens 5 Runden, und wenn er stoppt, erklärt er, warum und was noch von dir gebraucht wird.

Das ist uns sehr wichtig. Kontextwechsel sind für Menschen sehr teuer, und wir wollen nicht, dass Engineers zwei Dinge gleichzeitig im Kopf behalten müssen: an einem neuen Feature schreiben und sich dabei fragen, ob die Kommentare zum letzten PR erledigt sind. Sobald sie den Autopilot gestartet haben, können sich Engineers beruhigt der nächsten Aufgabe widmen.

Zusammengenommen sieht so der Alltag unseres Teams aus: Sobald Engineers einen PR eröffnet haben, können sie sich etwas anderem zuwenden. HeyDeer prüft ihn, und der Autopilot behebt, was gefunden wird. PRs mit niedrigem und mittlerem Risiko genehmigt HeyDeer, und sie werden direkt in main gemergt; bei PRs mit hohem Risiko prüft ein weiterer Engineer anhand des Rundgangs die Richtung.

5. Welche Teams so arbeiten können

Für wen eignet sich dieser Ansatz, bei dem „nur Änderungen mit hohem Risiko eine menschliche Prüfung brauchen“? Mit dem, was KI heute kann, denken wir, dass die meisten Start-ups sowie kleinen und mittleren Unternehmen so arbeiten können, solange ihr Geschäft keine besonders sensiblen Informationen betrifft. Du kannst damit beginnen, HeyDeer nur PRs mit niedrigem Risiko genehmigen zu lassen, und das auf mittleres Risiko ausweiten, sobald dein Team Vertrauen aufgebaut hat.

Fazit

So ungefähr lassen sich Anthropics Praktiken auf unsere Arbeit mit HeyDeer übertragen:

Werkzeuge und Modelle werden sich ändern, das Ziel nicht: Menschliche Aufmerksamkeit ist die knappste Ressource eines Teams – setze sie dort ein, wo sie am meisten zählt. Wenn auch dein Team merkt, dass KI Code schneller schreibt, als Menschen ihn prüfen können, probier HeyDeer aus.