Agent AI do kodu w 2025: szybciej czy wolniej pracujesz (i gdzie stawiać granicę autonomii w małym zespole IT)

W większości małych zespołów IT, z którymi rozmawiam, pytanie nie brzmi „czy wdrożyć agenta do kodu", bo już jest wdrożony. Ktoś zainstalował Cursora albo włączył Copilota w VS Code i po prostu z niego korzysta. Pytanie brzmi: dlaczego mimo tego sprinty nie są krótsze, a liczba poprawek po code review rośnie zamiast maleć. I to jest dobre pytanie, bo odpowiedź rzadko leży w samym narzędziu.

Zacznę od tezy, która w rozmowach z klientami budzi opór: agent AI do kodu w zespole 3-5 osobowym bez sformalizowanego procesu review jest ryzykiem większym niż brak automatyzacji. Nie dlatego, że narzędzie jest złe. Dlatego, że przyspiesza etap, który i tak nie był wąskim gardłem (pisanie kodu), a nie dotyka etapu, który faktycznie spowalnia projekt: zrozumienia, testowania i utrzymania tego, co powstało.

Gdzie agent faktycznie przyspiesza pracę

Są zadania, przy których agent kodu to czysty zysk czasu, bez dyskusji. Generowanie boilerplate'u, prostych endpointów CRUD, testów jednostkowych do funkcji, które już istnieją i mają jasną sygnaturę, konwersja formatu danych, pisanie skryptów pomocniczych, dokumentacja techniczna wygenerowana z komentarzy w kodzie. To zadania o niskiej niepewności: dobrze zdefiniowany wejście, dobrze zdefiniowane wyjście, mało kontekstu biznesowego do trzymania w głowie.

Jeśli programista w zespole codziennie traci 40-60 minut na pisanie powtarzalnych testów albo boilerplate'u do kolejnego modułu API, tam agent kodu daje wymierny zysk niemal od razu. To jest praca mechaniczna, którą kiedyś robił junior albo sam senior „na pamięci", i tu narzędzie faktycznie skraca czas do wdrożenia zmiany.

Problem zaczyna się w momencie, gdy przenosimy to samo zaufanie na zadania o wysokiej niepewności: refaktoryzację modułu, który ma pięcioletnią historię commitów, poprawkę buga w kodzie, którego logiki nikt w zespole już do końca nie pamięta, albo zmianę w systemie płatności, gdzie każda literówka kosztuje realne pieniądze. Tam agent generuje kod, który wygląda poprawnie, kompiluje się, przechodzi proste testy, i wprowadza subtelny błąd, który wypłynie za trzy tygodnie w produkcji.

Co pokazują badania: szybciej na papierze, wolniej w praktyce

Warto rozdzielić dwa rodzaje danych, bo w dyskusjach o AI w kodzie często się je miesza. Pierwszy typ to badania kontrolowane, gdzie deweloperzy dostają jasno zdefiniowane zadanie (np. napisać serwer HTTP w izolowanym środowisku) i mierzy się czas realizacji. W takich warunkach raporty GitHub pokazywały przyspieszenie sięgające nawet 55% w porównaniu z pracą bez asystenta AI. To imponująca liczba, ale dotyczy zadań stworzonych specjalnie pod eksperyment: krótkich, dobrze opisanych, bez balastu firmowego kodu i konwencji zespołu.

Drugi typ danych jest mniej wygodny i dlatego rzadziej się o nim mówi. Badanie METR z 2025 roku sprawdziło coś innego: jak asystenci AI działają nie na sztucznych zadaniach, tylko na realnym, dojrzałym kodzie open source, przy udziale doświadczonych programistów, którzy dobrze znają dany projekt. Wynik był odwrotny od intuicji: ci programiści z narzędziem AI byli wolniejsi o około 19% niż bez niego, mimo że subiektywnie deklarowali odczucie przyspieszenia.

Innymi słowy: im bardziej kod jest „obcy" dla modelu (specyficzna domena, stare zależności, niestandardowa architektura), tym mniejszy realny zysk czasu, a większe ryzyko, że wygenerowany fragment wygląda dobrze, ale nie pasuje do reszty systemu w sposób, który trudno wyłapać na pierwszy rzut oka.

Dlaczego w małym zespole IT to się kończy długiem technicznym

W dużej organizacji code review jest procesem sformalizowanym: dwie osoby zatwierdzają pull request, jest checklist, jest CI/CD z testami, jest ktoś odpowiedzialny za architekturę. W zespole trzyosobowym często tego procesu po prostu nie ma, bo nie ma na niego czasu ani ludzi. I to jest moment, w którym agent kodu przestaje być narzędziem wspierającym, a zaczyna być cichym źródłem długu technicznego.

Mechanizm jest prosty

Agent generuje działający kod szybciej, niż zespół jest w stanie go zrozumieć i zweryfikować. Presja czasu (deadline, klient czeka) sprawia, że kod trafia do produkcji bez pełnego przeglądu, bo „przecież działa, testy przeszły". Trzy miesiące później nikt w zespole nie pamięta, dlaczego dana funkcja jest napisana akurat tak, bo nikt jej nie napisał świadomie, tylko zaakceptował sugestię. Kolejna zmiana w tym miejscu kosztuje więcej czasu niż normalnie, bo trzeba najpierw odtworzyć logikę, zamiast ją znać.

To jest dokładnie ten sam mechanizm, który znamy z automatyzacji procesów biznesowych, tylko przeniesiony na kod. Automat robi 80% pracy dobrze, ale 20% przypadków wymaga decyzji człowieka, i jeśli nikt tej decyzji nie podejmuje, błąd nie znika, tylko przesuwa się dalej w łańcuchu, aż w końcu kosztuje więcej niż na początku. Widzimy to zresztą wprost przy automatyzacji faktur czy przy automatyzacji obsługi klienta: bez jasno wyznaczonego punktu, w którym system oddaje sprawę człowiekowi, oszczędność czasu na wejściu zamienia się w koszt naprawy na wyjściu.

Gdzie stawiać granicę autonomii agenta

Ta granica nie jest kwestią zaufania do narzędzia, tylko kwestią tego, kto ponosi konsekwencje błędu i jak szybko da się go wykryć. Test jednostkowy, który agent napisał źle, zwykle po prostu nie przejdzie, albo od razu widać, że coś jest nie tak. Błąd w logice naliczania rabatu, który wypłynie po miesiącu w postaci reklamacji klientów, jest dużo droższy w naprawie niż w prewencji.

Jak to ustawiamy w praktyce

W projektach, przy których pomagamy zespołom wdrożyć agenta do kodu bez utraty kontroli nad jakością, trzymamy się kilku zasad, które brzmią prosto, ale wymagają dyscypliny, bo łatwo je porzucić pod presją terminu.

Po pierwsze, każdy fragment wygenerowany przez agenta i przeznaczony do produkcji przechodzi przez ten sam proces review co kod napisany ręcznie, bez wyjątków „bo to tylko mały fragment". Po drugie, agent nie dostaje dostępu do zmiany plików konfiguracyjnych związanych z bezpieczeństwem, kluczami API czy uprawnieniami bez jawnej akceptacji człowieka na każdym kroku, nie tylko na końcu sesji. Po trzecie, w projekcie utrzymujemy minimalny poziom pokrycia testami dla modułów krytycznych, bo agent bez dobrych testów jako punktu odniesienia potrafi „naprawić" błąd tak, że test przestaje sprawdzać to, co powinien.

I ostatnia zasada, najczęściej łamana w praktyce: jeśli programista nie rozumie, dlaczego wygenerowany kod działa, nie powinien go commitować, niezależnie od presji czasowej. To brzmi jak oczywistość, ale w małych zespołach, gdzie jedna osoba odpowiada za pół systemu, jest to pierwsza zasada, którą porzuca się w piątek po południu przed wdrożeniem.

Ile to realnie zmienia w kosztach

Jeśli spojrzeć na to od strony budżetu, obraz jest bardziej złożony niż „AI oszczędza X godzin miesięcznie". Zysk czasu na etapie pisania kodu jest realny i widoczny od razu, dlatego łatwo go pokazać w prezentacji dla zarządu. Koszt weryfikacji, poprawek i długu technicznego jest rozłożony w czasie i trudniej go przypisać jednej decyzji, dlatego łatwo go zignorować, dopóki się nie skumuluje.

Z naszego doświadczenia sensowniej jest liczyć nie „ile czasu zaoszczędził agent", tylko „ile czasu zespół spędza na code review i poprawkach po wdrożeniu agenta w porównaniu z okresem przed". Jeśli ta druga liczba rośnie szybciej niż pierwsza spada, mamy sygnał, że autonomia agenta jest ustawiona za wysoko dla danego zespołu, niezależnie od tego, jak dobre jest samo narzędzie.

To zresztą uniwersalna zasada przy wdrażaniu jakiejkolwiek automatyzacji w firmie, nie tylko przy kodzie. Przy automatyzacji biura rachunkowego stosujemy dokładnie tę samą logikę: automat przejmuje pracę mechaniczną, człowiek zostaje ostatnią instancją tam, gdzie błąd kosztuje realne pieniądze albo relację z klientem. Kod nie jest tu wyjątkiem.