L'automazione delle prove in Lean ha appena superato un vero test software, ma la prova non è pronta per la produzione

L'automazione delle prove in Lean ha oltrepassato una soglia importante il 26 luglio, pur restando ben lontana da una release software pronta per la produzione. L'ingegnere della sicurezza Adam Langley ha realizzato in Lean un decompressore Zstandard funzionante, quindi ha usato diversi modelli linguistici di grandi dimensioni per generare prove verificate dalla macchina per la sua logica più complessa.

L'esperimento non ha prodotto un decompressore più veloce, una libreria pubblicata né dimostrazioni del fatto che l'AI possa verificare qualsiasi grande applicazione. Langley afferma che la sua versione funziona circa dieci volte più lentamente del comando standard zstd. Descrive inoltre l'implementazione come un progetto di apprendimento e ha scelto di non pubblicarne il codice.

Il cambiamento è più circoscritto, ma più rilevante. Un sistema di AI ha prodotto prove per software non banale, mentre Lean ha verificato indipendentemente se tali prove fossero valide. Questo porta la verifica assistita dall'AI oltre le spiegazioni fluide e il codice plausibile, in un flusso di lavoro con un test di accettazione insolitamente rigoroso.

La competizione principale non è più tra codice generato dall'AI e codice scritto da esseri umani. È tra generazione probabilistica e verifica deterministica. Il modello può tentare, correggersi e fallire ripetutamente, mentre un piccolo verificatore affidabile decide cosa entra nel programma finale.

Per gli sviluppatori, questo modello offre una possibile risposta agli agenti di coding inaffidabili. Per i knowledge worker, suggerisce un modello più ampio per l'automazione: lasciare che l'AI produca il primo tentativo disordinato, ma subordinare l'accettazione a condizioni esplicite e verificabili dalla macchina.

L'esperimento su Zstandard ha reso concreta l'automazione delle prove

Il test di Langley è importante perché ha applicato prove generate dall'AI a un normale software di sistema, non a un altro benchmark matematico isolato.

Lean è sia un linguaggio di programmazione sia un dimostratore interattivo di teoremi. I suoi tipi dipendenti consentono ai tipi di un programma di includere fatti sui valori, come la lunghezza esatta di un array o una relazione tra più output.

Questa capacità cambia ciò che la firma di una funzione può garantire. Una normale funzione di lettura file potrebbe restituire un array di byte. Una funzione Lean può restituire un array accompagnato da una prova che la sua lunghezza corrisponde al numero richiesto di byte.

Il riferimento ufficiale di Lean spiega perché questa architettura ha un valore insolito per il lavoro generato dall'AI. Le tattiche di Lean possono essere complesse e automatizzate, ma ogni termine di prova che producono passa attraverso un kernel relativamente piccolo.

Una tattica difettosa può far perdere tempo o generare un candidato non valido. Non può rendere valida una prova invalida, a meno che anche la base affidabile non contenga un difetto. Il verificatore, anziché il generatore, rimane l'autorità finale.

Langley ha scelto Zstandard perché offriva una sfida implementativa significativa. Zstandard, di solito chiamato zstd, è un formato di compressione senza perdita basato su corrispondenze in stile LZ77 e su due sistemi di codifica entropica.

La sua specifica di formato assegna la codifica Huffman ai dati letterali e l'entropia a stati finiti, o FSE, agli altri simboli e agli header Huffman. FSE usa uno stato trasportato tra i simboli, il che richiede di decodificare i flussi di bit nell'ordine inverso rispetto alla scrittura.

Questo meccanismo è molto più impegnativo che dimostrare l'uguaglianza tra due brevi espressioni aritmetiche. Un decompressore deve analizzare strutture binarie compatte, mantenere lo stato, rifiutare input non validi e ricostruire correttamente i byte originali.

L'esperimento Lean di Langley si è concentrato in particolare sulla costruzione della tabella FSE. La tabella determina come gli stati compressi riconducano ai simboli e quanti bit il decoder consuma.

Secondo quanto riferito, diversi LLM hanno generato in circa 20 minuti una prova di una proprietà importante del codice che costruisce tale tabella. Langley ha verificato che le prove risultanti superassero il type checker di Lean e non contenessero dichiarazioni sorry, il meccanismo di Lean per ammettere temporaneamente un'affermazione non dimostrata.

I modelli hanno però dovuto modificare alcune scelte implementative. Langley aveva usato Id.run per esprimere porzioni dell'algoritmo in uno stile più imperativo, rendendo più difficile l'uso del meccanismo delle prove.

Questo dettaglio impedisce una lettura semplicistica del risultato. L'AI non si è limitata a esaminare codice immutabile e ad allegarvi un certificato. Ha contribuito a rimodellare l'implementazione in una forma che favorisse la costruzione delle prove.

Tuttavia, il risultato ha creato un ciclo completo: scrivere software significativo, enunciare un invariante forte, generare una prova e chiedere a un kernel indipendente di accettarla o rifiutarla. È questo ciclo il vero evento.

L'automazione delle prove in Lean affronta il problema dei costi della verifica

La verifica formale ha già fornito garanzie eccezionali, ma il lavoro richiesto per le prove l'ha tenuta fuori dalla maggior parte dei progetti software quotidiani.

L'esempio storico più chiaro è seL4, un piccolo kernel di sistema operativo supportato da prove verificate dalla macchina. Le sue proprietà verificate coprono molto più del superamento di test su una selezione di input.

La verifica originale ha richiesto circa 20 anni-persona distribuiti su quattro anni e ha prodotto oltre 200.000 righe di script di prova Isabelle. Una retrospettiva descritta nella ricerca su seL4 mostra perché questi numeri non possano essere liquidati come eccessi accademici.

I team di verifica devono definire le proprietà corrette, collegare diversi livelli di astrazione, costruire prove e mantenere tali prove allineate al codice che cambia. Ogni attività richiede conoscenze specialistiche e un'ingegneria accurata.

Il ritorno può essere sostanziale. Il progetto seL4 riferisce di non aver riscontrato difetti di correttezza funzionale nel codice verificato da quando la sua prova principale è stata completata nel 2009. Tuttavia, la maggior parte dei team software non può investire anni di lavoro specialistico prima di rilasciare un singolo componente.

L'automazione tradizionale delle prove riduce parte di questo onere. Le tattiche possono risolvere schemi familiari, mentre i solver di soddisfacibilità modulo teorie, noti come solver SMT, risolvono condizioni logiche nei domini supportati.

Questi sistemi influenzano anche il modo in cui i programmatori scrivono codice verificato. Gli utenti esperti imparano quali formulazioni un solver può gestire e quali strutture apparentemente innocue fanno espandere la ricerca in modo incontrollabile.

Langley sostiene che gli LLM cambino questa equazione economica perché sono generatori di prove flessibili. Possono leggere le definizioni circostanti, esaminare messaggi di errore, riscrivere codice locale, proporre lemmi intermedi e tentare un'altra strada dopo un rifiuto.

L'irrilevanza delle prove rafforza questa tesi. In Lean, le proposizioni vivono in un universo proof-irrelevant, il che significa che il sistema si interessa generalmente al fatto che esista una prova valida, non a quale prova valida sia stata fornita.

Un ingegnere umano delle prove spesso dà valore all'eleganza, perché una prova chiara può sopravvivere più facilmente a modifiche successive. Se un LLM può rigenerare rapidamente una prova verificata, parte di questo calcolo di manutenzione cambia.

Questo non elimina l'ingegneria delle prove. Qualcuno deve ancora enunciare il teorema corretto, definire il confine affidabile e decidere se la rigenerazione dopo ogni modifica rimanga sostenibile.

Indebolisce però una delle principali obiezioni. Il codice generato, seppur brutto, è pericoloso quando gli sviluppatori non possono valutarne con sicurezza il comportamento. Una prova generata, seppur brutta, è meno preoccupante quando un kernel affidabile rifiuta ogni versione non valida.

Il flusso di lavoro emergente assomiglia più alla compilazione che al ragionamento collaborativo. Gli sviluppatori specificano la proprietà, un agente cerca un artefatto accettabile e il verificatore determina se la build ha successo.

Questa differenza conta per i manager che devono decidere dove collocare l'AI. Un assistente di coding che afferma che una funzione è sicura fornisce un'opinione. Un assistente che produce prove e restituisce un artefatto verificato dal kernel fornisce evidenza entro ipotesi dichiarate.

La distinzione mette anche in luce il nuovo collo di bottiglia. Se la generazione delle prove diventa economica, scrivere la specifica corretta diventa la competenza scarsa.

I team avranno bisogno di persone capaci di tradurre i requisiti in invarianti precisi. “Questo parser dovrebbe essere sicuro” non è verificabile. “Ogni parsing riuscito resta entro il buffer di input fornito” è più vicino a una proprietà che un sistema formale può valutare.

Per i knowledge worker, il compito equivalente consiste nel definire le condizioni di accettazione prima che inizi l'automazione. L'AI può redigere una previsione, riconciliare una policy o unire gli appunti di una riunione, ma un'automazione affidabile richiede una chiara definizione di ciò che deve restare vero.

Il nuovo avversario è la generazione senza verifica

La lezione più importante non è che gli LLM siano diventati affidabili, ma che la generazione inaffidabile può diventare utile all'interno di un ciclo di verifica affidabile.

La maggior parte dei prodotti di AI generativa chiede agli utenti di giudicare direttamente gli output. Un modello scrive un'email, riassume una riunione, modifica un foglio di calcolo o propone codice. L'essere umano cerca poi errori sottili con tempo e attenzione limitati.

Questo schema rende l'automazione attraente per lavori a basso rischio, ma difficile da fidare per sicurezza, finanza, conformità, infrastrutture e modifiche operative irreversibili. La sicurezza mostrata dal modello offre poca protezione, perché un linguaggio fluido non dimostra la correttezza.

L'automazione delle prove in Lean separa due compiti. L'LLM esplora un ampio spazio di possibili prove, mentre l'assistente di prova esegue un compito di verifica ristretto con regole esatte.

Il generatore può allucinare il nome di un teorema, applicare una trasformazione non valida o fraintendere una definizione. Questi fallimenti diventano candidati rifiutati anziché conclusioni accettate, a condizione che la proprietà dichiarata e il confine affidabile siano solidi.

Ricerche recenti indicano sistemi costruiti attorno a questa separazione. OpenProver, pubblicato nel luglio 2026, combina pianificazione, agenti worker e verifica Lean in un sistema open-source per la dimostrazione di teoremi.

La sua architettura assegna responsabilità diverse ad agenti specializzati, mantenendo al contempo il controllo formale automatico. Supporta inoltre la guida umana, riconoscendo che la ricerca delle prove trae ancora beneficio dalla direzione di esperti.

È un modello di prodotto diverso da quello di un chatbot con una finestra per il codice. L'output di valore non è la spiegazione del modello sul perché una prova dovrebbe funzionare. È l'oggetto di prova che supera una verifica indipendente.

Un modello analogo può migliorare il normale lavoro della conoscenza anche quando la dimostrazione formale completa non è necessaria. Si consideri un product manager che prepara un aggiornamento settimanale a partire da interviste, ticket, metriche e decisioni.

Un LLM può redigere rapidamente l'aggiornamento. Tuttavia, ogni affermazione fattuale dovrebbe restare riconducibile a una fonte, ogni metrica dovrebbe mantenere data e definizione e le contraddizioni irrisolte dovrebbero rimanere visibili.

Un sistema personale di gestione della conoscenza può contribuire a preservare questi collegamenti. Per esempio, il knowledge blending può riunire materiale locale correlato in un unico contesto di lavoro, anziché costringere l'utente a ricostruirlo da file sparsi.

Non è la stessa cosa di una prova matematica. Il verificatore può consistere in citazioni delle fonti, validazione dello schema, controlli di accesso, test aritmetici o un passaggio di approvazione umana.

Il principio architetturale resta simile. La libertà generativa appartiene alla fase precedente al controllo. Regole deterministiche, evidenze documentate o una revisione responsabile decidono cosa lo supera.

Questo cambia anche il modo in cui i team dovrebbero valutare la produttività dell'AI. Il tempo risparmiato durante la stesura è solo una metrica. Tempo di revisione, frequenza delle correzioni, tasso di difetti sfuggiti e qualità delle evidenze a supporto contano altrettanto.

Un agente che prepara bozze dieci volte più velocemente ma raddoppia lo sforzo di revisione non ha automatizzato il compito. Ha trasferito il lavoro in una fase meno visibile.

Al contrario, un agente che produce un primo risultato più lento ma con provenienza completa e validazione automatica può offrire una produttività più utile. Le evidenze riducono l’incertezza per ogni lettore a valle.

Lean rende questo principio insolitamente evidente perché la condizione di accettazione è binaria. La prova viene verificata oppure no. La maggior parte dell’automazione d’ufficio non dispone di un confine così netto, ma i team possono creare controlli più piccoli e specifici per ogni attività.

Un riepilogo finanziario può richiedere che ogni totale sia riconciliato con le celle di origine. Un confronto contrattuale può richiedere che ogni differenza segnalata rimandi alle clausole esatte. Un brief di ricerca può impedire che citazioni non supportate entrino nel documento finale.

Questi controlli non rendono il modello sottostante onesto o deterministico. Rendono più facile contenere le sue debolezze.

Cosa non dimostra il test su Zstandard

L’esperimento convalida un meccanismo promettente, ma non dimostra che l’AI possa verificare sistemi di produzione di grandi dimensioni in modo economico o completo.

La limitazione più evidente è l’ambito. Langley definisce il decompressore un giocattolo, afferma che il codice non è pubblicato e non lo presenta come modello esemplare per altri programmatori Lean.

Questo impedisce a revisori indipendenti di riprodurre il risultato, esaminare gli enunciati precisi dei teoremi o identificare componenti non verificati. Sappiamo, sulla base del resoconto dell’autore, che alcune prove selezionate hanno superato il type-checking.

Non sappiamo se tali enunciati coprano ogni proprietà richiesta a un decompressore di produzione. Una prova perfettamente valida di una specifica incompleta può coesistere con gravi difetti al di fuori di quella specifica.

Questo viene spesso chiamato il problema della specifica. Il verificatore può stabilire che il codice soddisfa un enunciato formale, ma non può decidere se gli esseri umani abbiano scelto l’enunciato corretto.

Un decompressore potrebbe dimostrare che gli input validi effettuano correttamente il round-trip, lasciando però al di fuori del teorema l’esaurimento della memoria, il comportamento in caso di denial-of-service, i limiti delle risorse o il parsing degli archivi. Ogni confine omesso crea spazio per il fallimento.

Anche la base di calcolo fidata è importante. Il piccolo kernel di Lean riduce drasticamente i componenti di cui bisogna fidarsi, ma i programmi reali interagiscono con compilatori, sistemi operativi, funzioni esterne, hardware e librerie esterne.

Langley ha esplorato la possibilità di chiamare assembly ottimizzato tramite il meccanismo extern di Lean. Piccoli esempi di equivalenza hanno funzionato, ma i tentativi di scalare l’approccio avrebbero incontrato requisiti di memoria severi o non sarebbero riusciti a progredire.

Questo risultato evidenzia un compromesso centrale. Il codice verificato ad alto livello può offrire solide garanzie logiche, mentre le prestazioni in produzione dipendono spesso da implementazioni e strumenti a basso livello che vanno oltre la prova immediata.

La stessa implementazione di Zstandard illustra il divario. Langley riferisce che il suo decoder Lean è circa dieci volte più lento dell’implementazione standard da riga di comando.

Le prestazioni non sono una preoccupazione marginale per il software di compressione. La decompressione si trova spesso su un percorso sensibile alla latenza che coinvolge archiviazione, distribuzione di pacchetti, database o trasferimento di rete.

Anche la manutenzione delle prove resta incerta. Langley suggerisce che una rigenerazione rapida potrebbe ridurre la necessità di progettare con cura le prove per le modifiche future.

Ciò è plausibile per un progetto circoscritto. Un codebase di grandi dimensioni può creare migliaia di obblighi interdipendenti, in cui una piccola modifica ai tipi si propaga tra i moduli e supera il contesto o il budget di ricerca di un agente.

I benchmark di ricerca non dovrebbero risolvere da soli questa questione. Le raccolte di teoremi matematici di solito forniscono obiettivi espliciti e ambienti controllati. Il codice di produzione include specifiche parziali, interfacce legacy, dipendenze in evoluzione e ipotesi non documentate.

Esiste anche un rischio legato al fattore umano. La generazione facile di prove può creare pressione a trattare qualsiasi controllo verde come una garanzia completa.

Un teorema verificato afferma esattamente ciò che dice il suo enunciato formale. Non offre alcuna garanzia su sicurezza, privacy, affidabilità o correttezza aziendale, a meno che tali proprietà non compaiano nel modello.

I team devono quindi sottoporre le specifiche a revisione con la stessa serietà oggi riservata alla revisione del codice. Altrimenti, l’AI accelererà la produzione di risposte convincenti a domande incomplete.

L’automazione delle prove con l’AI sposta il collo di bottiglia sulle specifiche

Se i modelli diventano generatori di prove competenti, il lavoro della conoscenza di valore si sposta dalla costruzione degli artefatti alla definizione di affermazioni e confini.

I team software hanno già sperimentato una versione di questa transizione. Gli agenti di coding riducono il costo di produrre funzioni, test, migrazioni e documentazione.

Man mano che l’output diventa più economico, decidere cosa costruire diventa più importante. Requisiti, interfacce, vincoli, modelli di minaccia e test di accettazione determinano se la generazione rapida crea valore oppure produce semplicemente altro materiale da ispezionare.

Lean estende questo cambiamento alle affermazioni di correttezza. Un programmatore può codificare un invariante in un tipo, chiedere a un LLM di costruire la prova e lasciare che il kernel verifichi il risultato.

Il contributo umano a maggiore leva è spesso a monte. Qualcuno deve riconoscere quale invariante conta, esprimerlo senza scappatoie e collegarlo al reale ambiente operativo.

I lavoratori della conoscenza affrontano la stessa struttura con strumenti meno formali. Un analista deve decidere quali evidenze siano valide per sostenere un’affermazione di mercato. Un recruiter deve definire quali criteri per i candidati siano legali e pertinenti.

Un responsabile dell’assistenza deve specificare quando è possibile inviare una risposta automatica e quando un caso richiede escalation. Un ricercatore deve distinguere tra una fonte diretta, un riepilogo secondario e un’inferenza non supportata.

Sono attività di specifica, anche quando nessuno le scrive in Lean. Trasformano aspettative vaghe in condizioni osservabili.

Le organizzazioni possono prepararsi registrando le regole decisionali accanto ai documenti che regolano. Una nota che dice “usa il numero più recente di clienti” è ambigua. Una regola che nomina la dashboard autorevole, l’orario di aggiornamento, la regione e il periodo di rendicontazione è verificabile.

La provenienza diventa altrettanto importante. Un modello non può riconciliare in modo affidabile la conoscenza di un team se il materiale sorgente ha perso data, proprietario, versione o relazione con le decisioni precedenti.

Ecco perché il passaggio dalle interfacce di chat ai sistemi di agenti richiede una migliore architettura delle informazioni. Gli agenti necessitano di contesto strutturato, autorizzazioni, regole di validazione e registri duraturi delle modifiche apportate.

Anche la revisione umana dovrebbe spostarsi verso le eccezioni. Se ogni affermazione generata dall’AI richiede un’ispezione riga per riga, il sistema resta un assistente anziché un livello di automazione.

Controlli utili possono approvare automaticamente i casi ordinari che soddisfano condizioni esplicite. Gli esseri umani si concentrano quindi su evidenze mancanti, fonti contraddittorie, valori insoliti, azioni sensibili alla sicurezza e modifiche al di fuori dei modelli noti.

Gli assistenti di prova formale offrono la versione più forte di questo flusso di lavoro, ma non sono adatti a ogni attività. Molte decisioni dipendono dal giudizio, da definizioni controverse o da informazioni incomplete.

L’obiettivo non è formalizzare ogni email. È identificare le affermazioni il cui fallimento comporta un costo reale e costruire intorno a esse controlli proporzionati.

Per il software, ciò potrebbe significare dimostrare la sicurezza dei limiti in un parser, testando convenzionalmente l’interfaccia utente. Per un team operativo, potrebbe significare riconciliare automaticamente i totali dei pagamenti, richiedendo al contempo l’approvazione umana per i trasferimenti.

Per i ricercatori, potrebbe significare validare ogni citazione e passaggio citato, lasciando invece l’interpretazione aperta al dibattito. La verifica dovrebbe proteggere il confine più importante.

L’esperimento di Langley rende più facile immaginare questa strategia progettuale. L’LLM non doveva diventare un matematico infallibile. Doveva generare un artefatto che un sistema più rigoroso potesse valutare.

Questa è una strada più realistica per l’AI aziendale che aspettare che i modelli smettano di commettere errori.

Tre segnali mostreranno se il cambiamento è reale

La fase successiva dipende da riproducibilità, scala e costo di manutenzione misurabile, piuttosto che da un’altra impressionante prova isolata.

Il primo segnale è un corpus pubblicato e riproducibile di software verificato ordinario. Il decompressore di Langley non può svolgere questo ruolo perché il codice sorgente e le prove non sono disponibili.

Progetti come lean-zip offrono un riferimento più ispezionabile. Il co-creatore di Lean Leonardo de Moura lo ha recentemente evidenziato come progetto di compressione verificato che implementa sia la compressione sia la decompressione.

I progetti futuri necessitano di enunciati precisi dei teoremi, ipotesi documentate, misurazioni delle prestazioni e test rispetto a implementazioni consolidate. Team indipendenti dovrebbero poter ricostruire ogni prova e identificare quali moduli restano al di fuori del confine verificato.

Se più progetti ripetono il modello su parser, codice di rete, formati di archiviazione e supporto crittografico, l’argomentazione a favore dell’automazione delle prove con Lean diventa più solida. Se i risultati restano concentrati in piccole dimostrazioni, l’affermazione più ampia si indebolisce.

Il secondo segnale è il comportamento della generazione delle prove dopo modifiche al codice reale. La costruzione iniziale della prova attira l’attenzione, ma è la manutenzione a determinare se l’economia funziona.

I team dovrebbero misurare il tempo di rigenerazione dopo refactoring, aggiornamenti delle dipendenze, modifiche alle specifiche e ottimizzazioni delle prestazioni. Dovrebbero inoltre registrare quanto spesso un esperto umano debba ristrutturare il codice o inventare lemmi intermedi.

Un successo rapido su un teorema stabile offre evidenze limitate su un’applicazione viva. Un sistema utile deve sopravvivere a mesi di sviluppo ordinario senza trasformare ogni pull request in un progetto imprevedibile di ricerca della prova.

Se i costi delle prove restano limitati e i fallimenti producono diagnosi utilizzabili, la verifica generata dall’AI può entrare nell’integrazione continua. Se piccole modifiche innescano ore di ricerca opaca, l’adozione resterà limitata.

Il terzo segnale è l’integrazione negli agenti di coding mainstream. Attualmente la generazione delle prove si colloca vicino ai flussi di lavoro di ricerca e agli ambienti Lean specializzati.

Il punto di flessione pratico arriva quando un agente può proporre un invariante, spiegarne l’ambito, generare la prova, eseguire il verificatore e mostrare esattamente quali ipotesi restano non verificate.

Questa interfaccia deve contrastare la falsa fiducia. Dovrebbe distinguere il comportamento testato da quello dimostrato e i moduli verificati dai wrapper non verificati.

Dovrebbe inoltre rendere altamente visibili le modifiche ai teoremi. Un agente non deve mai “risolvere” una prova fallita indebolendo silenziosamente la proprietà che gli utenti si aspettavano di preservare.

Per i lavoratori della conoscenza, questi segnali si traducono in un semplice test di approvvigionamento. Chiedete se un prodotto AI genera risposte oppure produce risposte con condizioni di accettazione applicabili.

Cercate provenienza a livello di fonte, controlli delle autorizzazioni, validazione strutturata, trasformazioni riproducibili e chiari percorsi di escalation. Una risposta rifinita senza questi controlli resta una bozza, indipendentemente da quanto suoni sicura.

L’automazione delle prove con Lean non dimostra che ora ci si possa fidare dell’AI da sola. È la prova che la fiducia può essere progettata attorno all’AI quando le affermazioni sono esplicite e la verifica resta indipendente.

La domanda per il prossimo progetto è pratica: quale decisione ricorrente crea un rischio sufficiente da giustificare un vero controllo di accettazione? Partite da lì, definite ciò che deve restare vero e fate sì che l’automazione si guadagni ogni controllo verde.