# Per-seat facturering verandert een code review van 60 cent in 4 dollar > Je wordt per ontwikkelaar gefactureerd en verbruikt reviews per pull request. Hier is die verdeling, plus de pull request waarin onze AI-reviewer één defect op zes vond. - Source: https://jays.fyi/nl/blog/per-seat-facturering-code-review - Author: Jay Derinbogaz - Published: 2026-08-08 - Language: nl - Tags: tooling, code-review, pricing - Reading time: 10 min - Machine translated: yes — original: https://jays.fyi/blog/how-i-removed-greptile ---
Ontvangstbewijs van Greptile voor $861,00, betaald op 3 augustus 2026.
Eén maand Greptile, augustus 2026. De prijspagina zegt $30.
Doe de deling op je AI-code-review-rekening. Neem wat je vorige maand betaalde en deel het door het aantal pull requests dat het ding daadwerkelijk heeft gereviewd. De adviesprijs is een ander getal, en dat is het getal dat je uit je hoofd kent. Ik deed de deling voor ons team en kreeg iets dat zo ver van de prijspagina af stond dat ik dacht dat ik een fout had gemaakt. De rekenkunde klopte. Ik had het product gekocht zoals het verkocht wordt en het gebruikt zoals we daadwerkelijk werken, en dat blijken twee verschillende producten te zijn. Hier is de stelling, en alles hierna is bewijs daarvoor. AI-code-review wordt verkocht per ontwikkelaar en verbruikt per pull request. Die twee getallen hebben niets met elkaar te maken, en de kloof ertussen is waar je geld naartoe gaat. En afzonderlijk, erger nog: de tool waarvoor we betaalden las een diff met zes echte defecten en vond er één. We hebben het vervangen door iets dat we zelf hebben gebouwd. Ik ga je het bewijs voor beide beweringen laten zien, inclusief de delen die ons slechter doen lijken. ## Zes defecten gingen erin. Eén kwam eruit. De pull request was een autosave-refactor in ons platform. Gewoon, middelgroot, het soort dat op een dinsdag wordt geopend en waar niemand wakker van ligt. Greptile reviewde het, liet twee opmerkingen achter en ging verder. Daarna ging een van onze engineers handmatig door de diff en beoordeelde het naar behoren, waarbij hij elk echt defect opschreef zonder te kijken welke tool wat had gerapporteerd. Zes defecten. Vier daarvan P1, het soort dat gebruikersgegevens beschadigt in plaats van iemand te irriteren. Autosave activeerde zichzelf na het normaliseren van waarden voor altijd opnieuw. Een mislukte save probeerde het opnieuw in een oneindige lus. Autosave overschreef wat de gebruiker actief aan het typen was in een ander tabblad. Een save-promise werd weggegooid zonder afhandeling. De pagina verlaten gooide alles wat nog openstond weg. De save-knop werd alleen weergegeven wanneer de stap *niet* kon worden opgeslagen. Eén van die zes werd gerapporteerd. Geen van die zes bereikte productie, en ik wil precies zijn over waarom. Een engineer ging zitten en las de diff regel voor regel. De reviewer was al geweest en weer weg. We betaalden voor een vangnet dat één van de zes ving, en de vijf die het liet vallen werden gevangen door precies de activiteit die het product bedoeld is te verminderen. ## Zelfverzekerd achterstevoren zijn is erger dan niets zeggen Er was een zevende bevinding. Die was niet echt. Ons werd verteld: "mislukte autosave heeft geen retry." Het defect dat in diezelfde functie zat wees de andere kant op: mislukte autosave probeerde het *voor altijd* opnieuw. De tool had de richting achterstevoren. Ik heb over die ene meer nagedacht dan over de vijf missers samen. Een misser is stilte, en stilte is overleefbaar, omdat je al aanneemt dat je reviewer niet alwetend is. Een omkering is erger dan stilte. Het stuurt een engineer naar het juiste bestand op zoek naar het verkeerde, en wanneer ze het ding dat er nooit was niet vinden, sluiten ze het bestand en markeren het als gereviewd. Een vals rapport verbruikt je aandacht, en het verbruikt het op precies de plek waar de echte bug zich verborg. Eén echte bevinding. Eén achterstevoren bevinding. Zes defecten in de diff. ## Eén model betekent één blinde vlek, en je zult nooit de vorm ervan leren kennen Mijn eerste reactie was dat we de verkeerde tool hadden gekocht. Die reactie was fout, en er overheen komen duurde langer dan ik zou willen toegeven. Elk frontier-model heeft blinde vlekken, en geen twee modellen hebben dezelfde. Elke leverancier levert die eigenschap, omdat het is wat deze systemen zijn. Dus als je je reviewproces op precies één model bouwt, heb je het gebouwd op precies één patroon van blindheid, en je zult nooit de vorm van dat patroon leren kennen, omdat het enige instrument dat het je zou kunnen tonen het instrument is dat blind is. Laat me dit verduidelijken. Koop de beste reviewer op de markt en je hebt één patroon van blindheid gekocht voor de volle prijs. Code-review werkte in de eerste plaats omdat een tweede persoon naar de diff keek. Dat was het hele mechanisme, en we lieten het vallen in de week dat we het automatiseerden. Dus bouwden we Juror. Verschillende frontier-modellen reviewen dezelfde diff parallel, elk via zijn eigen native agent-harness, elk vrij om je repository te doorzoeken zoals de leverancier het bedoeld heeft. Hun bevindingen worden samengevoegd, zodat drie bijna-identieke rapporten van één defect op de pull request terechtkomen als één enkele opmerking. We draaiden het tegen dezelfde commit. | Reviewer | Gevonden | Precisie | Kosten | Tijd | | --- | --- | --- | --- | --- | | Greptile | 1 van 6 | 50% | niet bekendgemaakt | niet bekendgemaakt | | Juror | **4 van 6** | **100%** | **$1,08** | 8m22s | ## Hier is het deel waar we verliezen Juror miste er twee. Greptile ving de weggegooide save-promise en wij niet. Geen van beide tools vond de oneindige retry-lus. Zet beide reviewers samen en je krijgt vijf van de zes, wat beter is dan elk afzonderlijk presteerde, en ik ga dat niet begraven onder de tabel hierboven. Ik had deze sectie kunnen schrappen. Ik houd hem omdat het *wel* de pitch is. Verschillende modellen vangen verschillende dingen, en een model van een concurrent dat iets vindt dat het onze miste, is de meest heldere demonstratie die beschikbaar is dat het draaien van één enkele reviewer de fout is. De dag dat dat ophoudt te gebeuren, is de dag dat ik me zorgen begin te maken dat onze jury is ingestort tot één mening met vier hoeden op. ## Je rekening volgt het aantal medewerkers. Je reviews volgen merges. Nu de rekening, want hier houdt het op over één pull request te gaan. [Greptile's Pro-plan](https://www.greptile.com/pricing) is **$30 per gebruiker per maand**, per augustus 2026. Dat omvat 50 credits per gebruiker, waarbij één credit een standaard review koopt en drie een diepere, en extra credits kosten $1 per stuk. Per review is dat goedkoop. Ongeveer zestig cent, als je elk credit dat je krijgt ook gebruikt. Ik wil hier volkomen eerlijk zijn: per eenheid is dat lager dan wat ons eigen tool kostte op de pull request hierboven. Een klein team dat zijn volledige tegoed opmaakt, moet de seats kopen, en ik ga niet doen alsof dat niet zo is. Niemand maakt zijn tegoed volledig op. Je wordt gefactureerd per *developer*. Je verbruikt reviews per *pull request*. Die twee getallen houden elkaar niet meer bij zodra het aantal medewerkers sneller groeit dan het aantal merges, dat wil zeggen: onmiddellijk, in elke engineeringorganisatie die ooit heeft bestaan. Twintig engineers op Pro is $600 per maand en duizend credits. Als dat team 150 pull requests merged, een volkomen normale maand, heb je **$4 per review** betaald en 850 credits laten verlopen. Je bezettingsgraad veranderde en de catalogusprijs niet, dus zestig cent werd vier dollar en niemand stuurde je er een e-mail over. Noem het de seat tax: geld dat wordt uitgegeven aan een per-developerlicentie voor een product dat per artefact wordt verbruikt. Het is onzichtbaar op de prijspagina, het schaalt met aanwervingen in plaats van gebruik, en het is de grootste post in wat je daadwerkelijk betaalt. ## Ik kan je vertellen wat dit kostte omdat wij de bon afdrukken Juror heeft geen seats. Het draait in je eigen GitHub Actions-runner, roept de model-API's aan met je eigen keys, en de rekening is de inference en niets anders. Die review van de autosave-PR, vier echte defecten en geen false positives, kostte **$1,08** en duurde acht minuten en tweeëntwintig seconden. Ik kan je dat tot op de cent vertellen omdat elke Juror-review eindigt met een tabel: elk model, zijn input tokens, zijn gecachte tokens, zijn output tokens, zijn dollars. Elk getal is gelabeld als `reported` wanneer de provider het heeft berekend, of `estimated` wanneer we het hebben afgeleid van gepubliceerde catalogusprijzen. Wanneer een harness ons geen van beide geeft, print het `unknown` en wordt het totaal gemarkeerd als een ondergrens. We raden niet en we ronden niet in ons eigen voordeel af. Kijk nu nog eens naar de twee cellen in die tabel die 'niet bekendgemaakt' zeggen. Ik ben op zoek gegaan naar die cijfers en ze zijn nergens gepubliceerd. Het tool vertelt je niet wat een review kost omdat het dat niet hoeft te doen. Je hebt een seat gekocht. De unit economics zijn de zaak van de leverancier, en de leverancier ziet liever dat je de vermenigvuldiging op hun manier blijft doen. Een reviewer die zijn eigen rekening afdrukt is het ding dat ik wilde en voor geen enkele prijs kon kopen. ## Wat ik niet ga doen is dit een benchmark noemen Dit is één pull request. Ons eigen [benchmarkprotocol](https://github.com/juror-ai/juror/blob/main/docs/benchmarking.md) zegt dat een vervangingsbeslissing 20 tot 30 beoordeelde PR's nodig heeft, verspreid over frontend, backend, migraties, concurrency, beveiligingsgevoelige code, en zowel kleine als grote diffs. We hebben er één. Die staat in de repository met een waarschuwing erbij dat het niet mag worden gepresenteerd als statistisch voldoende bewijs dat de ene reviewer de andere kan vervangen, en ik ga onze eigen waarschuwing niet schenden in een blogpost over hoe zorgvuldig we cijfers rapporteren. Vier van zes tegen één van zes is één beoordeeld geval. Het maakte me bereid om beide reviewers naast elkaar te laten draaien, en dat is het volledige gewicht dat het kan dragen. Een andere pull request, één die sterk leunt op repository-brede context waar een geïndexeerde reviewer het goed zou moeten doen, zou het resultaat plausibel kunnen omkeren. Als dat gebeurt, gaat die case ook de corpus in. De rekenkunde is het deel dat een steekproef van één overleeft. Dertig dollar per seat maal twintig engineers is $600 of ik dat nu leuk vind of niet, en 150 reviews tegen duizend credits is 15% bezettingsgraad in elke maand die je wilt meten. We hebben de overstap gemaakt op basis van de prijsstructuur, die ik met een deling kan verdedigen, en op basis van één veelbelovende case. De prestatieclaim is de enige die we niet hebben verdiend, dus die maak ik niet. ## Kom ons maar meten Neem mijn woord niet aan voor dit alles. Ik heb een commercieel belang bij jouw conclusie en je moet alles hierboven dienovereenkomstig wegen. Zet beide reviewers in shadow mode op je eigen repository. Laat ze een paar weken draaien zonder dat een van beide een merge blokkeert. Neem dan elke bevinding, haal de labels eraf zodat niemand weet welk tool wat zei, en laat een senior engineer ze koud tegen de code beoordelen. Tel wat elk heeft gevonden. Tel wat elk heeft verzonnen. We hebben de tooling precies hiervoor uitgebracht, omdat we het zelf nodig hadden: ```bash npx juror-ai benchmark --file your-corpus.json ``` Het rapporteert recall, precision, duplicate rate, kosten en latentie voor elke reviewer die je erin voert, en het vermeldt elke miss bij naam. De onze ook. Ik denk niet dat het seat-model het overleeft als iemand de deling maakt. Het overleeft nu omdat de deling lichtelijk vervelend is en de prijspagina zo is ingericht dat je er geen moeite voor doet. Iemand in je organisatie maakt die berekening uiteindelijk wel. Als ze dat doen, zal het antwoord geen zestig cent zijn. Die autosave-pull request is overigens vanochtend gemerged. Er waren nog twee commits nodig om daar te komen, één om navigatie-opslagen single-flight te maken en één om autosave te laten convergeren en de builder met rust te laten. Goede commits. Niets staat in brand. Niemand zal ooit weten dat ze nodig waren, omdat bugs die vóór de merge worden gevonden geen spoor achterlaten en geen incidentrapport genereren. Dat is het deel hiervan dat je zou moeten storen. De reviewer die er vijf miste kost hetzelfde of hij er nu zes of nul vindt, en hij zal je nooit vertellen voor welke van die twee maanden je zojuist hebt betaald. --- *Juror is open source en MIT-licentie: [github.com/juror-ai/juror](https://github.com/juror-ai/juror). Greptile-prijzen geciteerd van [greptile.com/pricing](https://www.greptile.com/pricing) per augustus 2026.*