Come costruire un'alternativa più economica a Greptile

Fai la divisione sulla tua fattura di code review con l’IA. Prendi quello che hai pagato il mese scorso e dividilo per il numero di pull request che lo strumento ha effettivamente rivisto. Il prezzo di listino è un numero diverso, ed è quello che hai memorizzato. Ho fatto la divisione per il nostro team e ho ottenuto un numero così lontano dalla pagina dei prezzi che ho pensato di aver sbagliato i conti.

L’aritmetica era giusta. Stavo comprando il prodotto nel modo in cui viene venduto e usandolo nel modo in cui lavoriamo davvero, e si scopre che sono due prodotti diversi.

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

L’abbiamo sostituito con qualcosa che abbiamo costruito noi. Ti mostro le ricevute per entrambe le affermazioni, incluse le parti che ci fanno fare una figura peggiore.

Sei difetti sono entrati. Uno ne è uscito.

La pull request era un refactor dell’autosave nella nostra piattaforma. Normale, di medie dimensioni, del tipo che viene aperta di martedì e nessuno perde il sonno. Greptile l’ha rivista, ha lasciato due commenti e ha proseguito.

Dopo, uno dei nostri ingegneri ha esaminato il diff a mano e lo ha valutato come si deve, annotando ogni difetto genuino senza guardare quale strumento avesse riportato cosa. Sei difetti. Quattro di livello P1, del tipo che corrompe i dati degli utenti invece di dare fastidio a qualcuno.

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

Uno di quei sei è stato segnalato.

Nessuno di quei sei è arrivato in produzione, e voglio essere preciso sul perché. Un ingegnere si è seduto e ha letto il diff riga per riga. Il revisore era già passato e andato. Stavamo pagando per una rete di sicurezza che ha catturato una cosa su sei, e le cinque che ha lasciato cadere sono state catturate dall’esatta attività che il prodotto esiste per ridurre.

Essere sicuri di sé al contrario è peggio che non dire nulla

C’era un settimo riscontro. Non era reale.

Ci è stato detto che “l’autosave fallito non ha retry”. Il difetto che si trovava nella stessa funzione puntava nella direzione opposta: l’autosave fallito riprovava per sempre. Lo strumento aveva la direzione invertita.

Ho pensato a quello più che ai cinque mancati messi insieme. Un mancato è 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 giusto a cercare la cosa sbagliata, e quando non trova la cosa che non c’è mai stata, chiude il file e lo segna come rivisto. Un falso report spende la tua attenzione, e la spende nel punto esatto in cui si nascondeva il vero bug.

Un riscontro reale. Un riscontro invertito. Sei difetti nel diff.

Un solo modello significa un solo 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 mi ci è voluto più tempo di quanto vorrei ammettere.

Ogni modello di frontiera ha punti ciechi, e non ce ne sono due con gli stessi. Ogni vendor spedisce quella proprietà, perché è ciò che questi sistemi sono. Quindi se costruisci il tuo processo di review su esattamente un modello, l’hai costruito su esattamente un pattern di cecità, e non ne imparerai mai la forma, perché l’unico strumento che potrebbe mostrartela è lo strumento che è cieco.

Lo dico esplicitamente. Compra il miglior revisore sul mercato e hai comprato un pattern di cecità a prezzo pieno. Il code review funzionava in primo luogo perché una seconda persona guardava il diff. Quello era l’intero meccanismo, e l’abbiamo abbandonato la settimana in cui l’abbiamo automatizzato.

Quindi abbiamo costruito Juror. Diversi modelli di frontiera rivedono lo stesso diff in parallelo, ciascuno attraverso il proprio harness agente nativo, ciascuno libero di cercare nel tuo repository come intende il suo vendor. I loro riscontri vengono collassati, così tre report quasi identici di un difetto arrivano sulla pull request come un singolo commento.

L’abbiamo eseguito sullo stesso commit.

Revisore	Trovati	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 mancati due.

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

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

La tua fattura segue il numero di dipendenti. Le tue review seguono i merge.

Ora la fattura, che è dove smette di essere una questione di una singola pull request.

Il piano Pro di Greptile costa 30 $ per posto al mese, ad agosto 2026. Include 50 crediti per posto, dove un credito compra una review standard e tre ne comprano una più approfondita, e i crediti aggiuntivi costano 1 $ ciascuno.

Per review, è economico. Circa sessanta centesimi, se usi ogni credito che ti viene dato. Voglio essere completamente onesto qui: su base unitaria è meno di quanto sia costato il nostro strumento sulla pull request qui sopra. Un piccolo team che consuma completamente la propria dotazione dovrebbe comprare i posti, e non farò finta del contrario.

Nessuno consuma completamente la propria dotazione.

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

La tua utilizzazione è cambiata e il prezzo di listino no, quindi sessanta centesimi sono diventati quattro dollari e nessuno ti ha mandato un’email al riguardo.

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

Posso dirti quanto è costato perché stampiamo lo scontrino

Juror non ha posti. Gira nel tuo runner di GitHub Actions, chiama le API dei modelli con le tue chiavi, e il conto è l’inferenza e nient’altro. Quella review della PR sull’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 review 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à nessuno dei due, stampa unknown e il totale è marcato come limite inferiore. Non facciamo stime a caso e non arrotondiamo a nostro favore.

Ora guarda di nuovo le due celle in quella tabella che dicono “non divulgato.” Sono andato a cercare quelle cifre e non sono pubblicate da nessuna parte. Lo strumento non ti dice quanto costa una review perché non deve. Hai comprato un posto. L’economia unitaria sono affari del venditore, e il venditore preferirebbe che continuassi a fare la moltiplicazione a modo suo.

Un reviewer che stampa il proprio conto è la cosa che volevo e che non potevo comprare a nessun prezzo.

Quello che non farò è chiamarlo benchmark

Questa è una pull request.

Il nostro protocollo di benchmarking dice che una decisione di sostituzione richiede da 20 a 30 PR valutate che coprano frontend, backend, migrazioni, concorrenza, codice sensibile alla sicurezza, e diff sia piccoli che grandi. Ne abbiamo una. Sta nel repository con un avviso allegato che dice che non deve essere presentata come prova statisticamente sufficiente che un reviewer possa sostituire l’altro, e non violerò il nostro stesso avviso dentro un post di blog su quanto accuratamente riportiamo i numeri.

Quattro su sei contro uno su sei è un caso valutato. Mi ha reso disposto a far girare entrambi i reviewer fianco a fianco, e questo è tutto il peso che può portare. Una pull request diversa, una che fa molto affidamento sul contesto a livello di repository dove un reviewer indicizzato dovrebbe andare bene, potrebbe plausibilmente invertire il risultato. Se lo fa, anche quel caso entra nel corpus.

L’aritmetica è la parte che sopravvive a un campione di uno. Trenta dollari a posto per venti ingegneri fa $600 che mi piaccia o no, e 150 review contro mille crediti è il 15% di utilizzazione in qualsiasi mese tu voglia misurare. Abbiamo cambiato in base alla struttura dei prezzi, che posso difendere con una divisione, e su un caso promettente. L’affermazione sulle prestazioni è quella che non ci siamo guadagnati, quindi non la faccio.

Vieni a misurarci

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

Metti entrambi i reviewer in modalità shadow sul tuo repository. Lasciali girare per qualche settimana senza che nessuno dei due blocchi un merge. Poi prendi ogni risultato, togli le etichette così nessuno sa quale strumento ha detto cosa, e fai valutare a un ingegnere senior i risultati a freddo contro il codice. Conta cosa ha trovato ciascuno. Conta cosa ha inventato ciascuno.

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

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

Riporta recall, precision, tasso di duplicati, costo e latenza per ogni reviewer che gli dai in pasto, e elenca ogni mancato rilevamento per nome. Inclusi i nostri.

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 perché non ti disturbi. Qualcuno nella tua organizzazione fa quel calcolo prima o poi. Quando lo fa, la risposta non sarà sessanta centesimi.

Quella pull request sull’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 stare 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 alcun rapporto di incidente. Questa è la parte che dovrebbe preoccuparti. Il reviewer che ne ha mancati 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. Prezzi di Greptile citati da greptile.com/pricing ad agosto 2026.