# La fatturazione per posto trasforma una revisione del codice da 60 centesimi in 4 dollari > Vieni fatturato per sviluppatore e consumi revisioni per pull request. Ecco la ripartizione, più la pull request valutata in cui il nostro revisore AI ha rilevato un difetto su sei. - Source: https://jays.fyi/it/blog/fatturazione-per-posto-revisione-codice - Author: Jay Derinbogaz - Published: 2026-08-08 - Language: it - Tags: tooling, code-review, pricing - Reading time: 10 min - Machine translated: yes — original: https://jays.fyi/blog/how-i-removed-greptile ---
Ricevuta da Greptile per $861,00, pagata il 3 agosto 2026.
Un mese di Greptile, agosto 2026. La pagina dei prezzi dice $30.
Fai la divisione sulla bolletta della tua revisione del codice con AI. 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. La revisione del codice con AI è 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 del salvataggio automatico 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 loro P1, il tipo che corrompe i dati dell'utente piuttosto che infastidire qualcuno. Il salvataggio automatico si riarmava per sempre dopo aver normalizzato i valori. Un salvataggio fallito riprovava in un ciclo infinito. Il salvataggio automatico 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 quei sei è stato segnalato. Nessuno di quei 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 "il salvataggio automatico fallito non ha tentativi". Il difetto reale, situato nella stessa funzione, era l'opposto: il salvataggio automatico fallito riprovava *per sempre*. Non un bug mancato. Uno invertito. Ho pensato a quello più dei 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 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 rapporto 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 mi ha richiesto più tempo di quanto mi piacerebbe 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 esattamente un modello, lo hai costruito su esattamente uno 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 nella revisione del codice, era l'intero meccanismo con cui funzionava la revisione del codice, 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 agente nativo, ciascuno libero di cercare nel tuo repository nel modo previsto dal suo fornitore. I loro riscontri collassano, così tre rapporti quasi duplicati di un difetto diventano un unico riscontro invece di tre, e ciò che arriva sulla pull request è un singolo commento. Lo abbiamo eseguito sullo stesso commit. | Revisore | Trovato | Precisione | Costo | Tempo | | --- | --- | --- | --- | --- | | Greptile | 1 of 6 | 50% | non divulgato | non divulgato | | Juror | **4 of 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 ciclo di riprova 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 sopra. Avrei potuto tagliare questa sezione. La tengo perché *è* l'argomento. Modelli diversi catturano cose diverse. Non è una clausola imbarazzante attaccata alla nostra proposta, è la proposta, e il modello di un concorrente che trova qualcosa che il nostro ha mancato è la dimostrazione più chiara 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. ## Non stai pagando per le revisioni. Stai pagando per le sedie. Ora il conto, che è dove questo smette di riguardare una singola pull request. Il [piano Pro di Greptile](https://www.greptile.com/pricing) è **$30 per posto al mese**, ad agosto 2026. Include 50 crediti per posto, dove un credito compra una revisione standard e tre ne comprano una più approfondita, e ulteriori crediti sono $1 ciascuno. Per revisione, è economico. Circa sessanta centesimi, se usi ogni credito che ti viene dato. Voglio essere completamente onesto: su base unitaria è inferiore a quanto è costato il nostro stesso strumento sulla pull request sopra. Un piccolo team che consuma completamente la sua dotazione dovrebbe acquistare i posti, e non fingerò il contrario. Nessuno consuma completamente la propria dotazione. Vieni fatturato per *sviluppatore*. Consumi revisioni per *pull request*. Questi due numeri smettono di corrispondere nel momento in cui il numero di dipendenti cresce più velocemente del tasso di merge, il che significa 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 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. Chiamiamola tassa sui posti: denaro speso per una licenza per sviluppatore per un prodotto consumato per artefatto. È invisibile sulla 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 costa perché stampiamo lo scontrino Juror non ha posti. Viene eseguito nel tuo runner di GitHub Actions, chiama le API dei modelli con le tue chiavi, e il conto è l'inferenza e nient'altro. Quella revisione della PR 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 indoviniamo 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 costa una revisione, perché non è obbligato. Hai comprato un posto. L'economia unitaria sono affari del venditore, e il venditore preferirebbe che continuassi a fare la moltiplicazione a modo loro. Quella era la cosa che volevo davvero e non potevo comprare a nessun prezzo. Non un revisore più economico. Un revisore che mi dice quanto ha speso. ## Quello che non farò è chiamarlo benchmark Questa è una pull request. Il nostro [protocollo di benchmarking](https://github.com/juror-ai/juror/blob/main/docs/benchmarking.md) 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 sul 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, una che fa molto affidamento sul contesto a livello di repository dove un revisore indicizzato dovrebbe funzionare bene, potrebbe plausibilmente invertirlo. Se lo fa, anche quel caso va 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 base della struttura dei prezzi, che posso difendere con una 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 dei due 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 ciascuno ha trovato. Conta cosa ciascuno ha inventato. Abbiamo rilasciato gli strumenti proprio per questo, perché ne avevamo bisogno noi stessi: ```bash npx juror-ai benchmark --file your-corpus.json ``` Riporta recall, precision, tasso di duplicati, costo e latenza per ogni revisore che gli fornisci, e elenca ogni mancanza per nome. Incluso il nostro. Non credo che il modello dei 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 tu 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 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 alcun rapporto di incidente. Questa è la parte che dovrebbe preoccuparti. Il revisore che ne ha persi cinque costa lo stesso che ne trovi sei o 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](https://github.com/juror-ai/juror). I prezzi di Greptile citati da [greptile.com/pricing](https://www.greptile.com/pricing) ad agosto 2026.*