Eine Code-Review-Plattform, die ihre eigenen Befunde belegen muss
Die meisten Review-Werkzeuge produzieren mehr zu lesen als zu beheben. Wir haben eines gebaut, in dem mehrere Analyse-Agenten dieselbe Änderung parallel bearbeiten, ein zweiter Durchgang gegen alles Gefundene argumentiert und was übrig bleibt mit Ersatzcode und dem Beleg dahinter ankommt. Hinter Terminal, Editor, API und einem unbeaufsichtigten Dienst steht eine einzige Engine, damit ein Review überall dasselbe bedeutet.
- BrancheEntwicklerwerkzeuge
- Art der ArbeitEigenes Produkt, intern gebaut
- StatusIm aktiven Einsatz, wird weiter ausgebaut
Eine Engine hinter jedem Weg zum Review
Die Plattform liest eine vorgeschlagene Änderung, ermittelt, was sie berührt, und legt sie mehreren Analyse-Agenten gleichzeitig vor. Die Befunde werden zusammengeführt, entdoppelt, nach Schweregrad sortiert und begrenzt, sodass am Ende eine Arbeitsliste steht und keine Wand. Das ist kein Linter, und es ist nicht die Meinung eines einzelnen Modells, aufgeschrieben als Urteil.
Dieselbe Engine läuft, ob die Anfrage aus einem Terminalbefehl kommt, aus dem Editor, aus der API oder aus einem Hintergrunddienst, der ein Repository nach eigenem Zeitplan beobachtet. Sie teilen sich eine Historie: Ein an der Tastatur gestartetes Review ist genau das, was das Dashboard später zeigt, und ein Pull Request bekommt seinen eigenen Kommentar aktualisiert, statt einen neuen daruntergestapelt.
Warum noch ein Review-Werkzeug
Automatisches Review hatte ein Glaubwürdigkeitsproblem, bevor es ein Abdeckungsproblem hatte. Gegen diese drei Fehlschläge haben wir entworfen.
Rauschen kostet mehr, als es findet
Ein Werkzeug, das Formatierungsrauschen, umsortierte Importe und selbstbewusste Vermutungen meldet, erzieht ein Team zum Überfliegen. Sobald Review-Ausgaben überflogen werden, wird der eine Befund, auf den es ankam, mit überflogen.
Ein Befund ohne Korrektur ist ein weiteres Ticket
Review-Kommentare, die ein Problem beschreiben und dann aufhören, geben die Arbeit an jemanden zurück, der ohnehin ausgelastet war. Wie der korrigierte Code aussieht, muss die lesende Person weiterhin selbst herausfinden, und entscheidet oft, dass es warten kann.
Jede Oberfläche verhielt sich anders
Review im Terminal, im Editor, am Pull Request und nach Zeitplan waren getrennte Werkzeuge mit getrenntem Verhalten und getrennter Historie. Dieselbe Änderung konnte das eine bestehen und am anderen scheitern.
Was wir gebaut haben
Eine Pipeline, vier Wege dorthin und mehrere Schichten Zweifel zwischen der Vermutung eines Modells und dem, was einem Menschen zu lesen gegeben wird.
Eine Review-Engine hinter jeder Oberfläche
Eine einzige Pipeline zerlegt die Änderung, filtert, reichert an, verteilt sie an Agenten und führt das Ergebnis zusammen. Formatierung und Speicherung gehören dem Aufrufer, und genau deshalb dürfen die Oberflächen sich unterscheiden, ohne dass das Review sich unterscheidet.
- Terminalbefehl, Editor-Integration, API mit Live-Updates und Hintergrunddienst führen dasselbe Review aus
- Eine gemeinsame Historie: Das an der Tastatur gestartete Review ist genau das, was das Dashboard später zeigt
- Modellanbieter liegen hinter einer einzigen Schnittstelle, einen hinzuzunehmen oder zu tauschen ist Konfiguration und kein Umbau
Befunde, die die Korrektur mitbringen
Fünf Schweregrade fallen auf drei Handlungen zusammen: jetzt beheben, bald beheben, später ansehen. So lässt sich ein Bericht von oben abarbeiten. Jeder Befund wird aus einer Karte des Codes angereichert und zeigt damit auf einen echten Pfad statt auf ein Muster.
- Jeder Befund trägt Ersatzcode, und das Schema weist einen zurück, der keinen hat
- Reviews werden aus einem Symbolindex angereichert: welche Funktionen sich geändert haben, wer sie aufruft, welche Tests sie abdecken und was was importiert
- Befunde werden über ihren Inhalt identifiziert, nicht über eine Zeilennummer, sodass eine Neuformatierung kein bereits erledigtes Thema wiederbelebt
Fünf Schichten zwischen Vermutung und Bericht
Jede Schicht ist billiger als die nächste, sodass das meiste Rauschen verschwindet, bevor etwas Teures passiert. Die letzte Schicht ist die strenge: Die Plattform versucht, den Befund am Quelltext zu belegen.
- Reine Whitespace-, Kommentar- und Import-Änderungen fallen weg, bevor auch nur ein Modell kontaktiert wird, und ein statischer Musterdurchlauf markiert riskanten Code vorab
- Befunde mit geringer Konfidenz verschwinden direkt nach dem Review, dann argumentiert ein zweiter Durchgang gegen jeden Übriggebliebenen und behält nur, was er nicht entkräften kann
- Wo es geht, schreibt die Plattform ein kleines Programm, das die Behauptung am echten Quelltext prüft und in einer isolierten Sandbox läuft; lässt sich die Prüfung nicht durchführen, bleibt der Befund erhalten, statt still zu verschwinden
Ein adversarialer Modus, der vorschlägt und nie anwendet
Eine Übung in drei Wellen gegen eine Codebasis: Eine Gruppe von Agenten sucht etwas Ausnutzbares, eine zweite schreibt den Patch, eine dritte prüft den Patch gegen die Lücke, die er zu schließen behauptet. Zurück kommt bestätigt, teilweise behoben, weiterhin offen oder Fehlalarm.
- Die Angreifenden arbeiten mit unterschiedlichen Aufträgen, Geschäftslogik-Prüfung, feindseliger Kunde, Chaos-Engineering, Observability und Compliance, damit der Durchlauf nicht fünf Kopien desselben Instinkts ist
- Patches entstehen als Diffs und werden validiert, nie ins Repository geschrieben; was landet, entscheidet ein Mensch
- Die Agenten arbeiten in einer Kommando-Positivliste mit gesperrten destruktiven Operationen, und ihre Ausgaben werden auf eingeschleuste Anweisungen geprüft
Was sich in der Praxis geändert hat
Wir veröffentlichen, was die Plattform tut, und keine Zahl dafür, wie gut sie es tut. Jede Genauigkeitsaussage bräuchte eine Messung, die wir nicht veröffentlicht haben.
Eine Arbeitsliste
Was ein Review erzeugt
Über Agenten hinweg zusammengeführte, entdoppelte, nach Schweregrad sortierte und begrenzte Befunde. Etwas, das man von oben abarbeitet, statt es von vorn bis hinten zu lesen.
Geprüft, nicht geraten
Was einen Menschen erreicht
Triviale Änderungen erreichen nie ein Modell, schwache Befunde fallen weg, die Übrigen werden bestritten, und wo es geht belegt die Plattform den Befund zuerst am Quelltext.
Ein Mensch entscheidet
Wie Änderungen landen
Korrekturen und Patches kommen als Vorschlag, mit Vorschau und einer Sicherung der Originaldatei. Ohne Zustimmung wird nichts ins Repository geschrieben.
Produziert Ihr Review-Prozess mehr zu lesen als zu beheben?
Erzählen Sie uns, wie Code bei Ihnen heute geprüft wird und wo es hakt. Wir sagen Ihnen, was sich zu automatisieren lohnt und was nicht.
Projekt besprechen