Przepływ pracy z AI w programowaniu: kryteria akceptacji, testy i CI

Największy problem z kodowaniem wspieranym przez AI nie polega na tym, że model pisze szybko. Problem polega na tym, że zespół często sprawdza ten szybki wynik najwolniejszą metodą: zmęczony programista czyta duży diff linia po linii i traktuje to jako kontrolę. To wygląda odpowiedzialnie, ale bywa słabsze niż pięć minut kryteriów akceptacji przed promptem.

Review jest nadal potrzebne, tylko powinno dotyczyć rzeczy, w których człowiek ma przewagę: zachowania systemu, granic danych, uprawnień, ryzyk migracji, warunków zatrzymania i definicji sukcesu. Człowiek nie jest dobrym symulatorem wszystkich gałęzi, wyścigów i przypadków bezpieczeństwa w ładnie sformatowanym kodzie.

Zdrowy proces zaczyna się od zlecenia pracy. Cel, zakres, rzeczy wykluczone, kryteria akceptacji, przypadki negatywne, polecenia testowe, reguły prywatności i moment, w którym agent ma zapytać człowieka. “Dodaj JWT login” to życzenie. “Nie zmieniaj schematu poza wskazaną migracją, odrzuć zablokowanych użytkowników, rotuj refresh tokeny, przetestuj replay i rate limit” to kontrakt.

Materiały Anthropic o Claude Code, dokumentacja GitHub Copilot coding agent i wskazówki OpenAI dla Codex prowadzą do podobnego wniosku: kontekst repozytorium, jasne instrukcje, ograniczony zakres, logi, testy i ludzka akceptacja. Agent działa dobrze dopiero wewnątrz procesu.

Opór ma źródło kulturowe. Pisanie kodu i ostre komentarze w PR były widocznym dowodem wartości. Kryteria i testy wyglądały jak administracja. Przy AI to właśnie one stają się rdzeniem inżynierii: nazwanie inwariantów, przypadków odmowy, minimalnych uprawnień i planu wycofania.

Testy są pamięcią rozmowy. Model może zgubić instrukcję, test nie. Unit tests, integracja, typy, lint, skany bezpieczeństwa i krótka lista produktowa dają reviewerowi lepszą podstawę niż samo wrażenie, że diff wygląda czysto.

W kontrakcie trzeba uwzględnić prywatność, koszt i lock-in. Do asystentów trafia kontekst repozytorium, logi i czasem dane wrażliwe. Zespół musi rozumieć retencję, trening, uprawnienia oraz to, czy potrzebne są narzędzia lokalne. Wynik powinien być odtwarzalny w CI, nie tylko w historii czatu.

Metoda pasuje do zespołów, które zlecają agentom realne zmiany: backend, płatności, auth, API, automatyzacje, migracje. Bez testów, stagingu i rollbacku pierwszym zadaniem AI powinno być zbudowanie tych barier.

Zmiana roli jest niewygodna, ale uczciwa. Programista nie jest ludzkim linterem dla maszyny. Jest projektantem ograniczeń, które pozwalają udowodnić zmianę.

Dobry nawyk polega na tym, by agent najpierw udowodnił najbardziej ryzykowną tezę. Gdy zmiana zależy od uprawnień, najpierw potrzebny jest test, który ma zawieść. Gdy zależy od wydajności, potrzebna jest komenda pomiaru i budżet. Gdy zależy od zewnętrznego API, trzeba zasymulować błąd, retry i degradację.

Człowiek nadal czyta to, co ważne: architekturę, utrzymanie, produkt i ryzyko. Nie udaje jednak jednocześnie kompilatora, testera i audytora bezpieczeństwa. Review staje się krótsze, ale bardziej techniczne.

Minimalny szablon mieści się w issue: cel, zakres, zakazy, kryteria, przypadki negatywne, komendy weryfikacji, właściciel review i rollback. Po kilku tygodniach staje się wspólnym nawykiem. Nowe osoby szybciej rozumieją, co można zlecić agentowi, a co wymaga rozmowy architektonicznej. Seniorzy zużywają mniej energii na kosmetykę, a więcej na realne granice systemu.

Start nie musi być duży. Wystarczą dwie obowiązkowe komendy w tickecie, jeden przypadek negatywny i zdanie o danych zakazanych. Potem zespół dopisuje punkty, gdy incydent, błąd albo review ujawnia lukę. Bramka nie jest ciężką ceremonią, tylko pamięcią operacyjną, która nie pozwala powtarzać tych samych błędów szybciej dzięki modelowi.

Warto też zmienić miary sukcesu. Liczba wygenerowanych linii albo liczba komentarzy w review nie mówi, czy system stał się bezpieczniejszy. Lepsze pytania brzmią: czy kryteria były jasne, czy testy obejmują ryzyko, czy rollback jest możliwy, czy uprawnienia nie urosły bez potrzeby i czy inny człowiek potrafi odtworzyć decyzję bez czytania całej rozmowy z modelem.

Dla pojedynczego programisty to nie jest degradacja. Pisanie kontraktów, testów i bramek wymaga zrozumienia użytkownika, kosztu błędu i utrzymania systemu. Model może dopisać funkcję, ale nie przejmie odpowiedzialności za produkcję.