9 zasad programowania z AI - #8: Review według ryzyka
Spis treści
W poprzedniej części ustawialiśmy moc i liczbę agentów. Im więcej ich pracuje, tym więcej zmian trzeba sprawdzić, a człowiek ma wciąż tyle samo czasu. Zostaje pytanie: kto, kiedy i jak dokładnie to sprawdza?
Zasada #8: review według ryzyka
Czas człowieka na przegląd zmian jest deficytem, więc poziom kontroli ustala ryzyko zmiany. Maszyny czytają resztę.
Review to po prostu przegląd zmian w kodzie przez drugą osobę (albo agenta), zanim trafią do wspólnej wersji. Zamiast pytać „czy przeczytałem wszystko”, pytamy: czy to wystarczająco bezpieczne.
Zmiana celu
Zespół Claude Code opisał własny proces w artykule na blogu Anthropic. Claude pisze tam ok. 90% kodu produktu (Claude Code), więc zespół zmienił cel: nie „każdy ma przeczytać każdą linijkę”, tylko minimalny czas ludzkiego przeglądu, który nie zwiększa liczby cofniętych zmian (tzw. revertów) ani awarii. Docelowo większość zmian ma wymagać najwyżej jednej osoby, a tą osobą może być sam autor.
Warstwy kontroli
Przegląd składa się z kilku warstw, z których większość robią maszyny:
- Agent sprawdza sam siebie: uruchamia testy i pokazuje wyniki, a pomocniczy agent z czystym kontekstem przegląda jego zmiany
- Przegląd przez AI: kilka agentów szuka błędów równolegle, a inne głosują; publikowane są tylko znaleziska, co do których jest zgoda
- Kontrola bezpieczeństwa, która blokuje zmianę, dopóki problemy nie zostaną zamknięte
- Automatyczne kontrole (CI), które uruchamiają się przy każdej zmianie: testy, kontrole poprawności i stylu kodu, budowanie projektu
- Zatwierdzenie przez człowieka, ale tylko tam, gdzie ryzyko tego wymaga
- Ostrożne wdrażanie: zmiany trafiają najpierw do pracowników firmy, dopiero potem do wszystkich, i da się je cofnąć jednym krokiem
Ilu ludzi? To zależy od ryzyka
Zasada: poziom kontroli ustala zmiana, nie autor. Dokumentacja i zmiany ukryte za przełącznikiem (tzw. flagą, czyli wyłączone, dopóki ich nie włączymy) mogą przejść bez człowieka, jeśli kontrole maszynowe są zielone. Zwykłe zmiany wymagają jednej osoby. Najwrażliwszy kod, jak płatności, automatyczne aktualizacje czy procesy publikacji, wymaga dwóch.
Zatwierdzenie agenta nie zastępuje człowieka. Osoba, która zleciła pracę agentowi, jest wymaganym recenzentem swojej zmiany.
Dane od Anthropic
Zespół podaje wyniki ze swoich repozytoriów: liczba zmian włączonych do głównej wersji kodu wzrosła ponad dwukrotnie (od czerwca do września), a udział cofniętych zmian spadł o ponad 40%. Odsetek zmian, które przechodzą przegląd za pierwszym razem, wzrósł z 65% do 78%, a zmian, które potrzebowały 5 lub więcej rund przeglądu, spadł z 8,9% do 1,5%. To dane producenta o własnym procesie, a nie niezależne badanie.
Żeby przegląd się nie ciągnął
Jedna zmiana przeszła ponad 50 rund przeglądu. Zespół wprowadził więc limit 3 rund (potem autor ma przemyśleć podejście), ponowne sprawdzanie tylko tego, co się zmieniło, i zakaz powtarzania tych samych uwag. Agenta-recenzenta też się doskonali: zmiany, które spowodowały awarię lub zostały cofnięte, trafiają do zestawu testowego, na którym codziennie sprawdza się, czy przegląd działa lepiej.
Przegląd nie musi blokować
Ryan Lopopolo z OpenAI idzie w inną stronę: propozycja zmiany to dla niego wspólne miejsce, w którym agenci i ludzie zostawiają uwagi, ale nikt niczego nie blokuje. Agent piszący kod może każdą uwagę przyjąć, odłożyć albo odrzucić, żeby nie był „zaszczuty” przez recenzentów. Zależy mu na tym, żeby kod był zaakceptowany, a nie idealny i utopiony w drobiazgach.
Gergely Orosz ostrzega przed drugą skrajnością: „zombie code reviews”, czyli przeglądami dla formalności, które nikogo nie chronią. Firma Ramp luzuje je dla mniej ważnych części kodu.
Jak poznawać kod, nie czytając wszystkiego
Zamiast czytać drobne zmiany linijka po linijce, zespół Claude Code prosi agenta o wyjaśnienie wybranego fragmentu albo o wizualne podsumowanie. Według zespołu uczy to więcej niż przeglądanie trywialnych różnic.
Co z tym zrobić od jutra?
- Wypisz 3 poziomy ryzyka dla swojego projektu (np. dokumentacja, zwykły kod, płatności i logowanie) i przypisz im liczbę ludzkich zatwierdzeń
- Dodaj do opisu każdej zmiany 3 pytania: jak to przetestowano, jakie jest ryzyko, jak to cofnąć
- Włącz przegląd przez AI na jednym projekcie i przez kilka tygodni dopracowuj jego zasady: czego szukać, czego nie komentować, jak ma wyglądać dowód
- Mierz nie tylko czas przeglądu, ale też liczbę cofniętych zmian i awarii. Jeśli rosną, czas człowieka nie został zaoszczędzony, tylko przesunięty
Jedna pułapka: puszczanie zmian bez człowieka, zanim masz szybki sposób cofania. Anthropic sam przyznaje, że brakuje mu jeszcze „bezpieczników”, które zaostrzałyby zatwierdzanie, gdy rośnie liczba cofnięć i awarii.
W ostatniej części zajmiemy się tym, co zostaje człowiekowi, kiedy agent robi coraz więcej.
A Wy – kto u Was przegląda zmiany pisane przez agenta i czy poziom kontroli zależy od ryzyka? Jestem ciekaw, jak to u Was działa – napiszcie w komentarzach 🙂
Komentarze
Ładowanie komentarzy…
