Praca z AI w kodzie po kilku tygodniach wygląda zupełnie inaczej niż na demo. Na początku ktoś wkleja zadanie, agent analizuje projekt, zmienia pliki, odpala testy i generuje opis pull requesta. Na krótkim filmie albo screenie z terminala wygląda to jak magia. I w dużej mierze faktycznie działa.
Potem zaczyna się codzienna praca. Agent dostaje realne zadania w prawdziwym repo, z historią, z dziwnym legacy i z kodem, którego nikt od lat nie chciał ruszać. Testy odpalają się inaczej niż sugeruje README. Połowa modułów wygląda jak dług techniczny, chociaż trzyma ważną integrację z zewnętrznym systemem.
Ustalenia, na których opiera się połowa projektu, nigdzie nie są zapisane. W tym momencie zaczynają wychodzić rzeczy, o których nikt nie mówi na demo. Nie dlatego, że agent jest zły. Dlatego, że codzienne używanie narzędzia wymaga zupełnie innych nawyków niż jednorazowe odpalenie go na świeżym projekcie.
Ten artykuł opisuje obserwacje, które zbieraliśmy przez kilka tygodni codziennej pracy z AI w kodzie. Każda z nich wyszła dopiero w praktyce i każda wpłynęła na to, jak dziś podchodzimy do współpracy z agentem.
Spis treści
- Podsumowanie od agenta — pierwszy test AI w kodzie
- Agent w nowym repo zgaduje szybciej, niż zdążysz wyjaśnić projekt
- Niewinne polecenia — kiedy AI w kodzie dostaje za dużo swobody
- Paczki, które agent zainstalował, zostają na lata
- Długa sesja z AI w kodzie kończy się dziwnym zachowaniem
- Prywatne prompty to stracona szansa dla zespołu
- Bez zasad firma ma zbiór prywatnych nawyków zamiast wdrożenia AI
- Kiedy agent jest wart swojego kosztu
- Najważniejsze wnioski
- Podsumowanie
Podsumowanie od agenta — pierwszy test AI w kodzie
Agent robi zmianę i podsumowuje ją bardzo pewnie. Testy wyglądają na dodane i opis brzmi sensownie, więc łatwo przejść dalej. Dopiero po wejściu w diff wychodzi, że test sprawdza najprostszy scenariusz, chociaż zadanie dotyczyło zupełnie innego przypadku. Czasem pojawia się też zmiana w pliku, którego wcale nie planowałeś ruszać, ponieważ agent uznał, że tak będzie czyściej.
To w rezultacie jedna z bardziej podstępnych rzeczy w pracy z AI w kodzie. Agent potrafi przygotować elegancką zmianę, dobrać sensowne nazwy i napisać podsumowanie, które brzmi bardzo spokojnie. Łatwo wtedy potraktować opis jako dowód wykonanej pracy.
Autor zmian, niezależnie od tego czy jest człowiekiem czy modelem, zwykle umie opowiedzieć własną robotę w korzystny sposób.
Dlatego po takich przypadkach coraz częściej zaczynam od sprawdzenia diffu, ponieważ szybko wychodzi, czy agent dotknął wyłącznie fragmentu związanego z zadaniem i czy nie dorzucił czegoś od siebie. Reviewer od razu widzi też, czy test faktycznie łapie przypadek, o którym była rozmowa, czy tylko daje miłe poczucie, że testy są.
Kod od AI często wygląda całkiem dobrze. Nazwy są poprawne i struktura jest czysta. Test istnieje i podsumowanie brzmi rozsądnie.
Błąd potrafi siedzieć głębiej, ponieważ może dotyczyć założenia, edge case'a, uprawnień albo tego, że test sprawdza najłatwiejszą wersję problemu. Dopóki nie zobaczę diffu, spokojne podsumowanie od agenta traktuję tylko jako początek sprawdzania.
Testy, które przechodzą, ale nic nie testują
Na przykład, warto zwrócić uwagę na jeszcze jeden wzorzec. Agent czasem dodaje test, który przechodzi, ale testuje zachowanie trywialne. Funkcja ma obsłużyć przypadek z pustą odpowiedzią z API, timeout albo częściowymi danymi, a test sprawdza, czy przy poprawnych danych zwraca poprawny wynik.
Technicznie test istnieje i technicznie przechodzi. Ale nie łapie tego, co miał łapać. W review łatwo to przeoczyć, bo plik testowy jest nowy, nazwy wyglądają sensownie i w podsumowaniu stoi, że testy zostały dodane.
Agent w nowym repo zgaduje szybciej, niż zdążysz wyjaśnić projekt
Pierwsze odpalenie agenta w nowym projekcie wygląda trochę jak wpuszczenie nowej osoby do zespołu i danie jej zadania bez żadnego kontekstu. Jednak AI w kodzie wymaga onboardingu podobnego do człowieka. Niby może czytać pliki i przejrzeć strukturę projektu. Może też odpalić wyszukiwanie i coś z tego wywnioskować.
Projekt składa się jednak również z dziwnych ustaleń, których nikt już nie pamięta, katalogów omijanych przez wszystkich od lat i testów odpalanych inaczej niż sugeruje dokumentacja.
W rezultacie na początku łatwo się zdziwić, że agent zgaduje. Odpala nie tę komendę, proponuje zmianę w złym miejscu albo refaktoruje fragment, którego nikt nie prosił ruszać. Z jego perspektywy to często ma sens, ponieważ dostał tylko pliki i próbuje zbudować sobie obraz projektu na podstawie tego, co widzi. Czasem trafi. Czasem bardzo nie.
Onboarding agenta traktowałbym podobnie jak onboarding nowej osoby w zespole. Nie ma sensu produkować wielkiego dokumentu i tworzyć wrażenia, że AI po jednej komendzie rozumie cały projekt. Wystarczy kilka rzeczy, które realnie zwiększają szansę na sensowną pracę. Jak odpalić testy. Jakiego package managera używać. Kiedy ma zapytać przed instalacją zależności. Których katalogów lepiej nie ruszać. Kiedy ma tylko zaproponować plan i kiedy może edytować pliki.
Pamięć projektu po miesiącu potrafi wyglądać jak piwnica po przeprowadzce. Wszystko może się kiedyś przydać i nikt nie wie, gdzie co leży. Wrzucałbym tam głównie rzeczy, które pomagają agentowi pracować zgodnie z projektem. Jeśli informacja nie wpływa na jego decyzje podczas pracy, prawdopodobnie nie powinna siedzieć w stałym kontekście.
Jest jeszcze jeden aspekt, który łatwo przeoczyć. Agent czyta pliki, ale nie zna historii decyzji. Nie wie, że ten dziwnie wyglądający moduł został napisany celowo, bo zewnętrzne API zmienia format odpowiedzi co kwartał i trzeba trzymać kilka wariantów parsera.
Nie wie, że testy w jednym katalogu odpalają się z flagą, której nie ma w konfiguracji, bo kiedyś ktoś dodał ją ręcznie na CI i zapomniał udokumentować. Kontekst projektu to dużo więcej niż pliki na dysku. Im szybciej agent dostanie te kilka krytycznych informacji, tym mniej czasu zespół straci na cofanie jego pomysłów.
Niewinne polecenia — kiedy AI w kodzie dostaje za dużo swobody
Na przykład najgorsze diffy dostawaliśmy po poleceniach, które brzmiały zbyt niewinnie. Chodzi o luźne prośby związane ze sprzątaniem modułu, poprawianiem architektury albo upraszczaniem kodu bez dokładnego zakresu. Developer pisze to z dobrą intencją, ponieważ chce dać AI trochę przestrzeni. W zamian dostaje kreatywność w miejscu, w którym kreatywność potrafi być kosztowna.
W legacy kodzie brzydkie rzeczy często mają długą historię. Czasem to zwykły dług techniczny. Czasem obsługa wyjątku dla jednego klienta i integracja z systemem, którego nikt już nie chce dotykać. Czasem decyzja sprzed kilku lat, której nie ma w dokumentacji. Agent tego nie wyczuje po samym wyglądzie pliku. Może uznać, że upraszcza, a tak naprawdę wyciąga klocek z konstrukcji, której nie rozumie.
Dlatego przy większych zmianach proszę najpierw o plan, ponieważ chcę zobaczyć, które pliki chce ruszyć i dlaczego akurat te. Chcę też wiedzieć, czego nie jest pewien, gdzie widzi ryzyko i których rzeczy nie będzie ruszać bez potwierdzenia. Dopiero po takim rozpoznaniu ma sens rozmowa o implementacji.
Zły pomysł łatwiej zatrzymać na etapie planu. Przy diffie na kilkanaście plików zaczyna się archeologia, szczególnie gdy agent dopisze, że zmiana upraszcza strukturę projektu.
To samo dotyczy refaktoru. Agent widzi powtórzony kod w trzech plikach i proponuje wyciągnięcie go do wspólnej funkcji. Na pierwszy rzut oka wygląda to jak porządkowanie. Problem pojawia się, gdy te trzy pliki celowo mają podobny kod, bo każdy obsługuje inny wariant integracji i za miesiąc mogą się rozjechać w różne strony. Agent nie ma pojęcia o planach zespołu i nie wie, że ten duplikat jest świadomy. Przy precyzyjnym zadaniu tego problemu nie ma, ponieważ agent dostaje jasny zakres i nie wychodzi poza niego.
Paczki, które agent zainstalował, zostają na lata
Przy zadaniach developerskich modele często proponują najkrótszą ścieżkę do celu. W praktyce potrafi to oznaczać dokładanie zależności tam, gdzie wystarczyłaby prostsza zmiana. Daty, walidacje, formatowanie i parsowanie bardzo łatwo kończą się propozycją dołożenia biblioteki, ponieważ dla modelu wygląda to jak szybka droga do działającego rozwiązania.
Potem w projekcie zostaje kolejna paczka, której zespół nie chciał utrzymywać. Po trzech miesiącach ktoś pyta, skąd się wzięła ta zależność i czy naprawdę jest potrzebna. Czasem wychodzi to dopiero wtedy, gdy aktualizacja wysypuje pół pipeline'u.
Uprawnienia agenta traktowałbym jak zwykły zdrowy rozsądek. Agent może czytać pliki, proponować zmiany i odpalać testy. Przy instalacji paczek, migracjach, sekretach, konfiguracji i destrukcyjnych komendach ma się zatrzymać, ponieważ szybkie rozwiązanie potrafi zostawić koszt na później.
Najbardziej zdradliwe jest to, że agent często robi takie rzeczy w dobrej wierze. On chce rozwiązać zadanie. W prawdziwym repo liczy się również to, ile kosztu zostaje po tej zmianie za miesiąc albo kwartał.
Podobna sytuacja dotyczy zmian w konfiguracji. Agent potrafi zmodyfikować plik konfiguracyjny, żeby jego zmiana zadziałała, bez sprawdzenia, czy ta konfiguracja wpływa na inne środowiska albo inne moduły.
W projekcie z kilkoma środowiskami taka zmiana potrafi wyglądać niewinnie lokalnie i wysypać deployment na staging albo produkcji. Dlatego konfiguracja, sekrety i pliki infrastrukturalne powinny być w jasno określonej strefie, której agent nie rusza bez pytania. Anthropic opisuje to jako permissions i allowed tools — konfiguracja, w której ustala się, co agent może robić sam, a co wymaga potwierdzenia.
Długa sesja z AI w kodzie kończy się dziwnym zachowaniem
Długa sesja z agentem potrafi wyglądać całkiem niewinnie. Na początku jest jeden bug, jeden plik i jedna hipoteza. Potem dochodzą logi i wynik testów. Pojawiają się dwa nieudane podejścia, zmiana założenia, cofnięcie jednej poprawki i jeszcze jeden plik dorzucony po drodze. Po godzinie niby dalej pracujesz nad tym samym zadaniem, ale w kontekście leży już wszystko.
W rezultacie zaczynają się dziwne odpowiedzi. Agent miesza stare ustalenia z nowymi, wraca do hipotezy, którą już odrzuciłeś, albo proponuje zmianę pasującą do poprzedniej wersji problemu. Łatwo wtedy powiedzieć, że model zgłupiał. Czasem pewnie tak. Bardzo często to my zrobiliśmy mu rozmowę, w której aktualne informacje są wymieszane ze śmieciami sprzed godziny.
Higiena kontekstu brzmi nudno, ale robi sporą różnicę. Kompresja kontekstu pomaga, kiedy nadal pracujesz nad tym samym zadaniem i rozmowa urosła do rozmiaru, w którym zaczyna przeszkadzać. Czyszczenie sesji ma sens po domknięciu tematu i przejściu do czegoś nowego. Warto też mieć szybki sposób na sprawdzenie, ile starego bagażu ciągnie się za rozmową, zanim zacznie wpływać na jakość odpowiedzi.
Dużo problemów z agentem zaczyna się od próby robienia całego dnia pracy w jednej sesji. Stary kontekst czasem pomaga i czasem zaczyna mieszać.
Dobrą praktyką jest traktowanie każdego zamkniętego zadania jako naturalnego momentu na reset. Skończyłeś bug fix, wrzuciłeś commit, temat zamknięty. Następne zadanie zasługuje na czystą sesję, w której agent nie ciągnie za sobą hipotez z poprzedniego problemu. W praktyce to oznacza kilka sekund więcej na start nowej rozmowy, ale za to dużo mniej czasu straconego na naprawianie odpowiedzi, które wynikały z pomieszanego kontekstu.
Prywatne prompty to stracona szansa dla zespołu
Przy review zmian, opisie PR-a, planie testów i sprawdzaniu ryzyka refaktoru łatwo złapać się na tym, że po raz trzeci piszesz agentowi prawie tę samą instrukcję. Niby drobiazg, bo wpisanie promptu zajmuje chwilę. Po którymś razie zaczyna być jednak widać, że to powtarzalny fragment pracy.
Wtedy dużo sensowniej wrzucić to do repo jako własną komendę albo skill. Oszczędność minuty pisania ma drugorzędne znaczenie. Ważniejsze jest to, że z prywatnego rytuału jednej osoby robi się coś, czego może używać cały zespół. Jeśli review zawsze sprawdza brakujące testy, edge case'y, security, zmiany poza zakresem i ryzyka, zespół nie musi liczyć na to, że każdy developer wpisze podobnie dobry prompt.
To bardzo niedoceniany kierunek. Większość rozmów o AI w firmach kręci się wokół modeli i narzędzi, a dużo większy temat jest bardziej przyziemny. Każdy używa tego inaczej. Jeden developer robi review, drugi generuje testy, trzeci pozwala agentowi refaktorować pół modułu, czwarty klika accept, bo wygląda dobrze. Niby wszyscy korzystają z tego samego narzędzia, ale proces jest rozsypany na prywatne nawyki.
Własna komenda może być nudna. Nawet powinna. Ma robić tę samą rzecz w podobny sposób za każdym razem. W firmowym użyciu AI przewidywalność często daje więcej niż efekt wow. Dokumentacja Claude Code opisuje to jako custom commands — pliki markdown w katalogu .claude/commands/, które każdy w zespole może odpalić jedną komendą.
Bez zasad firma ma zbiór prywatnych nawyków zamiast wdrożenia AI
W firmie brzmi to zwykle bardzo normalnie. Dajmy ludziom dostęp i niech testują. Przez pierwsze dni wszystko wygląda świetnie. Ktoś szybciej dowiózł feature, ktoś wygenerował testy, ktoś pokazał screen z terminala i ktoś wrzucił na Slacka, że to serio działa. I pewnie faktycznie działa.
Schody zaczynają się później, kiedy okazuje się, że każdy używa tego inaczej. Jeden developer pozwala AI instalować paczki, drugi nie. Jedna osoba wrzuca logi produkcyjne, druga boi się wkleić fragment kodu. Jedna robi diff po każdej zmianie, druga ufa podsumowaniu. Jedna ma własny prompt do review, druga prosi po prostu o sprawdzenie kodu. Na poziomie firmy wygląda to jak wdrożenie AI, ale w praktyce jest zbiorem prywatnych nawyków.
Agent z dostępem do repo wymaga zasad. Trzeba ustalić, co może robić sam i przy czym ma pytać. Trzeba też wiedzieć, czego nie wolno mu dotykać, jak sprawdzamy jego zmiany, co zapisujemy w pamięci projektu i czego nigdy nie pokazujemy modelowi.
AI może przyspieszyć pracę i bałagan jednocześnie. W skali jednego developera to łatwo ogarnąć. W skali zespołu brak zasad zaczyna generować problemy, które wychodzą dopiero przy review, przy aktualizacji zależności albo przy onboardingu kolejnej osoby. Dotyczy to zresztą nie tylko kodu — podobny schemat widzimy przy wdrożeniach KSeF, gdzie ręczna praca nie znika mimo nowego narzędzia.
Firmy, które przeszły przez ten etap, zwykle kończą z kilkoma prostymi ustaleniami. Lista rzeczy, które agent może robić sam. Lista rzeczy, przy których musi zapytać. Uzgodniony sposób sprawdzania zmian. Jedno miejsce, w którym leżą instrukcje dla agenta, zamiast rozrzuconych notatek na Slacku i w prywatnych plikach. To nie jest wielki governance ani polityka AI na pięćdziesiąt stron. To kilka ustaleń, które sprawiają, że praca z agentem jest powtarzalna między ludźmi w zespole. Więcej o tym, jak wdrożenie agenta AI w firmie potrafi wyglądać w praktyce, pisaliśmy w artykule AI agent nie naprawi chaosu w procesie.
Kiedy agent jest wart swojego kosztu
Przy agencie AI łatwo wpaść w zachwyt, który pojawia się przy każdym nowym narzędziu. Ktoś pokazuje, że agent sam przeanalizował projekt, zmienił pliki, odpalił testy i przygotował opis PR-a. Wygląda to efektownie, szczególnie na krótkim filmie albo screenie z terminala.
Pod spodem jest masa kontekstu, wywołań narzędzi, iteracji i sprawdzania plików. Czasem dochodzą też nieudane podejścia i tokeny, które lecą szybciej niż się wydaje. To naturalny koszt pracy agentów. Schody zaczynają się wtedy, kiedy ktoś patrzy wyłącznie na efekt końcowy i pomija koszt dojścia do tego efektu.
W prostych zadaniach agent może być przesadą. Czasem szybciej będzie użyć grep, sed, prostego skryptu albo zwykłego czatu. W większych zadaniach agent ma sens, ale wtedy tym bardziej trzeba pilnować zakresu i kontekstu. Szczególnie gdy dostał zbyt ogólne polecenie i zaczyna mielić pół repo.
Najbardziej praktyczne pytanie brzmi, czy to najlepszy sposób, żeby to zrobić. Ile kontekstu musi przetworzyć i ile review zostawi po sobie osobie, która później musi to zaakceptować. Często odpowiedź dalej będzie pozytywna. Warto jednak znać koszt, zanim zachwycimy się samym efektem.
Jest też druga strona tego równania. Agent potrafi zrobić w kilka minut coś, co developerowi zajęłoby pół dnia. Przejrzeć dwadzieścia plików, znaleźć wzorzec, zaproponować zmianę i wygenerować testy. Przy dobrze zdefiniowanym zadaniu i jasnym kontekście ta oszczędność jest realna. Problem pojawia się wtedy, gdy oszczędność czasu na kodowaniu zamienia się w dodatkowy czas na review, bo agent dotknął zbyt wielu rzeczy albo podjął decyzje, których nikt nie oczekiwał. Balans między tymi dwoma kosztami zależy od tego, jak precyzyjnie agent dostaje zadania i ile kontekstu ma na starcie. Podobne wyzwania pojawiają się przy automatyzacji sprzedaży B2B — tam też precyzja wdrożenia decyduje o tym, czy narzędzie realnie pomaga, czy tylko generuje dodatkową pracę.
Najważniejsze wnioski
- Diff jest ważniejszy niż podsumowanie — zawsze sprawdzaj, co agent faktycznie zmienił
- Onboarding agenta wymaga kilku konkretnych informacji, a nie dokumentu na sto stron
- Precyzyjne zadania dają lepsze diffy niż ogólne polecenia w stylu „posprzątaj"
- Agent nie powinien sam instalować zależności ani ruszać konfiguracji
- Długa sesja z AI w kodzie kończy się pomieszanym kontekstem — resetuj po każdym zamkniętym zadaniu
- Prywatne prompty warto przenieść do repo jako komendy dla całego zespołu
- Firma potrzebuje kilku prostych zasad, bo bez nich ma zbiór indywidualnych nawyków zamiast procesu
Podsumowanie
Agenci AI w kodzie realnie przyspieszają pracę. Jednak po kilku tygodniach codziennego używania wychodzi, że samo przyspieszenie to dopiero połowa tematu. Druga połowa to nawyki, zasady i kontekst, w którym agent pracuje.
Każda z opisanych obserwacji brzmi trochę nudno. I każda z nich wychodzi dopiero po kilku tygodniach realnej pracy z agentem. Wcześniej łatwiej skupić się na tym, co agent potrafi zrobić. Później zaczyna się liczyć to, jak z nim pracujemy na co dzień.
Jeśli szukasz praktycznych przykładów automatyzacji procesów w firmie, zajrzyj do artykułu o automatyzacji leadów B2B albo sprawdź, kiedy automatyzacja po KSeF naprawdę ma sens. Więcej znajdziesz w naszej bazie wiedzy.
