AI e matematica, Bun in Rust, Claude Opus 4.8

In sintesi: in poche settimane l'AI ha chiuso una congettura matematica aperta dal 1968, ha riscritto da zero un runtime JavaScript da un milione di righe e ha ricevuto un nuovo modello di punta pensato per orchestrare centinaia di agenti in parallelo. Il filo che unisce le tre notizie non è la potenza dei modelli: è la verifica. Ogni risultato conta perché qualcuno — o qualcosa — ha potuto controllarlo riga per riga.

Le 3 notizie in 30 secondi

Un prompt, sessant'anni di attesa. Liam Price, 23 anni e nessuna formazione avanzata in matematica, ha inserito il problema di Erdős #1196 in GPT-5.4 Pro. Ottanta minuti dopo aveva una dimostrazione, poi formalizzata in Lean e ripresa in un paper con Terence Tao tra gli autori.
Bun è stato riscritto in Rust dall'AI. Il runtime JavaScript alternativo a Node è passato da Zig a Rust con una migrazione guidata da agenti: circa 750.000 righe di Rust, undici giorni dal primo commit al merge, suite di test superata. Oggi è disponibile nel canale canary.
Anthropic ha rilasciato Claude Opus 4.8. A 41 giorni da Opus 4.7, con una nuova feature in Claude Code, i dynamic workflows, che permette di distribuire un singolo task su centinaia di subagent in parallelo.

1. Un problema da sessant'anni, zero lauree, un prompt

Il 13 aprile 2026 Liam Price, 23 anni, senza formazione accademica avanzata in matematica, ha fatto una cosa che fa in modo abbastanza casuale: ha preso uno dei problemi di Erdős, congetture lasciate aperte dal matematico Paul Erdős, e l'ha incollato in GPT-5.4 Pro. Un prompt, nessun contesto aggiuntivo.

Il problema era il #1196, una congettura di Erdős, Sárközy e Szemerédi sugli insiemi primitivi: insiemi di interi in cui nessun elemento divide un altro. La domanda era se, per insiemi composti solo da numeri grandi, una certa somma restasse sotto 1. Il miglior risultato precedente, di Jared Duker Lichtman nel 2023, si fermava a circa 1,399: un margine del 40% che nessuno riusciva a chiudere.

Il modello ha ragionato per circa ottanta minuti e ha prodotto una dimostrazione, che Price ha pubblicato sul forum di erdosproblems.com. Da lì la catena si è messa in moto: un altro utente ha capito che era qualcosa di serio, e la cosa è arrivata sul tavolo dei matematici di professione.

Perché è diverso dalle altre "AI risolve la matematica"

Le notizie su AI e problemi di Erdős circolano da mesi, e gli esperti avvertono che questi problemi sono un benchmark imperfetto: variano enormemente in difficoltà e importanza, e molte soluzioni prodotte dall'AI si sono rivelate meno originali di quanto sembrassero. Questo caso è diverso per due motivi.

Il primo è il metodo. La mossa decisiva non era una tecnica nuova, ma un accostamento inedito: catene di Markov con pesi basati sulla funzione di von Mangoldt, un approccio che sembra essere sfuggito alla letteratura precedente sin dal lavoro seminale di Erdős del 1935. Roba che esisteva, applicata dove nessuno l'aveva mai messa. Il metodo si è poi rivelato utile su tutta una famiglia di problemi, permettendo di dimostrare anche il #1217 e di dare una prova breve della Erdős Primitive Set Conjecture (#164).

Il secondo è la verifica. La dimostrazione è stata formalizzata in Lean, l'assistente di prova che obbliga a giustificare ogni singolo passaggio logico: se c'è un buco nel ragionamento, Lean rifiuta la prova. Non c'è spazio per le mani avanti. Oggi la scheda ufficiale del problema attribuisce la soluzione a GPT-5.4 Pro (su prompt di Price) e rimanda al paper firmato da Alexeev, Barreto, Li, Lichtman, Price, Shah, Tang e Tao.

Ed è qui il punto che in pochi raccontano. Un LLM è indeterministico: stesso prompt, risposte diverse. Genera output plausibili, non output garantiti. Lo stesso Tao ha messo in guardia sul rischio di survivor bias: migliaia di tentativi vengono lanciati su questi problemi, ma vengono riportati praticamente solo quelli riusciti. La svolta non è che l'AI risolve problemi difficili. È che ora esiste un'infrastruttura per sapere quando ha ragione.

2. Bun è stato completamente riscritto in Rust dall'AI

Seconda notizia, stesso schema: output enorme, verifica come discriminante.

Bun è un runtime JavaScript ad alte prestazioni, alternativa a Node.js, entrato nell'orbita Anthropic a fine 2025. Era scritto in Zig. Non lo è più.

Il 14 maggio 2026 la PR #30412, intitolata "Rewrite Bun in Rust", è stata unita al branch main di oven-sh/bun: 6.755 commit, 2.188 file modificati, oltre un milione di righe aggiunte, partendo da un branch chiamato claude/phase-a-port. Il nome del branch dice tutto su chi ha scritto il codice.

I numeri della migrazione: circa 750.000 righe di Rust, 99,8% della suite di test preesistente superata, undici giorni dal primo commit al merge. Centinaia di agenti hanno lavorato in parallelo, con due revisori assegnati a ogni file.

Cosa è, e cosa non è

Sumner è stato esplicito nella PR: la riscrittura supera la suite di test preesistente su tutte le piattaforme, corregge diversi memory leak e test instabili, il binario si riduce di 3-8 MB e i benchmark vanno da neutri a più veloci. L'architettura resta la stessa, le strutture dati le stesse, nessun async Rust. La motivazione principale, per Sumner, non è la performance ma la memory safety: avere un compilatore che intercetta una classe di bug che al team è costata anni di debugging.

Non è quindi un redesign: è un porting fedele su larghissima scala, il tipo di lavoro dove la ripetitività premia gli agenti e la correttezza è misurabile con i test. E la verifica non è stata solo automatica: la PR mostra le tracce di review di bot diversi (un'AI che genera, un'altra AI che controlla) mentre regressioni fuori dal perimetro dei benchmark, comportamenti platform-specific e manutenibilità a lungo termine restano da valutare con occhi umani.

Al momento la build Rust è disponibile solo nel canale canary, in attesa che atterrino le PR di ottimizzazione e pulizia rimanenti: un bun upgrade --canary per provarla. L'arrivo nel canale stabile è previsto con la versione 1.4.0.

3. Claude Opus 4.8 e i dynamic workflows

Terza notizia, e chiude il cerchio: la migrazione di Bun è il caso d'uso che Anthropic ha portato come prova del suo nuovo strumento.

Anthropic ha rilasciato Claude Opus 4.8 il 28 maggio 2026, ad appena 41 giorni da Opus 4.7. Il model id è claude-opus-4-8, il prezzo è invariato rispetto a 4.7, ed è disponibile su tutti i piani a pagamento oltre che su API, Amazon Bedrock, Google Vertex AI e Microsoft Foundry.

I benchmark migliorano quasi su tutta la linea, ma il dato più interessante è un altro: Opus 4.8 ha una probabilità circa 4 volte inferiore rispetto a 4.7 di lasciar passare senza segnalarlo un difetto nel codice che ha scritto, ed è più disposto a dichiarare le proprie incertezze. Per lavoro che gira senza supervisione, questo conta più di qualunque punteggio.

Dynamic workflows: centinaia di agenti su un solo task

La feature che cambia le cose operativamente è nel Claude Code. I dynamic workflows permettono a Claude di pianificare un lavoro e poi eseguirlo distribuendolo su decine o centinaia di subagent paralleli in una sola sessione, con la verifica integrata nel processo, così che i risultati vengano controllati prima di arrivare all'utente. Il tetto è di 1.000 subagent.

Due avvertenze, dette da Anthropic stessa. La prima: i dynamic workflows consumano molti più token di una sessione tipica, e la raccomandazione è di partire da task circoscritti per calibrare il consumo prima di lanciarli su un intero codebase. La seconda: sono sconsigliati dove serve comportamento deterministico. Sul piano dei controlli, la feature è attiva di default su Max, Team e API, mentre su Enterprise è disattivata e va abilitata da un amministratore.

Nell'annuncio è comparso anche il riferimento ai modelli di classe Mythos, la fascia sopra Opus: Anthropic ha dichiarato che i modelli Mythos-class richiedono ancora safeguard aggiuntivi prima di un rollout più ampio. A inizio giugno sono arrivati Claude Fable 5 e Claude Mythos 5, con l'accesso sospeso pochi giorni dopo per conformarsi a controlli sull'export del Dipartimento del Commercio USA: segno di quanto la capacità in ambito cybersecurity sia diventata il vero collo di bottiglia normativo di questa generazione di modelli.

Il filo rosso: generare è facile, verificare è tutto

Tre notizie diverse, una sola lezione operativa.

Una prova matematica passata da Lean. Un milione di righe di Rust validate da una suite di test e da revisori incrociati. Un modello progettato per dichiarare quando non è sicuro. In tutti e tre i casi il valore non sta nell'output dell'AI: sta nel sistema che permette di fidarsi di quell'output.

Usare bene l'AI non significa usarla tanto. Significa costruire il perimetro dentro cui il suo lavoro è controllabile: test, tipizzazione, verifica formale, review adversariale, criteri di accettazione espliciti. Chi ha già quel perimetro moltiplica. Chi non lo ha accumula debito tecnico a velocità inedita.

Domande frequenti

Chi ha risolto il problema di Erdős #1196? La dimostrazione è stata prodotta da GPT-5.4 Pro su prompt di Liam Price, 23 anni, senza formazione avanzata in matematica, il 13 aprile 2026. La scheda ufficiale su erdosproblems.com attribuisce la soluzione al modello, indicando Price come autore del prompt. Il risultato è stato poi ripreso in un paper con otto autori, tra cui Terence Tao.

Quanto tempo ha impiegato l'AI a risolverlo? Circa ottanta minuti di ragionamento, a partire da un singolo prompt.

Come si verifica una dimostrazione prodotta da un LLM? Con un assistente di prova come Lean, che controlla ogni passaggio logico in modo automatico e rifiuta la dimostrazione se trova un salto non giustificato, e con la revisione di matematici umani. Nel caso del #1196 sono state usate entrambe le strade.

Bun è già in Rust nella versione stabile? No. La riscrittura è stata unita al branch main il 14 maggio 2026 ed è provabile via canale canary (bun upgrade --canary). L'arrivo nel canale stabile è atteso con la 1.4.0, dopo le PR di ottimizzazione e pulizia.

Perché riscrivere Bun da Zig a Rust? La motivazione dichiarata da Jarred Sumner è la memory safety: avere strumenti assistiti dal compilatore per prevenire una classe di bug che era costata al team molto tempo di debugging. Il binario è inoltre più piccolo di 3-8 MB e i benchmark risultano neutri o migliori.

Cosa sono i dynamic workflows di Claude Code? Una funzione che permette a Claude di pianificare un task complesso e distribuirlo su decine o centinaia di subagent paralleli (fino a 1.000) in un'unica sessione, con verifica integrata. Consumano molti più token di una sessione normale.

Claude Opus 4.8 costa più di Opus 4.7? No, il prezzo base è rimasto invariato. La modalità fast è inoltre più veloce e, su 4.8, sensibilmente più economica rispetto alle versioni precedenti.

Queste notizie significano che l'AI può sostituire matematici e sviluppatori? Nessuno dei tre casi lo suggerisce. In tutti e tre il risultato è diventato utilizzabile solo grazie a un livello di verifica (formale, automatica o umana) costruito attorno all'output del modello. Il lavoro si sposta dalla produzione alla progettazione dei controlli.