Moje doświadczenie w QA nauczyło mnie, że bez szybkiego feedbacku rozwój złożonego oprogramowania jest obarczony wysokim ryzykiem błędu. Gdy pracowałam jako software engineer w JS, TDD było moim podstawowym narzędziem pracy – pozwalało na bieżąco weryfikować architekturę i chroniło przed regresją.
Dziś mój workflow opiera się na zarządzaniu agentami AI, którzy generują kod na podstawie moich instrukcji. W tym modelu pracy TDD stało się jeszcze ważniejsze niż wcześniej.
Dla jasności: to nie jest "vibe coding" znany z social mediów. Wciąż rzetelnie recenzuję każdą zmianę, ale mój focus się zmienił. Zamiast analizować kod znak po znaku, skupiam się na ustawieniu odpowiednich ram – tego, jak system ma działać i jaką wartość przyniesie biznesowi. Nie marnuję już czasu na zastanawianie się, czy funkcja mogłaby być napisana nieco inaczej. Oczywiście, gdy wiem, że dany fragment jest krytyczny, sprawdzam go bardzo dokładnie. Jednak w pozostałych przypadkach ufam moim agentom – to ich zadaniem jest dbanie o techniczne szczegóły, podczas gdy ja trzymam rękę na pulsie całości.
Weryfikacja kodu generowanego przez AI
Współpraca z LLM-ami zmienia charakter Code Review. Zamiast analizy każdej instrukcji warunkowej, skupiam się na architekturze i przepływie danych. Szczegóły implementacji są weryfikowane automatycznie.
W świecie kodu generowanego maszynowo, wysokie pokrycie testami gwarantuje, że:
- Happy path realizuje założenia biznesowe.
- Edge case’y, które AI może pominąć w procesie generowania tokenów, są obsłużone.
- Kolejne iteracje nie powodują regresji w istniejących modułach.
Bez testów kod generowany przez AI może sprawiać wrażenie poprawnego strukturalnie, jednocześnie nie realizując poprawnie logiki w scenariuszach innych niż podstawowe.
Testy jako definicja ograniczeń dla agenta
Modele AI wymagają precyzyjnych ram działania. Definiując testy na początku procesu, tworzysz zestaw reguł (guardrails), których implementacja musi przestrzegać. Dzięki temu agent nie musi interpretować niejasnych wymagań – otrzymuje konkretne, binarne kryteria poprawności.
Takie podejście wymusza również konkretne decyzje architektoniczne. Przykładowo, przeniesienie logiki do backendu może być podyktowane wyłącznie łatwością jej testowania i pełną kontrolą nad wynikiem operacji. Testy stają się więc narzędziem do precyzyjnego projektowania systemu. Nawet jeśli agent wygeneruje zbyt skomplikowaną lub błędną logikę, testy natychmiast wykażą rozbieżność z oczekiwanym rezultatem i wymuszą poprawki — a Ty nie będziesz musieć nawet brać w tym udziału!
Plan implementacji zamiast improwizacji
Wraz z rozwojem modeli zaczął ewoluować także mój workflow. Dzisiaj bardzo rzadko zaczynam od pisania kodu. Zamiast tego najpierw tworzę implementation plan, którego główną zasadą jest TDD.
Plan nie powstaje w jednej iteracji. Najpierw przygotowuję wstępną wersję, a potem iteruję nad nią z kilkoma agentami, z których każdy ma inny "focus", na przykład:
- architektura systemu,
- jakość implementacji,
- specyfika domeny problemu.
Dopiero po kilku takich iteracjach powstaje plan, który jest naprawdę dopracowany.
Implementacja fazami
Gdy plan jest gotowy, zaczyna się właściwa implementacja. Każda faza uruchamiana jest w osobnym czacie, żeby zachować czysty kontekst. I tutaj kluczową rolę odgrywa TDD — używam go tak często, że mam już do tego dedykowanego Claude Skilla.
W fazie 0 definiowane lub implementowane są testy. Od tego momentu ich zmiana jest praktycznie zabroniona – chyba że wydarzy się coś naprawdę wyjątkowego. Dalszy proces wygląda tak:
- Agent implementuje daną fazę.
- Weryfikuje implementację testami.
- Następnie kod trafia do trzech agentów recenzujących – zazwyczaj Software Architect, Senior Engineer oraz ekspert z domeny.
Każdy z nich jest krytyczny i ocenia rozwiązanie z innej perspektywy. Ich uwagi są następnie weryfikowane (bo zdarzają się również false positives). Jeśli są zasadne, agent wprowadza poprawki i ponownie uruchamia testy. Ten cykl powtarza się zazwyczaj trzy razy. Na końcu agent aktualizuje implementation plan i oznacza fazę jako zakończoną — a w nowym czacie rozpoczynam kolejną fazę (wszystko po to, aby ograniczać ilość kontekstu, którą zarzucam agenta).
Pamiętasz mój "brain dump"? Tam właśnie zapisuję cały postęp. Proszę też agentów o tworzenie "progress notes" w bazie wiedzy, dzięki czemu mogę śledzić wysokopoziomowy przepływ pracy nad każdą fazą. To pozwala mi w dowolnym momencie cofnąć zmiany lub wrócić do konkretnego kontekstu, bez tracenia czasu na przypominanie sobie szczegółów.
30 minut pracy AI zamiast godzin debugowania
Z zewnątrz taki proces może wydawać się długi. AI potrafi pracować nad jedną fazą nawet 20–30 minut, zanim wróci z finalnym rezultatem. W praktyce jednak efekt jest zupełnie inny niż przy szybkim generowaniu kodu. A przy dobrym rozplanowaniu pracy (np. użyciu git worktrees albo pracy nad kilkoma projektami równocześnie, lub w innej części codebase), ja mogę w tym czasie skupić się na czymś zupełnie innym.
Zamiast niedziałającej implementacji, ukrytych edge case’ów czy przypadkowych decyzji projektowych, dostaję rozwiązanie, które:
- przechodzi testy,
- zostało przeanalizowane z kilku perspektyw,
- jest zgodne z wcześniej ustalonym planem.
Testy pełnią tu rolę obiektywnego mechanizmu weryfikacji. Nie tylko dla mnie – ale również dla samego AI.
Dlaczego TDD jest dziś jeszcze ważniejsze
W świecie, w którym kod powstaje coraz szybciej, najcenniejsza staje się nie sama implementacja, ale pewność, że działa poprawnie. Dla mnie TDD zawsze było narzędziem przyspieszającym rozwój oprogramowania. W pracy z AI stało się czymś więcej. Stało się mechanizmem kontroli nad systemem, który potrafi generować kod szybciej, niż człowiek jest w stanie go przeczytać.
Zawsze doceniałam TDD, ale dziś widzę, jak ogromną rolę może odgrywać w nowoczesnym wytwarzaniu oprogramowania.
