Automatyzacja dowodów w Lean właśnie przeszła z badań do prawdziwego oprogramowania

Automatyzacja dowodów w Lean przekroczyła praktyczną granicę 26 lipca, gdy inżynier bezpieczeństwa Adam Langley opisał wspomagany przez AI, formalnie zweryfikowany dekoder Zstandard. Według Langleya kilka dużych modeli językowych wygenerowało istotne fragmenty dowodów w około 20 minut. Lean następnie sprawdził te dowody, nie akceptując niedokończonych symboli zastępczych. Eksperyment był niewielki, ale podważa uporczywe założenie dotyczące zweryfikowanego oprogramowania: dowód może już nie kosztować znacznie więcej niż sam program.

Nie oznacza to, że model AI udowodnił poprawność dekodera w jakimś szerokim, filozoficznym sensie. Langley wybrał właściwości, napisał dużą część implementacji i potwierdził, że Lean zaakceptował powstałe termy dowodowe. Jego dekoder był też około dziesięć razy wolniejszy od standardowego polecenia zstd. Rzeczywisty postęp jest węższy i bardziej użyteczny. AI potrafi obecnie wykonać wystarczająco dużo pracy nad formalnymi dowodami, by zmienić ocenę ekonomicznej zasadności projektów inżynieryjnych.

Stawia to zwykłe testowanie i weryfikację formalną w nowej rywalizacji. Testy badają wybrane wykonania, podczas gdy formalny dowód może objąć każde wejście reprezentowane przez twierdzenie. Historycznie tak silna gwarancja wiązała się z wyjątkowo wysokimi kosztami pracy. Słynny projekt systemu operacyjnego seL4 raportował nakłady na dowody znacznie większe niż na implementację. Jeśli AI skraca ten wysiłek, nie wchodząc do zaufanej ścieżki weryfikacji, oprogramowanie oparte na dowodach przestaje wyglądać na specjalizację zarezerwowaną dla jąder systemów i kryptografii.

Co faktycznie zmienił eksperyment z Zstandard w Lean

Najważniejszym wynikiem nie było to, że AI napisała kod. Chodziło o to, że wygenerowana przez AI praca nad dowodami przeszła niezależną kontrolę mechanicznego weryfikatora.

Langley stworzył dekompresor Zstandard w Lean, funkcyjnym języku programowania i interaktywnym asystencie dowodzenia twierdzeń. Zstandard, zwykle skracany do Zstd, to format kompresji stworzony z myślą o szybkiej kompresji bezstratnej. Jego dekoder musi poprawnie interpretować zwarte nagłówki, symbole kodowane entropijnie, długości, przesunięcia i powtarzające się sekwencje.

Te szczegóły tworzą dokładnie takie błędy, których zwykłe systemy typów nie potrafią łatwo wykluczyć. Zdekodowana długość może nie zgadzać się z dostępnymi danymi wejściowymi. Indeks tablicy może przekroczyć granicę. Nieprawidłowo sformowana tabela może wytworzyć stan, który nie powinien istnieć. Programiści zwykle zarządzają tymi możliwościami za pomocą walidacji, kontroli w czasie wykonania, testów, fuzzingu i uważnego przeglądu kodu.

Lean dodaje kolejną możliwość. Jego system typów zależnych pozwala typowi uwzględniać fakty o wartości. Funkcja może zwrócić zarówno tablicę bajtów, jak i sprawdzoną przez maszynę gwarancję, że tablica ma żądaną długość. Późniejszy kod może wykorzystać tę gwarancję podczas dostępu do elementu.

Langley pokazał ten wzorzec w gałęzi dekodera dla kodowania run-length. Gałąź musiała odczytać jeden bajt z bloku. Lean wymagał dowodu, że blok zawiera ten bajt. Implementacja połączyła żądaną długość odczytu z twierdzeniem pokazującym, że ten typ bloku zawsze ma rozmiar zawartości równy jeden.

Ten lokalny dowód był krótki. Bardziej doniosły przykład dotyczył finite state entropy, czyli FSE, którego Zstandard używa do efektywnego reprezentowania symboli. Langley zaimplementował algorytm budowania tabeli opisany przez format, a następnie poprosił systemy AI o udowodnienie uniwersalnych właściwości jego wyniku.

Żądane właściwości wykraczały poza testy oparte na przykładach. Obejmowały rozmiar tabeli, liczbę wpisów przypisanych do każdego symbolu oraz poprawne przejścia w obrębie tabeli. Innymi słowy, dowód opisywał reguły strukturalne, które powinny obowiązywać dla wszystkich akceptowanych rozkładów, a nie tylko dla trzech wektorów testowych dostarczonych przez specyfikację.

Langley informuje, że kilka LLM-ów ukończyło te dowody w około 20 minut. Twierdzi również, że praca zużyła jedynie ułamek standardowego miesięcznego limitu subskrypcji. Modele zmodyfikowały część jego implementacji, ponieważ jej imperatywna struktura opierała się mechanizmom dowodzenia Lean. Następnie potwierdził, że końcowe dowody przeszły sprawdzenie typów i nie zawierały sorry, jawnego znacznika Lean dla niedokończonego dowodu.

Pełne omówienie, w tym fragmenty kodu i ograniczenia, znajduje się w oryginalnym wpisie o automatyzacji dowodów. Nie opublikował repozytorium dekodera, więc zewnętrzni programiści nie mogą jeszcze odtworzyć każdego twierdzenia. Pozostaje to relacją z doświadczenia, a nie niezależnie porównanym wynikiem.

Mimo to eksperyment ustanawia wiarygodny przepływ pracy. Człowiek formułuje niezmiennik. AI szuka dowodu i w razie potrzeby przekształca kod. Lean sprawdza wytworzony term dowodowy. Model dostarcza pracę, ale to weryfikator decyduje o akceptacji.

To rozdzielenie odróżnia ten wynik od typowej demonstracji programowania z AI.

Dlaczego automatyzacja dowodów w Lean ma znaczenie dla pracowników wiedzy

Automatyzacja dowodów ma znaczenie, ponieważ może przekształcić ważne założenia z prozy w sprawdzone, wielokrotnego użytku artefakty pracy.

Większość pracowników wiedzy nie pisze dekoderów kompresji. Mimo to pracują w systemach zbudowanych z nieudokumentowanych założeń. Model finansowy zakłada, że jedna kolumna zawiera unikalne identyfikatory. Proces dotyczący polityk zakłada, że każda akceptacja ma przypisanego odpowiedzialnego właściciela. Proces badawczy oczekuje, że każdy cytat zachowa swoje źródło.

Zespoły często wyrażają te reguły w dokumentacji, komentarzach, materiałach wdrożeniowych lub notatkach ze spotkań. Reguły słabną, gdy praca przechodzi między narzędziami i działami. Zmieniona nazwa pola, nietypowy rekord lub zmodyfikowany proces mogą je unieważnić bez wywołania natychmiastowego ostrzeżenia.

Metody formalne rozwiązują podobny problem w oprogramowaniu. Przekształcają wybrane założenia w stwierdzenia wystarczająco precyzyjne, by maszyna mogła je sprawdzić. Lean wykorzystuje typy zależne, co oznacza, że typy mogą zależeć od wartości, a tym samym kodować szczegółowe relacje między wejściami i wyjściami.

Język nie uruchamia po prostu wygenerowanego przez AI skryptu dowodowego i nie ufa jego wnioskowi. Taktyki Lean konstruują termy dowodowe, czyli niezależnie sprawdzalne reprezentacje argumentu. Niewielkie jądro następnie weryfikuje, czy każdy term wynika z logicznych reguł systemu. Oficjalna dokumentacja jądra Lean opisuje to rozdzielenie wygodnej automatyzacji od zaufanego sprawdzania.

Ta architektura zmienia kalkulację ryzyka związanego z AI. Model językowy może halucynować taktyki, błędnie zrozumieć definicję lub dążyć do fałszywego celu. Większość takich niepowodzeń skutkuje odrzuconym kodem, a nie po cichu zaakceptowanym twierdzeniem. Model może być zawodny, podczas gdy końcowa bramka akceptacji pozostaje rygorystyczna.

Nie czyni to całego przepływu pracy wolnym od błędów. Poprawny dowód może ustanawiać niewłaściwe stwierdzenie. Definicje mogą pomijać zachowanie w świecie rzeczywistym. Importowane biblioteki mogą wprowadzać założenia. Zweryfikowana funkcja na poziomie kodu źródłowego może nadal zależeć od niezweryfikowanego kompilatora, systemu operacyjnego lub procesora.

Własne wskazówki Lean dotyczące walidacji dowodów podkreślają te granice. Akceptacja przez jądro pokazuje, że twierdzenie wynika z jego definicji i zależności. Nie pokazuje, że twierdzenie oddaje to, co człowiek zamierzał wyrazić.

Dla pracowników wiedzy to rozróżnienie przypomina arkusz kalkulacyjny z bezbłędnymi formułami, ale niewłaściwą definicją biznesową. Obliczenia mogą być wewnętrznie spójne, a mimo to odpowiadać na złe pytanie. Formalizacja przenosi najtrudniejszy przegląd w stronę specyfikacji.

To wartościowa zmiana. Ludzie zwykle lepiej oceniają intencję i kontekst niż tysiące mechanicznych kroków dowodowych. AI może przejąć większą część powtarzalnego wyszukiwania, podczas gdy ludzie analizują to, co rzeczywiście musi być prawdziwe.

Ten sam wzorzec pojawia się już w praktycznej pracy z informacjami. AI tworzy szkice podsumowań, klasyfikacji, zapytań i transformacji. Odpowiedzialny przepływ pracy następnie sprawdza wynik względem materiału źródłowego, schematów, ograniczeń lub deterministycznych obliczeń. Automatyzacja dowodów stosuje ten wzorzec na znacznie bardziej rygorystycznym poziomie.

Wyjaśnia też, dlaczego osobisty kontekst pozostaje ważny. Model nie może chronić niezmiennika, którego nigdy nie widzi. Zespoły potrzebują dostępu do zapisów decyzji, specyfikacji, przykładów i wyjątków definiujących poprawne zachowanie. Dobrze utrzymywana osobista baza wiedzy staje się częścią dyscypliny pracy z danymi wejściowymi, nawet gdy formalne dowodzenie pozostaje działalnością specjalistyczną.

Bezpośrednią szansą nie jest formalizowanie każdej notatki. Chodzi o identyfikowanie kosztownych założeń, które już zachowują się jak ukryte specyfikacje. Takie założenia często znajdują się na granicy między systemami, zespołami lub obowiązkami regulacyjnymi.

Nowa rywalizacja dotyczy kosztu dowodu i wartości weryfikacji

AI zmienia weryfikację formalną tylko wtedy, gdy redukuje pracę nad dowodami szybciej, niż zwiększa pracę nad specyfikacją i utrzymaniem.

Weryfikacji formalnej nigdy nie brakowało przekonujących rezultatów. Mikrojądro seL4 stanowi wyrazisty przykład. Jego dowody sprawdzone przez maszynę łączą implementacje z formalnymi specyfikacjami i obejmują właściwości, których samo testowanie nie jest w stanie ustalić.

Oficjalne materiały dotyczące weryfikacji seL4 wyjaśniają, że obsługiwane konfiguracje mają dowody poprawności funkcjonalnej na poziomie kodu. Niektóre konfiguracje rozszerzają te gwarancje na kod binarny. Projekt pokazuje, co metody formalne mogą zapewnić, gdy stawka uzasadnia trwały wysiłek specjalistów.

Pokazuje też, dlaczego wdrażanie pozostało ograniczone. Langley przytacza retrospektywę seL4, według której inżynierowie poświęcili około dziesięć razy więcej wysiłku na dowodzenie niż na projektowanie i implementację. Zauważa również, że kod dowodów przekroczył objętość implementacji w C ponad dwudziestokrotnie.

Tych proporcji nie należy traktować jako uniwersalnego podatku. seL4 dążył do wyjątkowo silnego poziomu zapewnienia jakości w złożonym jądrze systemu operacyjnego. Różne właściwości, języki i łańcuchy narzędzi generują różne koszty. Mimo to liczby te dobrze oddają historyczny problem: wysiłek dowodowy może zdominować realizację projektu.

Tradycyjna automatyzacja dowodów zmniejsza część tego obciążenia. Upraszczacze, procedury decyzyjne, solwery SAT i solwery SMT mogą rozwiązać wiele celów. Programiści często jednak muszą strukturyzować kod i lematy wokół tego, z czym każdy solwer radzi sobie dobrze.

Langley opisuje to jako rozwijanie szóstego zmysłu, by utrzymać zadowolenie solwera. Cel poza korzystnym fragmentem może skierować automatyczne wyszukiwanie na nieproduktywną ścieżkę. Inżynierowie poświęcają wtedy czas na przełożenie problemu na formę, którą narzędzie potrafi rozwiązać.

LLM-y wnoszą inną zdolność. Mogą czytać otaczające definicje, analizować komunikaty błędów, próbować taktyk, wprowadzać pośrednie lematy i poprawiać implementację. Nie wymagają, by każdy problem mieścił się w jednej ustalonej procedurze decyzyjnej.

Ta elastyczność czyni AI użyteczną jako warstwę orkiestracji nad istniejącymi narzędziami dowodowymi. Model może wywoływać deterministyczne taktyki tam, gdzie pasują, pisać jawny argument w innych miejscach i wykorzystywać informacje zwrotne Lean do naprawiania błędów. Model przeszukuje strategie dowodowe, podczas gdy jądro zapewnia twardy test akceptacji.

Doświadczenie Langleya ujawnia również istotny koszt. Jego asystenci AI zmienili kod budowania tabeli, ponieważ użył zbyt dużo Id.run, sposobu wyrażania obliczeń imperatywnych w Lean. Pierwotny kod mógł być czytelny i wykonywalny, ale był mniej przyjazny dla dowodów.

To inżynieria dowodów: praca polegająca na strukturyzowaniu programów i lematów tak, by dowody pozostawały możliwe i łatwe w utrzymaniu. AI może obniżyć jej koszt, ale nie usuwa podstawowego napięcia. Kod zoptymalizowany pod kątem znajomości dla ludzi, wydajności w czasie wykonania i prostoty dowodzenia nie zawsze będzie miał jeden wspólny kształt.

Pytanie ekonomiczne się więc zmienia. Zespoły nie pytają już tylko: „Czy potrafimy to udowodnić?”. Pytają: „Czy AI może utrzymywać dowód i jego strukturę wspierającą równie szybko, jak deweloperzy zmieniają produkt?”

Sprzyja to oprogramowaniu ze stabilnymi, wyraźnie określonymi granicami. Parsery, polityki autoryzacji, maszyny stanów protokołów, obliczenia finansowe i transformacje danych często ujawniają jasne własności. Ich tryby awarii również uzasadniają większy poziom pewności.

AWS dostarcza użytecznego porównania produkcyjnego za pośrednictwem Cedar, swojego języka polityk autoryzacji. AWS utrzymuje wykonywalne modele Lean obok implementacji w Rust i wykorzystuje dowody wraz z testami różnicowymi. Opublikowany opis zweryfikowanego rozwoju wskazuje, że wydania Cedar wymagają aktualnych modeli, dowodów i testów.

Cedar nie dowodzi, że każda aplikacja powinna zostać przeniesiona do Lean. Pokazuje jednak, że artefakty formalne mogą funkcjonować w rzeczywistym procesie wydawniczym. Wspomagane przez AI wyszukiwanie dowodów może poszerzyć grono zespołów zdolnych utrzymać taki proces.

Najsilniejszym modelem w krótkim terminie prawdopodobnie pozostanie model hybrydowy. Inżynierowie implementują kod produkcyjny w języku głównego nurtu. Formalizują zachowania o wysokiej wartości w Lean. Testy porównują obie implementacje, podczas gdy dowody ustanawiają własności modelu.

Langley wybrał bardziej bezpośrednią drogę, implementując dekoder w samym Lean. Stworzyło to silne powiązania między kodem a twierdzeniem, ale wiązało się z dużą karą wydajnościową. Wybór między zweryfikowanymi modelami a zweryfikowanym kodem produkcyjnym pozostaje kluczowy.

Czego dowód nie dowodzi

Dowód sprawdzony przez kernel może wyeliminować jedną klasę niepewności, pozostawiając otwartą specyfikację, granicę implementacji i środowisko działania.

Tytuł „Mamy już automatyzację dowodów” jest celowo prowokacyjny. Eksperyment potwierdza to w sensie praktycznym, lecz tylko w określonych granicach. Nie dowodzi, że LLM może samodzielnie weryfikować dowolne oprogramowanie produkcyjne.

Po pierwsze, kod źródłowy nie jest dostępny. Langley mówi, że zweryfikował, iż dowody przechodzą sprawdzanie typów i nie zawierają niedokończonych symboli zastępczych. Czytelnicy mogą ocenić jego rozumowanie i przykłady, ale nie mogą odtworzyć całego procesu budowania.

Po drugie, praca dotyczyła zabawkowego dekodera. Zstandard jest poważnym formatem, a konstrukcja tabel FSE nie jest trywialna. Projekt nie mierzył się jednak z wieloletnimi zmianami funkcji, wieloma zespołami, kompatybilnością wsteczną, wrogimi środowiskami integracyjnymi ani presją incydentów produkcyjnych.

Po trzecie, dekoder był około dziesięć razy wolniejszy od standardowej implementacji wiersza poleceń. Ta różnica ma znaczenie. Oprogramowanie nie może rezygnować ze swoich podstawowych wymagań operacyjnych tylko dlatego, że jego dowody są eleganckie.

Langley badał, czy zweryfikowany asembler mógłby rozwiązać problem wydajności. Rozważał użycie frameworka LNSym od AWS, aby udowodnić, że zoptymalizowany asembler AArch64 odpowiada funkcjom Lean. Małe przykłady działały, ale w jego testach podejście nie skalowało się. Jeden niewielki przykład wykorzystujący bv_decide, taktykę dla skończonych twierdzeń o wektorach bitowych, wymagał więcej pamięci, niż miała jego maszyna.

To przypomnienie, że sprawdzanie nie jest bezpłatne. Przetworzenie termu dowodu przez kernel może być kosztowne. Zautomatyzowane wyszukiwania mogą wyczerpać pamięć lub czas. Teoretycznie poprawny przepływ pracy może mimo to przekroczyć budżet procesu budowania.

Po czwarte, modele musiały zmieniać implementację. Nie jest to z natury złe. Dowód może ujawnić, że struktura programu ukrywa zależności, na których on polega. Refaktoryzacja w kierunku jawnych niezmienników może poprawić łatwość utrzymania.

Jednak refaktoryzacja generowana przez AI może również zmienić zachowanie lub pogorszyć wydajność. Końcowe twierdzenie chroni wyłącznie własności, które stwierdza. Inżynierowie nadal potrzebują testów, benchmarków, przeglądu kodu i modelowania zagrożeń dla wszystkiego, co znajduje się poza tymi własnościami.

Po piąte, ludzka specyfikacja pozostaje najbardziej wrażliwym punktem. Jeśli twierdzenie o dekoderze dowodzi poprawności tabeli, ale pomija przepełnienie liczby całkowitej w innym miejscu, zweryfikowana własność pozostaje prawdziwa, lecz niepełna. Jeśli sformalizowane zachowanie Zstandard różni się od rzeczywistego formatu, Lean może wiernie zweryfikować niewłaściwy model.

Odpowiedni format kompresji opisano w RFC 8878, lecz przekształcenie standardu pisanego prozą w definicje wymaga interpretacji. Dwuznaczność nie znika, gdy trafia do systemu dowodzenia twierdzeń. Staje się decyzją modelującą.

Ryzyko to rośnie, gdy niespecjaliści polegają na AI przy generowaniu zarówno stwierdzenia, jak i dowodu. Model może ułatwić udowodnienie twierdzenia, osłabiając je. Może wybrać wygodną definicję, która wyklucza problematyczne dane wejściowe. Może zadowolić sprawdzacz, jednocześnie rozmijając się z intencją recenzenta.

Oznacza to, że przegląd dowodów będzie potrzebował innego interfejsu. Recenzenci powinni otrzymywać objaśnienia każdego twierdzenia w prostym języku, jego założeń, importowanych aksjomatów, objętych ścieżek kodu i wykluczonych zachowań. Sam zielony znacznik wyboru nie wystarczy.

Organizacje będą również potrzebować śledzalności między decyzjami biznesowymi a definicjami formalnymi. Gdy zmienia się polityka, ktoś musi wiedzieć, które twierdzenie ją koduje. Gdy zmienia się implementacja, system musi wskazać, które gwarancje wymagają ponownego rozważenia.

To obszar, w którym pomoc AI może wykraczać poza pisanie taktyk. Agent może pobrać odpowiednią specyfikację, odwzorować zmianę kodu na dotknięte niezmienniki i podsumować niespełnione zobowiązania. Przeszukiwalna baza wiedzy może połączyć kontekst projektowy z artefaktami formalnymi.

Żadne z tych ograniczeń nie przekreśla wyniku. Określają one pracę potrzebną, aby przekształcić go z intrygującego eksperymentu w niezawodną praktykę inżynierską.

Automatyzacja dowodów Lean wywiera presję na narzędzia do kodowania AI

Gdy model potrafi wygenerować kod i sprawdzalny dowód, stwierdzenie „testy przeszły” zaczyna wyglądać na niepełną deklarację jakości.

Produkty AI do kodowania konkurują obecnie pod względem realizacji zadań, rozumienia repozytoriów, użycia narzędzi, wyników benchmarków i doświadczenia deweloperów. Ich bramki jakości nadal przypominają konwencjonalny rozwój oprogramowania. Agenci uruchamiają testy, lintery, narzędzia do sprawdzania typów, skanery bezpieczeństwa i procesy przeglądu przez ludzi.

Te kontrole są ważne, lecz większość z nich nie ustanawia zachowania uniwersalnego. Test jednostkowy dowodzi, że jedno wybrane wejście dało jeden oczekiwany wynik podczas jednego uruchomienia. Fuzzing rozszerza pokrycie za pomocą generowanych wejść, ale nadal próbuje jedynie wykonania programu. Analiza statyczna może obejmować szersze klasy, lecz każdy analizator działa w ramach określonych przybliżeń.

Twierdzenie może stwierdzać, że każde zaakceptowane wejście spełnia wybraną własność. Jeśli Lean sprawdzi dowód, gwarancja nie zależy od zaufania do modelu, który go wygenerował. To przekonujące wyróżnienie produktu dla agentowych systemów kodowania.

Presja pojawi się najpierw w wąskich zadaniach. Agent AI może wygenerować parser wraz z dowodem, że udane parsowanie nigdy nie przekracza granicy wejścia. Może zaimplementować regułę kontroli dostępu z twierdzeniem wykluczającym nieautoryzowane przejścia. Może utworzyć migrację bazy danych i udowodnić zachowanie niezmiennika schematu w modelu formalnym.

Narzędzia głównego nurtu nie muszą ujawniać składni Lean każdemu użytkownikowi. Mogą oferować formalną weryfikację jako dodatkowy tryb walidacji. Interfejs mógłby prosić deweloperów o zatwierdzenie własności opisanych prostym językiem, pokazywać ich formalne tłumaczenia oraz zwracać sprawdzone dowody albo konkretne kontrprzykłady.

Decydującą funkcją nie będą surowe wyniki w dowodzeniu twierdzeń. Będzie nią integracja. Automatyzacja dowodów musi współpracować z kontekstem repozytorium, systemami budowania, specyfikacjami, testami wydajnościowymi i przeglądem kodu.

Eksperyment Langleya dostarcza użytecznej lekcji produktowej. Modele działały interaktywnie. Napotykały kod opierający się dowodzeniu, zmieniały jego strukturę i kontynuowały, aż sprawdzacz zaakceptował wynik. Przypomina to bardziej agenta inżynierskiego niż system autouzupełniania.

Sugeruje również nową formę odpowiedzialności. Generowanie kodu przez AI często tworzy asymetrię: model może tworzyć kod szybciej, niż człowiek jest w stanie go zrecenzować. Agenci tworzący dowody mogą dołączać sprawdzalne maszynowo uzasadnienie do wybranych twierdzeń.

To uzasadnienie nie czyni przeglądu opcjonalnym. Pozwala recenzentom poświęcać mniej czasu na symulowanie mechanicznego działania, a więcej na analizę twierdzenia. Kluczowe pytanie staje się: „Czy jest to własność, której potrzebujemy?”, zamiast: „Czy model przeoczył gdzieś przypadek indeksu?”

Konkurenci mogą odpowiedzieć kilkoma drogami. Mogą integrować Lean bezpośrednio, łączyć modele z innymi asystentami dowodzenia, tworzyć certyfikaty dla wyspecjalizowanych solverów albo łączyć modele formalne z konwencjonalnym kodem. Zwycięskie podejście może różnić się zależnie od domeny.

Lean ma przewagę, ponieważ wspiera programowanie, dowodzenie twierdzeń, metaprogramowanie i szeroką automatyzację w jednym środowisku. Jego kernel zapewnia również wyraźną granicę zaufania. Lean nie jest jednak automatycznie właściwym językiem wdrożeniowym dla oprogramowania wrażliwego na wydajność.

AI tworząca dowody będzie zatem konkurować z potokami programistycznymi sprawdzającymi dowody, a nie tylko z innymi LLM-ami. Niezawodną jednostką jest cały system: model, formalne stwierdzenie, narzędzia dowodowe, kernel, założenia kompilatora, testy i recenzenci.

Dla pracowników wiedzy kupujących produkty AI tworzy to lepsze pytanie niż pytanie o dokładność modelu dostawcy. Zapytaj, które wyniki otrzymują deterministyczną walidację, które twierdzenia mają sprawdzalne uzasadnienie, a które nadal zależą od probabilistycznego osądu.

Automatyzacja dowodów dostarcza najsilniejszej wersji tego wzorca. Nie będzie miała zastosowania do każdego zadania, ale podnosi oczekiwania wobec każdego wyniku, który można formalnie określić.

Trzy sygnały pokażą, czy stanie się to normalną praktyką inżynierską

Kolejny etap zależy od odtwarzalności, utrzymania przy zmianach oraz funkcji wspieranych dowodami w codziennych narzędziach programistycznych.

Pierwszym sygnałem jest publiczne, odtwarzalne repozytorium oprogramowania porównywalne z eksperymentem Langleya. Deweloperzy muszą mieć możliwość sprawdzenia definicji, promptów lub śladów agenta, termów dowodowych, aksjomatów, czasów budowania i wymagań sprzętowych. Niezależne zespoły powinny móc ponownie uruchomić proces i testować alternatywne modele.

Odtwarzalność wzmocniłaby twierdzenie, że obecne LLM-y potrafią obsługiwać znaczącą pracę dowodową. Brak możliwości jej odtworzenia zawęziłby wynik do konfiguracji i osądu jednego wykwalifikowanego inżyniera. Oba rezultaty poprawiłyby dostępne dowody.

Drugim sygnałem jest wydajność w obliczu zmieniającego się kodu. Jednorazowy dowód może ukrywać znaczną pomoc człowieka. Bardziej wymagającym testem jest to, czy agent potrafi naprawiać dowody po realistycznych zmianach implementacji, bez osłabiania twierdzenia lub zniekształcania programu.

Zespoły powinny mierzyć czas naprawy dowodów, interwencje człowieka, koszt obliczeniowy, zmiany twierdzeń i regresje wydajności. Powinny również śledzić, jak często nieudany dowód ujawnia rzeczywisty błąd, zamiast nieszkodliwej zmiany strukturalnej.

Jeśli naprawa pozostanie szybka przez kilka miesięcy rozwoju, AI zmniejszy obciążenie utrzymaniowe inżynierii dowodów. Jeśli każda zmiana wywoła rozległą restrukturyzację, formalna weryfikacja pozostanie ograniczona do stabilnych komponentów o wysokiej wartości.

Trzecim sygnałem jest integracja produktowa. Warto obserwować agentów kodujących, którzy oferują własności sprawdzone przez kernel jako standardowy wynik, zwłaszcza dla parserów, silników polityk, implementacji protokołów i kodu przetwarzającego dane.

Wiarygodny produkt powinien oddzielać generowanie twierdzeń od ich sprawdzania. Powinien wyświetlać założenia, odrzucać niedokończone dowody, zachowywać logi weryfikacji i ostrzegać, gdy zmiana kodu unieważnia gwarancję. Powinien również zachować testowanie i benchmarki w przepływie pracy.

Jeśli te funkcje pojawią się w narzędziach głównego nurtu, automatyzacja dowodów Lean wyjdzie poza demonstracje dowodzenia twierdzeń. Jeśli pozostaną ograniczone do repozytoriów badawczych, wzrost produktywności nie przezwyciężył jeszcze kosztów integracji.

Dla pracowników wiedzy praktyczną odpowiedzią jest przygotowywanie lepszych specyfikacji. Dokumentuj decyzje definiujące poprawne działanie. Zachowuj materiały źródłowe. Wskazuj niezmienniki, których błędne zrozumienie prowadzi do kosztownych awarii. Wyraźnie określaj wyjątki.

Następnie zadaj trafniejsze pytanie o każdy proces pracy z AI: które wyniki można poddać wiarygodnej, niezależnej weryfikacji?

Dekoder Langley nie dowodzi, że całe oprogramowanie może zostać formalnie zweryfikowane. Pokazuje, że AI zaczęła mierzyć się z barierą kosztową, podczas gdy Lean zachowuje rygorystyczną bramkę końcową. To wystarczy, by zmienić mapę drogową.

Najbliższa przyszłość nie należy do oprogramowania pisanego przez nieomylne modele. To oprogramowanie proponowane przez omylne modele, ograniczane przez lepsze specyfikacje i sprawdzane przez systemy, którym nie zależy na tym, jak pewnie brzmi model.