Anthropic opublikowało podręcznik cyklu wytwarzania oprogramowania w świecie agentów. Kurs ma czternaście lekcji i opisuje to, czego zespół Anthropic sam używa przy budowaniu aplikacji z Claude Code. Materiał prowadzi przez dziewięć etapów: od zbierania wymagań w rozmowie z agentem, przez pliki intent, spec i plan, przez testy, ewaluacje w integracji ciągłej i automatyczny przegląd kodu, aż po wdrożenie i monitoring produkcji, który zamyka pętlę i wraca do planowania.
Dlaczego stary cykl przestał pasować
Klasyczny cykl wytwarzania oprogramowania, w skrócie S D L C, wygląda zawsze tak samo. Planowanie, projektowanie, budowanie, testowanie, wdrożenie, utrzymanie. Po utrzymaniu koło wraca do planowania i zaczyna się kolejna funkcja albo kolejny błąd.
Zanim pojawiły się agenty, każdy z tych etapów działał w tempie człowieka. Najwięcej czasu pochłaniało budowanie. Sztuczna inteligencja skróciła właśnie ten kawałek. Całe koło zrobiło się przez to znacznie krótsze.
Skoro budowanie przestało być wąskim gardłem, przesuwa się ono gdzie indziej. Anthropic wskazuje trzy miejsca, które trzeba dopracować: zbieranie wymagań, przegląd kodu napisanego przez model i wydawanie produktu. Cały podręcznik dotyczy w praktyce tych trzech obszarów.
Etap pierwszy: intent, czyli po co to robimy
W starym układzie planowanie oznaczało rozmowy z interesariuszami, klientami, menedżerami produktu, a potem spisywanie wymagań. Dziś tę rozmowę może poprowadzić agent. Służą do tego umiejętności typu grooming, które przepytują ciebie, a nie odwrotnie.
Agent schodzi w głąb każdego aspektu planu i przechodzi drzewo decyzyjne gałąź po gałęzi, dopóki nie dojdzie z tobą do wspólnego rozumienia problemu.
Kiedy kontekst jest już zebrany, całą rozmowę, decyzje i ustalenia zapisujesz do jednego pliku intent M D. Ten plik czyta człowiek i wykonuje maszyna.
Dwa zastrzeżenia, które łatwo przeoczyć. Po pierwsze, intent nie jest jeden na projekt. Możesz mieć osobny plik na każdą zmianę, wszystkie w jednym folderze intent. Po drugie, ten plik wcale nie musi leżeć w repozytorium. Jeśli twoje źródło prawdy to Jira, GitHub Projects albo Linear, trzymaj intent w samym zgłoszeniu. Statyczny plik w repo to tylko jedna z opcji.
Anthropic daje gotowy szablon. Zawiera tytuł intencji, opis problemu, proponowany efekt, użytkowników, których to dotyczy, ograniczenia i otwarte pytania. Do tego szablonu można dopisać prompt, w którym jedyną rzeczą do zmiany jest miejsce zapisu pliku. Można też zrobić z tego własną umiejętność albo komendę i odpalać ją na końcu sesji przepytywania.
Tak powstaje łańcuch artefaktów. Intent idzie dalej, do etapu projektowania.
Etap drugi: spec, czyli co dokładnie ma powstać
Różnica między dwoma plikami jest prosta. Intent wyjaśnia, dlaczego coś robimy. Spec definiuje co: wymagania techniczne i oczekiwane zachowanie.
Anthropic podaje gotowy prompt, który zamienia intent w spec. Nie musisz go używać. Jeśli masz w organizacji własne umiejętności do pisania specyfikacji albo własne szablony, użyj ich. Format ma znaczenie mniejsze niż to, czy w ogóle rozdzielasz „dlaczego” od „co”.
Etap trzeci: plan, czyli lista zadań dla agenta
Plan M D bierze intent i spec, a zamienia je w zadania, które agent może wykonać po kolei albo równolegle.
Tu też nie ma jednego słusznego formatu. Szablon Anthropic zawiera tytuł planu, listę plików, które mają się zmienić, kolejność prac — co pierwsze, co drugie — ryzyka do rozważenia oraz sposób udowodnienia, że praca jest skończona. Tym dowodem bywa plik testowy pokrywający dany obszar kodu.
Gotowe umiejętności do pisania planów robią mniej więcej to samo. Typowy plan implementacyjny ma cel, architekturę, stos technologiczny, odwołanie do specyfikacji, globalne ograniczenia i strukturę zadań. Każde zadanie wskazuje plik, interfejs i pole wyboru z kolejnością.
Nie bierz wszystkiego z tego materiału na raz. Używaj tego, co już u ciebie działa, a resztę traktuj jako punkt odniesienia i dokładaj pojedyncze elementy.
To jest chyba najbardziej praktyczna rada z całego podręcznika.
Etap czwarty: najpierw testy
Przed implementacją piszesz test. Powstaje pętla zwrotna: dopóki testy nie przechodzą, agent poprawia własny kod.
Zasada z podręcznika brzmi wprost. Zawsze daj agentowi sposób na sprawdzenie własnej pracy. Mogą to być testy, budowanie projektu, linter albo zrzut ekranu. Wtedy sesja sama znajduje i naprawia swoje błędy, zanim ty je w ogóle zobaczysz.
Wersja Anthropic sprawdza trzy rzeczy: testy, linter i build. Build nie oznacza tu pisania kodu, tylko sprawdzenie, czy projekt naprawdę się kompiluje i czy program zachowuje się sensownie. Instrukcja jest kategoryczna: nie zgłaszaj zadania jako gotowego, dopóki wszystkie trzy nie są na zielono.
Etap piąty: trzy warstwy testów
Autor materiału układa narzędzia testowe w trzy warstwy, w kolejności od dołu.
Warstwa pierwsza to testy funkcjonalne, czyli testy jednostkowe. Narzędzia: Dżest albo Witest. Testujesz pojedynczą funkcję — obliczenie, wywołanie punktu końcowego, pobranie danych.
Warstwa druga to testy komponentów. Jeśli aplikacja ma interfejs, mobilny albo webowy, komponenty testujesz biblioteką React Testing Library. Chodzi o przyciski, formularze, wszystko, co użytkownik widzi i czego dotyka.
Kolejność nie jest przypadkowa. Jeden komponent może wywoływać wiele funkcji, ale funkcje nie wywołują komponentów interfejsu. Zależność idzie w jedną stronę, więc najpierw pokrywasz testami warstwę niższą.
Warstwa trzecia to testy od końca do końca. Symulują całą ścieżkę użytkownika przez kolejne strony aplikacji. Dwa popularne narzędzia to Sajpres i Plejrajt.
Etap szósty: ewaluacje w integracji ciągłej
Po testach przychodzi kolej na ciągłe ewaluacje. Powód jest konkretny. Kiedy podmieniasz model na nowszy, nowy model może przeoczyć coś, co wcześniej działało. Musisz mieć czym to zmierzyć.
Anthropic radzi wziąć od dwudziestu do pięćdziesięciu prawdziwych zadań, które Claude już u ciebie wykonał. Mogą to być zrealizowane pull requesty albo zgłoszenia z GitHuba. Agent czyta ten materiał i z pomocą umiejętności typu skill creator buduje z niego zestaw ewaluacyjny.
Sam zapis ewaluacji jest banalny: zadanie to prompt plus oczekiwany wynik.
To wszystko ma potem chodzić w potoku C I C D. Podręcznik pokazuje przykładowy przepływ pracy GitHuba o nazwie agent eval. Dla każdej ewaluacji uruchamia Claude w trybie bez interfejsu, z listą dozwolonych narzędzi, i sprawdza, czy wynik spełnia oczekiwania. Zmieniasz model albo zmieniasz reguły — potok od razu mówi ci, czy umiejętność nadal działa.
Etap siódmy: przegląd kodu i haki
Kolejny krok to przegląd pull requestów przez agenta. Główny wniosek jest taki, że warto mieć jeden plik review M D z instrukcją przeglądu.
W wersji Anthropic taka instrukcja każe przepuścić zmianę przez trzy testy i oznaczyć każde znalezisko kategorią: błąd, bezpieczeństwo, zgodność. Rozdziela też wagę uwag na istotne i drobne. Zawiera również listę rzeczy, których zgłaszać nie wolno — plików generowanych ani tymczasowych.
Ten plik pisze człowiek. Najlepiej lider techniczny zespołu, bo to jest po prostu spisana procedura przeglądu kodu, a agent ma się do niej stosować.
Rekomendacja autora idzie krok dalej. Daj agentowi dostęp do dawnych pull requestów razem z komentarzami ludzi. Niech wyłuska powtarzające się wzorce i dopisze je do review M D. Wtedy przy nowym pull requeście wie z góry, czego szukać.
Sam przegląd to jednak za mało. Przed scaleniem zmian warto dołożyć haki. Hak blokuje konkretne działania agenta. Przykłady: próba dotknięcia produkcyjnej bazy danych, próba scalenia pull requesta, próba zapisania danych uwierzytelniających do repozytorium, edycja plików, których agent ruszać nie powinien.
Haki przydają się też w układzie, w którym agent recenzent wysyła uwagi agentowi wykonawcy. Wtedy hak pilnuje, żeby przed kolejnym obiegiem formatowanie było poprawne, a testy przechodziły. To jest bariera ochronna przed wypchnięciem błędów i wrażliwych danych na produkcję.
Etap ósmy: wdrożenie przed i po
Wdrożenie dzieli się na dwie części.
Przed wdrożeniem: przepływ pracy wywołuje Claude w trybie bez interfejsu, każe mu przeczytać cały log nieudanego budowania, znaleźć przyczynę, przygotować pull requesta i wystawić go do przeglądu. Poprawka przechodzi przez opisany wcześniej proces, a funkcja trafia na produkcję.
Po wdrożeniu: Claude wywołuje narzędzie statusu. To może być Data Dog, Sentry albo dowolny system monitorowania wydajności, który masz. Zadanie brzmi: sprawdź, czy coś się drastycznie nie psuje po tym wydaniu. Jeśli się psuje, agent dostaje narzędzie do wycofania zmiany, szuka przyczyny źródłowej, tworzy pull requesta i cały proces wdrożenia zaczyna się od nowa.
Etap dziewiąty: metryki zamykają pętlę
Ostatni etap to utrzymanie, czyli domknięcie pętli na metrykach. Znowu chodzi o dane z Sentry, Data Doga albo innego narzędzia do śledzenia wydajności.
Podręcznik pokazuje przykładowy plik konfiguracyjny, który cyklicznie patrzy na ostatnie trzydzieści dni. Claude przegląda logi i szuka rzeczy do poprawy. Powtarzający się błąd. Zapytanie do bazy, które robi się coraz wolniejsze. Miejsce, w którym użytkownicy odpadają z aplikacji.
Cokolwiek to jest, wraca do punktu wyjścia. Agent zakłada nowy plik intent M D i cały cykl rusza od początku.
Koniec artykułu.