Un lancio atteso si ferma ai box. Il pubblico guarda, gli addetti ai lavori annuiscono: meglio un ritardo che un passo falso. In mezzo, la sensazione familiare di quando il software promette meraviglie e poi inciampa su una parentesi mancante.
Non capita spesso di vedere una big tech tirare il freno a pochi metri dal traguardo. Eppure, è quello che succede ora: Google rinvia Gemini 3.5 Pro. Non è un colpo di scena hollywoodiano. È più il silenzio di una stanza dove si lavora sodo, di notte, con il caffè freddo accanto alla tastiera. L’azienda, dicono, vuole alzare l’asticella sul coding. E qui, per chi scrive o legge codice, il discorso si fa serio.
All’inizio può sembrare uno stop inspiegabile. Il mercato vuole novità, i concorrenti spingono. E tuttavia, chi si affida all’IA per scrivere funzioni, test e script sa che la magia crolla al primo bug. Un modello che “parla bene” ma “programma così e così” è come un’auto sportiva con i freni spugnosi. Bello l’impianto, ma al primo tornante si suda.
Perché fermarsi adesso conviene
Nei modelli di generazione di codice, la differenza la fanno tre cose concrete: test, sicurezza, manutenzione. I test sono i numeri che contano, dai benchmark pubblici come HumanEval e MBPP alle batterie interne. Non abbiamo dati ufficiali sul rendimento di Gemini 3.5 Pro su queste prove. Mancano percentuali, soglie o tabelle. Sappiamo però come si giudica un sistema serio: guarda il tasso di “pass@1” (quante volte centra la soluzione al primo colpo), il numero di bug evitabili, la percentuale di codice che compila e gira davvero.
La sicurezza è il secondo cardine. La qualità del codice non è solo “funziona o no”. È evitare iniezioni, credenziali hardcoded, dipendenze opache. Anche qui, niente numeri pubblici sul nuovo modello. Ma il problema è noto: un’IA può generare snippet “eleganti” che scivolano su edge case banali. L’esempio tipico? La funzione che ordina una lista e ignora i valori nulli, o quella che prende un input non sanificato e lo passa a una query. Sembra banale, ma in produzione costa caro.
Il terzo pezzo è la manutenzione. Gli sviluppatori chiedono coerenza: stesso stile, stessa struttura, stessi nomi. Vogliono docstring sensate, test unitari inclusi, e refactoring senza sorprese. Un modello che oggi scrive in TypeScript “quasi bene” e domani cambia convenzioni è difficile da integrare in una codebase viva. È qui che un rinvio può fare la differenza.
Cosa aspettarsi al rilancio
Qual è il “pezzo” che Google potrebbe sistemare? Probabile una combinazione di training mirato, esecuzione di codice in sandbox, e “chain-of-thought” più sobria nel debug. In pratica: meno verbosità, più passi verificabili. Aspettiamo funzioni più affidabili su progetti multi-file, citazioni delle fonti quando incorpora pattern esterni, e una gestione più chiara delle licenze open source. Sarebbero passi avanti concreti, non slogan.
Non ci sono date ufficiali per il nuovo rilascio. Non ci sono promesse scritte su pietra. C’è però un’aspettativa realistica: una IA per programmare che non sostituisca il team, ma lo faccia correre meglio. Penso al classico ticket da lunedì mattina: “logica di deduplicazione lenta, mem leak sporadico, test flaky”. L’assistente ideale non spara la soluzione “magica”. Propone una patch piccola, spiega il perché, aggiunge un test. E si prende la responsabilità di fallire in modo chiaro quando non sa.
L’immagine che resta è semplice: un cacciavite ben bilanciato vale più di una cassetta rumorosa. Se il rinvio di Gemini 3.5 Pro serve a consegnare meno rumore e più sostanza, la pausa è benvenuta. Nel frattempo, continuiamo a chiederci: quale riga di codice, domani, vorremmo davvero delegare a una macchina? E quale, invece, preferiamo ancora scrivere a mano, lentamente, con la cura di chi sa dove può nascondersi l’ultimo, minuscolo, errore.