Weryfikacja PDD Kit przesuwa przegląd kodu AI w stronę intencji dewelopera
Microsoft Research zaprezentowało weryfikację PDD Kit 5 listopada, proponując formalne kontrole kodu tworzonego przez agentów i przesuwając ludzki przegląd w stronę intencji dewelopera. Formalna weryfikacja wykorzystuje rozumowanie matematyczne, aby ustalić, czy kod spełnia jawnie określone właściwości przy zdefiniowanych założeniach. Obietnica jest konkretna: uczynić zatwierdzone wymaganie egzekwowalnym, zamiast liczyć na to, że implementacja agenta i testy odzwierciedlają pierwotne żądanie.
Demonstracja koncentruje się na logice logowania w Pet Store, pełnostosowej aplikacji internetowej napisanej w Rust. Microsoft twierdzi, że przepływ pracy wykorzystuje Verus, narzędzie weryfikacyjne dla Rust, do sprawdzania wygenerowanego kodu względem specyfikacji. Testy obejmują zależności i zachowanie wykraczające poza ten dowód. Ogłoszenie nie dowodzi, że cała aplikacja została formalnie zweryfikowana.
Punktem odniesienia jest rozwój oparty na specyfikacji, reprezentowany przez GitHub’s Spec Kit, który porządkuje wymagania przed implementacją. PDD Kit rozwija to podejście w kierunku obowiązków sprawdzanych maszynowo. Jego kluczowe pytanie dotyczy odpowiedzialności inżynierskiej: gdy agenci piszą implementację, jakich dowodów powinni wymagać recenzenci, zanim przyjmą za nią odpowiedzialność?
Weryfikacja PDD Kit celuje w konkretną część aplikacji pełnostosowej
Przykład weryfikacji logowania Microsoftu opisuje prototyp badawczy, a nie ogólną usługę zapewniania jakości dla dowolnych aplikacji. Zaprezentowana aplikacja zawiera około 5 000 wierszy Rust. Opisany dowód dotyczy jej logiki logowania, podczas gdy pozostałe komponenty pozostają zaufane i testowane.
Istotną zmianą jest połączenie między sprawdzonymi wymaganiami a zachowaniem implementacji weryfikowanym maszynowo.
To rozróżnienie ma znaczenie przy odczytywaniu określenia „full-stack web apps”. Aplikacja może zawierać zweryfikowany komponent, bez gwarancji obejmujących każdy otaczający go element. Poprawna decyzja dotycząca logowania nie dowodzi, że każde późniejsze działanie administracyjne prawidłowo sprawdza uprawnienia.
Microsoft podaje, że deweloper przeglądał intencję zamiast wyczerpująco czytać wygenerowany kod. To jest operacyjna propozycja projektu. Wkład człowieka przesuwa się w stronę określania, jakie zachowanie aplikacja jest winna swoim użytkownikom i jakie założenia akceptuje zespół.
Rozważmy różnicę między zatwierdzeniem opisu funkcji a zatwierdzeniem obowiązku dotyczącego zachowania. „Zadbaj o bezpieczne logowanie” wyraża cel, lecz pozostawia nierozstrzygniętą niemal każdą ważną decyzję. Recenzent musi wiedzieć, które konto uzyskuje dostęp, jakie warunki go umożliwiają oraz jak niepowodzenie zmienia wynik.
Formalna specyfikacja, czyli precyzyjne stwierdzenie wymaganego zachowania, czyni wybrane decyzje wystarczająco jawnymi, by mogły zostać sprawdzone mechanicznie. Ujawnia także pominięcia. Wymaganie, które nigdy nie odnosi się do określonego zachowania, nie daje weryfikatorowi podstaw do jego odrzucenia.
To rozróżnienie zmienia sposób, w jaki czytelnicy powinni oceniać demonstrację. Jej znaczenie opiera się na weryfikowalnej relacji między wymaganiami a kodem. Nie zależy od przedstawiania sklepu jako całkowicie bezpiecznego ani od ogłaszania końca ludzkiego przeglądu.
Najmocniejsza interpretacja ma zatem charakter stopniowy. Zespoły mogą sprawdzać, czy ściśle zdefiniowana, istotna logika aplikacji zyskuje na obowiązkach dowodowych. Mogą następnie zbadać, jak wiele otaczającego zachowania pozostaje poza tymi obowiązkami.
Takie podejście nadaje ogłoszeniu praktyczne ramy bez rozszerzania jego twierdzeń. Komponent logowania zapewnia konkretne miejsce do zbadania, czy przegląd intencji działa. Szersze twierdzenia o niezawodności aplikacji wymagają szerszych dowodów.
Wyznacza również właściwą granicę analizy. Pytanie brzmi, czy ten przepływ pracy poprawia pewność co do określonego zachowania, zachowując jednocześnie widoczność pozostałej niepewności.
Liderzy inżynierii dziedziczą problem specyfikacji
Bezpośrednia presja spada na osoby zatwierdzające wygenerowane zmiany. Recenzent nadal potrzebuje uzasadnionego powodu, by wierzyć, że oprogramowanie robi to, czego zażądała organizacja. Generowanie większej liczby szczegółów implementacyjnych nie tworzy automatycznie takiego powodu.
Przeglądanie intencji sprawia, że jakość wymagań staje się odpowiedzialnością operacyjną.
Tradycyjny przegląd może wykryć nieokreśloną regułę poprzez dokładną inspekcję implementacji. Recenzent może zauważyć, że nietypowy stan konta wymaga specjalnego traktowania. Przeniesienie uwagi z implementacji sprawia, że świadome odkrywanie takich reguł staje się ważniejsze.
Jest to konsekwencja proponowanego przepływu pracy, a nie zmierzony wynik wdrożenia. Jeśli wymagania stają się punktem odniesienia, względem którego maszyny oceniają kod, niekompletne wymagania stają się głównym źródłem ryzyka rezydualnego.
Właściciele produktów i recenzenci bezpieczeństwa zyskują zatem bardziej bezpośrednią rolę w zapewnianiu jakości oprogramowania. Muszą rozstrzygać decyzje biznesowe, które kod czasami ukrywa. Inżynierowie muszą przełożyć te decyzje na stwierdzenia zachowujące sens po precyzyjnym wyrażeniu.
Ilustracyjna funkcja odzyskiwania konta pokazuje trudność. Żądanie biznesowe może mówić, że zweryfikowani użytkownicy powinni odzyskać dostęp. Specyfikacja nadal musi zdefiniować weryfikację, wygasłe żądania, sprzeczne stany kont oraz okoliczności unieważniające wcześniejszą zgodę.
Każdy nierozstrzygnięty termin tworzy przestrzeń dla implementacji, która podąża za wiarygodną interpretacją, a jednocześnie rozczarowuje zleceniodawcę. Kontrole formalne mogą egzekwować wybraną interpretację. Wybór tej interpretacji pozostaje decyzją człowieka.
Badania Shuvendu Lahiri dotyczące formalizacji intencji wskazują walidację specyfikacji jako centralne wyzwanie. Praca przekonuje, że przekładanie nieformalnej intencji na sprawdzalne wymagania wymaga udziału użytkownika, ponieważ poprawność specyfikacji nie ma automatycznego wyroczni.
Badania te oferują użyteczną sceptyczną perspektywę wobec ogłoszenia. Udany dowód nie może rozstrzygnąć, czy zespół wybrał właściwy cel. Ustanawia relację między implementacją a zapisanym obowiązkiem.
Dla zarządzania inżynierią sugeruje to inny sposób oceny wysiłku wkładanego w przegląd. Czas poświęcony na doprecyzowanie wymagań powinien być traktowany jako część procesu dostarczania. Każde późniejsze ograniczenie wysiłku związanego z czytaniem kodu musi zostać ocenione względem tej wcześniejszej inwestycji.
To samo dotyczy odpowiedzialności po wydaniu produktu. Gdy wymaganie się zmienia, ktoś musi zdecydować, czy formalny obowiązek powinien zmienić się razem z nim. Traktowanie specyfikacji jako trwałego artefaktu technicznego wymaga odpowiedzialnego właściciela.
Historia decyzji staje się tu przydatna. Zespoły potrzebują dostępu do powodów stojących za zaakceptowanym wyjątkiem, założeniem dotyczącym zależności lub polityką obsługi błędów. Przeszukiwalna baza wiedzy może wspierać tę ciągłość między dokumentami technicznymi.
Sama dokumentacja nie może zapewnić gwarancji poprawności. Jej wkład polega na zachowaniu kontekstu, aby przyszli recenzenci mogli ocenić, czy istniejąca gwarancja nadal wyraża zamierzone zachowanie.
Szersza konsekwencja ma charakter organizacyjny. Jeśli przedsiębiorstwo chce, aby maszyny egzekwowały jego wymagania, musi najpierw uczynić te wymagania wystarczająco jasnymi, by móc za nie odpowiadać.
Wyjaśnienie PDD Kit poprzez lukę między regułą a jej znaczeniem
Opis proof-driven development od GitHub Next przedstawia PDD Kit jako partnera planowania w Chopin, jego środowisku współpracy przy planowaniu. Rejestruje decyzje w artefakcie intencji, który łączy ludzkie wymagania ze specyfikacjami i testami.
Opis ilustruje również znaczącą niejednoznaczność. Reguła zezwalająca na tokeny wyłącznie przy poprawnych hasłach nadal dopuszcza system odrzucający każde logowanie. Zapobieganie nieautoryzowanemu dostępowi i umożliwianie legalnego dostępu wymagają odrębnych obowiązków.
Specyfikacja musi wykluczać niedopuszczalne zachowanie, nie wykluczając przypadkowo usługi, której potrzebują użytkownicy.
Ten przykład wyjaśnia mechanizm wyraźniej niż abstrakcyjne twierdzenie o poprawności. Reguła może brzmieć kompletnie w rozmowie, a mimo to pozostawiać logicznie poprawną implementację, której nikt nie chce.
To samo rozumowanie ma zastosowanie poza logowaniem. Wyobraźmy sobie hipotetyczną usługę płatniczą, która nigdy nie może obciążyć nieupoważnionego konta. Usługa, która nigdy nie przetwarza płatności, spełnia to ograniczenie. Usługa użyteczna komercyjnie potrzebuje również wymagań regulujących prawidłowe płatności.
Te przykłady są ćwiczeniami rozumowania, a nie dodatkowymi demonstracjami PDD Kit. Pokazują, dlaczego wymagania potrzebują zarówno zakazów, jak i pozytywnych obowiązków. Zespół musi opisać, co oznacza udane zachowanie, obok błędów, którym chce zapobiec.
Gdy te decyzje stają się formalnymi obowiązkami, weryfikator sprawdza implementację względem nich. Według projektu Rust verification, Verus sprawdza specyfikacje statycznie, przed wykonaniem, zamiast wstawiać kontrole w czasie działania. Obecnie obsługuje podzbiór Rust i pozostaje w aktywnym rozwoju.
Taka architektura oddziela wygenerowanie odpowiedzi od jej zaakceptowania. Agent może zaproponować implementację i wspierający ją dowód. Weryfikacja mechaniczna określa, czy określone obowiązki są spełnione w obsługiwanym modelu.
To rozróżnienie jest istotne, ponieważ płynne wyjaśnienia są słabym dowodem poprawności implementacji. Agent może przekonująco opisać zamierzone zachowanie, jednocześnie pomijając gałąź. Obowiązek mechaniczny nadaje tej gałęzi zdefiniowany warunek do spełnienia.
Precyzja sama w sobie nie gwarantuje jednak użytecznego zakresu pokrycia. Załóżmy, że hipotetyczny kontrakt mówi, iż zwracany identyfikator konta musi mieć oczekiwany typ danych. Wymaganie to może być spełnione, choć identyfikator należy do niewłaściwego konta.
Silniejszy kontrakt łączyłby wynik z tożsamością ustaloną przez żądanie i zaakceptowanymi warunkami uwierzytelniania. Ważna właściwość dotyczy relacji między wartościami, a nie wyglądu pojedynczej wartości.
Dlatego weryfikacja PDD Kit zasługuje na ocenę na poziomie wymagań. Zielony wynik ma znaczenie wyłącznie wtedy, gdy recenzenci rozumieją, czego sprawdzone stwierdzenia zakazują i czego wymagają.
Znaczenie ma również praktyczna granica. Nieobsługiwane konstrukcje i zależności mogą uniemożliwić bezpośrednią weryfikację otaczającego kodu. Zespoły potrzebują wtedy jasnego opisu, które gwarancje opierają się na założeniach dotyczących tych komponentów.
Pozostaje zatem argument warstwowy. Ludzki osąd wybiera zamierzone zachowanie. Formalne stwierdzenia wyrażają wybrane obowiązki. Kontrola mechaniczna ustala relację implementacji do tych obowiązków przy zaakceptowanych założeniach.
Każda warstwa może nie zapewnić poziomu pewności, którego oczekują czytelnicy. Wartość wynika z ujawnienia tych warstw wystarczająco jasno, aby recenzenci mogli zbadać ich wzajemną relację.
PDD Kit wyjaśniony w ten sposób stanowi próbę uporządkowania odpowiedzialności wokół jednoznacznych zobowiązań dotyczących zachowania. Jego sukces zależy od tego, czy ta organizacja pozostanie zrozumiała, gdy aplikacje będą się zmieniać.
PDD Kit a testowanie to kwestia dowodów
Testowanie i weryfikacja formalna ustanawiają różne rodzaje dowodów. Test wykonuje wybrane sytuacje i sprawdza zaobserwowane wyniki. Dowód ustanawia określone właściwości w zakresie danych wejściowych i wykonań objętych jego modelem i założeniami.
Użyteczne porównanie pyta, jakie twierdzenie potwierdza każda kontrola.
Test przeglądarkowy może wykazać, że konkretna ścieżka logowania zadziałała w testowanym środowisku. Może ujawnić uszkodzony formularz, nieoczekiwaną odpowiedź lub błąd łączenia komponentów. Te obserwacje pozostają wartościowe, nawet gdy wybrana logika wewnętrzna ma dowód.
Obowiązek formalny może dotyczyć innego pytania: czy modelowana logika decyzyjna kiedykolwiek dopuszcza zabroniony wynik. Ta gwarancja zależy od specyfikacji i granicy wokół sprawdzanego kodu.
Żaden wynik nie powinien po cichu dziedziczyć zakresu drugiego. Udana ścieżka przeglądarkowa nie ustanawia każdego możliwego wyniku logowania. Dowód dotyczący funkcji decyzyjnej nie ustanawia, że wdrożona strona wysyła zamierzone żądanie.
Narzędzie GitHub do programowania sterowanego specyfikacją stanowi bliski punkt odniesienia. Spec Kit organizuje specyfikacje, planowanie, implementację i procesy przeglądu dla agentów programistycznych. Jego dokumentacja opisuje ustrukturyzowane przepływy pracy i wyniki weryfikacji, nie czyniąc każdej specyfikacji dowodem matematycznym.
Różnica dotyczy wskazówek procesowych i określonej formy dowodu. Ustrukturyzowany plan może poprawić koordynację i ujawnić brakującą pracę. Obowiązek formalny dodaje sprawdzalną maszynowo relację dla zachowania, które wyraża.
Przekształcanie tej różnicy w ogólne twierdzenie, że zespoły kierujące się specyfikacją nie mają mechanizmów egzekwowania, byłoby mylące. Zespoły mogą dołączać do swoich planów testy, analizy, bramki przeglądowe i inne kontrole. Pytanie dotyczy tego, co te kontrole faktycznie ustanawiają.
Praca Amazon nad rozwojem sterowanym weryfikacją oferuje kolejne porównanie. Badania nad Cedar łączą dowody dotyczące wykonywalnego modelu z testami różnicowymi, które porównują implementacje, oraz testami opartymi na właściwościach, które sprawdzają generowane przypadki.
Artykuł o Cedar informuje o wykryciu czterech błędów walidatora polityk za pomocą dowodów oraz kolejnych 21 błędów dzięki testowaniu. Te ustalenia dotyczą Cedar, a nie PDD Kit, i nie ustanawiają porównawczej wydajności produktów.
Stanowią jednak dowód dla szerszego stanowiska inżynierskiego: dowody i testy mogą wnosić uzupełniające się ustalenia. Różne techniki mogą ujawniać różne defekty w ramach tego samego wysiłku programistycznego.
Dla kupujących oceniających rozwój wspomagany przez agentów praktyczne pytanie staje się bardziej konkretne. Jaki dowód łączy wymaganie z kodem, który je implementuje? W którym miejscu to połączenie zależy od testowania, założeń lub ludzkiej inspekcji?
To bardziej użyteczna dyskusja zakupowa niż pytanie, czy produkt ogólnie wspiera weryfikację. Termin ten obejmuje twierdzenia o różnej sile i zakresie.
Porównanie PDD Kit z testowaniem powinno więc kończyć się mapą gwarancji. Recenzenci muszą widzieć, które wymagania mają dowody, które mają wykonane kontrole, a które pozostają kwestiami oceny.
Zweryfikowany komponent nadal zależy od swojego otoczenia
Weryfikacja PDD Kit nie eliminuje potrzeby badania granic. Zaufana baza obliczeniowa to zbiór komponentów i założeń, od których zależy gwarancja. Jeśli zaakceptowane założenie zawiedzie, dowód może pozostać ważny, podczas gdy oczekiwane zachowanie aplikacji zawiedzie.
Zakres gwarancji ma równie duże znaczenie jak sam fakt przejścia dowodu.
Opis Microsoft umieszcza wyszukiwania w bazie danych, sprawdzanie haseł, dostęp do zegara, podpisywanie tokenów i obsługę żądań poza przedstawionym dowodem. Te komponenty otrzymują testowanie i zaakceptowane kontrakty. Dowód nie ustanawia niezależnie poprawności ich implementacji.
To ograniczenie ma znaczenie, ponieważ otaczające komponenty łączą abstrakcyjne decyzje z rzeczywistymi tożsamościami i rzeczywistymi żądaniami. Poprawna decyzja wewnętrzna potrzebuje dokładnych informacji. Potrzebuje również, aby jej wynik został dostarczony właściwą ścieżką wykonania.
Rozważmy hipotetyczne wyszukiwanie, które zwraca niewłaściwe konto, jednocześnie zgłaszając sukces. Funkcja dalszego etapu mogłaby przetworzyć ten wynik dokładnie zgodnie ze specyfikacją. Ogólne zachowanie nadal rozczarowałoby użytkownika, ponieważ zawiodło zaakceptowane założenie dotyczące zależności.
To ogólny przykład rozumowania, a nie zgłoszona wada Pet Store. Pokazuje, dlaczego czytelnicy powinni badać założenia, zamiast traktować je jako drugorzędną dokumentację.
To samo rozróżnienie dotyczy pominiętych wymagań. Specyfikacja skupiona na decyzjach dostępowych nie obejmuje automatycznie responsywności, mechanizmów przeciwdziałania nadużyciom ani odzyskiwania konta. Każde dodatkowe twierdzenie potrzebuje własnego argumentu wspierającego.
Tworzy to ważną dyscyplinę raportowania. „Zweryfikowana logika logowania” powinna pozostać powiązana z faktycznymi właściwościami i granicą. Rozszerzenie tego sformułowania do „bezpiecznego systemu uwierzytelniania” dodawałoby twierdzenia, których przedstawione dowody nie muszą wspierać.
Istnieje również pytanie o wdrożenie. Weryfikacja ograniczona do Rust ogranicza miejsca, w których ten prototyp pasuje bezpośrednio. Organizacja korzystająca z innego języka aplikacyjnego musi rozważyć prace integracyjne, zanim oczekiwać będzie zastosowania tego samego przepływu pracy.
Istnienie tej pracy nie czyni podejścia niepraktycznym. Oznacza, że kalkulacja kosztów i korzyści zależy od komponentu, jego konsekwencji oraz wysiłku wymaganego do wyrażenia jego zachowania.
Mały komponent, którego awarie są kosztowne, może uzasadniać znaczną pracę nad specyfikacją. Często zmieniający się interfejs może wymagać innej równowagi. Są to kwestie oceny, a nie zmierzone wnioski o ekonomice PDD Kit.
Czytelnicy powinni także oddzielać demonstrację przepływu pracy od niezależnej walidacji. Opisy Microsoft i GitHub Next wyjaśniają system i doświadczenia autorów. Nie ustanawiają ogólnego ograniczenia liczby defektów w niezwiązanych ze sobą zespołach produkcyjnych.
Etykieta prototypu pozostawia pole do badania. Zachęca do pytań o powtarzalne użycie, wysiłek utrzymaniowy i zrozumienie przez recenzentów. Odpowiedź na te pytania wymaga dowodów wykraczających poza początkowy przykład aplikacji.
Rozsądny standard jest wymagający, ale konkretny. Recenzent powinien rozumieć obiecane zachowanie, zaakceptowane zależności, wykluczone twierdzenia i dowody dołączone do każdego z nich.
Ten standard wspiera ostrożne eksperymentowanie, nie wymagając od nikogo utożsamiania wąskiego dowodu z pełną gwarancją dla aplikacji.
Kolejne dowody powinny obejmować replikację, granice i utrzymanie
Kolejne wydarzenia powinny wyjaśnić, czy przepływ pracy wykracza poza jego początkową demonstrację. W nadchodzących miesiącach na uwagę zasługują trzy sygnały, w ustalonej kolejności: niezależna replikacja, zakres zależności i zachowanie podczas utrzymania.
Najmocniejsze dowody wdrożenia pokażą, że zespoły potrafią zachować znaczące gwarancje, gdy ich oprogramowanie się zmienia.
Po pierwsze, warto obserwować niezależne zespoły odtwarzające przepływ pracy dla logiki aplikacyjnej o innych wymaganiach. Użyteczny opis wskazywałby początkowe żądanie, zaakceptowaną specyfikację, wynikające z niej kontrole oraz wysiłek potrzebny do rozwiązania niejednoznaczności.
Udana replikacja wzmocniłaby argument, że metoda planowania przenosi się poza jej twórców. Powtarzająca się zależność od nieopisanego udziału ekspertów zawęziłaby taką interpretację.
Istotnym sygnałem są zrozumiałe dowody z innego środowiska. Sama dopracowana demonstracja nie może ujawnić, jak mniej zaznajomiony zespół radzi sobie ze sprzecznymi wymaganiami lub błędnie rozumianymi założeniami.
Po drugie, warto obserwować, jak projekty opisują i zarządzają zaufanymi zależnościami. Postęp może oznaczać objęcie dodatkowego zachowania dowodem. Może też oznaczać tworzenie jaśniejszych, bardziej odtwarzalnych kontroli dla komponentów, które pozostają poza nim.
Mniejsza granica wzmocniłaby wybrane gwarancje, jeśli nowe dowody dotyczą znaczących właściwości. Jaśniejsza granica poprawiłaby zdolność recenzentów do oceny pozostałego ryzyka.
Żadnego z tych kierunków nie należy oceniać wyłącznie przez liczbę komponentów. Zależności różnią się konsekwencjami. Przeniesienie pomocnika o niewielkim wpływie do zweryfikowanego kodu nie musi zmniejszać najważniejszej niepewności.
Bardziej ujawniające pytanie brzmi, które obietnice aplikacji nadal zależą od nieudowodnionego zachowania. Raportowanie tej relacji ułatwiłoby ocenę przyszłych demonstracji.
Po trzecie, warto obserwować, co dzieje się podczas zwykłej zmiany wymagania. Dojrzała ocena powinna śledzić komponent po jego początkowej akceptacji, w tym decyzje dotyczące specyfikacji towarzyszące nowemu zachowaniu.
Załóżmy, że hipotetyczny zespół zmienia politykę kont. Interesującym wynikiem jest to, czy recenzenci potrafią odróżnić zamierzoną zmianę polityki od regresji implementacyjnej. Nieudana kontrola musi prowadzić do świadomej decyzji o tym, który artefakt należy zmienić.
Dowody stabilnego, zrozumiałego utrzymania wzmocniłyby argument operacyjny. Wielokrotne osłabianie wymagań w celu przywrócenia przechodzących kontroli osłabiłoby go, nawet jeśli kompilacje ostatecznie się powiodły.
Dla potencjalnych użytkowników sygnały te sugerują metodę oceny. Wybierz ograniczony komponent, określ zachowanie, które ma znaczenie, i zapytaj, jaki dowód uzasadniałby akceptację jego implementacji.
Uwzględnij koszt przeglądu wymagań, rozumienia założeń i utrzymania kontroli. Te działania należą do tej samej oceny co ewentualne ograniczenie wysiłku związanego z czytaniem kodu.
Utrzymuj twierdzenia proporcjonalne do dowodów. Przepływ pracy może zwiększyć zaufanie do istotnego komponentu, nie zapewniając pełnej gwarancji dla otaczającego produktu.
Przed wdrożeniem weryfikacji PDD Kit przeanalizuj wymaganie, które twój zespół już uznaje za jasne. Poproś właściciela produktu i inżyniera o osobne opisanie jego udanych i niedopuszczalnych wyników. Porównaj ich odpowiedzi przed omówieniem dowodu. Następnie wskaż zależności, które muszą zachowywać się poprawnie, aby którykolwiek opis był spełniony. To ćwiczenie nie zweryfikuje implementacji, ale ujawni decyzje, które przepływ pracy weryfikacyjnej musi zachować. Czytaj opisy techniczne, mając te decyzje na uwadze, i szukaj wyraźnego połączenia między każdą obietnicą a jej dowodem. Użyteczne pytanie w kolejnej ocenie jest konkretne: czy recenzenci potrafią wyjaśnić, co gwarantuje oprogramowanie, dlaczego w to wierzą i co pozostaje poza tą gwarancją?
