Adam Langley afferma che l'automazione delle prove Lean è arrivata. La parte difficile si è solo spostata

Adam Langley afferma che l'automazione delle prove Lean ha superato una soglia pratica dopo che diversi modelli linguistici di grandi dimensioni hanno completato una difficile prova software in circa 20 minuti. L'affermazione contiene un'importante precisazione. L'AI ha generato la prova, ma Lean ne ha verificato ogni passaggio rispetto a una specifica formale.

Questa distinzione separa l'esperimento dall'ennesima storia sull'AI che produce codice plausibile. Langley ha realizzato un decompressore Zstandard in Lean, poi ha chiesto ai modelli di dimostrare proprietà universali della sua tabella di decodifica dell'entropia. Secondo quanto riferito, i modelli hanno concluso senza lacune irrisolte nelle prove, pur modificando anche parti della sua implementazione.

L'esperimento suggerisce un compromesso diverso per i team software. Gli sviluppatori potrebbero dedicare meno tempo a costruire prove e più tempo a decidere con precisione cosa debbano garantire i loro sistemi. Gli assistenti di coding AI generano una risposta e chiedono alle persone di trovare gli errori. Lean ribalta questo rapporto, rifiutando qualsiasi risposta che non soddisfi un'enunciazione verificabile da una macchina.

Questo non dimostra che la verifica formale sia diventata economica, semplice o adatta a ogni applicazione. Langley ha descritto il decompressore come un giocattolo, non ne ha pubblicato il codice sorgente e ne ha misurato le prestazioni a un decimo della velocità del comando standard zstd. Ricerche indipendenti mostrano inoltre che i dimostratori AI faticano quando le prove dipendono da repository grandi e poco familiari.

La conclusione più difendibile resta comunque significativa. L'AI può ora assorbire abbastanza lavoro ripetitivo sulle prove da rendere utile sperimentare la verifica anche al di fuori delle sue nicchie tradizionali. Per i knowledge worker, la lezione più ampia va oltre il software: l'automazione diventa più affidabile quando i criteri di accettazione sono espliciti e verificati in modo indipendente.

Un esperimento su Zstandard ha messo al lavoro l'automazione delle prove Lean

La notizia non è che un'AI abbia scritto un altro programma. È che un lavoro generato dall'AI ha superato un verificatore progettato per respingere gli errori logici.

Langley, ingegnere della sicurezza noto per il suo lavoro su crittografia e infrastrutture Internet, ha pubblicato l'esperimento il 26 luglio 2026. Il suo resoconto sulla proof automation descrive la realizzazione di un decompressore Zstandard in Lean e la formalizzazione di varie proprietà delle sue tabelle di decodifica.

Lean è al tempo stesso un linguaggio di programmazione funzionale e un assistente alla dimostrazione. Un assistente alla dimostrazione verifica se un argomento formale stabilisce una proposizione formulata con precisione. Il piccolo kernel di Lean convalida il termine di prova risultante, quindi gli utenti non devono fidarsi del modello che lo ha prodotto.

Il test si è concentrato sulla Finite State Entropy, o FSE, che Zstandard usa per codificare efficientemente alcuni valori. FSE assegna simboli in una tabella di stati in base alle loro probabilità. Ogni stato identifica un simbolo, il numero di bit da leggere e una base per calcolare lo stato successivo.

Una tabella corretta deve preservare diverse relazioni. Deve avere il numero previsto di voci, l'allocazione corretta per ogni simbolo e transizioni valide per ogni possibile stato. Ogni simbolo con probabilità diversa da zero deve inoltre avere esattamente un percorso verso ogni stato di destinazione.

I test unitari possono verificare esempi selezionati della specifica Zstandard. Non possono stabilire che queste proprietà valgano per ogni input valido. Langley ha invece scritto un unico teorema che copre l'intera funzione di costruzione della tabella.

Secondo quanto riferito, diversi LLM hanno prodotto una prova in circa 20 minuti. Langley ha confermato che Lean ha accettato il risultato e che i file non contenevano dichiarazioni sorry, che gli sviluppatori Lean usano come segnaposto per prove mancanti.

I modelli non si sono limitati a riempire un vuoto isolato. Hanno modificato il codice di generazione della tabella perché Langley aveva usato una struttura troppo in stile imperativo. Quella struttura era più difficile da analizzare per il meccanismo di prova.

Questo dettaglio è importante perché rivela sia l'attrattiva sia il costo. L'AI ha gestito la costruzione della prova, ma l'implementazione doveva comunque avere una forma che supportasse il ragionamento. La verifica non è arrivata come un pulsante finale di controllo qualità applicato a codice arbitrario.

Langley ha inoltre evitato di presentare il progetto come prova di idoneità alla produzione. Il codice resta inedito, il decoder copriva un esperimento delimitato e le sue prestazioni erano inferiori all'implementazione consolidata. La sua affermazione riguarda la disponibilità dell'automazione delle prove, non la preparazione di questo particolare decompressore.

Un progetto correlato offre un riferimento più ampio. Il creatore di Lean Leonardo de Moura ha evidenziato un'implementazione di zlib implementation assistita dall'AI che ha superato i test e dimostrato la correttezza di andata e ritorno a ogni livello di compressione. Insieme, questi esempi avvicinano la dimostrazione AI al normale codice di sistema.

Resta comunque un divario tra un artefatto impressionante e un processo ingegneristico ripetibile. Colmare quel divario determinerà se l'automazione delle prove Lean diventerà uno strumento di sviluppo comune o resterà una dimostrazione per esperti.

La vecchia barriera era il lavoro sulle prove, non la loro verifica

La verifica formale offriva già solide garanzie. Il suo problema economico era lo sforzo umano necessario per formularle e mantenerle.

Un test normale chiede se il software si sia comportato correttamente negli esempi eseguiti. La verifica formale chiede se un modello matematico soddisfi una proprietà dichiarata per ogni input compreso in quel modello. Questa promessa più ampia crea un carico di lavoro molto maggiore.

Il microkernel seL4 resta uno degli esempi storici più chiari. Il suo team di verifica ha prodotto una prova verificata da macchina che collega l'implementazione del kernel alla sua specifica formale. Il progetto ha dimostrato che il software di produzione, ad alta affidabilità e su larga scala, poteva essere verificato.

Ha anche documentato il costo. Secondo la retrospettiva del progetto del team, la verifica ha richiesto circa dieci volte lo sforzo dedicato alla progettazione e implementazione del codice C. Il materiale di prova superava l'implementazione di oltre venti volte in numero di righe.

Queste cifre non significano che ogni progetto verificato erediti lo stesso rapporto. seL4 perseguiva garanzie insolitamente estese su un sostanziale kernel di sistema operativo. Spiegano però perché la maggior parte delle organizzazioni software abbia scelto invece test, revisioni, analisi statica e monitoraggio operativo.

L'automazione tradizionale ha ridotto parte di questo onere. Strumenti come i solver SMT, che cercano soluzioni a vincoli logici, possono risolvere obblighi di prova ordinari. Funzionano bene quando il problema rientra nelle teorie supportate dal solver e nella struttura prevista.

L'esperienza diventa meno prevedibile quando un obiettivo si trova al di fuori di quella zona confortevole. Gli sviluppatori possono attendere senza sapere se un solver abbia bisogno di più tempo o non finirà mai. I team imparano inoltre schemi di implementazione che fanno comportare il solver come desiderato, creando un'altra disciplina ingegneristica specializzata.

Gli LLM affrontano il compito in modo diverso. Possono leggere definizioni, messaggi di errore, lemmi vicini e spiegazioni informali. Possono proporre risultati intermedi, rivedere tattiche fallite e riorganizzare il codice quando la rappresentazione attuale blocca i progressi.

Questa flessibilità rende la generazione di prove un obiettivo naturale per i modelli linguistici. Non è necessario fidarsi del modello come autorità finale. Deve produrre un artefatto che il kernel di prova accetti.

È un adattamento migliore rispetto a molti compiti di automazione d'ufficio. Un memorandum strategico generato non dispone di un verificatore completo per verità, rilevanza e giudizio. Una prova Lean ha una condizione di accettazione ristretta che il software può valutare in modo deterministico.

Il risultato cambia la prevista divisione del lavoro. Le persone specificano la proprietà, scelgono le assunzioni e decidono se il modello rappresenta la realtà. L'AI cerca una prova, mentre Lean verifica il risultato proposto.

Questo non elimina il lavoro umano. Sposta lo sforzo verso specificazione, architettura e revisione. Queste attività sono più difficili da automatizzare perché richiedono di decidere quali risultati contino.

Per i knowledge worker, questa è la storia di produttività più profonda. L'automazione più efficace non si limita a produrre più materiale. Collega il materiale generato a condizioni esplicite che determinano se il risultato è accettabile.

Questo principio si applica anche al lavoro di ricerca e operativo. Un team che usa una personal knowledge base può recuperare evidenze prima di generare una risposta. Il risultato necessita comunque di criteri che coprano qualità delle fonti, ambito e aggiornamento.

Lean rende questi criteri particolarmente rigorosi. La sua lezione non è che ogni compito richieda un dimostratore di teoremi. È che l'automazione diventa più affidabile quando l'organizzazione può definire un contratto verificabile.

L'AI cambia il costo della prova, non il significato della correttezza

L'automazione delle prove Lean può verificare che il codice soddisfi una specifica, ma non può decidere se la specifica descriva il problema giusto.

Questo è il ribaltamento centrale nell'esperimento di Langley. Il ragionamento incerto dei modelli non compromette automaticamente la prova perché Lean ne verifica l'output finale. Tuttavia, lo stesso verificatore non può salvare un teorema che formalizza il requisito sbagliato.

Supponiamo che un teorema su un decompressore dimostri che ogni transizione di stato generata rimanga all'interno della tabella. Questo è utile, ma non stabilisce la compatibilità con ogni file Zstandard. Non dice inoltre nulla sul comportamento rispetto al denial-of-service, ai limiti di memoria, ai canali laterali o alle prestazioni dell'implementazione.

Ogni garanzia aggiuntiva necessita di un'enunciazione corrispondente e di un collegamento al programma effettivo. Se tale collegamento omette un'assunzione, Lean può dimostrare l'enunciazione formale mentre il sistema distribuito resta vulnerabile.

Il problema assomiglia a un contratto ben scritto che disciplina la transazione sbagliata. Una perfetta coerenza interna non può riparare un obbligo mancante. La verifica aumenta la fiducia entro il confine definito dalle persone.

Il teorema FSE di Langley illustra il caso migliore. Le proprietà corrispondono direttamente alle assunzioni necessarie per il ciclo di decodifica ottimizzato. Dimensione della tabella, allocazione dei simboli, transizioni valide e raggiungibilità unica sono invarianti concreti, non ampie affermazioni sulla qualità.

Una volta che questi invarianti esistono, il compilatore e il kernel possono applicarli in tutto il programma. Una modifica futura che ne violi uno non supererà il controllo dei tipi finché l'implementazione o la prova non verranno cambiate.

Questo crea una diversa superficie di revisione. Gli ingegneri non devono esaminare migliaia di passaggi di prova generati con uguale attenzione. Devono verificare il teorema, le sue assunzioni e il collegamento tra codice e modello.

È qui che si sposta l'esperienza scarsa. Un ingegnere senior che prima trascorreva giorni a guidare tattiche potrebbe invece dedicare quei giorni a perfezionare il contratto formale. L'AI gestisce gran parte della ricerca meccanica, mentre i revisori umani valutano se il contratto meriti fiducia.

L'approccio può anche rendere i disaccordi più produttivi. I team di prodotto, sicurezza e ingegneria usano spesso la stessa parola, come “valido”, attribuendole però definizioni diverse. Una specifica formale costringe queste definizioni a diventare condizioni visibili.

Il lavoro della conoscenza soffre dello stesso problema degli invarianti nascosti. Un'analisi di mercato potrebbe richiedere fonti attuali, una regione definita e un periodo di rendicontazione fisso. I team lasciano spesso questi vincoli in commenti, note di riunione o nella memoria di un dipendente.

L’IA può generare un report rifinito violando silenziosamente uno qualsiasi di essi. Un flusso di lavoro migliore rappresenta i vincoli importanti prima che la generazione inizi. Alcune condizioni possono diventare controlli automatizzati, mentre altre restano domande esplicite per la revisione.

Ecco perché il knowledge blending è importante nel lavoro assistito dall’IA. L’output generato diventa più facile da valutare quando resta collegato ai record, alle decisioni e alle evidenze pertinenti. Il controllo è meno assoluto del kernel di Lean, ma il principio operativo è simile.

Le organizzazioni dovrebbero quindi resistere all’interpretazione più semplicistica dell’automazione delle prove. Il vantaggio non è il permesso di smettere di rivedere l’output dell’IA. È l’opportunità di effettuare revisioni a un livello più utile.

La generazione delle prove diventa meno costosa. Definire la correttezza diventa più centrale. I team che non riescono a concordare sui requisiti non otterranno garanzie solide aggiungendo Lean o un prover IA.

La verifica formale con Lean ora mette sotto pressione i flussi di lavoro basati solo sui test

La pressione immediata ricade sui team che sviluppano codice sensibile alla sicurezza e che continuano a considerare i test la massima garanzia disponibile.

I test restano essenziali perché valutano esecuzioni reali, integrazioni, prestazioni e comportamento nell’ambiente operativo. La verifica formale risponde a una domanda diversa: controlla se un modello soddisfa una proprietà in tutti i casi coperti dalla prova.

Nessuno dei due metodi sostituisce l’altro. Langley ha usato i vettori di test Zstandard come normali unit test, dimostrando al contempo proprietà più ampie del generatore di tabelle. I test verificavano esempi di compatibilità, mentre il teorema copriva invarianti strutturali universali.

Il cambiamento è economico. In precedenza, la verifica formale richiedeva una quantità di lavoro specializzato tale da consentire a molti team di scartarla prima ancora di valutarne i vantaggi. Se l’IA riduce il tempo necessario per costruire le prove, quella liquidazione automatica diventa più difficile da difendere.

Il software crittografico offre un primo banco di prova. Piccoli errori aritmetici possono invalidare sistemi di sicurezza più ampi, e molte funzioni importanti dispongono già di specifiche matematiche. Il valore delle garanzie universali è insolitamente chiaro.

Un rapporto di esperienza del maggio 2026 ha descritto una pipeline di verifica Rust che traduce codice crittografico di produzione in Lean. Combina strumenti di estrazione Rust, librerie di specifiche formali e prover IA quali Aristotle e Aleph.

I ricercatori hanno applicato la pipeline a componenti di Plonky3 e RISC Zero. I target includevano aritmetica dei campi, verifica dell’inclusione Merkle, valutazione di polinomi e operazioni FRI utilizzate dai sistemi a conoscenza zero. Ogni prova inviata continuava a passare attraverso il kernel di Lean.

L’articolo registra anche attriti ingegneristici. Le versioni della toolchain cambiavano nel tempo, gli strumenti di traduzione supportavano solo porzioni di Rust e lemmi mancanti bloccavano l’automazione. I prover IA hanno risolto alcuni obblighi, mentre altri richiedevano ancora lavoro manuale.

Queste evidenze supportano una previsione misurata. La verifica entrerà probabilmente in produzione attraverso componenti circoscritti e ad alto valore, anziché intere applicazioni aziendali. I team possono iniziare con parser, regole di autorizzazione, operazioni crittografiche e logica di transizione dello stato.

Questi componenti hanno tre proprietà utili. Il loro comportamento può spesso essere specificato con precisione, i guasti comportano costi elevati e i loro confini sono abbastanza ridotti perché gli strumenti attuali possano comprenderli.

La pressione raggiungerà anche i fornitori che vendono sistemi di coding IA. Generare più codice sta diventando meno distintivo. Produrre codice con proprietà verificabili in modo indipendente costituisce un’affermazione più forte.

Un agente di coding potrebbe infine restituire tre artefatti collegati: un’implementazione, una dichiarazione formale del comportamento richiesto e una prova verificata dal kernel. I revisori potrebbero concentrarsi sul fatto che la dichiarazione corrisponda al requisito di prodotto.

Le piattaforme incentrate sui test risponderanno anziché scomparire. Ci si può aspettare combinazioni più forti di fuzzing, property testing, esecuzione simbolica e prove. I test generati continueranno a individuare discrepanze tra modelli formali e complessi ambienti di deployment.

Anche i fornitori di verifica formale devono affrontare pressioni. Il loro vantaggio tradizionale include competenze rare nella costruzione delle prove. L’IA riduce il valore del lavoro ripetitivo sulle tattiche, aumentando al contempo la domanda di progettazione delle specifiche, integrazione e architettura delle garanzie.

I manager non dovrebbero interpretare questo cambiamento come un’immediata riduzione delle assunzioni. L’adozione iniziale di solito crea lavoro di integrazione prima di eliminare il lavoro di manutenzione. I team avranno bisogno di persone che comprendano sia il dominio applicativo sia il confine della prova.

La domanda utile non è quindi se Lean sostituisca la programmazione convenzionale. È quali assunzioni costose possano ora passare da commenti e checklist di revisione a contratti applicati dalla macchina.

Cosa il risultato su Zstandard non dimostra

Un decoder giocattolo non pubblicato non può dimostrare che gli attuali prover IA siano scalabili su repository di produzione, modifiche frequenti o sistemi con specifiche inadeguate.

Langley ha dichiarato direttamente questi limiti. Il suo decoder funzionava circa dieci volte più lentamente del comando zstd sulla sua macchina. Ha inoltre avvertito che i tipi forti possono amplificare le modifiche, perché le assunzioni riviste si propagano attraverso i tipi derivati.

Questa propagazione può essere un vantaggio. Espone ogni componente dipendente che richiede attenzione. Può anche trasformare una piccola modifica di prodotto in un grande progetto di manutenzione delle prove.

Le prestazioni creano un altro compromesso. Lean può effettuare aggiornamenti in-place quando un oggetto ha un solo riferimento. Una piccola modifica al codice che conserva un altro riferimento può quindi danneggiare le prestazioni senza modificare la correttezza funzionale.

L’automazione delle prove non rileva automaticamente quella regressione. Il teorema deve includere un modello di prestazioni appropriato, oppure un altro benchmark deve intercettarla. Correttezza ed efficienza restano affermazioni ingegneristiche separate.

La scala del repository presenta la sfida più importante. L’esempio di Langley aveva un’implementazione focalizzata e un teorema collegato a definizioni vicine. I sistemi di produzione distribuiscono il significato tra pacchetti, codice generato, configurazioni di build, database e servizi esterni.

Lo studio VeriSoftBench del 2026 ha testato questo problema usando 500 obblighi di prova provenienti da 23 repository Lean open source. Il suo benchmark sui repository ha preservato definizioni specifiche dei progetti e dipendenze tra file.

I ricercatori hanno rilevato che i prover addestrati su compiti Lean orientati alla matematica si trasferivano male alla verifica software incentrata sui repository. Le prestazioni diminuivano quando le prove dipendevano da catene più ampie e articolate di definizioni locali.

Fornire un contesto selezionato con cura ha migliorato i risultati rispetto all’esposizione di un intero repository. Restava comunque ampio margine di miglioramento. Il recupero del contesto aiutava, ma non risolveva il problema di ragionamento.

Questa scoperta limita direttamente l’interpretazione più forte dell’affermazione di Langley. Gli LLM possono oggi produrre prove software significative. Non possono ancora gestire ogni obbligo di prova semplicemente perché un progetto usa Lean.

Esiste anche una lacuna di verifica attorno all’esperimento pubblicato. I lettori possono esaminare la spiegazione, l’enunciato del teorema e le avvertenze di Langley. Non possono riprodurre il risultato completo perché non ha pubblicato il decoder né i file delle prove.

La sua conferma che non restavano dichiarazioni sorry è una utile evidenza diretta. Non equivale a una build indipendente da un repository con versioni fissate. Il risultato dovrebbe essere trattato come un rapporto ingegneristico credibile, non come un benchmark.

I team di sicurezza devono inoltre esaminare la base informatica fidata. Il kernel di Lean è intenzionalmente piccolo e implementazioni indipendenti del kernel possono confrontare i risultati. Tuttavia, i deployment dipendono ancora da compilatori, comportamento a runtime, hardware e accuratezza di eventuali modelli esterni.

Il sistema può dimostrare che una funzione Lean soddisfa una specifica Lean. È necessario ulteriore lavoro per mostrare che il codice nativo ottimizzato preserva quella semantica. Langley ha suggerito l’assembly verificato come possibile direzione.

Questi limiti non annullano il risultato. Ne definiscono il contesto. L’automazione delle prove Lean sembra utile per componenti delimitati le cui proprietà possano essere espresse con precisione e le cui dipendenze rientrino nel contesto disponibile.

Questo è già più pratico della vecchia assunzione secondo cui la prova formale richieda sempre a uno specialista di realizzare manualmente ogni passaggio. Resta molto lontano da un pulsante universale “verifica” per il software generato.

Tre segnali mostreranno se l’automazione delle prove è davvero arrivata

La fase successiva dipende dalla riproducibilità, dalla manutenzione su scala di repository e dall’adozione nei normali flussi di lavoro ingegneristici.

Il primo segnale è un’implementazione pubblica e riproducibile che corrisponda al modello di Langley. Dovrebbe includere codice sorgente, enunciati dei teoremi, prove generate, dipendenze fissate e una build automatizzata che rifiuti lacune non risolte.

Un artefatto pubblicato consentirebbe a team indipendenti di misurare il tempo delle prove, la dipendenza dal modello e i costi di manutenzione. Rivelerebbe anche quanto intervento umano sia avvenuto tra l’implementazione iniziale e la prova accettata.

Se diversi team riproducono il flusso di lavoro su parser o librerie di compressione, la conclusione di Langley diventa più solida. Se i risultati dipendono da ampi prompt nascosti o da ristrutturazioni manuali, l’attuale affermazione sulla produttività si indebolisce.

Il secondo segnale è la prestazione su repository in evoluzione. Un sistema utile deve riparare le prove dopo normali refactoring, aggiornamenti delle dipendenze e modifiche ai requisiti. Risolvere un teorema una volta è meno prezioso che mantenerlo risolto tra una release e l’altra.

I benchmark su scala di repository dovrebbero quindi aggiungere compiti longitudinali. Un prover IA potrebbe ricevere commit consecutivi e riparare le prove interessate preservando la specifica originale. I team dovrebbero tracciare le riparazioni accettate, il tempo trascorso, l’uso di calcolo e le modifiche umane.

Il miglioramento sulle dense dipendenze locali affronterebbe la debolezza identificata da VeriSoftBench. Il fallimento continuo confinerebbe la dimostrazione IA a piccoli moduli con contesto accuratamente curato.

Il terzo segnale è l’integrazione negli agenti di coding mainstream e nei sistemi di integrazione continua. L’automazione delle prove diventa operativa quando una pull request può dichiarare un invariante richiesto, generare una prova e farla verificare automaticamente da Lean.

Questo processo richiede anche modalità di errore trasparenti. Un modello che non riesce a trovare una prova deve distinguere tra contesto mancante, teorema difficile, codice incompatibile e affermazione falsa. Altrimenti, i team ricevono un’altra build rossa opaca.

L’adozione inizierà probabilmente dove le organizzazioni già scrivono requisiti precisi. Crittografia, implementazioni di protocolli, compilatori, controlli finanziari e sistemi di controllo degli accessi corrispondono a questa descrizione. Il software aziendale più ampio si muoverà più lentamente.

I lavoratori della conoscenza dovrebbero osservare lo stesso schema nei propri strumenti. Un’automazione affidabile necessita di input espliciti, regole di accettazione, evidenze tracciabili e un verificatore con l’autorità di rifiutare il risultato.

La maggior parte delle attività d’ufficio non può raggiungere la certezza matematica. Può comunque adottare controlli più circoscritti. Un brief di ricerca può richiedere fonti datate. Un’analisi commerciale può richiedere che ogni affermazione su un account sia collegata a un record cliente. Un aggiornamento di progetto può segnalare affermazioni non supportate dal lavoro recente.

Questo cambiamento trasforma l’IA da autore non controllato a generatore di candidati che opera all’interno di un processo controllato. Le persone mantengono la responsabilità di definire il confine e rivedere ciò che i controlli non possono coprire.

L’automazione delle prove Lean offre la versione più chiara di quel futuro perché il suo verificatore è esatto. Il modello può essere incoerente, prolisso o ripetutamente errato durante la ricerca. Solo una prova valida raggiunge il programma.

La domanda dei prossimi mesi non è se gli LLM possano generare prove formali. Possono già farlo. La domanda è se i team possano trasformare ripetutamente requisiti reali in software mantenuto e verificato dalla macchina, senza ricreare il vecchio onere lavorativo decuplicato.

Scegli un’ipotesi costosa nel tuo flusso di lavoro e annota cosa la renderebbe verificabilmente vera. Se la condizione può essere controllata, automatizza quel controllo prima di automatizzare ulteriore output. Questa è la lezione pratica dell’esperimento di Langley e lo standard che l’automazione della proof deve ora soddisfare.