Claude Code prüft 30.000 Merges am Tag – mit einem Reviewer pro Abstraktionsebene
One reviewer per layer: splitting code review by the way code is read
Das Claude-Code-Team musste seinen Review-Prozess umbauen, als die Zahl der täglich gemergten Änderungen im Monorepo von rund 2.500 im Mai auf über 30.000 im September sprang. Statt Zeile für Zeile zu lesen, durchläuft jede Änderung sechs Prüfschichten, von Intent und Form über lokale Bedeutung, Verdrahtung und Laufzeit bis zur Nutzung. Der Autor schlägt vor, jeder Ebene einen eigenen Agenten mit engem Kontext zu geben – als Baum, in dem Verträge nach oben wandern statt rohem Code.
Wir befolgen diese Regel in unserem Code und brechen sie dann in unseren Prompts.
- jwpapi
Mein Problem ist gerade, dass jede Art von Review-Prozess unnötige Komplexität hinzufügt, die später deine Agilität bremst, deine Kosten erhöht und die Performance verschlechtert.
Wenn du ein Feature hast und 6 verschiedene Reviewer es durchgehen, bläht sich die Logik leicht auf. Ich frage mich, wie andere das handhaben? Ich bin voll dabei und will, dass das funktioniert, aber das ist meine aktuelle Einschränkung.
Ich bekomme oft schlechte Vorschläge von Review-Monitoren, weil sie etwas falsch verstehen. Manchmal bekomme ich gute, sehr gute, aber manche sind schlecht. Also bin ich immer offen für Reviews zu Bugs, aber ich hätte Angst, dass es nach 6 Reviewern nur ein Haufen Text ist und mich verwirrt, sodass das Endergebnis schlechter ist, als wenn ich selbst die wirklich kritischen Dinge durchgehe. Mein Kontext ist auch begrenzt und komplett hands-off ist nicht zuverlässig genug...
Wie macht ihr das?
- fg137
Benchmarks oder das ist nicht besser als mein Einzeiler "mach ein Code-Review für diese Änderung"
- visarga
Ich denke, es ist ein guter Ansatz für dieses Jahr, aber es übersieht etwas Wichtiges – woher weißt du, dass der Code nach Wochen und Monaten der Steuerung über viele Sitzungen hinweg noch deine Absicht widerspiegelt? Nachrichten fließen in die Sitzung und verschwinden aus dem Blickfeld, und über Kompaktierungen/neue Sitzungen hinweg werden sie vergessen. Um das zu lösen, protokolliere ich jede Benutzernachricht in einem Chat-Log und überprüfe es von Zeit zu Zeit, um die neueste Form der Benutzerabsicht herauszudestillieren.
Eine andere Art von Review, die hier oder in Anthropics Artikel nicht erwähnt wird, ist das Plan-Review. Ich erstelle den Plan für einen Arbeitsabschnitt und lasse dann den Plan (als Datei gespeichert) von einem oder mehreren Agenten überprüfen. Das prüft den Plan gegen Projektbeschränkungen, bevor er ausgeführt wird.
Wenn wir das Testen lösen können, ist das Programmieren fast vollständig automatisiert. Das einzige verbleibende Problem war immer Vertrauen: Warum sollten wir dem Code vertrauen? Wenn du ihn manuell liest, ist es wie Motorradfahren. Wenn nicht, brauchst du eine Möglichkeit, das Risiko zu senken. Es gibt viele Ideen dazu, der OP und Anthropic haben ihre Ansätze gezeigt. Ich denke jedoch, der Ansatz ist projektspezifisch, keine allgemeine Methode.