Brama dowodowa

Agent zgłosił „wszystkie testy przechodzą” bez uruchomienia pytest. Odpowiedź brzmiała pewnie. Sformułowanie było naturalne. Twierdzenie było fałszywe. Żaden zestaw testów nie został wywołany podczas sesji. Agent wywnioskował, że testy powinny przejść na podstawie swojego rozumienia zmian w kodzie i przedstawił tę dedukcję jako fakt.

Wyłapałem to, ponieważ stosuję zasadę: każdy raport końcowy musi powoływać się na konkretne dowody. Nie „jestem pewien, że testy przechodzą”. Wynik testów, wklejony, pokazujący zero błędów. Nie „plik powinien być zaktualizowany”. Ścieżka do pliku, numer linii, konkretna zmiana. Nie „to jest zgodne z istniejącym wzorcem”. Nazwa wzorca, plik, w którym się znajduje, i linia, w której nowy kod go odwzorowuje.

Ta zasada ma w moim systemie swoją nazwę: brama dowodowa. Żadna praca nie jest ukończona, dopóki każde twierdzenie w raporcie końcowym nie jest poparte czymś obserwowalnym. „Uważam, że” to nie dowód. „Powinno” to nie dowód. „Jestem pewien” to nie dowód. Dowodem jest ścieżka do pliku, wynik testu, konkretne odwołanie do kodu lub bezpośrednia obserwacja.

Dlaczego to ma teraz znaczenie

Modele językowe generują wiarygodny tekst. To ich główna zdolność i zarazem główne ryzyko. Wiarygodne twierdzenie o wynikach testów jest nie do odróżnienia od zweryfikowanego twierdzenia o wynikach testów — chyba że zażądamy artefaktu weryfikacyjnego.

Tryb awarii nie polega na halucynacji w dramatycznym sensie. Agent nie wymyśla fikcyjnych frameworków testowych ani nie fabrykuje komunikatów o błędach. Tryb awarii polega na tym, że wnioskowanie jest przedstawiane jako obserwacja. Agent rozumuje, że testy powinny przejść, i raportuje to rozumowanie tak, jakby było uruchomieniem testów. Rozumowanie może być nawet prawidłowe. Ale rozumowanie o testach to nie to samo co uruchomienie testów, a w luce między jednym a drugim przeżywają błędy.

Nazywam to weryfikacją widmową: raport końcowy, który twierdzi, że weryfikacja nastąpiła, choć tak nie było. Z moich obserwacji w ponad 500 autonomicznych sesjach wynika, że weryfikacja widmowa odpowiada za 12% awarii agentów wymagających interwencji człowieka.¹ To najczęstszy tryb awarii, który nie generuje widocznego błędu. Agent raportuje sukces. Wynik wygląda czysto. Bug trafia na produkcję.

Brama

Brama dowodowa składa się z sześciu kryteriów. Każda nietrywialna zmiana musi dostarczyć dowody dla wszystkich sześciu, zanim praca zostanie oznaczona jako ukończona.

Kryteria są celowo konkretne. Każde z nich wymaga określonego artefaktu, a nie ogólnego zapewnienia. „Zgodność z wzorcami w kodzie” nie jest spełnione przez „zastosowałem istniejące konwencje”. Jest spełnione przez „wzorzec ponawiania prób w fetch_nvd() odpowiada wykładniczemu cofaniu w fetch_semantic_scholar() w linii 241”.

Konkretność jest sednem sprawy. Agent, który musi podać ścieżkę do pliku i numer linii, nie jest w stanie przeprowadzić weryfikacji widmowej. Albo plik istnieje pod tą ścieżką i kod odpowiada twierdzeniu, albo nie. Nie ma wiarygodnego środka.

Wahanie jako sygnał

Brama dowodowa zawiera detektor wahania. Określone słowa uruchamiają ponowną weryfikację:

• „powinno” („to powinno działać”)
• „prawdopodobnie” („to prawdopodobnie obsługuje ten przypadek brzegowy”)
• „wydaje się” („wynik wydaje się prawidłowy”)
• „uważam, że” („uważam, że testy przechodzą”)
• „wygląda poprawnie” („implementacja wygląda poprawnie”)
• „jestem pewien” („jestem pewien, że to jest prawidłowe”)

Każde z tych słów wskazuje, że agent rozumuje o wyniku, zamiast go obserwować. Rozumowanie może być prawidłowe. Ale jeśli agent może bezpośrednio zaobserwować wynik (uruchamiając test, czytając plik, sprawdzając dane wyjściowe), rozumowanie jest słabszą formą dowodu niż obserwacja.

Gdy raport końcowy zawiera język wahania, odpowiedź nie brzmi „mylisz się”. Odpowiedź brzmi „zastąp wahanie obserwacją”. Jeśli uważasz, że testy przechodzą — uruchom je i wklej wynik. Jeśli wydaje się prawidłowe — przeczytaj plik i wskaż linię. Wahanie jest sygnałem, że weryfikacja została pominięta, a nie że weryfikacja się nie powiodła.

Dlaczego agenci się wahają

Agenci wahają się z trzech powodów, a zrozumienie tych powodów ma znaczenie przy projektowaniu bramy.

Presja okna kontekstowego. Uruchomienie zestawu testów pochłania kontekst. Odczytanie pliku pochłania kontekst. Agent zarządzający długą sesją może pominąć weryfikację, aby zachować kontekst na kolejne zadanie. Brama dowodowa czyni ten kompromis widocznym: agent nie może zgłosić ukończenia bez artefaktu, więc presja kontekstowa ujawnia się jako niedokończona praca, a nie jako weryfikacja widmowa.

Unikanie wywołań narzędzi. Niektóre konfiguracje agentów penalizują lub ograniczają wywołania narzędzi. Agent, który może zgłosić „testy przechodzą” bez wywoływania pytest, oszczędza jedno wywołanie narzędzia. Brama dowodowa eliminuje tę drogę na skróty: wynik testów jest obowiązkowy, więc wywołanie narzędzia jest obowiązkowe.

Trening na wzorcach ludzkich. Ludzie regularnie piszą raporty końcowe z językiem wahania. „Zaktualizowałem konfigurację i testy powinny przechodzić.” Agent wytrenowany na ludzkim tekście odtwarza ten wzorzec. Brama dowodowa jest interwencją po treningu, która przełamuje ten wzorzec, odmawiając przyjęcia raportu bez artefaktu.

Próba dumy

Brama dowodowa jest częścią szerszego systemu jakości, który nazywam próbą dumy. Pięć pytań zadawanych po każdej nietrywialnej zmianie:

1. Czy doświadczony inżynier uznałby to z szacunkiem?
2. Czy kod sam się wyjaśnia?
3. Czy przypadki brzegowe są obsłużone?
4. Czy to odpowiedni poziom prostoty?
5. Czy zostawiłem bazę kodu w lepszym stanie niż ją zastałem?

Próba dumy jest subiektywna tam, gdzie brama dowodowa jest obiektywna. Brama dowodowa pyta „czy potrafisz udowodnić, że to działa?”. Próba dumy pyta „czy z dumą pokazałbyś to komuś, kogo szanujesz?”. Oba podejścia są konieczne. Dowód bez dumy tworzy kod, który działa, ale nikt nie chce go utrzymywać. Duma bez dowodu tworzy kod, który dobrze się czyta, ale może nie działać.

Połączenie tworzy pętlę jakości: zaimplementuj, przejrzyj każdą linię, przepuść przez bramę dowodową, zastosuj próbę dumy, napraw każdy znaleziony problem i powtarzaj, aż oba kryteria zostaną spełnione. Pętla nie jest wydajna. Nie jest szybka. Jest poprawna. W świecie, w którym agenci potrafią generować wiarygodny kod z dużą prędkością, poprawność stanowi czynnik wyróżniający.

Tryby awarii

Brama dowodowa wyłapuje weryfikację widmową. Nie wyłapuje każdego trybu awarii. Siedem nazwanych trybów awarii pojawia się w sesjach autonomicznych agentów:¹

Spirala skrótów. Pomijanie kroków bramy dowodowej w celu szybszego zgłoszenia ukończenia. Agent tworzy częściowy raport i twierdzi, że jest kompletny.

Miraż pewności. „Jestem pewien” wypowiedziane z dużym przekonaniem. Brama dowodowa wyłapuje ten język, ale wystarczająco elokwentny agent może przeformułować wahanie, aby uniknąć wykrycia.

Plateau wystarczalności. Kod działa, ale nie jest czysty ani dobrze przetestowany. Kryterium „najprostsze działające rozwiązanie” bramy dowodowej częściowo to adresuje, ale próba dumy jest główną linią obrony.

Widzenie tunelowe. Szlifowanie jednej funkcji przy jednoczesnym psuciu sąsiedniego kodu. Kryterium „brak regresji” adresuje ten problem, ale tylko jeśli agent sprawdza właściwe pliki.

Odroczony dług. TODO/FIXME/HACK w zatwierdzonym kodzie. Brama dowodowa tego nie sprawdza. Odpowiednią obroną jest osobna reguła lintera.

Pusty raport. „Gotowe” bez dowodów dla któregokolwiek kryterium. Struktura bramy dowodowej czyni to oczywiście niekompletnym, ale agent może stworzyć raport, który wygląda na kompletny, pomijając jedno kryterium.

Weryfikacja widmowa. Główny cel bramy dowodowej. Twierdzenia o testowaniu lub weryfikacji bez artefaktu. Wskaźnik awarii wynoszący 12% spada do niemal zera, gdy brama jest konsekwentnie egzekwowana.

Dyscyplina

Brama dowodowa nie jest innowacją techniczną. Jest dyscypliną. Dyscypliną wymagania dowodów przed akceptacją twierdzeń. Dyscypliną traktowania „uważam, że” jako niewystarczającego. Dyscypliną uruchamiania testu, nawet gdy wiadomo, że przejdzie.

Dyscyplina ma teraz większe znaczenie niż przed erą agentów. Programista, który mówi „testy przechodzą”, zazwyczaj uruchomił testy. Twierdzenie i obserwacja zlewają się w jedno, ponieważ człowiek wykonał oba kroki. Agent, który mówi „testy przechodzą”, mógł nie wykonać żadnego z nich. Brama dowodowa oddziela twierdzenie od obserwacji i wymaga obu.

W erze wiarygodnych wyników dowód jest jedynym niezawodnym sygnałem. Wszystko inne to wnioskowanie.

FAQ

Czy to nie jest po prostu przegląd kodu?

Przegląd kodu sprawdza, czy kod jest poprawny. Brama dowodowa sprawdza, czy raport końcowy jest uczciwy. Przegląd kodu może zatwierdzić poprawny kod, który nigdy nie był testowany. Brama dowodowa wymaga wyniku testów niezależnie od tego, czy kod wygląda poprawnie.

Czy to spowalnia rozwój?

Tak. Uruchamianie testów, czytanie plików i powoływanie się na konkretne dowody wymaga czasu. Alternatywą jest wypuszczanie kodu zweryfikowanego widmowo i odkrywanie błędów na produkcji. Brama dowodowa zamienia szybkość rozwoju na pewność wdrożenia.

Czy agenci mogą nauczyć się obchodzić bramę dowodową?

Agent mógłby sfabrykować wynik testów lub podać nieprawidłowe numery linii. Brama dowodowa nie jest odporna na działania celowe. Wyłapuje typowy tryb awarii (wnioskowanie przedstawiane jako obserwacja), a nie tryb adversarialny (celowa fabrykacja). Celowa fabrykacja wymaga innej obrony.

Jak egzekwować to w przypadku autonomicznych agentów?

Kryteria bramy dowodowej są częścią promptu systemowego. Pętla jakości (zaimplementuj, przejrzyj, przepuść przez bramę, sprawdź, napraw, powtórz) jest zakodowana w systemie orkiestracji. Agent nie może zgłosić ukończenia bez przedstawienia dowodów dla wszystkich sześciu kryteriów. Jeśli brakuje któregoś kryterium, pętla wraca do kroku naprawy.

Źródła