Non stai pagando per le code review. Stai pagando per le sedie.

Fai la divisione sulla tua fattura di AI code review. Non il prezzo di listino, la divisione reale: quanto hai pagato il mese scorso, diviso per il numero di pull request che ha revisionato. L’ho fatto per il nostro team e il numero era così peggiore di quello sulla pagina dei prezzi che ho pensato di aver fatto un errore.

Non avevo fatto un errore. Avevo solo comprato il prodotto nel modo in cui mi era stato venduto invece del modo in cui lo usiamo.

Ecco la tesi, e tutto ciò che segue ne è la prova. L’AI code review viene venduta per sviluppatore e consumata per pull request. Questi due numeri non hanno nulla a che fare l’uno con l’altro, e il divario tra di loro è dove vanno i tuoi soldi. Separatamente, e peggio, lo strumento per cui pagavamo ha letto un diff con sei difetti reali e ne ha trovato uno.

Lo abbiamo sostituito con qualcosa che abbiamo costruito. Ti mostrerò le ricevute per entrambe le affermazioni, incluse le parti che ci fanno apparire peggio.

Sei difetti sono entrati. Uno è uscito.

La pull request era un refactor dell’autosalvataggio nella nostra piattaforma. Ordinaria, di medie dimensioni, il tipo che viene aperto di martedì e nessuno perde il sonno. Greptile l’ha revisionata, ha lasciato due commenti, e ha proseguito.

In seguito uno dei nostri ingegneri ha esaminato il diff a mano e lo ha valutato correttamente, annotando ogni difetto genuino senza guardare quale strumento avesse riportato cosa. Sei difetti. Quattro di essi P1, il tipo che corrompe i dati utente piuttosto che infastidire qualcuno.

L’autosalvataggio si riarmava per sempre dopo aver normalizzato i valori. Un salvataggio fallito riprovava in un loop infinito. L’autosalvataggio sovrascriveva ciò che l’utente stava digitando attivamente in un’altra scheda. Una promise di salvataggio veniva scartata senza gestione. Lasciare la pagina faceva cadere tutto ciò che era in sospeso. Il pulsante di salvataggio veniva renderizzato solo quando lo step non poteva essere salvato.

Uno di questi sei è stato segnalato.

Nessuno di questi sei è arrivato in produzione, e voglio essere preciso sul perché, perché la ragione è il punto centrale. Sono stati scoperti perché un umano ha letto il diff. Non perché il revisore li abbia fermati. Stavamo pagando per una rete di sicurezza che ha catturato una cosa su sei, e la cosa che ha catturato le altre cinque è stato un ingegnere che leggeva il codice riga per riga, che è esattamente l’attività che il prodotto esiste per ridurre.

Essere sicuri al contrario è peggio che non dire nulla

C’era un settimo riscontro. Non era reale.

Ci è stato detto “l’autosalvataggio fallito non ha retry.” Il difetto reale, situato nella stessa funzione, era l’opposto: l’autosalvataggio fallito riprovava per sempre. Non un bug mancato. Uno invertito.

Ho pensato a quello più delle cinque mancanze messe insieme. Una mancanza è silenzio, e il silenzio è sopportabile, perché dai già per scontato che il tuo revisore non sia onnisciente. Un’inversione è peggio del silenzio. Manda un ingegnere nel file corretto a cercare la cosa sbagliata, e quando non trova la cosa che non c’è mai stata, chiude il file e lo segna come revisionato. Un falso report non solo non ti aiuta. Spende la tua attenzione, e la spende esattamente nel posto in cui si nascondeva il vero bug.

Un riscontro reale. Un riscontro al contrario. Sei difetti nel diff.

Un modello significa un punto cieco, e non ne imparerai mai la forma

La mia prima reazione è stata che avevamo comprato lo strumento sbagliato. Quella reazione era sbagliata, e superarla ha richiesto più tempo di quanto vorrei ammettere.

Ogni modello all’avanguardia ha punti ciechi e non sono gli stessi punti ciechi. Questo non è un difetto del prodotto di un particolare fornitore, è ciò che questi sistemi sono. Il che significa che se costruisci il tuo processo di revisione su un solo modello, lo hai costruito su un solo schema di cecità, e non imparerai mai la forma di quello schema, perché l’unico strumento che potrebbe mostrartelo è lo strumento che è cieco.

Lasciami spiegare. Il problema non è che il tuo revisore sia scarso. Il problema è che il tuo revisore è singolo. Un secondo parere non è mai stato un lusso nel code review, era l’intero meccanismo con cui il code review funzionava, e lo abbiamo silenziosamente abbandonato nel momento in cui lo abbiamo automatizzato.

Così abbiamo costruito Juror. Diversi modelli all’avanguardia revisionano lo stesso diff in parallelo, ciascuno attraverso il proprio harness nativo dell’agente, ciascuno libero di cercare nel tuo repository come il suo fornitore intende. I loro riscontri collassano, così tre report quasi duplicati di un difetto diventano un unico riscontro anziché tre, e ciò che arriva sulla pull request è un singolo commento.

Lo abbiamo eseguito sullo stesso commit.

Revisore	Trovato	Precisione	Costo	Tempo
Greptile	1 su 6	50%	non divulgato	non divulgato
Juror	4 su 6	100%	$1.08	8m22s

Ecco la parte in cui perdiamo

Juror ne ha persi due.

Greptile ha catturato la promise di salvataggio scartata e noi no. Nessuno dei due strumenti ha trovato il loop infinito di retry. Mettendo insieme entrambi i revisori si ottengono cinque su sei, che è meglio di quanto ciascuno abbia fatto da solo, e non ho intenzione di seppellirlo sotto la tabella sopra.

Avrei potuto tagliare questa sezione. La tengo perché è l’argomento. Modelli diversi catturano cose diverse. Non è un’aggiunta imbarazzante alla nostra proposta, è la proposta, e il fatto che un modello concorrente trovi qualcosa che il nostro ha perso è la dimostrazione più chiara disponibile che eseguire un singolo revisore è l’errore. Il giorno in cui smetterà di accadere sarà il giorno in cui inizierò a preoccuparmi che la nostra giuria sia collassata in un’unica opinione con quattro cappelli.

Non stai pagando per le revisioni

Ora la fattura, che è dove questo smette di riguardare una singola pull request.

Il piano Pro di Greptile è $30 per seat al mese, ad agosto 2026. Include 50 crediti per seat, dove un credito compra una revisione standard e tre ne comprano una più approfondita, e crediti aggiuntivi sono $1 ciascuno.

Per revisione, è economico. Circa sessanta centesimi, se usi tutti i crediti che ti vengono dati. Voglio essere completamente onesto: su base unitaria, è inferiore a quanto costava il nostro strumento per la pull request sopra. Un piccolo team che consuma completamente la sua assegnazione dovrebbe acquistare i posti, e non farò finta del contrario.

Nessuno consuma completamente la propria assegnazione.

Vieni fatturato per sviluppatore. Consumi revisioni per pull request. Questi due numeri smettono di coincidere nel momento in cui il numero di dipendenti cresce più velocemente del tasso di merge, il che significa immediatamente, in ogni organizzazione ingegneristica che sia mai esistita. Venti ingegneri su Pro costano $600 al mese e mille crediti. Se quel team fa il merge di 150 pull request, un mese del tutto normale, hai pagato $4 per revisione e lasciato scadere 850 crediti.

Il prezzo di listino non è mai cambiato. Il tuo utilizzo sì. Sessanta centesimi sono diventati quattro dollari e nessuno ti ha mandato un’email.

Chiamatela tassa sul posto: denaro speso per una licenza per sviluppatore per un prodotto consumato per artefatto. È invisibile nella pagina dei prezzi, scala con le assunzioni invece che con l’uso, ed è la voce più grande in ciò che effettivamente paghi.

Posso dirti quanto è costato perché stampiamo la ricevuta

Juror non ha posti. Viene eseguito nel tuo runner di GitHub Actions, chiama le API dei modelli con le tue chiavi, e il conto è solo l’inferenza e nient’altro. Quella revisione della PR di autosave, quattro difetti reali e nessun falso positivo, è costata $1.08 e ha impiegato otto minuti e ventidue secondi.

Posso dirtelo al centesimo perché ogni revisione di Juror termina con una tabella: ogni modello, i suoi token di input, i suoi token in cache, i suoi token di output, i suoi dollari. Ogni cifra è etichettata reported quando il provider l’ha calcolata, o estimated quando l’abbiamo derivata dai prezzi di listino pubblicati. Quando un harness non ci dà né l’uno né l’altro, stampa unknown e il totale è segnato come limite inferiore. Non facciamo supposizioni e non arrotondiamo a nostro favore.

Ora guarda di nuovo le due celle in quella tabella che dicono “non divulgato”. Non è una lacuna nella mia ricerca. Lo strumento non ti dice quanto è costata una revisione, perché non deve. Hai comprato un posto. L’economia unitaria è affare del venditore, e il venditore preferirebbe che continuassi a fare la moltiplicazione a modo loro.

Quella era la cosa che volevo davvero e che non potevo comprare a nessun prezzo. Non un revisore più economico. Un revisore che mi dicesse quanto ha speso.

Quello che non farò è chiamarlo benchmark

Questa è una sola pull request.

Il nostro protocollo di benchmarking dice che una decisione di sostituzione necessita di 20-30 PR giudicate che coprano frontend, backend, migrazioni, concorrenza, codice sensibile alla sicurezza, e sia diff piccoli che grandi. Noi ne abbiamo una. Si trova nel repository con un avviso che dice che non deve essere presentata come prova statisticamente sufficiente che un revisore possa sostituire l’altro, e non violerò il nostro stesso avviso in un post del blog su quanto accuratamente riportiamo i numeri.

Quattro su sei contro uno su sei non è un risultato di benchmark. È un caso giudicato che mi ha reso disposto a eseguirli entrambi fianco a fianco. Una pull request diversa, che si basi molto sul contesto a livello di repository dove un revisore indicizzato dovrebbe funzionare bene, potrebbe plausibilmente invertirlo. Se accade, quel caso entra anche nel corpus.

Ciò che non è un campione di uno è l’aritmetica. Trenta dollari a posto per venti ingegneri sono $600 che mi piaccia o no, e 150 revisioni contro mille crediti sono un utilizzo del 15% in qualsiasi mese tu voglia misurare. Abbiamo cambiato sulla struttura dei prezzi, che posso difendere con la divisione, e su un caso promettente. Non su un’affermazione di performance che non abbiamo ancora guadagnato.

Vieni a misurarci

Non prendere la mia parola per tutto questo. Ho un interesse commerciale nella tua conclusione e dovresti pesare tutto quanto sopra di conseguenza.

Metti entrambi i revisori in modalità ombra sul tuo repository. Lasciali eseguire per qualche settimana senza che nessuno blocchi un merge. Poi prendi ogni risultato, togli le etichette in modo che nessuno sappia quale strumento ha detto cosa, e fai giudicare a un ingegnere senior a freddo rispetto al codice. Conta cosa ha trovato ciascuno. Conta cosa ha inventato ciascuno.

Abbiamo rilasciato gli strumenti proprio per questo, perché ne avevamo bisogno noi stessi:

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

Riporta recall, precisione, tasso di duplicati, costo e latenza per ogni revisore che gli dai, e elenca ogni mancanza per nome. Incluso il nostro.

Non credo che il modello a posti sopravviva al contatto con chiunque faccia la divisione. Sopravvive ora perché la divisione è leggermente fastidiosa e la pagina dei prezzi è organizzata in modo che non ti disturbi. Qualcuno nella tua organizzazione prima o poi fa quel calcolo. Quando lo fa, la risposta non sarà sessanta centesimi.

Quella pull request di autosave è stata mergiata stamattina, tra l’altro. Ci sono voluti altri due commit per arrivarci, uno per rendere i salvataggi di navigazione single-flight e uno per far convergere l’autosave e lasciare in pace il builder. Buoni commit. Niente in fiamme.

Nessuno saprà mai che erano necessari, perché i bug trovati prima del merge non lasciano traccia e non generano report di incidente. Questa è la parte che dovrebbe preoccuparti. Il revisore che ne ha persi cinque costa lo stesso sia che ne trovi sei sia che ne trovi zero, e non ti dirà mai per quale di quei due mesi hai appena pagato.

---

Juror è open source e con licenza MIT: github.com/juror-ai/juror. I prezzi di Greptile sono citati da greptile.com/pricing ad agosto 2026.