Adam Langley affirme que l’automatisation des preuves Lean est arrivée. La partie difficile s’est simplement déplacée

Adam Langley affirme que l’automatisation des preuves Lean a franchi un seuil pratique après que plusieurs grands modèles de langage ont achevé une preuve logicielle difficile en une vingtaine de minutes. Cette affirmation s’accompagne d’une précision importante. L’IA a généré la preuve, mais Lean a vérifié chaque étape par rapport à une spécification formelle.

Cette distinction différencie cette expérience d’une nouvelle histoire d’IA produisant du code plausible. Langley a construit un décompresseur Zstandard dans Lean, puis a demandé à des modèles de prouver des propriétés universelles de sa table de décodage d’entropie. Les modèles auraient terminé sans lacunes de preuve non résolues, bien qu’ils aient également modifié certaines parties de son implémentation.

L’expérience suggère un autre compromis pour les équipes logicielles. Les développeurs pourraient consacrer moins de temps à construire des preuves et davantage à décider précisément ce que leurs systèmes doivent garantir. Les assistants de codage par IA génèrent une réponse et demandent aux humains d’y trouver les erreurs. Lean inverse cette relation en rejetant toute réponse qui ne satisfait pas un énoncé vérifiable par machine.

Cela ne prouve pas que la vérification formelle soit devenue peu coûteuse, facile ou adaptée à toutes les applications. Langley a décrit le décompresseur comme un jouet, n’en a pas publié le code source et a mesuré une vitesse égale à un dixième de celle de la commande standard zstd. Des recherches indépendantes montrent également que les prouveurs IA peinent lorsque les preuves dépendent de dépôts volumineux et inconnus.

La conclusion la plus défendable reste néanmoins importante. L’IA peut désormais absorber suffisamment de travail répétitif lié aux preuves pour que la vérification mérite d’être testée au-delà de ses niches traditionnelles. Pour les travailleurs du savoir, la leçon plus large dépasse le logiciel : l’automatisation devient plus fiable lorsque les critères d’acceptation sont explicites et vérifiés de manière indépendante.

Une expérience Zstandard a mis l’automatisation des preuves Lean à l’œuvre

La nouvelle n’est pas qu’une IA a écrit un autre programme. C’est qu’un travail généré par IA a passé un vérificateur conçu pour rejeter les erreurs logiques.

Langley, ingénieur en sécurité connu pour ses travaux sur la cryptographie et l’infrastructure internet, a publié l’expérience le 26 juillet 2026. Son récit sur l’automatisation des preuves décrit la construction d’un décompresseur Zstandard dans Lean et la formalisation de plusieurs propriétés de ses tables de décodage.

Lean est à la fois un langage de programmation fonctionnelle et un assistant de preuve. Un assistant de preuve vérifie qu’un argument formel établit une proposition formulée avec précision. Le petit noyau de Lean valide le terme de preuve obtenu, de sorte que les utilisateurs n’ont pas besoin de faire confiance au modèle qui l’a produit.

Le test portait sur Finite State Entropy, ou FSE, que Zstandard utilise pour encoder efficacement certaines valeurs. FSE répartit les symboles dans une table d’états selon leurs probabilités. Chaque état identifie un symbole, le nombre de bits à lire et une base pour calculer l’état suivant.

Une table correcte doit préserver plusieurs relations. Elle doit contenir le nombre attendu d’entrées, la bonne allocation pour chaque symbole et des transitions valides pour chaque état possible. Chaque symbole de probabilité non nulle doit également disposer d’exactement un chemin vers chaque état cible.

Les tests unitaires peuvent vérifier des exemples sélectionnés de la spécification Zstandard. Ils ne peuvent pas établir que ces propriétés sont valables pour chaque entrée valide. Langley a plutôt écrit un théorème couvrant la fonction complète de construction de table.

Plusieurs LLM auraient produit une preuve en une vingtaine de minutes. Langley a confirmé que Lean acceptait le résultat et que les fichiers ne contenaient aucune déclaration sorry, utilisée par les développeurs Lean comme espace réservé pour les preuves manquantes.

Les modèles ne se sont pas simplement contentés de remplir un blanc isolé. Ils ont modifié le code de génération de table parce que Langley utilisait une structure trop impérative. Cette structure était plus difficile à analyser pour la mécanique de preuve.

Ce détail compte, car il révèle à la fois l’attrait et le coût. L’IA a pris en charge la construction de la preuve, mais l’implémentation devait toujours adopter une forme propice au raisonnement. La vérification n’est pas arrivée comme un bouton final de contrôle qualité appliqué à un code arbitraire.

Langley a également évité de présenter le projet comme une preuve de production. Le code reste non publié, le décodeur couvrait une expérience limitée et ses performances restaient en retrait par rapport à l’implémentation établie. Son affirmation concerne la disponibilité de l’automatisation des preuves, et non l’état de préparation de ce décompresseur particulier.

Un projet connexe offre un point de référence plus large. Le créateur de Lean, Leonardo de Moura, a mis en avant une implémentation zlib assistée par IA qui a réussi les tests et prouvé la correction aller-retour à chaque niveau de compression. Ensemble, ces exemples rapprochent la démonstration par IA du code systèmes ordinaire.

Ils laissent toutefois subsister un écart entre un artefact impressionnant et un processus d’ingénierie reproductible. Combler cet écart déterminera si l’automatisation des preuves Lean devient un outil de développement courant ou reste une démonstration d’expert.

L’ancien obstacle était le travail de preuve, pas la vérification des preuves

La vérification formelle offrait déjà de fortes garanties. Son problème économique était l’effort humain nécessaire pour les formuler et les maintenir.

Un test ordinaire demande si le logiciel s’est comporté correctement pour les exemples exécutés. La vérification formelle demande si un modèle mathématique satisfait une propriété énoncée pour chaque entrée de ce modèle. Cette promesse plus vaste crée une charge de travail bien plus importante.

Le micro-noyau seL4 demeure l’un des exemples historiques les plus clairs. Son équipe de vérification a produit une preuve vérifiée par machine reliant l’implémentation du noyau à sa spécification formelle. Le projet a montré qu’un logiciel de production à grande échelle et à haute assurance pouvait être vérifié.

Il a également documenté le coût. Selon la rétrospective du projet de l’équipe, la vérification a nécessité environ dix fois l’effort consacré à la conception et à l’implémentation du code C. Le matériel de preuve dépassait l’implémentation de plus de vingt fois en nombre de lignes.

Ces chiffres ne signifient pas que chaque projet vérifié hérite du même ratio. seL4 visait des garanties exceptionnellement étendues sur un noyau de système d’exploitation conséquent. Ils expliquent toutefois pourquoi la plupart des organisations logicielles ont plutôt choisi les tests, les revues, l’analyse statique et la surveillance opérationnelle.

L’automatisation traditionnelle a réduit une partie de cette charge. Des outils tels que les solveurs SMT, qui cherchent des solutions à des contraintes logiques, peuvent résoudre des obligations de preuve routinières. Ils fonctionnent bien lorsque le problème correspond aux théories prises en charge par le solveur et à sa structure attendue.

L’expérience devient moins prévisible lorsqu’un objectif se situe hors de cette zone confortable. Les développeurs peuvent attendre sans savoir si un solveur a besoin de plus de temps ou s’il ne terminera jamais. Les équipes apprennent aussi des schémas d’implémentation qui font bien fonctionner le solveur, créant une autre discipline d’ingénierie spécialisée.

Les LLM abordent la tâche différemment. Ils peuvent lire des définitions, des messages d’erreur, des lemmes voisins et des explications informelles. Ils peuvent proposer des résultats intermédiaires, réviser des tactiques ayant échoué et réorganiser le code lorsque la représentation actuelle bloque les progrès.

Cette flexibilité fait de la génération de preuves une cible naturelle pour les modèles de langage. Il n’est pas nécessaire de faire confiance à un modèle comme autorité finale. Il doit produire un artefact que le noyau de preuve accepte.

C’est une meilleure adéquation que de nombreuses tâches d’automatisation de bureau. Une note stratégique générée ne dispose pas d’un vérificateur complet de vérité, de pertinence et de jugement. Une preuve Lean possède une condition d’acceptation étroite que le logiciel peut évaluer de manière déterministe.

Le résultat modifie la division attendue du travail. Les humains spécifient la propriété, sélectionnent les hypothèses et décident si le modèle représente la réalité. L’IA cherche une preuve, tandis que Lean vérifie le résultat proposé.

Cela n’élimine pas le travail humain. Cela déplace l’effort vers la spécification, l’architecture et la revue. Ces activités sont plus difficiles à automatiser, car elles exigent de décider quels résultats comptent.

Pour les travailleurs du savoir, c’est l’histoire de productivité plus profonde. L’automatisation la plus solide ne produit pas simplement davantage de contenu. Elle relie le contenu généré à des conditions explicites qui déterminent si le résultat est acceptable.

Ce principe s’applique aussi au travail de recherche et aux opérations. Une équipe utilisant une base de connaissances personnelle peut récupérer des éléments de preuve avant de générer une réponse. Le résultat nécessite toujours des critères couvrant la qualité des sources, le périmètre et l’actualité.

Lean rend ces critères particulièrement stricts. Sa leçon n’est pas que chaque tâche nécessite un démonstrateur de théorèmes. Elle est que l’automatisation devient plus fiable lorsque l’organisation peut définir un contrat vérifiable.

L’IA modifie le coût de la preuve, pas le sens de la correction

L’automatisation des preuves Lean peut vérifier que du code respecte une spécification, mais elle ne peut pas décider si la spécification saisit le bon problème.

C’est le renversement central de l’expérience de Langley. Le raisonnement incertain des modèles ne compromet pas automatiquement la preuve, car Lean vérifie leur sortie finale. Pourtant, ce même vérificateur ne peut pas sauver un théorème qui formalise la mauvaise exigence.

Supposons qu’un théorème sur un décompresseur prouve que chaque transition d’état générée reste à l’intérieur de la table. C’est utile, mais cela n’établit pas la compatibilité avec chaque fichier Zstandard. Cela ne dit rien non plus du comportement face au déni de service, des limites mémoire, des canaux auxiliaires ou des performances de l’implémentation.

Chaque garantie supplémentaire nécessite un énoncé correspondant et un lien avec le programme réel. Si ce lien omet une hypothèse, Lean peut prouver l’énoncé formel tandis que le système déployé reste vulnérable.

Le problème ressemble à un contrat bien rédigé qui régit la mauvaise transaction. Une cohérence interne parfaite ne peut pas réparer une obligation manquante. La vérification accroît la confiance à l’intérieur de la frontière définie par les personnes.

Le théorème FSE de Langley illustre le meilleur cas. Les propriétés correspondent directement aux hypothèses nécessaires à la boucle de décodage optimisée. La taille de la table, l’allocation des symboles, les transitions valides et l’accessibilité unique sont des invariants concrets plutôt que de grandes affirmations sur la qualité.

Une fois ces invariants établis, le compilateur et le noyau peuvent les appliquer dans l’ensemble du programme. Une modification future qui enfreint l’un d’eux échouera à la vérification de type jusqu’à ce que l’implémentation ou la preuve soit modifiée.

Cela crée une surface de revue différente. Les ingénieurs n’ont pas besoin d’examiner avec la même attention des milliers d’étapes de preuve générées. Ils doivent auditer le théorème, ses hypothèses et le lien entre le code et le modèle.

C’est là que se déplace l’expertise rare. Un ingénieur senior qui passait autrefois des jours à guider des tactiques pourrait plutôt consacrer ces jours à affiner le contrat formel. L’IA prend en charge une grande partie de la recherche mécanique, tandis que les réviseurs humains évaluent si le contrat mérite leur confiance.

Cette approche peut aussi rendre les désaccords plus productifs. Les équipes produit, sécurité et ingénierie emploient souvent le même mot, tel que « valide », tout en lui donnant des définitions différentes. Une spécification formelle force ces définitions à devenir des conditions visibles.

Le travail du savoir souffre du même problème d’invariants cachés. Une analyse de marché peut nécessiter des sources récentes, une région définie et une période de référence fixe. Les équipes laissent souvent ces contraintes dans des commentaires, des notes de réunion ou la mémoire d’un employé.

L’IA peut générer un rapport soigné tout en enfreignant silencieusement n’importe laquelle de ces contraintes. Un meilleur processus représente les contraintes importantes avant le début de la génération. Certaines conditions peuvent devenir des vérifications automatisées, tandis que d’autres restent des questions de revue explicites.

C’est pourquoi le knowledge blending est important dans le travail assisté par IA. Le résultat généré devient plus facile à évaluer lorsqu’il reste relié aux enregistrements, décisions et preuves pertinents. La vérification est moins absolue que le noyau de Lean, mais le principe opérationnel est similaire.

Les organisations devraient donc résister à l’interprétation la plus facile de l’automatisation de la preuve. Le bénéfice n’est pas l’autorisation d’arrêter de revoir les résultats de l’IA. C’est l’occasion de réviser à un niveau plus utile.

La génération de preuves devient moins coûteuse. Définir la correction devient plus central. Les équipes qui ne parviennent pas à s’accorder sur les exigences n’obtiendront pas de solides garanties en ajoutant Lean ou un prouveur IA.

La vérification formelle avec Lean exerce désormais une pression sur les processus fondés uniquement sur les tests

La pression immédiate s’exerce sur les équipes qui développent du code sensible en matière de sécurité et qui considèrent encore les tests comme leur niveau d’assurance le plus élevé.

Les tests restent essentiels, car ils évaluent les exécutions réelles, les intégrations, les performances et le comportement dans l’environnement. La vérification formelle répond à une autre question. Elle vérifie si un modèle satisfait une propriété dans tous les cas couverts par la preuve.

Aucune des deux méthodes ne remplace l’autre. Langley a utilisé des vecteurs de test Zstandard comme tests unitaires ordinaires tout en prouvant des propriétés plus larges du générateur de tables. Les tests vérifiaient des exemples de compatibilité, tandis que le théorème couvrait des invariants structurels universels.

Le changement est économique. La vérification formelle exigeait auparavant une telle quantité de travail spécialisé que de nombreuses équipes pouvaient l’écarter avant même d’en évaluer les bénéfices. Si l’IA réduit le temps de construction des preuves, ce rejet automatique devient plus difficile à justifier.

Les logiciels cryptographiques offrent un premier terrain de démonstration. De petites erreurs arithmétiques peuvent invalider des systèmes de sécurité plus vastes, et de nombreuses fonctions importantes disposent déjà de spécifications mathématiques. La valeur des garanties universelles y est particulièrement claire.

Un rapport d’expérience de mai 2026 décrivait un pipeline de vérification Rust qui traduit du code cryptographique de production en Lean. Il combine des outils d’extraction Rust, des bibliothèques de spécifications formelles et des prouveurs IA tels qu’Aristotle et Aleph.

Les chercheurs ont appliqué le pipeline à des composants de Plonky3 et RISC Zero. Les cibles comprenaient l’arithmétique de corps, la vérification d’inclusion Merkle, l’évaluation polynomiale et les opérations FRI utilisées par les systèmes à divulgation nulle de connaissance. Chaque preuve soumise passait toujours par le noyau de Lean.

L’article consigne également des difficultés d’ingénierie. Les versions des chaînes d’outils dérivaient, les outils de traduction ne prenaient en charge que certaines parties de Rust, et l’absence de lemmes bloquait l’automatisation. Les prouveurs IA ont résolu certaines obligations, tandis que d’autres exigeaient encore un travail manuel.

Ces éléments étayent une prévision mesurée. La vérification entrera probablement en production via des composants étroits et à forte valeur plutôt que par des applications métier entières. Les équipes peuvent commencer par les analyseurs syntaxiques, les règles d’autorisation, les opérations cryptographiques et la logique de transition d’état.

Ces composants possèdent trois propriétés utiles. Leur comportement peut souvent être spécifié précisément, les défaillances entraînent des coûts élevés, et leurs limites sont suffisamment réduites pour que les outils actuels puissent les comprendre.

La pression atteindra aussi les fournisseurs de systèmes de codage par IA. Générer davantage de code devient moins distinctif. Produire du code doté de propriétés vérifiables indépendamment constitue une promesse plus forte.

Un agent de codage pourrait à terme renvoyer trois artefacts liés : une implémentation, un énoncé formel du comportement requis et une preuve vérifiée par le noyau. Les relecteurs pourraient se concentrer sur la correspondance entre l’énoncé et l’exigence produit.

Les plateformes centrées sur les tests réagiront plutôt que de disparaître. Il faut s’attendre à des combinaisons plus étroites de fuzzing, de tests basés sur les propriétés, d’exécution symbolique et de preuve. Les tests générés continueront de détecter les écarts entre les modèles formels et les environnements de déploiement désordonnés.

Les fournisseurs de vérification formelle subissent également une pression. Leur avantage traditionnel comprend une expertise rare dans la construction de preuves. L’IA réduit la valeur du travail répétitif sur les tactiques tout en augmentant la demande en conception de spécifications, intégration et architecture d’assurance.

Les responsables ne devraient pas interpréter cette évolution comme une réduction immédiate des recrutements. L’adoption précoce crée généralement du travail d’intégration avant de supprimer du travail de maintenance. Les équipes auront besoin de personnes qui comprennent à la fois le domaine applicatif et la frontière de la preuve.

La question utile n’est donc pas de savoir si Lean remplace la programmation conventionnelle. Elle est de déterminer quelles hypothèses coûteuses peuvent désormais passer des commentaires et des listes de contrôle de revue à des contrats imposés par la machine.

Ce que le résultat sur Zstandard ne prouve pas

Un seul décodeur jouet non publié ne peut pas établir que les prouveurs IA actuels passent à l’échelle sur des dépôts de production, des changements fréquents ou des systèmes mal spécifiés.

Langley a exposé directement ces limites. Son décodeur s’exécutait environ dix fois plus lentement que la commande zstd sur sa machine. Il a également averti que des types forts peuvent amplifier les changements, car des hypothèses révisées se propagent à travers les types dérivés.

Cette propagation peut être un avantage. Elle expose chaque composant dépendant qui nécessite une attention. Elle peut également transformer un petit changement produit en vaste projet de maintenance des preuves.

Les performances créent un autre compromis. Lean peut effectuer des mises à jour sur place lorsqu’un objet n’a qu’une seule référence. Une modification mineure du code qui conserve une autre référence peut donc dégrader les performances sans modifier la correction fonctionnelle.

L’automatisation des preuves ne détecte pas automatiquement cette régression. Le théorème doit inclure un modèle de performance approprié, ou un autre benchmark doit la détecter. La correction et l’efficacité restent des affirmations d’ingénierie distinctes.

L’échelle des dépôts présente le défi le plus important. L’exemple de Langley comportait une implémentation ciblée et un théorème relié à des définitions proches. Les systèmes de production répartissent leur sens entre des paquets, du code généré, des configurations de build, des bases de données et des services externes.

L’étude VeriSoftBench de 2026 a testé ce problème à l’aide de 500 obligations de preuve provenant de 23 dépôts Lean open source. Son benchmark de dépôts conservait les définitions propres aux projets et les dépendances entre fichiers.

Les chercheurs ont constaté que les prouveurs entraînés sur des tâches Lean orientées mathématiques se transféraient mal vers la vérification logicielle centrée sur les dépôts. Les performances diminuaient lorsque les preuves dépendaient de chaînes plus longues, à plusieurs étapes, de définitions locales.

La fourniture d’un contexte soigneusement sélectionné a amélioré les résultats par rapport à l’exposition d’un dépôt entier. Elle laissait néanmoins une marge d’amélioration substantielle. La récupération de contexte aidait, mais ne résolvait pas le problème de raisonnement.

Cette constatation limite directement l’interprétation la plus forte de l’affirmation de Langley. Les LLM peuvent aujourd’hui produire des preuves logicielles significatives. Ils ne peuvent pas encore traiter chaque obligation de preuve simplement parce qu’un projet utilise Lean.

Il existe également une lacune de vérification autour de l’expérience publiée. Les lecteurs peuvent examiner l’explication, l’énoncé du théorème et les réserves de Langley. Ils ne peuvent pas reproduire le résultat complet, car il n’a pas publié le décodeur ni les fichiers de preuve.

Sa confirmation qu’aucune déclaration sorry ne subsistait constitue une preuve directe utile. Ce n’est pas la même chose qu’une compilation indépendante depuis un dépôt épinglé. Le résultat devrait être considéré comme un rapport d’ingénierie crédible, et non comme un benchmark.

Les équipes de sécurité doivent également examiner la base de calcul de confiance. Le noyau de Lean est volontairement petit, et des implémentations indépendantes du noyau peuvent comparer les résultats. Pourtant, les déploiements dépendent toujours des compilateurs, du comportement à l’exécution, du matériel et de l’exactitude de tout modèle externe.

Le système peut prouver qu’une fonction Lean respecte une spécification Lean. Un travail supplémentaire est nécessaire pour montrer que le code natif optimisé préserve ces sémantiques. Langley a suggéré l’assembleur vérifié comme une direction possible.

Ces limites n’effacent pas le résultat. Elles le situent. L’automatisation des preuves Lean semble utile pour des composants délimités dont les propriétés peuvent être énoncées précisément et dont les dépendances tiennent dans le contexte disponible.

C’est déjà plus pratique que l’ancienne hypothèse selon laquelle la preuve formelle exige toujours qu’un spécialiste élabore manuellement chaque étape. Cela reste très éloigné d’un bouton universel « vérifier » pour les logiciels générés.

Trois signaux montreront si l’automatisation des preuves est réellement arrivée

La prochaine phase dépend de la reproductibilité, de la maintenance à l’échelle des dépôts et de l’adoption au sein des processus d’ingénierie ordinaires.

Le premier signal est une implémentation publique et reproductible correspondant au modèle de Langley. Elle devrait inclure le code source, les énoncés de théorèmes, les preuves générées, les dépendances épinglées et une compilation automatisée qui rejette les trous non résolus.

Un artefact publié permettrait à des équipes indépendantes de mesurer le temps de preuve, la dépendance au modèle et les coûts de maintenance. Il révélerait également l’ampleur de l’intervention humaine entre l’implémentation initiale et la preuve acceptée.

Si plusieurs équipes reproduisent le processus sur des analyseurs syntaxiques ou des bibliothèques de compression, la conclusion de Langley deviendra plus solide. Si les résultats dépendent d’un prompting caché important ou de restructurations manuelles, l’affirmation actuelle sur la productivité s’affaiblira.

Le deuxième signal est la performance sur des dépôts qui évoluent. Un système utile doit réparer les preuves après des refactorisations normales, des mises à jour de dépendances et des exigences modifiées. Résoudre un théorème une fois est moins précieux que le maintenir résolu au fil des versions.

Les benchmarks à l’échelle des dépôts devraient donc ajouter des tâches longitudinales. Un prouveur IA pourrait recevoir des commits consécutifs et réparer les preuves affectées tout en préservant la spécification d’origine. Les équipes devraient suivre les réparations acceptées, le temps écoulé, l’utilisation de calcul et les modifications humaines.

Une amélioration sur des dépendances locales denses répondrait à la faiblesse identifiée par VeriSoftBench. Un échec persistant cantonnerait la preuve par IA à de petits modules avec un contexte soigneusement sélectionné.

Le troisième signal est l’intégration dans les agents de codage grand public et les systèmes d’intégration continue. L’automatisation des preuves devient opérationnelle lorsqu’une pull request peut énoncer un invariant requis, générer une preuve et faire vérifier automatiquement celle-ci par Lean.

Ce processus doit aussi proposer des modes d’échec transparents. Un modèle incapable de trouver une preuve doit distinguer l’absence de contexte, un théorème difficile, un code incompatible et un énoncé faux. Dans le cas contraire, les équipes reçoivent une autre build rouge opaque.

L’adoption commencera probablement là où les organisations rédigent déjà des exigences précises. La cryptographie, les implémentations de protocoles, les compilateurs, les contrôles financiers et les systèmes de contrôle d’accès correspondent à cette description. Les logiciels métier plus larges avanceront plus lentement.

Les travailleurs du savoir devraient observer le même schéma dans leurs propres outils. Une automatisation fiable nécessite des entrées explicites, des règles d’acceptation, des preuves traçables et un vérificateur ayant l’autorité de rejeter le résultat.

La plupart des tâches de bureau ne peuvent pas atteindre une certitude mathématique. Elles peuvent néanmoins adopter des contrôles plus restreints. Une note de recherche peut exiger des sources datées. Une analyse commerciale peut exiger que chaque affirmation sur un compte corresponde à un enregistrement client. Une mise à jour de projet peut signaler les déclarations non étayées par des travaux récents.

Ce changement transforme l’IA, d’auteur non contrôlé, en générateur de candidats opérant dans un processus maîtrisé. Les personnes conservent la responsabilité de définir la frontière et de revoir ce que les contrôles ne peuvent pas couvrir.

L’automatisation des preuves Lean offre la version la plus claire de cet avenir, car son vérificateur est exact. Le modèle peut être incohérent, verbeux ou erroné à répétition pendant la recherche. Seule une preuve valide atteint le programme.

La question des prochains mois n’est pas de savoir si les LLM peuvent générer des preuves formelles. Ils le peuvent déjà. La question est de savoir si les équipes peuvent transformer à répétition de vraies exigences en logiciels maintenus et vérifiés par machine, sans recréer l’ancienne charge de travail décuplée.

Choisissez une hypothèse coûteuse dans votre workflow et notez ce qui permettrait de la rendre vérifiablement vraie. Si cette condition peut être contrôlée, automatisez ce contrôle avant d’automatiser davantage de production. C’est la leçon pratique de l’expérience de Langley, ainsi que le niveau de preuve que l’automatisation doit désormais atteindre.