# Pro-Sitzplatz-Abrechnung macht aus einer 60-Cent-Code-Review 4 Dollar > Sie werden pro Entwickler abgerechnet und verbrauchen Reviews pro Pull Request. Hier ist diese Aufteilung, plus der Pull Request, bei dem unser KI-Reviewer einen von sechs Fehlern gefunden hat. - Source: https://jays.fyi/de/blog/pro-sitzplatz-abrechnung-code-review - Author: Jay Derinbogaz - Published: 2026-08-08 - Language: de - Tags: tooling, code-review, pricing - Reading time: 10 min - Machine translated: yes — original: https://jays.fyi/blog/how-i-removed-greptile ---
Quittung von Greptile über 861,00 $, bezahlt am 3. August 2026.
Ein Monat Greptile, August 2026. Die Preisseite sagt 30 $.
Dividiere deine KI-Code-Review-Rechnung. Nimm, was du letzten Monat bezahlt hast, und teile es durch die Anzahl der Pull Requests, die das Ding tatsächlich reviewed hat. Der Listenpreis ist eine andere Zahl, und es ist die, die du auswendig kennst. Ich habe die Division für unser Team durchgeführt und etwas bekommen, das so weit von der Preisseite entfernt war, dass ich annahm, ich hätte einen Fehler gemacht. Die Arithmetik war in Ordnung. Ich hatte das Produkt so gekauft, wie es verkauft wird, und es so benutzt, wie wir tatsächlich arbeiten, und das erweisen sich als zwei verschiedene Produkte. Hier ist die These, und alles danach ist 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. Und separat, schlimmer noch: Das Tool, für das wir bezahlten, las einen Diff mit sechs echten Defekten 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 Defekte gingen rein. Einer kam raus. Der Pull Request war ein Autosave-Refactor in unserer Plattform. Gewöhnlich, mittelgroß, die Art, die an einem Dienstag eröffnet wird und bei der niemand den Schlaf verliert. Greptile hat ihn reviewed, zwei Kommentare hinterlassen und ist weitergemacht. Danach ist einer unserer Engineers den Diff von Hand durchgegangen und hat ihn ordentlich beurteilt, jeden echten Defekt aufgeschrieben, ohne darauf zu achten, welches Tool was gemeldet hatte. Sechs Defekte. Vier davon P1, die Art, die Benutzerdaten korrumpiert, statt jemanden zu nerven. Autosave bewaffnete sich nach dem Normalisieren von Werten für immer neu. Ein fehlgeschlagener Save wiederholte sich in einer Endlosschleife. Autosave überschrieb, was der Benutzer in einem anderen Tab aktiv tippte. Ein Save-Promise wurde unbehandelt verworfen. Das Verlassen der Seite ließ alles Ausstehende fallen. Der Save-Button rendert nur, wenn der Schritt *nicht* gespeichert werden *konnte*. Einer von diesen sechs wurde gemeldet. Keiner von diesen sechs erreichte die Produktion, und ich möchte präzise sein, warum. Ein Engineer setzte sich hin und las den Diff Zeile für Zeile. Der Reviewer war schon da gewesen und wieder gegangen. Wir bezahlten für ein Sicherheitsnetz, das eines von sechs fing, und die fünf, die es fallen ließ, wurden von genau der Aktivität gefangen, die das Produkt zu reduzieren existiert. ## Selbstbewusst falsch zu liegen ist schlimmer als nichts zu sagen Es gab einen siebten Befund. Er war nicht echt. Uns wurde gesagt: „Fehlgeschlagener Autosave hat kein Retry.“ Der Defekt in genau derselben Funktion zeigte in die andere Richtung: Fehlgeschlagener Autosave wiederholte *für immer*. Das Tool hatte die Richtung umgedreht. Ich habe über diesen einen mehr nachgedacht als über die fünf Misses zusammen. Ein Miss ist Stille, und Stille ist überlebensfähig, weil du bereits annimmst, dass dein Reviewer nicht allwissend ist. Eine Inversion ist schlimmer als Stille. Sie schickt einen Engineer in die richtige Datei, um nach dem falschen Ding zu suchen, und wenn sie das Ding nicht finden, das nie da war, schließen sie die Datei und markieren sie als reviewed. Ein falscher Bericht verbraucht deine Aufmerksamkeit, und er verbraucht sie an genau dem Ort, an dem der echte Bug sich versteckte. Ein echter Befund. Ein umgedrehter Befund. Sechs Defekte 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 keine zwei Modelle haben dieselben. Jeder Anbieter liefert diese Eigenschaft, weil es das ist, was diese Systeme sind. Wenn du also deinen Review-Prozess auf genau einem Modell aufbaust, hast du ihn auf genau einem Muster von Blindheit aufgebaut, und du wirst nie die Form dieses Musters lernen, weil das einzige Instrument, das es dir zeigen könnte, das Instrument ist, das blind ist. Lass mich das ausbuchstabieren. Kaufe den besten Reviewer auf dem Markt, und du hast ein Muster von Blindheit zum vollen Preis gekauft. Code-Review funktionierte überhaupt erst, weil eine zweite Person auf den Diff schaute. Das war der ganze Mechanismus, und wir haben ihn in der Woche fallen gelassen, in der wir ihn automatisiert haben. Also haben wir Juror gebaut. Mehrere Frontier-Modelle reviewen denselben Diff parallel, jedes durch seine eigene native Agent-Harness, jedes frei, dein Repository so zu durchsuchen, wie es sein Anbieter beabsichtigt hat. Ihre Befunde kollabieren, sodass drei fast identische Berichte über einen Defekt als einzelner Kommentar auf dem Pull Request landen. Wir haben es gegen denselben Commit laufen lassen. | Reviewer | Gefunden | Precision | 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 des Retry. Wenn man beide Reviewer zusammennimmt, bekommt man fünf von sechs, was besser ist, als jeder allein geschafft hat, und ich werde das nicht unter der Tabelle oben begraben. Ich hätte diesen Abschnitt streichen können. Ich behalte ihn, weil er *das* Argument ist. Verschiedene Modelle fangen verschiedene Dinge, und ein Modell eines Konkurrenten, das etwas findet, das unseres verpasst hat, ist die sauberste verfügbare Demonstration, dass ein einzelner Reviewer zu betreiben der Fehler ist. Der Tag, an dem das aufhört zu passieren, ist der Tag, an dem ich anfange zu sorgen, dass unsere Jury zu einer Meinung kollabiert ist, die vier Hüte trägt. ## Deine Rechnung folgt der Kopfzahl. Deine Reviews folgen den Merges. Jetzt die Rechnung, wo das aufhört, um einen einzelnen Pull Request zu gehen. [Greptiles Pro-Plan](https://www.greptile.com/pricing) kostet **30 $ pro Sitzplatz pro Monat**, Stand August 2026. Das beinhaltet 50 Credits pro Sitzplatz, wobei ein Credit einen Standard-Review kauft und drei einen tieferen, und weitere Credits kosten 1 $ pro Stück. Pro Review ist das günstig. Ungefähr sechzig Cent, wenn du jeden Kredit nutzt, den du bekommst. Ich will hier völlig fair sein: Pro Einheit gerechnet ist das niedriger, als was unser eigenes Tool bei dem Pull Request oben gekostet hat. Ein kleines Team, das sein Kontingent vollständig aufbraucht, sollte die Sitze kaufen, und ich werde nicht so tun, als wäre es anders. Niemand braucht sein Kontingent vollständig auf. Du wirst pro *Entwickler* abgerechnet. Du verbrauchst Reviews pro *Pull Request*. Diese beiden Zahlen hören auf, einander zu folgen, sobald die Mitarbeiterzahl schneller wächst als die Merge-Rate – das heißt: sofort, in jeder Engineering-Organisation, die je existiert hat. Zwanzig Entwickler auf Pro sind 600 $ im Monat und tausend Credits. Wenn dieses Team 150 Pull Requests merged, ein völlig normaler Monat, hast du **4 $ pro Review** bezahlt und 850 Credits verfallen lassen. Deine Auslastung hat sich bewegt, der Listenpreis nicht, also wurden aus sechzig Cent vier Dollar, und niemand hat dir eine E-Mail darüber geschickt. Nenn es Sitzsteuer: Geld, das für eine Pro-Entwickler-Lizenz ausgegeben wird, für ein Produkt, das pro Artefakt verbraucht wird. Sie ist auf der Preisseite unsichtbar, sie skaliert mit Einstellungen statt mit Nutzung, und sie ist der größte Posten in dem, was du tatsächlich zahlst. ## Ich kann dir sagen, was das kostet, weil wir die Rechnung ausdrucken Juror hat keine Sitze. Es läuft in deinem eigenen GitHub-Actions-Runner, ruft die Modell-APIs mit deinen eigenen Schlüsseln auf, und die Rechnung ist die Inferenz und sonst nichts. Dieses Review des Autosave-PRs, vier echte Defekte und keine False Positives, kostete **1,08 $** und dauerte acht Minuten und zweiundzwanzig Sekunden. Ich kann dir das auf den Cent genau sagen, weil jedes Juror-Review mit einer Tabelle endet: jedes Modell, seine Input-Tokens, seine gecachten Tokens, seine Output-Tokens, seine Dollar. Jede Zahl ist mit `reported` gekennzeichnet, wenn der Anbieter sie berechnet hat, oder mit `estimated`, wenn wir sie aus veröffentlichten Listenpreisen abgeleitet haben. Wenn ein Harness uns keins von beidem gibt, druckt es `unknown` und die Summe wird als untere Grenze markiert. Wir raten nicht und wir runden nicht zu unseren Gunsten. Jetzt schau dir nochmal die zwei Zellen in dieser Tabelle an, die „nicht offengelegt“ sagen. Ich habe nach diesen Zahlen gesucht, und sie sind nirgendwo veröffentlicht. Das Tool sagt dir nicht, was ein Review kostet, weil es das nicht muss. Du hast einen Sitz gekauft. Die Unit Economics sind die Sache des Anbieters, und der Anbieter hätte es lieber, wenn du die Multiplikation weiterhin auf seine Art machst. Ein Reviewer, der seine eigene Rechnung ausdruckt, ist das, was ich wollte und zu keinem Preis kaufen konnte. ## Was ich nicht tun werde, ist, das ein Benchmark zu nennen Das ist ein Pull Request. Unser eigenes [Benchmarking-Protokoll](https://github.com/juror-ai/juror/blob/main/docs/benchmarking.md) sagt, dass eine Ersatzentscheidung 20 bis 30 begutachtete PRs braucht, die Frontend, Backend, Migrationen, Nebenläufigkeit, sicherheitskritischen Code und sowohl kleine als auch große Diffs abdecken. Wir haben einen. Er liegt im Repository mit einer Warnung, die besagt, dass er nicht als statistisch ausreichender Beleg dafür präsentiert werden darf, dass einer der Reviewer den anderen ersetzen kann, und ich werde unsere eigene Warnung nicht in einem Blogbeitrag darüber verletzen, wie sorgfältig wir Zahlen berichten. Vier von sechs gegen eine von sechs ist ein begutachteter Fall. Er hat mich bereit gemacht, beide Reviewer nebeneinander laufen zu lassen, und das ist das gesamte Gewicht, das er tragen kann. Ein anderer Pull Request, einer, der stark auf repository-weitem Kontext basiert, wo ein indexierter Reviewer gut abschneiden sollte, könnte das Ergebnis plausibel umkehren. Wenn das passiert, kommt dieser Fall auch ins Korpus. Die Arithmetik ist der Teil, der eine Stichprobe von eins überlebt. Dreißig Dollar pro Sitz 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 du messen willst. Wir haben uns auf die Preisstruktur gestützt, die ich mit Division verteidigen kann, und auf einen vielversprechenden Fall. Der Performance-Anspruch ist der, den wir uns nicht verdient haben, also erhebe ich ihn nicht. ## Komm und miss uns Nimm mein Wort für nichts davon. Ich habe ein kommerzielles Interesse an deiner Schlussfolgerung, und du solltest alles oben Genannte entsprechend gewichten. Stell beide Reviewer im Schattenmodus auf dein eigenes Repository. Lass sie ein paar Wochen laufen, ohne dass einer einen Merge blockiert. Nimm dann jeden Befund, entferne die Beschriftungen, damit niemand weiß, welches Tool was gesagt hat, und lass einen Senior Engineer sie kalt gegen den Code begutachten. Zähl, was jeder gefunden hat. Zähl, was jeder erfunden hat. Wir haben das Tooling genau dafür ausgeliefert, weil wir es selbst brauchten: ```bash npx juror-ai benchmark --file your-corpus.json ``` Es berichtet Recall, Präzision, Duplikatrate, Kosten und Latenz für jeden Reviewer, den du ihm fütterst, und es listet jeden Fehlgriff namentlich auf. Unsere 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 gestaltet ist, dass du dich nicht darum kümmerst. Jemand in deiner Organisation führt diese Berechnung irgendwann durch. Wenn sie es tun, 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 je wissen, dass sie nötig waren, denn Bugs, die vor dem Merge gefangen werden, hinterlassen keine Spur und erzeugen keinen Incident-Report. Das ist der Teil, der dich beunruhigen sollte. Der Reviewer, der fünf davon verpasst hat, kostet dasselbe, ob er sechs oder null findet, und er wird dir nie sagen, für welchen dieser zwei Monate du gerade bezahlt hast. --- *Juror ist Open Source und MIT-lizenziert: [github.com/juror-ai/juror](https://github.com/juror-ai/juror). Greptile-Preise zitiert von [greptile.com/pricing](https://www.greptile.com/pricing) Stand August 2026.*