Adam Langley twierdzi, że automatyzacja dowodów w Lean już działa. Trudna część po prostu się przesunęła

Adam Langley twierdzi, że automatyzacja dowodów w Lean przekroczyła praktyczny próg po tym, jak kilka dużych modeli językowych ukończyło trudny dowód dotyczący oprogramowania w około 20 minut. To stwierdzenie wymaga jednak ważnego zastrzeżenia. AI wygenerowała dowód, lecz Lean sprawdził każdy krok względem formalnej specyfikacji.

To rozróżnienie oddziela ten eksperyment od kolejnej historii o AI tworzącej wiarygodnie wyglądający kod. Langley stworzył w Lean dekompresor Zstandard, a następnie poprosił modele o udowodnienie uniwersalnych własności jego tablicy dekodowania entropii. Modele miały ukończyć zadanie bez nierozwiązanych luk w dowodzie, choć zmieniły też części jego implementacji.

Eksperyment wskazuje na inną umowę dla zespołów programistycznych. Deweloperzy mogliby poświęcać mniej czasu na konstruowanie dowodów, a więcej na precyzyjne określanie, co ich systemy muszą gwarantować. Asystenci programowania AI generują odpowiedź i proszą ludzi o znalezienie błędów. Lean odwraca tę relację, odrzucając każdą odpowiedź, która nie spełnia stwierdzenia możliwego do sprawdzenia przez maszynę.

Nie jest to dowód na to, że weryfikacja formalna stała się tania, prosta lub odpowiednia dla każdej aplikacji. Langley opisał dekompresor jako zabawkę, nie ujawnił jego źródeł i zmierzył jego wydajność na poziomie jednej dziesiątej szybkości standardowego polecenia zstd. Niezależne badania pokazują również, że provery AI mają trudności, gdy dowody zależą od dużych, nieznanych repozytoriów.

Bardziej uzasadniony wniosek wciąż jest istotny. AI może obecnie przejąć wystarczająco dużo powtarzalnej pracy związanej z dowodami, by warto było testować weryfikację poza jej tradycyjnymi niszami. Dla pracowników wiedzy szersza lekcja wykracza poza oprogramowanie: automatyzacja staje się bardziej godna zaufania, gdy kryteria akceptacji są jawne i niezależnie sprawdzane.

Eksperyment z Zstandard wykorzystał automatyzację dowodów w Lean

Wiadomością nie jest to, że AI napisała kolejny program. Chodzi o to, że praca wygenerowana przez AI przeszła przez mechanizm sprawdzający zaprojektowany do odrzucania błędów logicznych.

Langley, inżynier bezpieczeństwa znany z pracy nad kryptografią i infrastrukturą internetową, opublikował eksperyment 26 lipca 2026 roku. Jego opis automatyzacji dowodów przedstawia budowę dekompresora Zstandard w Lean oraz sformalizowanie kilku własności jego tablic dekodowania.

Lean jest jednocześnie funkcyjnym językiem programowania i asystentem dowodzenia. Asystent dowodzenia sprawdza, czy formalny argument ustanawia precyzyjnie sformułowane twierdzenie. Niewielkie jądro Lean waliduje wynikowy termin dowodowy, więc użytkownicy nie muszą ufać modelowi, który go wygenerował.

Test koncentrował się na Finite State Entropy, czyli FSE, którego Zstandard używa do efektywnego kodowania części wartości. FSE przypisuje symbole do tablicy stanów zgodnie z ich prawdopodobieństwami. Każdy stan określa symbol, liczbę bitów do odczytu oraz wartość bazową do obliczenia następnego stanu.

Poprawna tablica musi zachowywać kilka relacji. Musi mieć oczekiwaną liczbę wpisów, prawidłowy przydział dla każdego symbolu oraz poprawne przejścia dla każdego możliwego stanu. Każdy symbol o niezerowym prawdopodobieństwie musi też mieć dokładnie jedną drogę do każdego stanu docelowego.

Testy jednostkowe mogą sprawdzać wybrane przykłady ze specyfikacji Zstandard. Nie mogą ustalić, że te własności obowiązują dla każdego prawidłowego wejścia. Langley zamiast tego napisał jedno twierdzenie obejmujące kompletną funkcję konstruowania tablicy.

Kilka LLM-ów miało wygenerować dowód w około 20 minut. Langley potwierdził, że Lean zaakceptował wynik i że pliki nie zawierały deklaracji sorry, których deweloperzy Lean używają jako symboli zastępczych dla brakujących dowodów.

Modele nie tylko wypełniły odizolowaną lukę. Zmieniły kod generowania tablicy, ponieważ Langley zastosował zbyt wiele struktur w stylu imperatywnym. Taka struktura była trudniejsza do przeanalizowania przez mechanizmy dowodzenia.

Ten szczegół ma znaczenie, ponieważ pokazuje zarówno atrakcyjność, jak i koszt. AI zajęła się konstrukcją dowodu, ale implementacja nadal potrzebowała formy wspierającej rozumowanie. Weryfikacja nie pojawiła się jako końcowy przycisk kontroli jakości stosowany do dowolnego kodu.

Langley unikał też przedstawiania projektu jako dowodu gotowości produkcyjnej. Kod pozostaje nieopublikowany, dekoder obejmował ograniczony eksperyment, a jego wydajność ustępowała uznanej implementacji. Jego twierdzenie dotyczy dostępności automatyzacji dowodów, a nie gotowości tego konkretnego dekompresora.

Powiązany projekt daje szerszy punkt odniesienia. Twórca Lean, Leonardo de Moura, zwrócił uwagę na wspomaganą przez AI implementację zlib, która przeszła testy i udowodniła poprawność przejścia tam i z powrotem na każdym poziomie kompresji. Razem te przykłady przybliżają dowodzenie z AI do zwykłego kodu systemowego.

Nadal pozostawiają jednak lukę między imponującym artefaktem a powtarzalnym procesem inżynieryjnym. Zamknięcie tej luki określi, czy automatyzacja dowodów w Lean stanie się powszechnym narzędziem programistycznym, czy pozostanie demonstracją dla ekspertów.

Starą barierą była praca nad dowodami, a nie ich sprawdzanie

Weryfikacja formalna już oferowała silne gwarancje. Jej problemem ekonomicznym był ludzki wysiłek potrzebny do ich sformułowania i utrzymania.

Zwykły test pyta, czy oprogramowanie zachowało się poprawnie dla uruchomionych przykładów. Weryfikacja formalna pyta, czy model matematyczny spełnia określoną własność dla każdego wejścia w ramach tego modelu. Ta szersza obietnica tworzy znacznie większy nakład pracy.

Mikrojądro seL4 pozostaje jednym z najczytelniejszych historycznych przykładów. Jego zespół weryfikacyjny stworzył sprawdzony maszynowo dowód łączący implementację jądra z formalną specyfikacją. Projekt pokazał, że oprogramowanie produkcyjne na dużą skalę i o wysokim poziomie pewności może zostać zweryfikowane.

Udokumentował też koszty. Według retrospektywy projektu zespołu weryfikacja wymagała około dziesięciokrotnie większego wysiłku niż projektowanie i implementacja kodu C. Materiał dowodowy przekroczył liczbę linii implementacji ponad dwudziestokrotnie.

Te liczby nie oznaczają, że każdy zweryfikowany projekt odziedziczy ten sam współczynnik. seL4 realizował wyjątkowo rozległe gwarancje w obszarze znaczącego jądra systemu operacyjnego. Wyjaśniają jednak, dlaczego większość organizacji tworzących oprogramowanie wybierała zamiast tego testy, przeglądy, analizę statyczną i monitorowanie operacyjne.

Tradycyjna automatyzacja zmniejszyła część tego obciążenia. Narzędzia takie jak solvery SMT, które szukają rozwiązań ograniczeń logicznych, mogą rozwiązywać rutynowe zobowiązania dowodowe. Działają dobrze, gdy problem mieści się w obsługiwanych przez solver teoriach i oczekiwanej strukturze.

Doświadczenie staje się mniej przewidywalne, gdy cel znajduje się poza tą komfortową strefą. Deweloperzy mogą czekać, nie wiedząc, czy solver potrzebuje więcej czasu, czy nigdy nie zakończy działania. Zespoły uczą się też wzorców implementacyjnych, które sprawiają, że solver działa, tworząc kolejną wyspecjalizowaną dyscyplinę inżynieryjną.

LLM-y podchodzą do zadania inaczej. Mogą czytać definicje, komunikaty o błędach, sąsiednie lematy i nieformalne wyjaśnienia. Mogą proponować wyniki pośrednie, poprawiać nieudane taktyki i reorganizować kod, gdy bieżąca reprezentacja blokuje postęp.

Ta elastyczność sprawia, że generowanie dowodów jest naturalnym celem dla modeli językowych. Model nie musi być zaufanym ostatecznym autorytetem. Musi wytworzyć artefakt, który akceptuje jądro dowodzenia.

To lepsze dopasowanie niż wiele zadań automatyzacji biurowej. Wygenerowana notatka strategiczna nie ma kompletnego mechanizmu sprawdzającego prawdziwość, trafność i osąd. Dowód Lean ma wąski warunek akceptacji, który oprogramowanie może ocenić deterministycznie.

Wynik zmienia oczekiwany podział pracy. Ludzie określają własność, wybierają założenia i decydują, czy model odzwierciedla rzeczywistość. AI szuka dowodu, podczas gdy Lean weryfikuje zaproponowany wynik.

Nie eliminuje to pracy człowieka. Przenosi wysiłek w stronę specyfikacji, architektury i przeglądu. Działania te trudniej zautomatyzować, ponieważ wymagają decyzji o tym, które wyniki mają znaczenie.

Dla pracowników wiedzy to głębsza historia produktywności. Najsilniejsza automatyzacja nie tylko tworzy więcej materiału. Łączy generowany materiał z jawnymi warunkami, które określają, czy wynik jest akceptowalny.

Ta zasada odnosi się także do badań i pracy operacyjnej. Zespół korzystający z osobistej bazy wiedzy może odzyskiwać dowody przed wygenerowaniem odpowiedzi. Wynik nadal wymaga kryteriów obejmujących jakość źródeł, zakres i aktualność.

Lean czyni te kryteria wyjątkowo rygorystycznymi. Jego lekcja nie polega na tym, że każde zadanie potrzebuje provera twierdzeń. Chodzi o to, że automatyzacja staje się bardziej niezawodna, gdy organizacja potrafi zdefiniować sprawdzalny kontrakt.

AI zmienia koszt dowodu, a nie znaczenie poprawności

Automatyzacja dowodów w Lean może zweryfikować, że kod spełnia specyfikację, ale nie może zdecydować, czy specyfikacja ujmuje właściwy problem.

To kluczowe odwrócenie w eksperymencie Langleya. Niepewne rozumowanie modeli nie podważa automatycznie dowodu, ponieważ Lean sprawdza ich końcowy wynik. Ten sam mechanizm sprawdzający nie może jednak uratować twierdzenia, które formalizuje niewłaściwe wymaganie.

Załóżmy, że twierdzenie dotyczące dekompresora dowodzi, iż każde wygenerowane przejście stanu pozostaje wewnątrz tablicy. To wartościowe, ale nie ustanawia kompatybilności z każdym plikiem Zstandard. Nie mówi też nic o zachowaniu w przypadku odmowy usługi, limitach pamięci, kanałach bocznych ani wydajności implementacji.

Każda dodatkowa gwarancja wymaga odpowiadającego jej stwierdzenia i połączenia z rzeczywistym programem. Jeśli to połączenie pomija założenie, Lean może udowodnić formalne stwierdzenie, podczas gdy wdrożony system pozostanie podatny na zagrożenia.

Problem przypomina dobrze napisany kontrakt regulujący niewłaściwą transakcję. Doskonała spójność wewnętrzna nie naprawi brakującego zobowiązania. Weryfikacja zwiększa pewność wewnątrz granicy zdefiniowanej przez ludzi.

Twierdzenie Langleya dotyczące FSE ilustruje lepszy przypadek. Własności bezpośrednio odpowiadają założeniom potrzebnym zoptymalizowanej pętli dekodowania. Rozmiar tablicy, przydział symboli, prawidłowe przejścia i unikalna osiągalność są konkretnymi niezmiennikami, a nie szerokimi twierdzeniami o jakości.

Gdy takie niezmienniki już istnieją, kompilator i jądro mogą egzekwować je w całym programie. Przyszła zmiana, która naruszy którykolwiek z nich, nie przejdzie sprawdzenia typów, dopóki implementacja lub dowód nie zostaną zmienione.

Tworzy to inną powierzchnię przeglądu. Inżynierowie nie muszą analizować tysięcy wygenerowanych kroków dowodowych z równą uwagą. Muszą audytować twierdzenie, jego założenia oraz połączenie między kodem a modelem.

To właśnie tam przenosi się deficytowa wiedza ekspercka. Starszy inżynier, który wcześniej spędzał dni na prowadzeniu taktyk, może zamiast tego poświęcić te dni na dopracowanie formalnego kontraktu. AI obsługuje dużą część mechanicznego wyszukiwania, podczas gdy ludzcy recenzenci oceniają, czy kontrakt zasługuje na zaufanie.

Podejście to może również uczynić spory bardziej produktywnymi. Zespoły produktowe, bezpieczeństwa i inżynieryjne często używają tego samego słowa, na przykład „prawidłowy”, mając na myśli różne definicje. Formalna specyfikacja wymusza przekształcenie tych definicji w widoczne warunki.

Praca z wiedzą cierpi na ten sam problem ukrytych niezmienników. Analiza rynku może wymagać aktualnych źródeł, określonego regionu i ustalonego okresu raportowania. Zespoły często pozostawiają te ograniczenia w komentarzach, notatkach ze spotkań lub pamięci jednego pracownika.

AI może wygenerować dopracowany raport, jednocześnie po cichu naruszając dowolne z tych warunków. Lepszy proces przedstawia istotne ograniczenia, zanim rozpocznie się generowanie. Niektóre warunki mogą stać się zautomatyzowanymi kontrolami, podczas gdy inne pozostają jawnymi pytaniami do przeglądu.

Dlatego łączenie wiedzy ma znaczenie w pracy wspieranej przez AI. Wygenerowany rezultat łatwiej ocenić, gdy pozostaje powiązany z odpowiednimi zapisami, decyzjami i dowodami. Kontrola jest mniej absolutna niż jądro Leana, ale zasada działania jest podobna.

Organizacje powinny zatem opierać się najłatwiejszej interpretacji automatyzacji dowodów. Korzyść nie polega na uzyskaniu pozwolenia na zaprzestanie przeglądania rezultatów AI. To możliwość prowadzenia przeglądu na bardziej wartościowym poziomie.

Generowanie dowodów staje się tańsze. Definiowanie poprawności nabiera większego znaczenia. Zespoły, które nie potrafią uzgodnić wymagań, nie zyskają silnych gwarancji tylko przez dodanie Lean lub dowodzącego AI.

Formalna weryfikacja Lean wywiera teraz presję na procesy oparte wyłącznie na testach

Bezpośrednia presja dotyczy zespołów tworzących kod wrażliwy na kwestie bezpieczeństwa, które nadal traktują testy jako najwyższy dostępny poziom zapewnienia jakości.

Testowanie pozostaje niezbędne, ponieważ ocenia rzeczywiste wykonania, integracje, wydajność i zachowanie w środowisku. Formalna weryfikacja odpowiada na inne pytanie. Sprawdza, czy model spełnia daną własność we wszystkich przypadkach objętych dowodem.

Żadna z tych metod nie zastępuje drugiej. Langley używał wektorów testowych Zstandard jako zwykłych testów jednostkowych, jednocześnie dowodząc szerszych własności generatora tablic. Testy sprawdzały przykłady zgodności, podczas gdy twierdzenie obejmowało uniwersalne niezmienniki strukturalne.

Zmiana ma charakter ekonomiczny. Formalna weryfikacja wcześniej wymagała na tyle specjalistycznej pracy, że wiele zespołów mogło ją odrzucić, zanim oceniło jej korzyści. Jeśli AI skraca czas konstruowania dowodów, taka automatyczna rezygnacja staje się trudniejsza do obrony.

Oprogramowanie kryptograficzne oferuje wczesny poligon doświadczalny. Drobne błędy arytmetyczne mogą unieważnić większe systemy bezpieczeństwa, a wiele ważnych funkcji ma już specyfikacje matematyczne. Wartość uniwersalnych gwarancji jest tu wyjątkowo wyraźna.

Raport z doświadczeń z maja 2026 opisał pipeline weryfikacji Rust, który tłumaczy produkcyjny kod kryptograficzny na Lean. Łączy on narzędzia do ekstrakcji Rust, biblioteki formalnych specyfikacji oraz dowodzące AI, takie jak Aristotle i Aleph.

Badacze zastosowali pipeline do komponentów z Plonky3 i RISC Zero. Cele obejmowały arytmetykę ciał, weryfikację przynależności Merkle, ewaluację wielomianów oraz operacje FRI używane przez systemy zero-knowledge. Każdy przesłany dowód nadal przechodził przez jądro Lean.

Artykuł dokumentuje również trudności inżynieryjne. Wersje toolchainu się rozchodziły, narzędzia translacyjne obsługiwały jedynie fragmenty Rust, a brakujące lematy blokowały automatyzację. Dowodzące AI zamknęły część zobowiązań, podczas gdy inne nadal wymagały pracy ręcznej.

Te dowody wspierają wyważoną prognozę. Weryfikacja prawdopodobnie trafi do produkcji poprzez wąskie komponenty o wysokiej wartości, a nie całe aplikacje biznesowe. Zespoły mogą zacząć od parserów, reguł autoryzacji, operacji kryptograficznych i logiki przejść stanów.

Komponenty te mają trzy użyteczne właściwości. Ich zachowanie można często precyzyjnie określić, awarie wiążą się z wysokimi kosztami, a ich granice są wystarczająco niewielkie, by obecne narzędzia mogły je zrozumieć.

Presja dotrze również do dostawców systemów AI do programowania. Generowanie większej ilości kodu staje się mniej wyróżniające. Tworzenie kodu o niezależnie weryfikowalnych własnościach stanowi silniejszą propozycję.

Agent programistyczny mógłby ostatecznie zwracać trzy powiązane artefakty: implementację, formalne stwierdzenie wymaganego zachowania oraz dowód sprawdzony przez jądro. Recenzenci mogliby skupić się na tym, czy stwierdzenie odpowiada wymaganiu produktowemu.

Platformy skoncentrowane na testowaniu odpowiedzą, zamiast zniknąć. Należy oczekiwać silniejszych połączeń fuzzingu, testowania własności, wykonania symbolicznego i dowodów. Generowane testy nadal będą wykrywać rozbieżności między formalnymi modelami a chaotycznymi środowiskami wdrożeniowymi.

Dostawcy formalnej weryfikacji również stoją pod presją. Ich tradycyjna przewaga obejmuje rzadką wiedzę specjalistyczną w konstruowaniu dowodów. AI zmniejsza wartość powtarzalnej pracy nad taktykami, jednocześnie zwiększając zapotrzebowanie na projektowanie specyfikacji, integrację i architekturę zapewnienia jakości.

Menedżerowie nie powinni interpretować tej zmiany jako natychmiastowego ograniczenia zatrudnienia. Wczesne wdrożenie zwykle tworzy pracę integracyjną, zanim eliminuje pracę utrzymaniową. Zespoły będą potrzebować osób rozumiejących zarówno domenę aplikacji, jak i granicę dowodu.

Użyteczne pytanie nie brzmi więc, czy Lean zastępuje konwencjonalne programowanie. Chodzi o to, które kosztowne założenia można teraz przenieść z komentarzy i list kontrolnych przeglądu do kontraktów egzekwowanych przez maszynę.

Czego wynik dotyczący Zstandard nie dowodzi

Jeden nieopublikowany dekoder zabawkowy nie może wykazać, że obecne dowodzące AI skalują się na repozytoria produkcyjne, częste zmiany lub słabo określone systemy.

Langley bezpośrednio wskazał te ograniczenia. Jego dekoder działał na jego komputerze około dziesięć razy wolniej niż polecenie zstd. Ostrzegł również, że silne typy mogą wzmacniać zmiany, ponieważ zmienione założenia propagują się przez typy pochodne.

Ta propagacja może być zaletą. Ujawnia każdy zależny komponent wymagający uwagi. Może też przekształcić niewielką zmianę produktu w duży projekt utrzymania dowodów.

Wydajność tworzy kolejny kompromis. Lean może wykonywać aktualizacje in-place, gdy obiekt ma pojedyncze odwołanie. Drobna zmiana kodu, która zachowuje kolejne odwołanie, może więc pogorszyć wydajność bez zmiany poprawności funkcjonalnej.

Automatyzacja dowodów nie wykrywa automatycznie takiej regresji. Twierdzenie musi obejmować odpowiedni model wydajności albo inny benchmark musi ją wychwycić. Poprawność i efektywność pozostają odrębnymi twierdzeniami inżynieryjnymi.

Skala repozytorium stanowi najważniejsze wyzwanie. Przykład Langleya miał skoncentrowaną implementację i twierdzenie powiązane z pobliskimi definicjami. Systemy produkcyjne rozpraszają znaczenie między pakietami, generowanym kodem, konfiguracjami kompilacji, bazami danych i usługami zewnętrznymi.

Badanie VeriSoftBench z 2026 roku przetestowało ten problem, wykorzystując 500 zobowiązań dowodowych z 23 repozytoriów Lean typu open source. Jego benchmark repozytoriów zachował definicje specyficzne dla projektów i zależności między plikami.

Badacze stwierdzili, że dowodzące trenowane na zadaniach Lean zorientowanych na matematykę słabo przenosiły się na weryfikację oprogramowania skoncentrowaną na repozytoriach. Wydajność spadała, gdy dowody zależały od większych, wieloetapowych łańcuchów lokalnych definicji.

Dostarczanie starannie wybranego kontekstu poprawiało wyniki w porównaniu z udostępnieniem całego repozytorium. Wciąż pozostawiało znaczną przestrzeń do poprawy. Pobieranie kontekstu pomagało, ale nie rozwiązywało problemu rozumowania.

To ustalenie bezpośrednio ogranicza najsilniejszą interpretację twierdzenia Langleya. LLM-y potrafią dziś tworzyć znaczące dowody programowe. Nie potrafią jeszcze obsłużyć każdego zobowiązania dowodowego tylko dlatego, że projekt używa Lean.

Istnieje również luka weryfikacyjna wokół opublikowanego eksperymentu. Czytelnicy mogą przeanalizować wyjaśnienie Langleya, stwierdzenie twierdzenia i zastrzeżenia. Nie mogą odtworzyć pełnego wyniku, ponieważ nie opublikował dekodera ani plików dowodowych.

Jego potwierdzenie, że nie pozostały żadne deklaracje sorry, stanowi użyteczny dowód z pierwszej ręki. Nie jest tym samym co niezależne zbudowanie projektu z przypiętego repozytorium. Wynik należy traktować jako wiarygodny raport inżynieryjny, a nie benchmark.

Zespoły bezpieczeństwa muszą również zbadać zaufaną bazę obliczeniową. Jądro Lean jest celowo małe, a niezależne implementacje jądra mogą porównywać wyniki. Jednak wdrożenia nadal polegają na kompilatorach, zachowaniu środowiska uruchomieniowego, sprzęcie oraz dokładności każdego zewnętrznego modelu.

System może udowodnić, że funkcja Lean spełnia specyfikację Lean. Potrzebna jest dodatkowa praca, aby wykazać, że zoptymalizowany kod natywny zachowuje tę semantykę. Langley wskazał zweryfikowany asembler jako jeden z możliwych kierunków.

Te ograniczenia nie przekreślają wyniku. Umiejscawiają go w odpowiednim kontekście. Automatyzacja dowodów Lean wydaje się użyteczna dla ograniczonych komponentów, których własności można precyzyjnie określić i których zależności mieszczą się w dostępnym kontekście.

To już bardziej praktyczne niż dawne założenie, że formalny dowód zawsze wymaga specjalisty ręcznie tworzącego każdy krok. Wciąż jest to dalekie od uniwersalnego przycisku „zweryfikuj” dla generowanego oprogramowania.

Trzy sygnały pokażą, czy automatyzacja dowodów naprawdę nadeszła

Kolejna faza zależy od odtwarzalności, utrzymania w skali repozytorium oraz wdrożenia w zwykłych procesach inżynieryjnych.

Pierwszym sygnałem jest publiczna, odtwarzalna implementacja odpowiadająca wzorcowi Langleya. Powinna zawierać kod źródłowy, stwierdzenia twierdzeń, wygenerowane dowody, przypięte zależności oraz zautomatyzowane budowanie, które odrzuca nierozwiązane luki.

Opublikowany artefakt pozwoliłby niezależnym zespołom zmierzyć czas dowodzenia, zależność od modelu i koszty utrzymania. Ujawniłby również, ile interwencji człowieka nastąpiło między początkową implementacją a zaakceptowanym dowodem.

Jeśli kilka zespołów odtworzy proces dla parserów lub bibliotek kompresji, wniosek Langleya stanie się mocniejszy. Jeśli wyniki zależą od rozległego ukrytego promptowania lub ręcznej restrukturyzacji, obecne twierdzenie o produktywności osłabnie.

Drugim sygnałem jest wydajność w zmieniających się repozytoriach. Użyteczny system musi naprawiać dowody po zwykłych refaktoryzacjach, aktualizacjach zależności i zmienionych wymaganiach. Jednorazowe rozwiązanie twierdzenia ma mniejszą wartość niż utrzymanie jego rozwiązania między wydaniami.

Benchmarki w skali repozytorium powinny więc dodawać zadania podłużne. Dowodzące AI mogłoby otrzymywać kolejne commity i naprawiać dotknięte dowody przy zachowaniu pierwotnej specyfikacji. Zespoły powinny śledzić zaakceptowane naprawy, czas wykonania, wykorzystanie mocy obliczeniowej i edycje człowieka.

Poprawa w gęstych lokalnych zależnościach odpowiedziałaby na słabość zidentyfikowaną przez VeriSoftBench. Dalsze niepowodzenia ograniczyłyby dowodzenie przez AI do małych modułów ze starannie dobranym kontekstem.

Trzecim sygnałem jest integracja z głównonurtowymi agentami programistycznymi i systemami ciągłej integracji. Automatyzacja dowodów staje się operacyjna, gdy pull request może określić wymagany niezmiennik, wygenerować dowód i automatycznie zlecić Lean jego weryfikację.

Proces ten potrzebuje również przejrzystych trybów awarii. Model, który nie potrafi znaleźć dowodu, musi rozróżniać brakujący kontekst, trudne twierdzenie, niezgodny kod i fałszywe stwierdzenie. W przeciwnym razie zespoły otrzymują kolejny nieprzejrzysty czerwony build.

Wdrożenie prawdopodobnie zacznie się tam, gdzie organizacje już zapisują precyzyjne wymagania. Kryptografia, implementacje protokołów, kompilatory, kontrole finansowe i systemy kontroli dostępu pasują do tego opisu. Szersze oprogramowanie biznesowe będzie rozwijać się wolniej.

Pracownicy wiedzy powinni obserwować ten sam wzorzec we własnych narzędziach. Niezawodna automatyzacja potrzebuje jawnych danych wejściowych, reguł akceptacji, śledzalnych dowodów i mechanizmu sprawdzającego uprawnionego do odrzucenia wyniku.

Większość zadań biurowych nie może osiągnąć matematycznej pewności. Nadal mogą przyjąć węższe bramki. Brief badawczy może wymagać datowanych źródeł. Analiza sprzedaży może wymagać, aby każde twierdzenie dotyczące konta mapowało się na rekord klienta. Aktualizacja projektu może oznaczać stwierdzenia niepoparte niedawną pracą.

Ta zmiana przekształca AI z niekontrolowanego autora w generatora kandydatów działającego wewnątrz kontrolowanego procesu. Ludzie zachowują odpowiedzialność za określenie granicy i przegląd tego, czego kontrole nie mogą objąć.

Automatyzacja dowodów Lean oferuje najczytelniejszą wersję tej przyszłości, ponieważ jej mechanizm sprawdzający jest dokładny. Model może być niespójny, rozwlekły lub wielokrotnie błędny podczas poszukiwania. Do programu trafia tylko prawidłowy dowód.

Pytanie na najbliższe kilka miesięcy nie brzmi, czy LLM-y potrafią generować jakiekolwiek formalne dowody. Już potrafią. Pytanie brzmi, czy zespoły potrafią wielokrotnie przekształcać rzeczywiste wymagania w utrzymywane, sprawdzane maszynowo oprogramowanie bez odtwarzania dawnego dziesięciokrotnego obciążenia pracą.

Wybierz jedno kosztowne założenie w swoim procesie pracy i zapisz, co musiałoby się wydarzyć, aby można było je zweryfikować. Jeśli warunek da się sprawdzić, zautomatyzuj tę kontrolę, zanim zautomatyzujesz tworzenie większej ilości wyników. To praktyczna lekcja płynąca z eksperymentu Langleya oraz standard, który automatyzacja musi dziś spełniać.