Domenica sera, una formula e la finale dei Mondiali
A tarda sera di domenica 19 luglio 2026 il matematico Levent Alpoge ha pubblicato una singola mappa polinomiale e ha ringraziato due amici: uno per avergli posto la domanda e uno, ha scritto, per aver lavorato durante la finale dei Mondiali. Il secondo amico era Claude Fable 5. Il post riportava l'orario 02:19 UTC del 20 luglio. La formula che conteneva era un controesempio alla congettura di Jacobi, aperta dal 1939.
La mappa porta tre variabili complesse in tre uscite complesse. Il suo determinante jacobiano vale -2, una costante diversa da zero, cioè esattamente la condizione che secondo la congettura avrebbe dovuto garantire un'inversa polinomiale. Quell'inversa non esiste, perché tre ingressi diversi finiscono nello stesso punto: (0, 0, -1/4), (1, -3/2, 13/2) e (-1, 3/2, 13/2) vanno tutti in (-1/4, 0, 0).
Alpoge lavora in Anthropic e ha attribuito al modello la scoperta. Quel riconoscimento è la parte che il settore citerà per il prossimo mese. Non è la parte che conta di più per chi guida un'azienda.
Che cosa scrisse Keller nel 1939
La congettura era una promessa di ricostruibilità. Il matematico tedesco Ott-Heinrich Keller si chiese se una mappa polinomiale il cui determinante jacobiano è una costante diversa da zero debba per forza avere un'inversa che sia a sua volta un polinomio. In parole più semplici: se una trasformazione non fa mai collassare l'informazione a livello locale, in nessun punto, si riesce sempre a ricostruire l'ingresso a partire dall'uscita usando lo stesso tipo di aritmetica usato all'andata.
Per 87 anni si è dato per scontato che la risposta fosse sì e nessuno è riuscito a dimostrarlo. In geometria algebrica era rimasta uno di quei problemi che attirano risultati parziali, casi particolari e, a intervalli, dimostrazioni poi ritirate.
Il controesempio risponde alla domanda dalla dimensione tre in su. Il caso a due variabili resta aperto, e la pull request che ha formalizzato la confutazione lo dice in modo esplicito. È un risultato più limitato della versione dei titoli, e raccontarlo con onestà impone di riportare quella differenza.
La verifica è durata ore perché qualcuno aveva scritto prima la domanda
Nel giro di un giorno Paul Lezeau aveva formalizzato il controesempio nell'assistente di dimostrazione Lean e aveva aperto la pull request 4474 sul repository formal-conjectures di Google DeepMind, intitolata feat: add Jacobian disproof. I revisori l'hanno approvata. Un audit indipendente pubblicato nella stessa discussione ha confermato che la dimostrazione non contiene alcun sorry, alcun native_decide e nessun assioma personalizzato, che è il modo in cui la comunità Lean dice che non si è dato nulla per buono e non si è lasciato passare nulla senza controllo.
La velocità è venuta dalla preparazione, non dal modello. Il repository conteneva già un enunciato formale della congettura di Jacobi, concordato fra persone e messo per iscritto prima che qualcuno avesse un controesempio con cui metterlo alla prova. Come ha scritto il blog dello Xena Project, una volta che le persone concordano sul fatto che l'enunciato formale coglie fedelmente la congettura, controllare se un codice Lean forse generato dall'IA costituisce davvero una dimostrazione o una confutazione è una banalità.
Quella frase va letta due volte. La parte difficile, lenta e umana è avvenuta anni prima, quando qualcuno ha tradotto una frase del 1939 in una forma verificabile a macchina. L'affermazione è arrivata una domenica sera ed era risolta il lunedì perché il test di accettazione esisteva già.
Verificato non vuol dire capito
Lo stesso blog è netto sul limite. Il passo successivo, scrive, è che le persone capiscano esattamente che cosa succede in questo esempio. Una macchina può certificare che i tre punti coincidono. Non è ancora in grado di spiegare a nessuno perché proprio questa mappa, fra tutte, sia stata quella che ha fatto cadere un'ipotesi vecchia di 87 anni. Nemmeno la revisione tra pari su rivista è conclusa, e un preprint di verifica non è una rivista.
E non è nemmeno un episodio isolato. Lo stesso blog conta tre controesempi in tre mesi: la congettura di Erdos sulle distanze unitarie a maggio, una domanda di Grothendieck sugli schemi di gruppi a luglio e ora quella di Keller. Timothy Gowers ha detto che era la prima volta in cui un modello linguistico risolveva un problema noto di cui lui avesse sentito parlare fuori dal proprio ambito. Tre dati sono uno schema che si sta formando, non uno schema dimostrato.
Scrivete il test di accettazione prima di comprare il modello
La lezione trasferibile riguarda il metodo, non la matematica. Quasi tutte le affermazioni sulle capacità dell'IA arrivate sul tavolo di un imprenditore quest'anno erano un punteggio di benchmark pubblicato da chi vende il modello. Questa è arrivata come un oggetto che un estraneo poteva controllare in un pomeriggio, rispetto a un criterio scritto prima che l'affermazione esistesse, con uno strumento che non risponde né al laboratorio né a chi l'affermazione l'ha fatta.
È una specifica che potete copiare. Prima del prossimo acquisto di IA, scrivete il criterio di accettazione in una forma valutabile senza la collaborazione del fornitore: un insieme di test fisso che tenete voi, una regola di punteggio concordata in anticipo, un formato di uscita che uno script sotto il vostro controllo sia in grado di valutare. Se l'unica prova delle prestazioni è un numero calcolato dal fornitore, avete comprato un comunicato stampa.
Tenete la seconda lezione accanto alla prima. Il controesempio è certificato e resta non spiegato, ed è esattamente la forma di gran parte di ciò che l'IA produce dentro un'azienda: corretto in un modo che potete testare, opaco in un modo che non potete verificare. Progettate per la prima cosa e assumete per la seconda.
Da leggere ora: Test indipendenti mettono Kimi K3 sopra Fable 5 | Il modello di punta di Google è in ritardo e senza una nuova data



