Pro-Sitzplatz-Abrechnung macht aus einer 60-Cent-Code-Review 4 Dollar

Mach die Division bei deiner KI-Code-Review-Rechnung. Nicht den Listenpreis, die tatsächliche Division: was du letzten Monat bezahlt hast, geteilt durch die Anzahl der Pull Requests, die es reviewed hat. Ich habe es für unser Team gemacht und die Zahl war so viel schlechter als die Zahl auf der Preisseite, dass ich dachte, ich hätte einen Fehler gemacht.

Ich hatte keinen Fehler gemacht. Ich hatte das Produkt einfach so gekauft, wie es mir verkauft wurde, anstatt so, wie wir es nutzen.

Hier ist die These, und alles danach ist der Beleg dafür. KI-Code-Review wird pro Entwickler verkauft und pro Pull Request konsumiert. Diese beiden Zahlen haben nichts miteinander zu tun, und die Lücke zwischen ihnen ist das, wohin dein Geld fließt. Unabhängig davon, und schlimmer noch, das Tool, für das wir bezahlten, las einen Diff mit sechs echten Fehlern und fand einen.

Wir haben es durch etwas ersetzt, das wir selbst gebaut haben. Ich werde dir die Belege für beide Behauptungen zeigen, einschließlich der Teile, die uns schlechter dastehen lassen.

Sechs Fehler gingen rein. Einer kam raus.

Der Pull Request war ein Autosave-Refaktor in unserer Plattform. Gewöhnlich, mittelgroß, die Art, die an einem Dienstag aufgemacht wird und bei der niemand schlaflose Nächte hat. Greptile hat ihn reviewed, zwei Kommentare hinterlassen und ist weitermarschiert.

Hinterher ist einer unserer Ingenieure den Diff von Hand durchgegangen und hat ihn ordentlich beurteilt, jeden echten Fehler notiert, ohne darauf zu achten, welches Tool was gemeldet hatte. Sechs Fehler. Vier davon P1, die Art, die Benutzerdaten korrumpiert, anstatt jemanden zu nerven.

Autosave hat sich nach dem Normalisieren von Werten für immer wieder scharf geschaltet. Ein fehlgeschlagener Speichervorgang wiederholte sich in einer Endlosschleife. Autosave überschrieb, was der Benutzer in einem anderen Tab gerade tippte. Ein Save-Promise wurde unbehandelt verworfen. Das Verlassen der Seite ließ alles Ausstehende fallen. Der Speichern-Button wurde nur gerendert, wenn der Schritt nicht gespeichert werden konnte.

Einer dieser sechs wurde gemeldet.

Keiner dieser sechs erreichte die Produktion, und ich möchte genau erklären, warum, denn der Grund ist der springende Punkt. Sie wurden entdeckt, weil ein Mensch den Diff gelesen hat. Nicht weil der Reviewer sie aufgehalten hat. Wir bezahlten für ein Sicherheitsnetz, das eines von sechs Dingen fing, und das, was die anderen fünf fing, war ein Ingenieur, der den Code Zeile für Zeile las – genau die Tätigkeit, die das Produkt reduzieren soll.

Selbstbewusst daneben zu liegen ist schlimmer, als nichts zu sagen

Es gab einen siebten Befund. Er war nicht echt.

Uns wurde gesagt: „Fehlgeschlagenes Autosave hat keinen Wiederholungsversuch.“ Der tatsächliche Fehler, in derselben Funktion, war das Gegenteil: fehlgeschlagenes Autosave wiederholte sich für immer. Kein übersehener Bug. Ein umgekehrter.

Ich habe über diesen einen mehr nachgedacht als über die fünf Fehlschläge zusammen. Ein Fehlschlag ist Stille, und Stille ist überlebensfähig, weil du bereits annimmst, dass dein Reviewer nicht allwissend ist. Eine Umkehrung ist schlimmer als Stille. Sie schickt einen Ingenieur in die richtige Datei, um nach der falschen Sache zu suchen, und wenn sie die Sache, die nie da war, nicht finden, schließen sie die Datei und markieren sie als reviewed. Ein falscher Bericht hilft dir nicht nur nicht. Er verbraucht deine Aufmerksamkeit, und zwar genau an der Stelle, an der der echte Bug sich versteckte.

Ein echter Befund. Ein verkehrter Befund. Sechs Fehler im Diff.

Ein Modell bedeutet einen blinden Fleck, und du wirst nie seine Form lernen

Meine erste Reaktion war, dass wir das falsche Tool gekauft hatten. Diese Reaktion war falsch, und darüber hinwegzukommen dauerte länger, als ich zugeben möchte.

Jedes Frontier-Modell hat blinde Flecken, und es sind nicht dieselben blinden Flecken. Das ist kein Mangel in einem bestimmten Anbieterprodukt, es ist das, was diese Systeme sind. Was bedeutet, dass du, wenn du deinen Review-Prozess auf genau einem Modell aufbaust, ihn auf genau einem Muster von Blindheit aufbaust, und du wirst nie die Form dieses Musters lernen, denn das einzige Instrument, das es dir zeigen könnte, ist das Instrument, das blind ist.

Lass mich das klarstellen. Das Problem ist nicht, dass dein Reviewer schlecht ist. Das Problem ist, dass dein Reviewer einzeln ist. Eine zweite Meinung war nie ein Luxus im Code-Review, sie war der gesamte Mechanismus, durch den Code-Review funktionierte, und wir haben sie stillschweigend fallen gelassen, sobald wir es automatisiert haben.

Also haben wir Juror gebaut. Mehrere Frontier-Modelle reviewen denselben Diff parallel, jedes durch sein eigenes natives Agenten-Harness, jedes frei, dein Repository so zu durchsuchen, wie sein Anbieter es beabsichtigt hat. Ihre Befunde werden zusammengefasst, sodass drei nahezu doppelte Berichte eines Fehlers zu einem Befund werden statt zu drei, und was auf dem Pull Request landet, ist ein einzelner Kommentar.

Wir haben es gegen denselben Commit laufen lassen.

Reviewer	Gefunden	Präzision	Kosten	Zeit
Greptile	1 von 6	50%	nicht offengelegt	nicht offengelegt
Juror	4 von 6	100%	$1.08	8m22s

Hier ist der Teil, in dem wir verlieren

Juror hat zwei verpasst.

Greptile hat das verworfene Save-Promise gefangen und wir nicht. Kein Tool fand die Endlosschleife. Nimmt man beide Reviewer zusammen, kommt man auf fünf von sechs, was besser ist, als jedes allein geschafft hat, und das werde ich nicht unter der obigen Tabelle vergraben.

Ich hätte diesen Abschnitt streichen können. Ich behalte ihn, weil er die Argumentation ist. Unterschiedliche Modelle fangen unterschiedliche Dinge. Das ist kein unbequemer Vorbehalt, der an unser Pitch geheftet ist, es ist das Pitch, und dass ein Konkurrenzmodell etwas findet, das unseres übersehen hat, ist die sauberste verfügbare Demonstration dafür, dass ein einzelner Reviewer zu betreiben der Fehler ist. Der Tag, an dem das aufhört, ist der Tag, an dem ich mir Sorgen mache, dass unsere Jury zu einer Meinung in vier Hüten zusammengefallen ist.

Du bezahlst nicht für Reviews. Du bezahlst für Stühle.

Jetzt die Rechnung, wo dies aufhört, um einen einzelnen Pull Request zu gehen.

Greptiles Pro-Plan kostet 30 $ pro Sitzplatz pro Monat, Stand August 2026. Das beinhaltet 50 Credits pro Sitzplatz, wobei ein Credit ein Standard-Review kauft und drei ein tiefergehendes, und weitere Credits kosten jeweils 1 $.

Pro Review ist das günstig. Etwa sechzig Cent, wenn man jedes Guthaben nutzt, das man bekommt. Ich möchte hier völlig fair sein: Auf Einzelbasis ist das niedriger als das, was unser eigenes Tool für den Pull-Request oben gekostet hat. Ein kleines Team, das sein Kontingent voll ausschöpft, sollte die Plätze kaufen, und ich werde nicht so tun, als ob das anders wäre.

Niemand schöpft sein Kontingent voll aus.

Sie werden pro Entwickler abgerechnet. Sie verbrauchen Reviews pro Pull-Request. Diese beiden Zahlen hören auf, einander zu entsprechen, sobald die Mitarbeiterzahl schneller wächst als die Merge-Rate, also sofort, in jeder jemals existierenden Engineering-Organisation. Zwanzig Entwickler mit Pro kosten 600 $ pro Monat und tausend Credits. Wenn dieses Team 150 Pull-Requests merged, ein völlig normaler Monat, haben Sie 4 $ pro Review bezahlt und 850 Credits verfallen lassen.

Der Listenpreis hat sich nie geändert. Ihre Auslastung schon. Sechzig Cent wurden zu vier Dollar, und niemand hat Ihnen eine E-Mail darüber geschickt.

Nennen Sie es die Sitzsteuer: Geld, das für eine Pro-Entwickler-Lizenz für ein Produkt ausgegeben wird, das pro Artefakt verbraucht wird. Sie ist auf der Preisseite unsichtbar, skaliert mit Neueinstellungen statt mit Nutzung und ist der größte Posten in dem, was Sie tatsächlich bezahlen.

Ich kann Ihnen sagen, was das gekostet hat, weil wir die Quittung ausdrucken

Juror hat keine Plätze. Es läuft in Ihrem eigenen GitHub Actions Runner, ruft die Modell-APIs mit Ihren eigenen Schlüsseln auf, und die Rechnung ist die Inferenz und sonst nichts. Diese Review des Autosave-PRs, vier echte Fehler und keine Fehlalarme, hat 1,08 $ gekostet und acht Minuten und zweiundzwanzig Sekunden gedauert.

Das kann ich auf den Cent genau sagen, weil jede Juror-Review mit einer Tabelle endet: jedes Modell, seine Input-Tokens, seine gecachten Tokens, seine Output-Tokens, seine Dollar. Jede Zahl ist als reported gekennzeichnet, wenn der Anbieter sie berechnet hat, oder als estimated, wenn wir sie aus veröffentlichten Listenpreisen abgeleitet haben. Wenn ein Harness uns keins von beidem liefert, gibt es unknown aus, und die Summe wird als untere Schranke markiert. Wir raten nicht und wir runden nicht zu unseren Gunsten.

Schauen Sie sich jetzt noch einmal die beiden Zellen in dieser Tabelle an, die »not disclosed« sagen. Das ist keine Lücke in meiner Recherche. Das Tool sagt Ihnen nicht, was eine Review gekostet hat, weil es das nicht muss. Sie haben einen Platz gekauft. Die Stückkosten sind das Geschäft des Anbieters, und der Anbieter hätte es lieber, wenn Sie weiterhin auf seine Weise multiplizieren.

Das war das, was ich eigentlich wollte und zu keinem Preis kaufen konnte. Kein günstigerer Reviewer. Ein Reviewer, der mir sagt, was er ausgegeben hat.

Was ich nicht tun werde, ist, dies einen Benchmark zu nennen

Das ist ein einziger Pull-Request. Unser eigenes Benchmarking-Protokoll besagt, dass eine Ersatzentscheidung 20 bis 30 beurteilte PRs benötigt, die Frontend, Backend, Migrationen, Nebenläufigkeit, sicherheitskritischen Code sowie kleine und große Diffs abdecken. Wir haben einen. Er liegt im Repository mit einem Warnhinweis, dass er nicht als statistisch ausreichender Beweis dafür präsentiert werden darf, dass einer der Reviewer den anderen ersetzen kann, und ich werde nicht gegen unsere eigene Warnung verstoßen, in einem Blogbeitrag darüber, wie sorgfältig wir Zahlen melden.

Vier von sechs gegen einen von sechs ist kein Benchmark-Ergebnis. Es ist ein einziger beurteilter Fall, der mich bereit gemacht hat, beide nebeneinander laufen zu lassen. Ein anderer Pull-Request, einer, der stark auf repository-weiten Kontext angewiesen ist, wo ein indexierter Reviewer gut abschneiden sollte, könnte das plausibel umkehren. Wenn das passiert, kommt dieser Fall auch in das Korpus.

Was keine Stichprobe von eins ist, ist die Arithmetik. Dreißig Dollar pro Platz mal zwanzig Entwickler sind 600 $, ob es mir gefällt oder nicht, und 150 Reviews gegen tausend Credits sind 15 % Auslastung in jedem Monat, den Sie messen wollen. Wir haben auf die Preisstruktur umgestellt, die ich mit Division verteidigen kann, und auf einen vielversprechenden Fall. Nicht auf eine Leistungsbehauptung, die wir noch nicht verdient haben.

Messen Sie uns

Glauben Sie mir bei all dem nicht einfach. Ich habe ein kommerzielles Interesse an Ihrer Schlussfolgerung, und Sie sollten alles oben Genannte entsprechend gewichten.

Setzen Sie beide Reviewer im Schattenmodus auf Ihrem eigenen Repository ein. Lassen Sie sie ein paar Wochen laufen, ohne dass einer einen Merge blockiert. Nehmen Sie dann jeden Befund, entfernen Sie die Labels, sodass niemand weiß, welches Tool was gesagt hat, und lassen Sie einen Senior Engineer sie kalt gegen den Code beurteilen. Zählen Sie, was jeder gefunden hat. Zählen Sie, was jeder erfunden hat.

Wir haben die Werkzeuge genau dafür ausgeliefert, weil wir sie selbst brauchten:

npx juror-ai benchmark --file your-corpus.json

Es berichtet Recall, Precision, Duplikatsrate, Kosten und Latenz für jeden Reviewer, den Sie ihm füttern, und listet jeden Fehlschlag namentlich auf. Unseren eingeschlossen.

Ich glaube nicht, dass das Sitzmodell den Kontakt mit jemandem überlebt, der die Division durchführt. Es überlebt jetzt, weil die Division leicht lästig ist und die Preisseite so angeordnet ist, dass Sie sich nicht die Mühe machen. Irgendwann führt jemand in Ihrer Organisation diese Berechnung durch. Wenn das passiert, wird die Antwort nicht sechzig Cent sein.

Dieser Autosave-Pull-Request wurde übrigens heute Morgen gemerged. Es brauchte zwei weitere Commits, um dorthin zu gelangen, einen, um Navigations-Speicherungen Single-Flight zu machen, und einen, um Autosave konvergieren zu lassen und den Builder in Ruhe zu lassen. Gute Commits. Nichts brennt.

Niemand wird jemals wissen, dass sie notwendig waren, denn Fehler, die vor dem Merge gefangen werden, hinterlassen keine Spur und erzeugen keinen Vorfallbericht. Das ist der Teil, der Sie beunruhigen sollte. Der Reviewer, der fünf davon übersehen hat, kostet das Gleiche, ob er sechs oder null findet, und er wird Ihnen nie sagen, für welchen dieser beiden Monate Sie gerade bezahlt haben.

---

Juror ist Open Source und MIT-lizenziert: github.com/juror-ai/juror. Greptile-Preise zitiert von greptile.com/pricing Stand August 2026.