Agenty Claude Code podpięte do Fluttera

Przez większość mojej kariery przyjęty kształt „narzędzi programisty” wyglądał tak: ty piszesz, edytor trochę pomaga, kompilator dużo krzyczy. Pętla była sterowana człowiekiem i szybka, bo kompilator był szybki.

Claude Code zmienia ten kształt. AI nie siedzi w marginesie edytora autouzupełniając nazwy — ono uruchamia toolchain. Czyta repo, odpala flutter analyze, wybiera niezdany test, czyta test, czyta kod pod testem, proponuje łatkę, aplikuje ją, odpala ponownie. To nie autouzupełnianie. To kolega z zespołu.

Gdzie to zmieniło mój workflow (na lepsze)

Pierwsza rzecz, którą zauważyłem: agent jest nudno-dobry w nudnych rzeczach. Dodanie nowego ekranu, podpięcie routingu, przeprowadzenie modelu przez repozytorium do widoku — ta praca, która kiedyś pochłaniała wtorkowy poranek, teraz dzieje się, gdy dolewam kawy.

Druga rzecz: na naprawdę trudnych problemach agent jest grzeczny wobec niepewności. Pisze test, odpala, czyta wynik, wraca i mówi „test pokazuje, że bug jest w serializerze, nie w widżecie; myślę, że poprawka jest tutaj — spróbować?” To lepsza rozmowa niż ta, którą wcześniej miałem sam ze sobą.

Format „przepisu”

Wszystko działa lepiej, gdy dasz agentowi kształt. W każdym repo Fluttera trzymam katalog .claude/skills/ z krótkimi, imperatywnymi plikami markdown — każdy to „przepis” na konkretny krok SDLC. Jeden na dodanie funkcjonalności. Jeden na naprawę buga. Jeden na wydanie. Każdy przepis mówi agentowi, jakie komendy odpalić, w jakiej kolejności i co znaczy „gotowe”.

Przepis na fix może wyglądać tak: (1) zreprodukuj buga niezdanym testem; (2) przepchnij test najmniejszą łatką; (3) odpal cały suite; (4) odpal lintera; (5) commituj z wiadomością w stylu Conventional Commits. Agent idzie tą ścieżką i dostaję PR w dokładnie takim kształcie, jaki sam bym ułożył.

Haczyk jest taki, że przepisy są krótkie. Długie przepisy gniją. Jeśli przepis ma więcej niż tuzin punktów, dzielę go na pół.

Co przestałem robić

Kiedyś trzymałem TODO każdej funkcjonalności w głowie. Teraz wysyłam agenta i robię coś innego. Gdy wraca, czytam diff.

Kiedyś przełączałem się między tuzinem kart. Teraz agent czyta za mnie dokumentację i ją parafrazuje. Sprawdzam punktowo, gdy odpowiedź ma znaczenie.

Kiedyś pisałem kod szkieletowy. Teraz piszę kontrakt — interfejsy, schematy, nazwy testów — a agent uzupełnia implementację, która go spełnia.

Twarde kawałki dalej piszę ręcznie. Te, w których trzeba przemyśleć subtelny niezmiennik albo podchwytliwy cache. W tym AI jeszcze nie jest lepsze. Ale uwolniło tyle łatwego czasu, że mogę rzeczywiście myśleć o trudnych rzeczach, zamiast być odrętwiały po przedarciu się przez tysiąc drobnych ceremonii.

Co jeszcze rozgryzam

Interesujący tryb błędu to nie „AI pisze zły kod”. To „AI pisze dobry kod dla złego pytania”. Dajesz mu zgłoszenie buga „przycisk nie działa”, a on dodaje sprawdzenie stanu wyłączonego — gdy prawdziwy problem jest taki, że wcześniejszy refaktor sprawił, że handler tapa jest nieosiągalny. Poprawka działa na zgłoszony objaw i ukrywa źródło.

Antidotum to bycie uczciwym co do tego, czym jest bug. Co i tak jest dobrą praktyką. Po prostu robi się drożej, jeśli się ją pomija.

Jeśli chcesz spróbować

Wrzuć do repo folder .claude/skills/ z fix.md, feature.md, ship.md. Każdy krótki. Każdy mówi agentowi, co znaczy „gotowe” dla tego rodzaju zadania. Zaufaj linterowi i suitowi testów — to sygnały zwrotne agenta, a jeśli są słabe, agent zacznie dryfować. Im lepsze twoje narzędzia, tym lepszy twój agent.

Flutter akurat ma świetne narzędzia. flutter analyze, flutter test, dart format, dart fix. Podepnij je do agenta i próg jakości pilnuje się sam.

Prawdziwa zmiana dla mnie nie dotyczyła kodu. Dotyczyła tego, co robię cały dzień. Mniej pisania. Więcej myślenia. Więcej wysyłki.