Naprawianie dryfu intencji: warstwa specyfikacji i nadzoru dla programowania z AI

Każdy, kto poważnie korzysta z agentów programujących, zna ten moment: trzy godziny po rozpoczęciu sesji agent z pełnym przekonaniem implementuje coś, co zostało wyraźnie wykluczone godzinę wcześniej. Nie stał się mniej sprawny. Decyzja po prostu przestała mieścić się w jego polu uwagi. Historia czatu to złe miejsce do przechowywania ustaleń.

Ten rodzaj błędu nazywam dryfem intencji. Po tym, jak spotkał mnie wystarczająco wiele razy, przestałem traktować go jako problem z promptami. To problem procesu. Zespoły ludzkie rozwiązały go dziesiątki lat temu: specyfikacjami, kryteriami akceptacji i zapisem decyzji. Programowanie z użyciem AI w większości jeszcze go nie rozwiązało — dlatego zbudowałem AppMakera, otwartą warstwę nadzoru działającą nad środowiskiem agenta.

Trzy założenia

Pierwsze: artefakty są ważniejsze niż zapis rozmowy. Każda funkcja dostaje trwały katalog: wywiad, dokument wymagań, dekompozycję, zapis realizacji każdej części, retrospektywę. Agent przed działaniem czyta artefakty, a nie ogólne wrażenie z rozmowy. Sesja może się zakończyć, skrócić albo pomylić; katalog zostaje.

Drugie: identyfikowalność jest ważniejsza niż zaufanie. Każde kryterium z dokumentu wymagań ma stały identyfikator (na przykład pcrit-007), który przechodzi przez dekompozycję, kryteria akceptacji i nazwy testów aż do kodu produkcyjnego. Korzyść jest bardzo praktyczna: dryf staje się zerwanym powiązaniem, które wykryje prosty skrypt. Moja bramka kontrolna nie pyta modelu, czy wymagania są spełnione — przeszukuje pliki.

Trzecie: osąd jest zasobem rzadkim, więc używa się go na końcu. Kontrole przebiegają warstwami: najpierw deterministyczne skrypty, potem udokumentowane kryteria oceniane przez człowieka, na końcu ocena modelu — tylko tam, gdzie dwie pierwsze warstwy nie sięgają. Niektórych ocen nie deleguje się nigdy: sprawy tożsamości, pieniędzy, marki i decyzje nieodwracalne są oznaczone jako wymagające człowieka, a system kieruje je do niego, zamiast zgadywać.

Pierwsze spotkanie z produkcją

Pierwszym prawdziwym sprawdzianem była platforma do prowadzenia spraw klinicznych. Funkcja dotyczyła oceny ryzyka biopsychospołecznego, a sesja trwała około pięciu i pół godziny, od pomysłu do produkcji. Po drodze: 7 rozpisanych części, 21 testów jednostkowych przeprowadzonych w uczciwym cyklu „najpierw test, potem kod", 37 odhaczonych kryteriów akceptacji, 4 wdrożenia bibliotek. Słownik projektu sam zapełnił się terminami z odnośnikami do konkretnych plików i linii. Komentarze w kodzie produkcyjnym wskazują dokument wymagań, który realizują — brzmi to jak drobiazg, dopóki nie czyta się tego kodu pół roku później.

Tego, co cenię najbardziej, nie ma na tej liście. Zapis sesji odnotowuje, co się nie udało — skille, które deklarowały zapis plików, ale go nie wykonywały, konflikt zmiennej w zsh, zbyt starą wersję Pythona — oraz co pozostało niesprawdzone, łącznie z pełnym cyklem życia aż po archiwizację. Kilka tygodni później ta lista jest zamknięta: ta sama platforma przeprowadziła już 6 funkcji przez pełny cykl, a 22 części trafiły na produkcję. Opublikować niesprawdzone hipotezy, a potem po kolei je zamknąć — takiemu dowodowi ufam bardziej niż jakiemukolwiek benchmarkowi.

Dowód na samym sobie

Strona, którą właśnie czytasz, również powstała z użyciem AppMakera: wymagania zebrane w wywiadzie, rozpisane na 16 sprawdzalnych kryteriów, podzielone na 9 części, kod pisany od testów, całość pilnowana bramkami. Artefakty są częścią historii repozytorium tej strony. Kiedy agent, który ją budował, zacznie odpowiadać na pytania o nią — już wkrótce — całość się domknie.

Mądrzejsze modele same nie usuną dryfu intencji. Usuwa go danie modelowi tego, co od dawna dajemy inżynierom: systemu, w którym decyzje są zapisane, powiązane i sprawdzane. Model — trzeba mu to oddać — rzeczywiście czyta specyfikację za każdym razem.