Przez dwanaście tygodni pracowałem dla klienta nie tyle nad kodem, ile nad procesem wokół niego. Zmiany opisywał klient — osoba bez doświadczenia programistycznego — a kod pisał za niego Claude Code. Moim zadaniem było zautomatyzowanie reszty: planowania, review, testów i wdrażania, tak żeby to, co wychodzi z modelu, dało się bezpiecznie wpuścić na produkcję.
W tym czasie nie powstała ani jedna linijka kodu napisana ręcznie, a każdy pull request szedł z opisem zmiany, automatycznym review i testami po drodze. Człowiek wchodził tam, gdzie proces sam oznaczał coś jako decyzję krytyczną.
Samo pisanie kodu przez model nie jest tu jednak najciekawsze, bo to dziś potrafi każdy. Ciekawe jest, ile pracy wokół kodu da się zdjąć z człowieka, żeby przy takim tempie nic się nie posypało.
Projekt jest komercyjny i objęty poufnością, więc nie podaję nazwy klienta ani szczegółów produktu.
Kto właściwie napisał ten kod
Kodu pisanego ręcznie nie było wcale. Człowiek miał w tym układzie trzy zadania: opisać, co ma się zmienić, zatwierdzić plan, zanim powstanie kod, i rozstrzygnąć te miejsca, w których proces sam sygnalizował, że decyzja jest krytyczna. Resztą zajmował się agent.
To trzecie zadanie nie powinno spadać na osobę, która opisuje zmiany. Kiedy proces oznacza coś jako krytyczne — uprawnienia, pieniądze, dane innych firm — decyzję musi podjąć ktoś, kto potrafi przeczytać diff i przewidzieć, co się stanie po wdrożeniu. W praktyce oznacza to doświadczonego programistę. Automatyzacja zdejmuje z człowieka rutynę, nie odpowiedzialność.
Najpierw rozmowa, potem kod
Zmiana zaczyna się tu od procedury, która przepytuje: jedno pytanie naraz, z propozycją odpowiedzi i furtką na „nie, inaczej”. Model dopytuje o rzeczy, których w zleceniu nie było — co ma się stać w przypadku brzegowym, czy dotyczy to również starych danych, po czym poznamy, że jest gotowe.
Dopiero z tej rozmowy powstaje plan, a dopiero zatwierdzony plan idzie do implementacji. Każda taka rozmowa zostawia po sobie plik, więc po trzech miesiącach w repozytorium leży komplet opisów: co, dlaczego i po czym poznamy, że gotowe.
Ten etap wygląda na najbardziej zbędny w całym procesie, a jest odwrotnie. Model, który dostaje jedno zdanie polecenia, resztę zgaduje, i to bardzo przekonująco. Po dwudziestu pytaniach nie ma już czego zgadywać. Tę samą zasadę stosuję we własnych projektach — przy ZapiszPrzepis plan przed kodem skrócił budowę wyszukiwarki z tygodnia do trzech dni.
Jak wygląda review
Kod napisany przez model trzeba przeczytać, a przy kilku zmianach dziennie nikt nie zrobi tego ręcznie z należytą uwagą. Tę część wziął na siebie Cezar — narzędzie spinające agenty z cyklem życia zadania na GitHubie, w które wpięto własny zestaw procedur.
Pull request pojawia się na GitHubie i dostaje etykietę, która uruchamia workflow:
- Krok 1
Rozpoznanie zmiany
Agent czyta diff, powiązane zadanie i plan zmiany, jeśli istnieje.
- Krok 2
Uzupełnienie dokumentacji
Jeśli ktoś pominął etap planowania, agent odtwarza opis zmiany z tego, co faktycznie powstało.
- Krok 3
Review w sześciu wymiarach
Zgodność z planem, zakres, bezpieczeństwo, architektura, spójność ze wzorcami, kryteria akceptacji.
- Krok 4
Werdykt i komentarz
Zaakceptowane, do poprawy albo odrzucone — wraz z listą znalezisk, każde z plikiem i numerem linii.
- Krok 5
Etykieta na liście
Stan zmiany widać na liście pull requestów kolorem, bez wchodzenia w szczegóły.
Agent ma przy tym zakaz dotykania kodu. Wolno mu zapisać jedynie dokumentację zmiany, nigdy poprawkę w źródłach.
Etykieta przy tytule wystarcza na co dzień za cały interfejs: zielona znaczy, że agent nie ma zastrzeżeń, pomarańczowa — że są uwagi do przeczytania.
Co ten agent wyłapuje
Pojedyncze review zaczyna się od werdyktu i tabeli z oceną w sześciu wymiarach:
Pod nią idą ponumerowane znaleziska, każde z wagą, plikiem, numerem linii i propozycją poprawki:
Blisko połowa tych uwag nie dotyczy jakości kodu, tylko tego, czy zmiana robi to, co zapowiedziała, czy odhaczono kryteria akceptacji i czy nie wjechało coś, czego nikt nie zamawiał.
Linter tego nie sprawdzi, bo nie zna planu, a człowiek o siedemnastej patrzy już tylko na diff, a nie na to, od czego zaczynał.
Jeden konkret zamiast przymiotników
Na jednym z pull requestów agent zgłosił, że jedna ze ścieżek zapisu sprawdza uprawnienia na poziomie organizacji, ale pomija dostęp do konkretnej firmy. Interfejs tego nie ujawniał, bo lista wyboru była już przefiltrowana. Użytkownik mógł jednak wysłać spreparowany formularz i podpiąć zasób należący do innej firmy.
Agent podał plik i numer linii, pokazał identyczną operację w sąsiednim pliku, gdzie sprawdzenie było zrobione poprawnie, i napisał, którą funkcję dodać. Typy tego nie złapią, bo obie ścieżki są poprawne pod względem typów, a testu nikt takiego nie napisał.
Więcej znalezisk nie znaczy lepiej
To jest pułapka, w którą łatwo wpaść przy automatycznym review. W innym projekcie korzystałem z CodeRabbita i dostawałem długie listy uwag, z których większość okazywała się fałszywa. Przeglądanie ich kosztowało więcej czasu niż samo czytanie kodu, a po dwóch tygodniach zacząłem je przewijać. Narzędzie formalnie działało, w praktyce przestało cokolwiek wnosić.
Tutaj problem był odwrotny: uwag krytycznych wyszło podejrzanie mało. Kod recenzował model, który sam go napisał, a trudno wychwycić założenie, które samemu się przyjęło.
Obie skrajności kończą się tak samo — człowiek przestaje czytać. Review jest warte tyle, ile jego trafność, a nie ile pozycji ma lista. Stąd wniosek, który biorę do kolejnych projektów: rozdzielać pisanie i recenzowanie między modele różnych dostawców i sprawdzać, który wyłapuje rzeczy, na które naprawdę reagujesz.
Tempo
Połowa pull requestów zamykała się w godzinę. Zmiany były małe, więc review trwało krótko; review było automatyczne, więc nie czekało na czyjś wolny wieczór. Nic się nie odkładało, więc nic nie puchło.
Zwykle wystarczały dwie rundy uwag, choć zdarzały się zmiany, które wracały kilkanaście razy.
Jeden adres, pod który zagląda agent
Projekt wystartował na publicznym pakiecie procedur do Claude Code, ale plany szły do jednego katalogu, specyfikacje do drugiego, raporty postępu do trzeciego. Człowiek jakoś sobie z tym radzi, bo pamięta, gdzie co wrzucił.
Agent nie pamięta nic między sesjami. Dostaje wyłącznie to, co potrafi znaleźć, i na tym stoi cały opisany wyżej mechanizm: review porównuje zmianę z jej planem, więc plan leżący pod nieoczekiwanym adresem jest dla agenta tym samym, co plan nieistniejący.
Gdzie to nie działa
Planowanie zostało świadomie odpuszczone. Z czasem uznano, że zajmuje za dużo czasu, i część zmian ruszała prosto do implementacji. Procedura potrafi odtworzyć opis po fakcie, więc dokumentacja nie ma dziur — ale opis pisany po implementacji odpowiada na pytanie „co zrobiliśmy”, podczas gdy wartość tego etapu leży w pytaniu „co powinniśmy zrobić”, zadanym wcześniej.
Bramka kompilacji rzadko się uruchamia. Agent ma zbudować gałąź i sprawdzić typy, ale zwykle nie ma pod ręką środowiska. Twardą bramką pozostaje CI, a agent dokłada to, czego CI sprawdzić nie umie. Jak wpinam AI w same testy, opisałem w przewodniku po testach E2E z Playwrightem.
Co z tego ma Twój projekt
- Każda zmiana jest opisana, zanim powstanie, i sprawdzona wobec tego opisu, kiedy powstanie. Nic nie wchodzi na produkcję bez śladu, dlaczego weszło.
- Kryteria akceptacji nie są odhaczane na słowo. Jeśli coś z listy cicho wypadło, wychodzi to w review, zanim dojedzie do wdrożenia.
- AI nie ma prawa zapisu tam, gdzie ryzyko jest realne. Poprawki lądują jako szkic do zatwierdzenia, nigdy jako automatyczne scalenie.
- Proces zostaje u Ciebie. Procedury to zwykłe pliki w Twoim repozytorium, które możesz czytać i zmieniać.
- Jedna osoba odpowiedzialna za całość — od ustalenia zakresu, przez wdrożenie, po wsparcie po starcie.
Podsumowanie
- Kod może w całości pisać model, o ile przed implementacją stoi rozmowa i plan, a po niej automatyczne review. Samo generowanie kodu jest tu najłatwiejszą częścią.
- Blisko połowa uwag z review dotyczy zgodności z planem i kryteriami akceptacji, a nie jakości kodu. Nie sprawdzi tego narzędzie, które nie zna ustaleń.
- Automatyczne review skraca cykl, bo nie czeka na wolny wieczór. Połowa zmian zamykała się w godzinę.
- Liczba znalezisk to zły miernik. Zbyt długa lista fałszywych alarmów i zbyt krótka lista uwag kończą się tym samym: człowiek przestaje czytać.
- Do pisania i do recenzowania warto brać modele różnych dostawców. Ten sam model rzadko widzi własne błędne założenia.
- Decyzje oznaczone jako krytyczne zatwierdza doświadczony programista. Proces wskazuje miejsce, ale ocenić skutki musi ktoś, kto umie przeczytać diff.
Skąd wziąłem Cezara
Na 10xDevs — kursie prowadzonym przez Przemka Smyrdka i Marcina Czarkowskiego z Przeprogramowani. Narzędzie pokazywał na gościnnym spotkaniu Piotr Karwatka, twórca Divante, dziś rozwijający Open Mercato.
Samo narzędzie mocno się od tego czasu zmieniło. Opisany wyżej proces jest jednak niezależny od konkretnego przycisku w interfejsie: procedury to pliki w repozytorium, a bramką jest etykieta na pull requeście.
