Gemini 3.1 Pro contro Gemini 3.7 Flash per la manutenzione del codice: come misurare se vale la pena pagare di più

La decisione: pagare per un’attività risolta, non per un’impressione

Scegliere tra Gemini 3.1 Pro e Gemini 3.7 Flash per la manutenzione del codice non significa semplicemente chiedersi quale sia «migliore». Per un team, la questione pratica è quale modello porti a termine una specifica attività con una patch corretta, quanto costi arrivare a quel risultato e quanto tempo serva. Un modello che risponde in fretta, ma introduce una regressione o richiede diversi cicli di correzione, può risultare meno efficiente di un altro con una singola chiamata più costosa.

Un confronto utile deve valutare il lavoro completato. Occorre verificare se la modifica risolve il problema segnalato, supera test pertinenti ed evita di alterare parti del codice non coinvolte nella richiesta. Bisogna inoltre conteggiare tentativi falliti, uso di strumenti, nuovi tentativi, intervento umano ed esecuzioni che non producono una patch accettabile. Il costo di una singola chiamata, da solo, non descrive il costo della manutenzione di un repository.

Qui non sono disponibili risultati di una prova svolta sugli stessi repository e con un unico harness. Sarebbe quindi scorretto affermare che Flash sia sufficiente per le attività di routine, che Pro giustifichi il costo aggiuntivo per quelle complesse o che uno dei due sia il vincitore. Quello che segue è un protocollo per ottenere una risposta e una guida per interpretare i risultati senza presentare ipotesi come fatti.

Quali modelli si confrontano e che cosa verificare prima di iniziare

Il primo passo è fissare l’identità esatta di ciascun sistema. La scheda ufficiale consultata identifica Gemini 3.1 Pro con l’ID `gemini-3.1-pro-preview` e indica che si tratta di una versione Preview. La guida ufficiale sul ragionamento consultata include `gemini-3.7-flash` e `gemini-3.1-pro-preview` tra i modelli per i quali riporta informazioni di configurazione. Nei registri della prova non bisogna sostituire questi nomi con etichette abbreviate: l’identificatore inviato all’API fa parte della configurazione sperimentale.

La disponibilità e lo stato possono cambiare. Prima di avviare le esecuzioni, e di nuovo al termine della prova, occorre verificare gli identificatori accettati, il canale utilizzato e se un modello non è più disponibile o ha cambiato stato. Se un modello cambia durante il test, l’articolo deve indicare a quale versione appartiene ciascuna esecuzione oppure separare i periodi; non deve trattarli implicitamente come un unico campione omogeneo.

Vanno registrati anche il fornitore e il canale di accesso, la data, i parametri di generazione, il limite di contesto, le regole di arresto e qualsiasi configurazione di ragionamento. La documentazione ufficiale descrive opzioni e valori predefiniti, ma questo non dimostra che due valori con lo stesso nome corrispondano allo stesso sforzo di calcolo, budget interno o comportamento. Un confronto tra livelli «equivalenti» sarebbe difendibile solo definendo operativamente che cosa significa equivalenza e riportando i parametri effettivamente usati.

Anche le tariffe non vanno copiate da una tabella datata né dedotte dal nome del modello. Occorre verificare le componenti di fatturazione applicabili alla data di esecuzione e spiegare che cosa è incluso: input, output, chiamate agli strumenti o altri costi pertinenti. Se l’accesso passa da un livello intermedio o prevede una tariffa diversa da quella dell’API diretta, quel canale va misurato e descritto, perché i risultati non si trasferiscono automaticamente a un altro canale.

Progettazione: repository, segnalazioni e criteri di accettazione

Il set di prova deve essere congelato prima di eseguire i modelli. Per ogni attività servono un repository e un commit di base identificabili, una descrizione del problema, un ambiente ricostruibile e un criterio di accettazione scritto in anticipo. Modificare le attività o le regole dopo aver scoperto quale modello ha prodotto ciascuna patch aumenta il rischio di adattare la valutazione ai risultati.

È opportuno selezionare segnalazioni provenienti da repository diversi e raggrupparle per tipo e difficoltà: diagnosi di un bug, correzione circoscritta, modifica che interessa più file e attività in cui i test esistenti non coprono completamente il comportamento atteso. La distribuzione va pubblicata. Una raccolta composta soprattutto da piccole modifiche potrebbe favorire un profilo di lavoro; una raccolta costituita principalmente da problemi ampi potrebbe favorirne un altro. La varietà riduce questo rischio, ma non lo elimina.

Le segnalazioni devono essere autentiche e pertinenti alla manutenzione, ma la selezione richiede cautela. Il paper di SWE-bench descrive un precedente basato su problemi ricavati da issue reali di GitHub. La documentazione del dataset e dell’harness può orientare la costruzione di una valutazione, ma usare attività di un benchmark non garantisce che una prova specifica misuri bene il lavoro di un team. Inoltre, OpenAI ha pubblicato un avvertimento sui limiti di SWE-bench Verified: tale avvertimento va attribuito alla posizione di OpenAI, non presentato come una verifica indipendente dei modelli qui confrontati.

Per ridurre la contaminazione, bisogna controllare se la soluzione o una patch equivalente sia già presente nel contesto fornito, nei file dell’attività o nei materiali accessibili al sistema. È importante descrivere anche quali informazioni riceve ogni modello: issue, cronologia, istruzioni, documentazione e test. Non basta dire che entrambi hanno ricevuto «lo stesso prompt» se uno ha avuto accesso a dati aggiuntivi o a strumenti diversi.

Le attività devono essere eseguite su copie pulite dello stesso commit. L’harness, le dipendenze e i comandi di test devono rimanere identici. Un ambiente riproducibile aiuta a distinguere l’effetto del modello da quello di una macchina, di una versione di una dipendenza o di una modifica manuale al repository. Se un’attività fallisce per un problema infrastrutturale e non per la patch, va classificata secondo una regola stabilita prima di esaminare i risultati.

Definire «attività accettata» prima di esaminare le patch

Superare un test non equivale automaticamente a fornire una soluzione accettabile. I test esistenti potrebbero non coprire il requisito centrale e una patch potrebbe farli passare con una modifica troppo ampia o alterando il comportamento in modo da nascondere il problema. L’accettazione dovrebbe combinare test automatizzati pertinenti e una revisione umana strutturata.

Come minimo, la rubrica deve verificare se la patch risolve la segnalazione, preserva il comportamento non pertinente, introduce regressioni note, modifica solo ciò che è necessario ed è manutenibile. Deve inoltre precisare come comportarsi quando il risultato sembra corretto, ma i test sono insufficienti. In quei casi si possono aggiungere controlli indipendenti oppure classificare l’attività come incerta, invece di imporre un esito positivo o negativo senza prove.

I revisori dovrebbero esaminare patch anonimizzate e applicare la stessa rubrica senza conoscere il modello d’origine. È utile registrare i disaccordi e definire una procedura per risolverli, per esempio una seconda revisione. Anche la valutazione umana è imperfetta: per questo vanno pubblicati la definizione di accettazione, i motivi di rifiuto e la quota di decisioni contestate.

Due prospettive diverse: stesso budget e stesso limite di tempo

Un confronto con budget uguale e uno con tempo uguale rispondono a domande diverse. Non vanno fusi in un unico dato. Nel primo caso si assegna a ciascun modello un tetto di spesa per attività, includendo le componenti di fatturazione definite per la prova. Si osserva quante attività porta a termine con una patch accettabile prima di raggiungere quel limite. Un tentativo fallito consuma parte del budget e deve rimanere nei risultati.

Nel secondo caso entrambi i modelli ricevono la stessa scadenza massima, misurata dall’inizio dell’attività alla consegna. Il cronometro deve includere attese, chiamate agli strumenti, nuovi tentativi e ogni altra latenza percepita dall’utente. Se la revisione umana viene misurata separatamente, va dichiarato; se viene inclusa, bisogna applicare lo stesso procedimento a entrambi. Altrimenti, confrontare solo il tempo di risposta del modello con il tempo totale di un flusso di lavoro significa mescolare metriche diverse.

Per garantire condizioni eque, prima dell’esecuzione si devono fissare spesa massima, scadenza, numero di tentativi, limite di passaggi, autorizzazioni e criterio di arresto. Se il modello raggiunge il limite senza produrre una patch accettabile, il risultato è un’attività non risolta in quelle condizioni, non un’esecuzione da rimuovere dall’analisi. Questo approccio risponde a una domanda concreta di acquisto: che cosa si ottiene con una somma massima o entro una finestra temporale definita.

Che cosa misurare per attività e per gruppo

La metrica centrale dovrebbe essere il tasso di accettazione: la quota di esecuzioni che producono una patch accettata secondo la rubrica. Per essere interpretabile, va accompagnata dal numero totale di attività e tentativi, non riportata soltanto come percentuale. Un tasso elevato su poche esecuzioni comporta un’incertezza diversa dallo stesso tasso osservato su un insieme più ampio.

Vanno riportate regressioni, test pertinenti superati, modifiche non necessarie, nuovi tentativi, errori di servizio, intervento umano e attività concluse senza una patch. La spesa può essere espressa per tentativo e per patch accettata, sempre specificando formula e componenti di fatturazione. Se un modello non risolve un’attività, il relativo costo non scompare dal denominatore: escludere gli insuccessi darebbe una visione artificialmente favorevole del costo per risultato positivo.

La latenza dovrebbe essere suddivisa almeno in tempo del modello, attese o code quando misurabili, operazioni con gli strumenti e tempo totale fino alla consegna. Per i team può essere rilevante anche la durata della revisione e della correzione manuale. Due modelli con tempi di generazione simili possono comportare carichi diversi se uno richiede più verifiche o riparazioni.

I risultati vanno suddivisi per tipo e difficoltà dell’attività, oltre a presentare un riepilogo complessivo. Il dato aggregato potrebbe nascondere che un modello gestisce meglio le piccole modifiche mentre l’altro evita errori nei cambiamenti che interessano più file. Non si dovrebbe definire «migliore» il modello in testa a una media se il team che legge lavora su un profilo di attività diverso.

Ripetizioni, errori di servizio e incertezza

L’output di un modello può variare da un’esecuzione all’altra, anche quando attività e ambiente restano invariati. Perciò una sola esecuzione per segnalazione non basta a descrivere la stabilità. Il numero di ripetizioni va stabilito prima di iniziare, giustificato in base alla portata della prova e mantenuto uguale per ogni modello e attività. Quando le condizioni del servizio impediscono di completare un’esecuzione, bisogna distinguere un errore infrastrutturale da un insuccesso del modello, senza cancellare il dato.

Occorre mostrare variabilità e incertezza, non soltanto una media. Si possono pubblicare conteggi, intervalli appropriati e risultati per singola attività; il metodo statistico va scelto in base al disegno e descritto. Se il campione è piccolo, la conclusione deve essere circoscritta: una differenza osservata in quei casi non dimostra che si ripresenti con altri linguaggi, repository, team o livelli di difficoltà.

Conta anche la sensibilità all’harness. Cambiare il prompt, il limite degli strumenti, il budget di contesto o le regole di arresto può modificare il risultato. Una prova controllata identifica l’effetto di una configurazione specifica; non misura una capacità universale indipendente dal modo in cui il modello viene usato. Se si svolgono ulteriori prove con altre configurazioni, vanno presentate separatamente e non mescolate al risultato principale.

Matrice decisionale per i team di ingegneria

Senza i risultati della prova, la matrice non può attribuire un vantaggio empirico a Gemini 3.1 Pro o Gemini 3.7 Flash. Può però aiutare a tradurre i dati raccolti in una decisione coerente con il lavoro del team. Il confronto deve considerare la soglia minima di qualità: se un modello non raggiunge il tasso di accettazione o il livello di sicurezza richiesto, un costo inferiore non basta a compensare.

Per attività di routine e ben delimitate, il team può verificare per prima cosa se Flash raggiunge quella soglia rispettando budget e scadenza. È un’ipotesi da verificare, non una proprietà dimostrata qui. Per attività difficili, con modifiche estese o conseguenze rilevanti, occorre accertare se Pro aumenti il tasso di accettazione o riduca l’intervento umano abbastanza da giustificare la spesa aggiuntiva, senza presumere che il nome Pro garantisca quel risultato.

In entrambi i casi, il flusso di lavoro deve mantenere la revisione umana quando il rischio della modifica lo richiede. Se entrambi i modelli producono spesso patch da correggere, o se i test disponibili non consentono di verificare il comportamento, la conclusione ragionevole può essere che nessuno dei due soddisfa i criteri di automazione per quella categoria di attività. La decisione può anche essere ibrida, purché l’instradamento tra modelli venga misurato e non si dia per scontato che scegliere in base alla difficoltà migliori il risultato.

Materiali per riprodurre la prova e limiti delle conclusioni

Un confronto destinato a orientare una decisione ingegneristica dovrebbe pubblicare protocollo, attività incluse, commit di base, configurazione di ciascun modello, limiti e rubrica di accettazione. Quando autorizzazioni e licenze lo consentono, è utile fornire anche le patch, i registri anonimizzati, i risultati dei test e i motivi di rifiuto. Esclusioni e tentativi falliti fanno parte delle prove, non sono dettagli secondari.

L’harness può basarsi su pratiche di valutazione riproducibili, come l’esecuzione delle patch in ambienti isolati e il controllo dell’applicazione delle modifiche. La documentazione dell’harness di SWE-bench descrive un approccio che usa ambienti Docker per eseguire e valutare le attività. È un riferimento metodologico; non significa che l’uso di quell’harness garantisca, da solo, che la prova rappresenti il flusso di lavoro di un’azienda.

I risultati sosterranno conclusioni solo sui modelli, sulle versioni, sulle attività, sulla configurazione e sulla data documentati. Non consentiranno di dedurre automaticamente il comportamento di altri prodotti Google, di altre versioni o di altri fornitori. Non sostituiscono neppure la valutazione su repository privati, con le regole di sicurezza e revisione proprie di ciascun team. Alla domanda «quando vale la pena pagare di più per un’attività risolta?» si può rispondere solo dopo aver definito che cosa conta come attività risolta e aver misurato il costo completo nel contesto pertinente.

Per ora, la risposta editoriale più rigorosa non è un vincitore, ma una condizione per decidere: confrontare entrambi i modelli su attività congelate, con accettazione alla cieca, limiti comuni di spesa e tempo e pubblicazione dell’incertezza. Se i dati mostrano differenze consistenti e utili per il profilo del team, sarà possibile raccomandare un’opzione per quell’uso. In caso contrario, sarà più corretto dichiarare che le prove disponibili non consentono di distinguerli.

Continua a esplorare

Correzioni e trasparenza

Se trovi un dato errato o non aggiornato, inviaci la pagina e la fonte da verificare.