Asystenci AI w codziennej pracy programisty: kiedy pomagają, a kiedy przeszkadzają

Dwa lata temu dyskusja brzmiała “czy warto używać AI w programowaniu”. Dziś pytanie jest inne: jak używać, żeby faktycznie oszczędzać czas, a nie tworzyć sobie nowej kategorii problemów. Po kilkunastu miesiącach intensywnej pracy z różnymi asystentami (Claude Code, Copilot, Cursor) mam kilka obserwacji, które mogą zaoszczędzić Ci rozczarowań.

Gdzie AI realnie wygrywa

Boilerplate i rzeczy powtarzalne. Pisanie testów jednostkowych, generowanie migracji bazy danych, tworzenie struktur DTO, parsowanie obcego formatu XML do własnego modelu. To zadania, gdzie LLM jest szybszy od Ciebie kilkukrotnie i nie robi błędów.

Praca w nieznanym stacku. Kiedy musisz szybko ogarnąć framework, którego nie używałeś od roku, zapytanie asystenta jest szybsze niż przeglądanie dokumentacji. Nie zastępuje to zrozumienia, ale pozwala ruszyć z miejsca.

Refaktoryzacja rutynowa. Zmiana wszystkich var_dump na logger, dodanie type hintów do istniejącego kodu, konwersja z promise chains na async/await. Rzeczy, które zajmują godzinę, robią się w pięć minut.

Review własnego kodu. Przekazanie LLM-owi gotowego PR-a z prośbą o wskazanie potencjalnych problemów często wyłapuje edge case’y, których sam nie zauważyłeś.

Gdzie AI przeszkadza

Projektowanie architektury. LLM widzi fragment, nie całość. Kiedy pytasz “jak powinienem to ustrukturyzować”, dostajesz odpowiedź pasującą do generycznych wzorców, a nie do realiów Twojego projektu. Architekturę dalej projektujesz sam.

Kod bezpieczeństwa. Asystenci AI regularnie generują kod podatny na SQL injection, XSS czy niewłaściwą walidację uploadu plików, szczególnie kiedy prosisz o “prosty formularz kontaktowy” albo “endpoint do uploadu”. Wszystko, co dotyka granicy zaufania, przeglądam ręcznie linijka po linijce.

Debugowanie zaawansowanych problemów. Kiedy masz wyciek pamięci, deadlock albo dziwne zachowanie cache’u, LLM będzie strzelał coraz bardziej desperackie hipotezy. W tych sytuacjach profiler, logi i zdrowy rozsądek biją AI na głowę.

Kod, którego nie rozumiesz. Największe ryzyko: akceptujesz sugestię, bo “działa”, ale nie wiesz dokładnie dlaczego. Za pół roku, kiedy coś się zepsuje, masz w kodzie fragment, którego nikt w zespole nie jest w stanie sensownie utrzymać. Zasada jest jedna: jeśli nie rozumiesz każdej linijki, nie commituj.

Moja praktyka

Traktuję AI jak młodszego kolegę z zespołu, który wie dużo, pisze szybko, ale nie ma kontekstu biznesowego i czasem robi głupie błędy. Delegowanie mu prostych zadań uwalnia mi czas na rzeczy, w których faktycznie potrzeba myślenia. Code review robię tak samo skrupulatnie jak przy juniorze, może nawet bardziej, bo AI pisze pewniej niż junior, co łatwiej uśpić czujność.