Come usiamo Jev per due compiti nella code review con IA
Il modello decisionale Jev risponde con numeri, non con testo. Lo usiamo per due compiti nella code review con IA; secondo le misure, confronta e non giudica.
In sintesi. Un modello decisionale (decision model) è un modello di IA che non scrive testo e risponde con un numero a domande tipizzate. diffox ultra usa il modello Jev di TypeSafe nella quarta fase di una review, quando sceglie che cosa pubblicare. A settembre 2026 abbiamo misurato dove aiuta e dove no; in questo articolo raccontiamo le misure e le lezioni che ne abbiamo tratto.
- Due compiti. Prima della selezione, risponde a dieci domande su ogni rilievo candidato. Dopo la selezione, trova i rilievi che risalgono alla stessa causa e ne tiene uno solo.
- Dove aiuta: confrontare. Quando gli si chiede se due rilievi descrivono lo stesso bug, 46 delle 47 coppie che ha segnalato erano davvero lo stesso bug.
- Dove non aiuta: giudicare. Su «questo rilievo è reale?» non distingueva meglio del punteggio di confidenza del modello che ha scritto il rilievo.
- La regola. Chiedi a un modello decisionale di scegliere, non di giudicare: «questi due sono uguali?», «quale?», «che livello?».
Come risponde un modello decisionale
I primi tre articoli hanno raccontato i risultati di diffox, il suo prezzo e le quattro fasi di una review. Questo parla di un modello che lavora in una di quelle fasi senza scrivere una sola frase.
Se fai una domanda a un modello linguistico, la risposta è un testo. A un modello decisionale invece dai uno stato e domande tipizzate, e lui risponde a ciascuna con un solo numero: una probabilità di sì, una distribuzione tra opzioni o un livello su una scala. Risponde insieme a tutte le domande di una richiesta. Jev, di TypeSafe, è un modello di questo tipo; TypeSafe lo chiama modello «System One».
Poiché la risposta non è un testo, due cose diventano più semplici: decidere con una soglia e combinare la risposta con altri segnali. Una diventa più difficile: il modello risponde solo alla domanda che gli fai e non dice mai che era posta male. Per questo abbiamo dovuto misurare per capire quali domande valga la pena fare.
Che cosa fa Jev in diffox ultra
Una review passa per quattro fasi: contesto, revisione specialistica, verifica delle evidenze, e scelta e pubblicazione. Jev lavora solo in diffox ultra e solo nella quarta fase. Le verifiche delle evidenze restano semplice codice; diffox, il prodotto principale, non usa alcun modello decisionale.
Il primo compito arriva prima della selezione. In diffox ultra due modelli distinti leggono la modifica. Per ogni rilievo candidato di queste due review, il modello decisionale riceve due serie di domande, e le sue dieci risposte entrano nel punteggio della selezione insieme ai segnali propri del rilievo. Viene pubblicato il rilievo il cui punteggio supera la soglia. Da solo, il modello decisionale non pubblica né elimina alcun rilievo; le sue risposte sono uno degli input del punteggio.
Il secondo compito arriva dopo la selezione. I rilievi da pubblicare passano al modello decisionale a coppie: «questi due descrivono la stessa causa?». Se la risposta è 0,5 o più, il successivo viene scartato e resta quello col punteggio più alto. Se un candidato aspettava il posto rimasto libero, lo prende quando supera la stessa prova. Nella verifica delle evidenze, Second Witness unisce la stessa obiezione fatta nello stesso punto; il modello decisionale, invece, trova rilievi che stanno su righe diverse ma risalgono allo stesso bug.
Se il modello decisionale non risponde, la review va avanti: la selezione si fa senza le sue risposte, la ricerca dei duplicati viene saltata e il registro della review lo annota.
Che cosa chiediamo al modello decisionale
Le domande del primo compito non servono a capire se un rilievo è corretto, ma che tipo di affermazione fa e su che cosa si basa. Per ogni rilievo candidato, il modello decisionale riceve quattro cose: il titolo della pull request, l’agente che ha scritto il rilievo e la sua descrizione, la modifica nel file del rilievo (al massimo 15.000 caratteri) e il testo del rilievo.
| Domanda | Che cosa guarda | Risposta |
|---|---|---|
| Sul percorso principale? | Il bug si verifica con un input normale e valido, o solo quando qualcos’altro fallisce, con un input malevolo o con un’impostazione insolita? | probabilità di sì |
| Una precauzione? | Il rilievo segnala un risultato errato, o propone una precauzione: una validazione, un controllo difensivo, un altro tipo di errore? | probabilità di sì |
| Un effetto visibile? | Se non corretto, un utente o un chiamante vedrebbe qualche differenza? Codice morto, un import inutilizzato o documentazione non aggiornata non ne fanno. | probabilità di sì |
| Si basa su ciò che non si vede? | L’affermazione si appoggia a codice, a un chiamante o a un’impostazione che qui non sono mostrati? | probabilità di sì |
| Causato da questa modifica? | Il problema viene dalle righe che questo diff aggiunge o modifica, o c’era già prima? | probabilità di sì |
| Un revisore commenterebbe? | Un revisore esperto commenterebbe questo punto? La scala va dal non menzionarlo al bloccare il merge. | livello da 1 a 5 |
| Confronto con codice fratello? | Il rilievo si basa su codice fratello nella stessa modifica che fa la stessa cosa in modo diverso e mostra la forma voluta? | probabilità di sì |
| Una piccola correzione? | Basterebbe cambiare un nome, un valore, un operatore o una condizione per correggere il codice? | probabilità di sì |
| Prudente? | L’affermazione dice «potrebbe, forse», o dice con certezza che cosa va storto? | probabilità di sì |
| Voluto? | A giudicare dal titolo della pull request e dalla forma del diff, il comportamento contestato è lo scopo di questa modifica: qualcosa rimosso di proposito, un nuovo limite? | probabilità di sì |
Nove delle dieci sono domande sì/no, a cui il modello risponde con una probabilità di sì; l’altra, quella del revisore, chiede un livello da 1 a 5. Le dieci risposte entrano nel punteggio della selezione insieme ai segnali propri del rilievo: gravità, tipo, esito delle verifiche delle evidenze e se altri rilievi indicano lo stesso punto. È poi il punteggio a decidere quali rilievi pubblicare. A ogni agente si pongono anche una o due domande sul suo tema, ma nel punteggio entrano solo queste dieci risposte.
Queste domande hanno in comune una cosa: la risposta è già davanti al modello. Se un bug è sul percorso principale lo dice lo scenario del rilievo; se l’affermazione è prudente si vede dalla frase stessa. Al modello decisionale non chiediamo di rigiudicare il rilievo, ma solo di leggere il testo che ha davanti e di metterlo in una casella.
Dove il modello decisionale aiuta
A settembre 2026 abbiamo misurato dove il modello decisionale aiuta. Abbiamo usato rilievi che quattro diverse configurazioni di review hanno trovato in pull request di progetti open source, ognuno confrontato con bug segnati in anticipo da persone. Il risultato più netto è arrivato su una domanda: due rilievi descrivono lo stesso bug? È quella che evita a un bug un secondo commento.
Abbiamo chiesto «stessa causa?» per 374 coppie di rilievi; 58 descrivevano davvero lo stesso bug. Con una soglia di 0,5, il modello decisionale ha segnalato 47 coppie, 46 delle quali giuste. Il suo punteggio di separazione era 0,99; quello di una regola che chiede solo «stesso file?» è 0,73. Il punteggio di separazione è la probabilità che una coppia dello stesso bug, presa a caso, finisca davanti a una coppia di bug diversi presa a caso: 0,5 è testa o croce, 1 è perfetto.
Lo stesso tipo di domanda è servito anche altrove: collocare la gravità di un rilievo su uno di quattro livelli. La concordanza esatta con la gravità data dalle persone era del 49,5% con il giudizio del motore e del 56,8% con la correzione del modello decisionale (222 rilievi). L’abbiamo misurato, ma oggi non è attivo in nessuno dei due prodotti.
Dove non aiuta
Lo stesso modello è stato debole su «questo rilievo è reale?». 315 rilievi su 656 corrispondevano a un bug noto. Il punteggio di separazione del modello decisionale era 0,64, quello della confidenza del modello che ha scritto il rilievo 0,65: non meglio di un segnale che avevamo già.
Restringere la domanda non ha cambiato nulla: dodici domande mirate e un modello appreso che le combina hanno portato il punteggio di separazione solo a 0,67.
La differenza sta nella domanda stessa. Quando confronta due testi, il modello ha tutte le prove davanti. Se il codice si comporti davvero così, invece, non è scritto da nessuna parte; per saperlo bisogna leggere il codice e costruire uno scenario. In diffox è il lavoro degli agenti specializzati, e l’affermazione è provata da una citazione del file.
Quale strumento per quale compito?
In una review lavorano quattro tipi di strumenti, e ognuno è bravo in un compito diverso.
| Strumento | Produce | Stesso input, stessa risposta | Compito in diffox |
|---|---|---|---|
| Semplice codice | un sì o un no netto | sempre | verifiche delle evidenze, rilevatori basati su regole |
| Modello decisionale | una probabilità, una scelta o un livello | quasi: interrogato di nuovo, al massimo 0,07 di scarto | in diffox ultra, dieci domande e la ricerca dei duplicati |
| Modello linguistico (LLM) | testo | no | agenti specializzati; titoli e suggerimenti di correzione |
| Selettore appreso | un punteggio | sempre | quali rilievi vengono pubblicati |
La divisione dei compiti viene dalla tabella. Una domanda a cui una regola fissa può rispondere va al codice. Confrontare due cose che ha davanti, o scegliere tra poche opzioni, va al modello decisionale. Leggere il codice, costruire uno scenario e spiegarlo a un lettore va al modello linguistico. Trasformare tutti questi segnali in un’unica decisione «pubblicare o no» va al selettore appreso.
Sette lezioni per usare un modello decisionale
Quello che i nostri esperimenti ci hanno insegnato mentre portavamo un modello decisionale nel prodotto:
- Chiedigli di scegliere, non di giudicare. La risposta a «questi due sono uguali?», «che livello?», «quale?» è davanti a lui; quella a «è giusto?» no.
- Invia in una sola richiesta le domande che condividono uno stato. Una domanda in più quasi non rallenta la risposta. Una delle nostre fasi non lo faceva: inviava una richiesta per rilievo e ogni volta lo stesso diff. Con una sola richiesta lo stato inviato si è ridotto del 55%.
- Blocca la versione. Le soglie si misurano sulle probabilità di una versione. diffox ultra usa una versione fissa, non un alias «latest»; se la versione cambia, la soglia si misura di nuovo.
- Prima di aggiungerlo, confrontalo con quello che hai. Un nuovo segnale vale quello che aggiunge a quelli che hai già. La nostra domanda «è reale?» non ha aggiunto nulla al punteggio di confidenza del rilievo.
- Fanne un input, non una barriera. In diffox ultra le risposte del modello decisionale non eliminano né pubblicano da sole alcun rilievo; entrano nel punteggio della selezione. L’unica cosa che elimina è un secondo commento sullo stesso bug.
- Scegli la soglia pensando al lettore. La soglia della ricerca dei duplicati è 0,5: 46 delle 47 coppie che segnala sono giuste. A 0,9 non ci sarebbe alcun errore, ma si troverebbe solo il 36% dei duplicati.
- Se la risposta non arriva, la review deve proseguire senza. E annotarlo nel registro: una fase mancante è meglio di una saltata in silenzio.
Domande frequenti
Che cos’è un modello decisionale (decision model)?
Un modello di IA che non scrive testo. Gli dai uno stato e domande tipizzate, e lui risponde a ciascuna con un numero: una probabilità di sì, una distribuzione tra opzioni o un livello su una scala. Risponde insieme a tutte le domande di una richiesta. Jev, di TypeSafe, è un modello di questo tipo; diffox ultra lo usa nella fase di selezione di una review.
In che cosa un modello decisionale è diverso da LLM-as-a-judge?
Con LLM-as-a-judge un modello linguistico legge un output e scrive il suo verdetto come testo, spesso con il ragionamento. Un modello decisionale non scrive testo: restituisce per ogni domanda una probabilità di sì, una scelta o un livello, e risponde insieme a tutte le domande di una richiesta. Per questo la sua risposta si confronta facilmente con una soglia e si combina facilmente con altri segnali; è così che lo usa diffox ultra.
Anche diffox usa un modello decisionale?
No. Il modello decisionale lavora solo in diffox ultra. In diffox, quali rilievi pubblicare si decide dai segnali propri dei rilievi, e semplice codice unisce la stessa obiezione fatta nello stesso punto.
Il modello decisionale vede il mio codice?
Per ogni rilievo candidato vede il suo testo, la modifica nel suo file (al massimo 15.000 caratteri), il titolo della pull request e la descrizione dell’agente che l’ha scritto. Questi dati vanno a TypeSafe, che fornisce il modello, direttamente o tramite OpenRouter; la nostra pagina sulla privacy indica i servizi usati.
Il modello decisionale può eliminare un rilievo?
Da solo no. Le sue risposte entrano nel punteggio della selezione, ed è il punteggio a decidere quali rilievi pubblicare. L’unica cosa che elimina è il secondo rilievo di una stessa causa; viene pubblicato quello col punteggio più alto.
Perché non chiedete al modello decisionale se un rilievo è reale?
L’abbiamo misurato: su quella domanda non separava meglio del punteggio di confidenza del modello che ha scritto il rilievo. Sapere se il codice si comporta davvero così richiede di leggerlo e costruire uno scenario; in diffox lo fanno gli agenti specializzati, e l’affermazione è provata da una citazione del file.
Dà sempre la stessa risposta alla stessa domanda?
Quasi. Interrogato di nuovo sulle stesse domande, le sue risposte sono variate al massimo di 0,07. Per questo misuriamo le soglie sulle probabilità di una versione e blocchiamo la versione.