Automatyzacja dowodów Lean właśnie przeszła test prawdziwego oprogramowania, ale dowód nie jest gotowy do produkcji

Automatyzacja dowodów Lean przekroczyła ważną granicę 26 lipca, choć wciąż daleko jej do wydania oprogramowania gotowego do produkcji. Inżynier bezpieczeństwa Adam Langley stworzył działający dekompresor Zstandard w Lean, a następnie wykorzystał kilka dużych modeli językowych do wygenerowania dowodów sprawdzanych maszynowo dla jego najtrudniejszej logiki.

Eksperyment nie przyniósł szybszego dekompresora, opublikowanej biblioteki ani dowodu, że AI potrafi zweryfikować dowolną dużą aplikację. Langley twierdzi, że jego wersja działa około dziesięciu razy wolniej niż standardowe polecenie zstd. Opisuje też implementację jako projekt edukacyjny i nie zdecydował się opublikować jej kodu.

Zmiana jest węższa, ale bardziej doniosła. System AI wygenerował dowody dla nietrywialnego oprogramowania, a Lean niezależnie sprawdził, czy są one poprawne. To przenosi weryfikację wspomaganą przez AI poza płynne wyjaśnienia i wiarygodnie brzmiący kod — do przepływu pracy z wyjątkowo rygorystycznym testem akceptacji.

Głównym starciem nie jest już kod generowany przez AI kontra kod pisany przez ludzi. Chodzi o probabilistyczne generowanie kontra deterministyczną weryfikację. Model może zgadywać, poprawiać i wielokrotnie ponosić porażkę, podczas gdy niewielki zaufany weryfikator decyduje, co trafia do gotowego programu.

Dla programistów ten wzorzec oferuje możliwą odpowiedź na niewiarygodnych agentów kodujących. Dla pracowników wiedzy sugeruje szerszy model automatyzacji: pozwolić AI stworzyć chaotyczną pierwszą wersję, ale uzależnić akceptację od jawnych warunków, które można sprawdzić maszynowo.

Eksperyment ze Zstandard uczynił automatyzację dowodów konkretną

Test Langleya ma znaczenie, ponieważ zastosował dowody generowane przez AI do zwykłego oprogramowania systemowego, a nie do kolejnego odizolowanego benchmarku matematycznego.

Lean jest jednocześnie językiem programowania i interaktywnym asystentem dowodzenia twierdzeń. Jego typy zależne pozwalają, by typy programu obejmowały fakty o wartościach, takie jak dokładna długość tablicy lub relacja między kilkoma wynikami.

Ta możliwość zmienia zakres obietnic składanych przez sygnaturę funkcji. Zwykła funkcja odczytująca plik może zwracać tablicę bajtów. Funkcja Lean może zwracać tablicę wraz z dowodem, że jej długość odpowiada żądanej liczbie bajtów.

Oficjalna dokumentacja Lean wyjaśnia, dlaczego ta architektura ma nietypową wartość dla pracy generowanej przez AI. Taktyki Lean mogą być złożone i zautomatyzowane, ale każdy tworzony przez nie termin dowodowy przechodzi przez stosunkowo niewielkie jądro.

Błędna taktyka może marnować czas lub wygenerować nieprawidłowego kandydata. Nie może uznać nieprawidłowego dowodu za poprawny, chyba że wada występuje również w zaufanym fundamencie. Ostatecznym autorytetem pozostaje weryfikator, a nie generator.

Langley wybrał Zstandard, ponieważ stanowił on istotne wyzwanie implementacyjne. Zstandard, zwykle nazywany zstd, jest bezstratnym formatem kompresji opartym na dopasowywaniu w stylu LZ77 oraz dwóch systemach kodowania entropijnego.

Jego specyfikacja formatu przypisuje kodowanie Huffmana danym literalnym, a Finite State Entropy, czyli FSE, innym symbolom i nagłówkom Huffmana. FSE wykorzystuje stan przenoszony między symbolami, co wymaga dekodowania strumieni bitów w odwrotnej kolejności niż kolejność zapisu.

Ta mechanika jest znacznie bardziej wymagająca niż udowodnienie, że dwa krótkie wyrażenia arytmetyczne są równe. Dekompresor musi analizować zwarte struktury binarne, utrzymywać stan, odrzucać nieprawidłowe dane wejściowe i poprawnie odtwarzać oryginalne bajty.

Eksperyment Lean Langleya zwrócił szczególną uwagę na konstrukcję tablicy FSE. Tablica określa, jak skompresowane stany są mapowane z powrotem na symbole oraz ile bitów zużywa dekoder.

Jak podano, kilka LLM-ów wygenerowało w około 20 minut dowód istotnej własności tego kodu budującego tablicę. Langley sprawdził, że wynikowe dowody przechodzą kontrolę typów Lean i nie zawierają deklaracji sorry, czyli mechanizmu Lean umożliwiającego tymczasowe przyjęcie nieudowodnionego stwierdzenia.

Modele musiały jednak zmienić część decyzji implementacyjnych. Langley użył Id.run, aby wyrazić fragmenty algorytmu w bardziej imperatywnym stylu, co utrudniało korzystanie z mechanizmów dowodowych.

Ten szczegół nie pozwala na uproszczoną interpretację wyniku. AI nie tylko przeanalizowała niezmienny kod i dołączyła certyfikat. Pomogła przekształcić implementację w formę wspierającą konstrukcję dowodów.

Mimo to wynik zamknął pełną pętlę: napisać znaczące oprogramowanie, sformułować silny niezmiennik, wygenerować dowód i poprosić niezależne jądro o jego przyjęcie lub odrzucenie. To właśnie ta pętla jest prawdziwym wydarzeniem.

Automatyzacja dowodów Lean mierzy się z problemem kosztu weryfikacji

Weryfikacja formalna zapewniała wcześniej wyjątkową pewność, lecz nakład pracy związany z dowodami trzymał ją poza większością codziennych projektów programistycznych.

Najwyraźniejszym historycznym przykładem jest seL4, niewielkie jądro systemu operacyjnego wsparte dowodami sprawdzanymi maszynowo. Jego zweryfikowane własności obejmują znacznie więcej niż przechodzenie testów na wybranym zbiorze danych wejściowych.

Oryginalna weryfikacja wymagała około 20 osobolat pracy rozłożonych na cztery lata i zaowocowała ponad 200 000 linii skryptu dowodowego Isabelle. Retrospektywa opisana w badaniach seL4 pokazuje, dlaczego tych liczb nie można zbyć jako akademickiej przesady.

Zespoły weryfikacyjne muszą zdefiniować właściwe własności, połączyć różne warstwy abstrakcji, konstruować dowody i utrzymywać ich zgodność ze zmieniającym się kodem. Każde z tych zadań wymaga specjalistycznej wiedzy i starannej pracy inżynierskiej.

Korzyści mogą być znaczne. Projekt seL4 informuje, że od ukończenia głównego dowodu w 2009 roku w zweryfikowanym kodzie nie wykryto defektów poprawności funkcjonalnej. Większość zespołów programistycznych nie może jednak zainwestować lat specjalistycznej pracy przed wydaniem jednego komponentu.

Tradycyjna automatyzacja dowodów zmniejsza część tego obciążenia. Taktyki potrafią rozwiązywać znane wzorce, podczas gdy solvery spełnialności modulo teorii, znane jako solvery SMT, rozstrzygają warunki logiczne w obsługiwanych dziedzinach.

Systemy te wpływają również na sposób, w jaki programiści piszą zweryfikowany kod. Doświadczeni użytkownicy uczą się, które sformułowania solver potrafi obsłużyć, a które pozornie nieszkodliwe struktury powodują niekontrolowany wzrost przestrzeni przeszukiwania.

Langley argumentuje, że LLM-y zmieniają tę ekonomię, ponieważ są elastycznymi generatorami dowodów. Potrafią czytać otaczające definicje, analizować komunikaty o błędach, przepisywać lokalny kod, proponować lemata pośrednie i próbować innej drogi po odrzuceniu.

Nierelewantność dowodów wzmacnia ten argument. W Lean zdania należą do uniwersum nieistotnego dla dowodów, co oznacza, że systemowi zazwyczaj zależy na istnieniu poprawnego dowodu, a nie na tym, który poprawny dowód został dostarczony.

Ludzki inżynier dowodów często ceni elegancję, ponieważ jasny dowód może łatwiej przetrwać późniejsze zmiany. Jeśli LLM potrafi szybko ponownie wygenerować sprawdzony dowód, część tej kalkulacji utrzymaniowej się zmienia.

Nie eliminuje to inżynierii dowodów. Ktoś nadal musi sformułować właściwe twierdzenie, zdefiniować zaufaną granicę i zdecydować, czy regenerowanie dowodu po każdej zmianie pozostaje opłacalne.

Osłabia jednak jeden ważny zarzut. Brzydki wygenerowany kod jest niebezpieczny, gdy programiści nie potrafią pewnie ocenić jego działania. Brzydki wygenerowany dowód budzi mniejsze obawy, gdy zaufane jądro odrzuca każdą nieprawidłową wersję.

Wyłaniający się przepływ pracy przypomina raczej kompilację niż wspólne rozumowanie. Programiści określają własność, agent szuka akceptowalnego artefaktu, a weryfikator decyduje, czy kompilacja się powiedzie.

Ta różnica ma znaczenie dla menedżerów decydujących, gdzie powinno znaleźć się AI. Asystent programistyczny, który twierdzi, że funkcja jest bezpieczna, przedstawia opinię. Asystent tworzący dowody, który zwraca artefakt sprawdzony przez jądro, dostarcza dowodu w ramach zadeklarowanych założeń.

To rozróżnienie ujawnia również nowe wąskie gardło. Jeśli generowanie dowodów stanie się tanie, rzadką umiejętnością będzie pisanie właściwej specyfikacji.

Zespoły będą potrzebowały osób potrafiących przełożyć wymagania na precyzyjne niezmienniki. „Ten parser powinien być bezpieczny” nie jest sprawdzalne. „Każde pomyślne parsowanie pozostaje w granicach dostarczonego bufora wejściowego” jest bliższe własności, którą system formalny może ocenić.

Dla pracowników wiedzy odpowiednikiem jest zdefiniowanie warunków akceptacji przed rozpoczęciem automatyzacji. AI może przygotować prognozę, uzgodnić politykę lub połączyć notatki ze spotkań, lecz godna zaufania automatyzacja wymaga jasnego określenia tego, co musi pozostać prawdziwe.

Nowym przeciwnikiem jest generowanie bez weryfikacji

Najważniejsza lekcja nie polega na tym, że LLM-y stały się niezawodne, lecz na tym, że niewiarygodne generowanie może stać się użyteczne w ramach niezawodnej pętli sprawdzania.

Większość generatywnych produktów AI prosi użytkowników o bezpośrednią ocenę wyników. Model pisze e-mail, podsumowuje spotkanie, edytuje arkusz kalkulacyjny lub proponuje kod. Człowiek następnie szuka subtelnych błędów, dysponując ograniczonym czasem i uwagą.

Ten wzorzec czyni automatyzację atrakcyjną dla prac o niskim ryzyku, ale trudną do zaufania w obszarach bezpieczeństwa, finansów, zgodności z przepisami, infrastruktury i nieodwracalnych zmian operacyjnych. Pewność siebie modelu zapewnia niewielką ochronę, ponieważ płynny język nie stanowi dowodu poprawności.

Automatyzacja dowodów Lean rozdziela dwa zadania. LLM bada dużą przestrzeń możliwych dowodów, podczas gdy asystent dowodzenia wykonuje wąskie zadanie weryfikacyjne według ścisłych reguł.

Generator może halucynować nazwę twierdzenia, zastosować nieprawidłowe przekształcenie lub błędnie zrozumieć definicję. Takie porażki stają się odrzuconymi kandydatami, a nie zaakceptowanymi wnioskami, o ile deklarowana własność i zaufana granica są poprawne.

Najnowsze badania wskazują na systemy budowane wokół tego rozdziału. OpenProver, opublikowany w lipcu 2026 roku, łączy planowanie, agentów wykonawczych i weryfikację Lean w otwartoźródłowym systemie dowodzenia twierdzeń.

Jego architektura przypisuje wyspecjalizowanym agentom różne odpowiedzialności, zachowując automatyczne sprawdzanie formalne. Wspiera też sterowanie przez człowieka, uznając, że przeszukiwanie dowodów nadal korzysta z kierunku wyznaczanego przez ekspertów.

To inny model produktu niż chatbot z oknem kodu. Wartościowym wynikiem nie jest wyjaśnienie modelu, dlaczego dowód powinien działać. Jest nim obiekt dowodowy, który przetrwa niezależne sprawdzenie.

Podobny wzorzec może poprawić zwykłą pracę z wiedzą, nawet gdy pełne dowodzenie twierdzeń nie jest konieczne. Rozważmy menedżera produktu przygotowującego cotygodniową aktualizację na podstawie wywiadów, zgłoszeń, metryk i decyzji.

LLM może szybko przygotować jej wersję roboczą. Każde stwierdzenie faktyczne powinno jednak pozostać możliwe do prześledzenia do źródła, każda metryka powinna zachować swoją datę i definicję, a nierozwiązane sprzeczności powinny pozostać widoczne.

Osobisty system wiedzy może pomóc zachować te powiązania. Na przykład knowledge blending może zgromadzić powiązane lokalne materiały w jednym kontekście roboczym, zamiast zmuszać użytkownika do odtwarzania go z rozproszonych plików.

Nie jest to to samo co dowód matematyczny. Weryfikator może składać się z cytowań źródeł, walidacji schematu, kontroli dostępu, testów arytmetycznych lub etapu zatwierdzenia przez człowieka.

Zasada architektoniczna pozostaje podobna. Swoboda generowania należy przed bramką. Deterministyczne reguły, udokumentowane dowody lub rozliczalny przegląd decydują, co przez nią przechodzi.

Zmienia to również sposób, w jaki zespoły powinny oceniać produktywność AI. Czas zaoszczędzony podczas tworzenia wersji roboczej to tylko jedna miara. Czas przeglądu, częstotliwość poprawek, wskaźnik przenikania defektów oraz jakość materiału dowodowego są równie istotne.

Agent, który tworzy wersje robocze dziesięć razy szybciej, ale podwaja wysiłek potrzebny na przegląd, nie zautomatyzował zadania. Przeniósł pracę do mniej widocznego etapu.

W przeciwieństwie do tego agent, który wolniej dostarcza pierwszy wynik z pełnym pochodzeniem danych i automatyczną walidacją, może zapewnić większą użyteczność w pracy. Dowody zmniejszają niepewność dla każdego kolejnego odbiorcy.

Lean czyni tę zasadę wyjątkowo widoczną, ponieważ warunek akceptacji jest binarny. Dowód przechodzi sprawdzenie albo nie. Większość automatyzacji pracy biurowej nie ma tak wyraźnej granicy, ale zespoły mogą tworzyć mniejsze, dopasowane do zadań bramki.

Podsumowanie finansowe może wymagać, aby każda suma była zgodna z komórkami źródłowymi. Porównanie umów może wymagać, by każda oznaczona różnica prowadziła do konkretnych klauzul. Notatka badawcza może uniemożliwiać trafienie niepopartych cytatów do finalnego dokumentu.

Takie bramki nie czynią bazowego modelu uczciwym ani deterministycznym. Ułatwiają jednak ograniczanie jego słabości.

Czego test Zstandard nie dowodzi

Eksperyment potwierdza obiecujący mechanizm, ale nie dowodzi, że AI może tanio lub całkowicie weryfikować duże systemy produkcyjne.

Najbardziej oczywistym ograniczeniem jest zakres. Langley nazywa dekompresor zabawką, twierdzi, że kod nie został opublikowany, i nie przedstawia go jako wzorca dla innych programistów Lean.

Uniemożliwia to niezależnym recenzentom odtworzenie wyniku, zbadanie dokładnych twierdzeń lub wskazanie niezweryfikowanych komponentów. Na podstawie relacji autora wiemy, że wybrane dowody przeszły kontrolę typów.

Nie wiemy, czy te stwierdzenia obejmują każdą właściwość wymaganą od produkcyjnego dekompresora. Doskonale poprawny dowód niepełnej specyfikacji może współistnieć z poważnymi wadami poza tą specyfikacją.

Często nazywa się to problemem specyfikacji. Weryfikator może ustalić, że kod spełnia formalne stwierdzenie, ale nie potrafi rozstrzygnąć, czy ludzie wybrali właściwe stwierdzenie.

Dekompresor mógłby dowieść, że poprawne dane wejściowe prawidłowo przechodzą pełny cykl, pozostawiając poza twierdzeniem wyczerpanie pamięci, zachowanie w przypadku ataku typu denial-of-service, limity zasobów lub analizę archiwów. Każda pominięta granica tworzy przestrzeń na awarię.

Istotne znaczenie ma także zaufana baza obliczeniowa. Niewielkie jądro Lean znacząco ogranicza liczbę komponentów, którym trzeba zaufać, lecz rzeczywiste programy współdziałają z kompilatorami, systemami operacyjnymi, funkcjami obcymi, sprzętem i zewnętrznymi bibliotekami.

Langley badał wywoływanie zoptymalizowanego asemblera za pośrednictwem mechanizmu extern Lean. Drobne przykłady równoważności działały, ale próby skalowania tego podejścia miały podobno prowadzić do bardzo wysokich wymagań pamięciowych albo nie przynosiły postępu.

Wynik ten uwypukla kluczowy kompromis. Zweryfikowany kod wysokiego poziomu może zapewniać silne gwarancje logiczne, podczas gdy wydajność produkcyjna często zależy od implementacji niskiego poziomu i narzędzi wykraczających poza bezpośredni dowód.

Sama implementacja Zstandard ilustruje tę lukę. Langley podaje, że jego dekoder Lean działa około dziesięć razy wolniej niż standardowa implementacja wiersza poleceń.

Wydajność nie jest drobną kwestią w oprogramowaniu kompresującym. Dekompresja często znajduje się na ścieżce wrażliwej na opóźnienia, obejmującej pamięć masową, dystrybucję pakietów, bazy danych lub transfer sieciowy.

Niepewna pozostaje również konserwacja dowodów. Langley sugeruje, że szybkie ich ponowne generowanie może ograniczyć potrzebę starannego projektowania dowodów pod przyszłe zmiany.

Jest to prawdopodobne w przypadku ograniczonego projektu. Duża baza kodu może tworzyć tysiące współzależnych zobowiązań, gdzie niewielka zmiana typu rozprzestrzenia się po modułach i przekracza możliwości kontekstowe lub budżet wyszukiwania agenta.

Benchmarki badawcze nie powinny samodzielnie rozstrzygać tej kwestii. Zbiory twierdzeń matematycznych zwykle oferują jasno określone cele i kontrolowane środowiska. Kod produkcyjny obejmuje częściowe specyfikacje, starsze interfejsy, zmieniające się zależności i nieudokumentowane założenia.

Istnieje także ryzyko związane z czynnikiem ludzkim. Łatwe generowanie dowodów może wywołać presję, by każde zielone potwierdzenie traktować jako kompleksową gwarancję.

Sprawdzone twierdzenie mówi dokładnie to, co zawiera jego formalne stwierdzenie. Nie daje gwarancji bezpieczeństwa, prywatności, niezawodności ani poprawności biznesowej, chyba że te właściwości znajdują się w modelu.

Zespoły muszą zatem traktować przegląd specyfikacji z taką samą powagą jak obecnie przegląd kodu. W przeciwnym razie AI przyspieszy tworzenie przekonujących odpowiedzi na niepełne pytania.

Automatyzacja dowodów AI przenosi wąskie gardło do specyfikacji

Jeśli modele staną się kompetentnymi generatorami dowodów, cenna praca oparta na wiedzy przesunie się od tworzenia artefaktów ku definiowaniu twierdzeń i granic.

Zespoły programistyczne już doświadczyły wersji tej transformacji. Agenci kodujący obniżają koszt tworzenia funkcji, testów, migracji i dokumentacji.

Gdy wytwarzanie wyników staje się tańsze, większego znaczenia nabiera decyzja o tym, co należy zbudować. Wymagania, interfejsy, ograniczenia, modele zagrożeń i testy akceptacyjne określają, czy szybkie generowanie tworzy wartość, czy jedynie więcej materiału do sprawdzenia.

Lean rozszerza tę zmianę na twierdzenia dotyczące poprawności. Programista może zakodować niezmiennik w typie, poprosić LLM o skonstruowanie dowodu i pozwolić jądru zweryfikować wynik.

Największy wkład człowieka często pojawia się wcześniej. Ktoś musi rozpoznać, który niezmiennik ma znaczenie, wyrazić go bez luk i powiązać z rzeczywistym środowiskiem działania.

Pracownicy wiedzy mierzą się z tą samą strukturą przy mniej formalnych narzędziach. Analityk musi zdecydować, jakie dowody kwalifikują się do poparcia twierdzenia rynkowego. Rekruter musi określić, które kryteria kandydatów są legalne i istotne.

Menedżer wsparcia musi sprecyzować, kiedy można wysłać automatyczną odpowiedź, a kiedy sprawa wymaga eskalacji. Badacz musi odróżnić źródło bezpośrednie, wtórne podsumowanie i niepoparty wniosek.

Są to zadania specyfikacyjne, nawet gdy nikt nie zapisuje ich w Lean. Przekształcają niejasne oczekiwania w obserwowalne warunki.

Organizacje mogą się przygotować, zapisując reguły decyzyjne obok dokumentów, których dotyczą. Notatka mówiąca „użyj najnowszej liczby klientów” jest niejednoznaczna. Reguła wskazująca autorytatywny panel, czas odświeżenia, region i okres raportowania jest testowalna.

Równie ważne staje się pochodzenie danych. Model nie może wiarygodnie uzgadniać wiedzy zespołu, jeśli materiały źródłowe utraciły datę, właściciela, wersję lub powiązanie z wcześniejszymi decyzjami.

Dlatego przejście od interfejsów czatowych do systemów agentowych wymaga lepszej architektury informacji. Agenci potrzebują ustrukturyzowanego kontekstu, uprawnień, reguł walidacji i trwałych zapisów wprowadzonych zmian.

Nadzór człowieka również powinien koncentrować się na wyjątkach. Jeśli każde stwierdzenie wygenerowane przez AI wymaga kontroli wiersz po wierszu, system pozostaje asystentem, a nie warstwą automatyzacji.

Użyteczne bramki mogą automatycznie zatwierdzać rutynowe przypadki spełniające jawne warunki. Ludzie skupiają się wtedy na brakujących dowodach, sprzecznych źródłach, nietypowych wartościach, działaniach wrażliwych pod względem bezpieczeństwa i zmianach wykraczających poza znane wzorce.

Formalne asystenty dowodzenia oferują najsilniejszą wersję takiego procesu, ale nie są odpowiednie dla każdego zadania. Wiele decyzji zależy od osądu, spornych definicji lub niepełnych informacji.

Celem nie jest formalizacja każdego e-maila. Chodzi o wskazanie twierdzeń, których błędność wiąże się z realnym kosztem, oraz zbudowanie wokół nich proporcjonalnych kontroli.

W oprogramowaniu może to oznaczać dowodzenie bezpieczeństwa granic w parserze przy jednoczesnym konwencjonalnym testowaniu interfejsu użytkownika. Dla zespołu operacyjnego może to oznaczać automatyczne uzgadnianie sum płatności przy jednoczesnym wymaganiu zatwierdzenia przez człowieka dla przelewów.

Dla badaczy może to oznaczać walidację każdego przypisu i cytowanego fragmentu, przy pozostawieniu interpretacji otwartej na debatę. Weryfikacja powinna chronić granicę, która ma największe znaczenie.

Eksperyment Langleya ułatwia wyobrażenie sobie tej strategii projektowej. LLM nie musiał stać się bezbłędnym matematykiem. Musiał wygenerować artefakt, który bardziej rygorystyczny system mógł ocenić.

To bardziej realistyczna ścieżka dla AI w przedsiębiorstwach niż czekanie, aż modele przestaną popełniać błędy.

Trzy sygnały pokażą, czy ta zmiana jest realna

Kolejny etap zależy od powtarzalności, skali i mierzalnych kosztów utrzymania, a nie od kolejnego imponującego, jednorazowego dowodu.

Pierwszym sygnałem jest opublikowany, odtwarzalny zbiór zwykłego zweryfikowanego oprogramowania. Dekompresor Langleya nie może pełnić tej roli, ponieważ kod źródłowy i dowody są niedostępne.

Projekty takie jak lean-zip stanowią bardziej możliwy do zbadania punkt odniesienia. Współtwórca Lean, Leonardo de Moura, niedawno wskazał go jako zweryfikowany projekt kompresji implementujący zarówno kompresję, jak i dekompresję.

Przyszłe projekty potrzebują precyzyjnych stwierdzeń twierdzeń, udokumentowanych założeń, pomiarów wydajności i testów względem uznanych implementacji. Niezależne zespoły powinny móc odtworzyć każdy dowód oraz wskazać, które moduły pozostają poza zweryfikowaną granicą.

Jeśli kilka projektów powtórzy ten wzorzec w parserach, kodzie sieciowym, formatach przechowywania danych i obsłudze kryptografii, argument za automatyzacją dowodów Lean stanie się silniejszy. Jeśli wyniki pozostaną skupione w małych demonstracjach, szersze twierdzenie osłabnie.

Drugim sygnałem będzie zachowanie generowania dowodów po rzeczywistych zmianach w kodzie. Początkowe konstruowanie dowodów przyciąga uwagę, ale to utrzymanie decyduje o opłacalności.

Zespoły powinny mierzyć czas ponownego generowania po refaktoryzacji, aktualizacjach zależności, zmianach specyfikacji i optymalizacji wydajności. Powinny też rejestrować, jak często ekspert musi przebudować kod lub wymyślić pośrednie lematy.

Szybki sukces przy stabilnym twierdzeniu daje ograniczone dowody dotyczące żyjącej aplikacji. Użyteczny system musi przetrwać miesiące zwykłego rozwoju bez przekształcania każdego pull requestu w nieprzewidywalny projekt wyszukiwania dowodów.

Jeśli koszty dowodów pozostaną ograniczone, a niepowodzenia będą generować praktyczne diagnozy, weryfikacja generowana przez AI może wejść do ciągłej integracji. Jeśli niewielkie zmiany będą uruchamiać godziny nieprzejrzystego wyszukiwania, wdrożenie pozostanie ograniczone.

Trzecim sygnałem jest integracja z głównym nurtem agentów kodujących. Generowanie dowodów znajduje się obecnie blisko procesów badawczych i wyspecjalizowanych środowisk Lean.

Praktyczny punkt zwrotny nastąpi, gdy agent będzie potrafił zaproponować niezmiennik, wyjaśnić jego zakres, wygenerować dowód, uruchomić weryfikator i dokładnie pokazać, które założenia pozostają niezweryfikowane.

Taki interfejs musi przeciwdziałać fałszywemu poczuciu pewności. Powinien odróżniać zachowanie przetestowane od udowodnionego oraz zweryfikowane moduły od niezweryfikowanych otoczek.

Powinien także wyraźnie uwidaczniać zmiany twierdzeń. Agent nigdy nie może „naprawiać” nieudanego dowodu przez potajemne osłabienie właściwości, którą użytkownicy oczekiwali zachować.

Dla pracowników wiedzy sygnały te przekładają się na prosty test zakupowy. Należy zapytać, czy produkt AI generuje odpowiedzi, czy tworzy odpowiedzi z egzekwowalnymi warunkami akceptacji.

Szukaj pochodzenia danych na poziomie źródeł, kontroli uprawnień, ustrukturyzowanej walidacji, odtwarzalnych transformacji i jasnych ścieżek eskalacji. Dopracowana odpowiedź bez tych mechanizmów pozostaje szkicem, niezależnie od tego, jak pewnie brzmi.

Automatyzacja dowodów Lean nie dowodzi, że AI można już ufać samodzielnie. Stanowi dowód, że zaufanie można zaprojektować wokół AI, gdy twierdzenia są jawne, a weryfikacja pozostaje niezależna.

Pytanie dla kolejnego projektu jest praktyczne: która powtarzająca się decyzja tworzy ryzyko wystarczające, by uzasadnić prawdziwą bramkę akceptacji? Zacznij od niej, określ, co musi pozostać prawdą, i spraw, by automatyzacja zasłużyła na każde zielone potwierdzenie.