Dlaczego gotowe rozwiązanie AI frustruje zespoły — i co można z tym zrobić

W przypadku większości technologii, im dłużej je używasz, tym bardziej spokojnie na nie polegasz. W przypadku narzędzi AI jest odwrotnie: w swoim rocznym badaniu ponad 49 000 developerów, Stack Overflow odnotował wzrost wykorzystania do 84%, podczas gdy zaufanie do dokładności tych narzędzi spadło z 40% do 29% w ciągu zaledwie jednego roku.

To zjawisko jest mi dobrze znane. Nasze pierwsze doświadczenia z narzędziami AI w rozwoju miały niewiele wspólnego z efektem wow, który polega na szybszej pracy i mniejszym nakładzie pracy, o którym pisała prasa techniczna. Nasi deweloperzy byli zawiedzeni: AI generowało przeciętne kodowanie, które zajmowało dużo czasu na przegląd i ostatecznie musiało być przepisane. Zespół oczekiwał, że AI zaoszczędzi czas, a zamiast tego dostał dodatkową pracę. Więc nieco po tych pierwszych próbach włączenia narzędzi AI do codziennego workflow, zespół wrócił do pracy w sposób, w jaki zawsze pracował.

Dziś te same narzędzia przyspieszają zarówno pisanie kodu, jak i jego przegląd dla naszych deweloperów — nie dlatego, że znaleźliśmy lepszy model, ale dlatego, że zmieniliśmy sposób pracy z nim. Oto, co nas tam doprowadziło.

Dlaczego kod napisany przez AI frustruje deweloperów

AI opiera się na ogromnej masie publicznego kodu z całego internetu, a ten kod rzadko jest wzorcowy: jego jakość jest przeciętna, a model odtwarza tę przeciętność.

Ale “przeciętny” nie jest limitem tego, co jest możliwe — jest to po prostu to, co model wytwarza, dopóki nie zna Twojego projektu: jego konwencji, struktury kodu, decyzji architektonicznych. W badaniu ponad 600 developerów, Qodo stwierdziło, że wśród tych, którzy nie są zadowoleni z jakości kodu AI, 44% przypisuje to właśnie brakowi kontekstu. To właśnie utrzymuje wyjście na poziomie przeciętnym.

Dobra wiadomość jest taka, że kontekst, jaki AI otrzymuje, jest właściwie jedyną zmienną, którą zespół kontroluje w pełni. Jak dobrze narzędzie rozumie projekt, zależy nie od modelu, ale od tego, co mu dasz.

Drugim powodem jest mentalny — sama natura pracy się zmienia. Kiedy AI pisze większość kodu, głównym aktem dewelopera nie jest już pisanie, ale sprawdzanie tego, co zostało wygenerowane: czytanie czyjejś rozwiązania, ważenie alternatyw, decydowanie, co jest gotowe do wysłania. To jest inna umiejętność niż pisanie kodu samemu, a dla każdego, kto kochał pisanie, nie przychodzi łatwo.

W swoim raporcie Octoverse z 2025 roku, GitHub opisuje właśnie tę zmianę: deweloperzy, którzy posunęli się najdalej z AI, nie nazywają się już “autorami kodu” i stają się czymś bliższym jego “kreatywnym dyrektorom”, gdzie kluczową umiejętnością jest kierowanie i weryfikacja. Ale droga do tej roli prowadzi przez błędy i frustrację, aż do momentu, w którym osoba zobaczy korzyści w swojej własnej pracy.

Czym AI zmienia się z źródła frustracji w funkcjonalne narzędzie

Kiedy nasz zespół po raz pierwszy zaczął korzystać z AI, niektórzy deweloperzy pracowali z Claude Code, inni próbowali OpenAI Codex, GitHub Copilot lub Gemini CLI, a każde narzędzie dawało różne wyniki. Więc kiedy postanowiliśmy uporządkować sposób, w jaki zespół pracował z AI, pierwszą rzeczą, którą zrobiliśmy, było ustalenie jednego narzędzia.

To nie jest tylko nasza praktyka. Weźmy historię zespołu w Linear: do wczesnego 2026 roku pracowali oni na zasadzie “pozwól każdemu pracować w sposób, który mu odpowiada”, a w styczniu kierownictwo porzuciło ten podejście i przeniosło wszystkich do jednego sposobu pracy — ograniczając wybór do dwóch narzędzi AI i prosząc developerów o pisanie kodu tylko z ich użyciem, zamiast ręcznie. Według firmy, średnia produktywność wzrosła już następnego miesiąca o 30% w połączonych PR i o 33% w zadaniach zamkniętych na inżyniera.

Powiedziano, że samo wspólne narzędzie nie poprawia kodu — musi być ono skonfigurowane: ustawione reguły, coś w rodzaju rules.md, które określają, jak pisać kod — które podejścia stosować, czego unikać. Następnie przychodzą niestandardowe umiejętności dla zadań typowych dla Twojego projektu, abyś nie musiał wyjaśniać tego samego co kilka razy. I wreszcie, warto wskazać agentowi na istniejącą bazę kodu: analizuje, jak projekt jest napisany i wytwarza nowy kod w tym samym stylu, a nie w stylu ogólnym. Im więcej kontekstu otrzymuje narzędzie, tym mniej musisz pisać ręcznie później.

Ale najtrudniejszą częścią nie jest technika. Przejście od autora kodu do jego ewaluatora nie następuje samoistnie — ten przejście potrzebuje pomocy. Najbardziej bezpośrednia droga to szkolenia i certyfikacja. W naszym przypadku, na przykład, dziesięciu developerów przechodzi przez program partnerski z dostawcą narzędzia, podczas gdy obok nich pracuje osoba odpowiedzialna za wdrożenie, która wyjaśnia, dlaczego narzędzie wyprodukowało dany wynik i jak go naprawić.

Kiedy zespół pracuje w sposób skoordynowany, pozostaje jeden wąskie gardło — przegląd — i warto go wzmocnić za pomocą AI. Agent przechodzi przez każdy pull request jako pierwszy i zajmuje się oczywistymi: rutynowymi błędami, stylem, powtórzeniami, lukami w zabezpieczeniach. Człowiek-przeglądający nie musi już patrzeć na wszystko bez rozróżnienia, tylko na architekturę i kluczowe decyzje. Efekt jest zauważalny nawet w firmach, które budują te narzędzia: w Anthropic, po wprowadzeniu takiego agenta, udział pull requestów, które otrzymały istotną recenzję wzrósł z 16% do 54%, a inżynierowie nie zgadzali się z mniej niż 1% jego komentarzy.

Dla nas to skróciło cykl przeglądu, który wcześniej rozciągał się na dwa lub trzy dni przez kilka rund, i zdjęło rutynę z naszych starszych inżynierów, pozostawiając im tylko naprawdę trudne miejsca. Kiedy narzędzie wreszcie zaczęło produkować wyniki, które nie wymagały przeróbek, pojawiło się zaufanie do niego.

Gdzie zaufanie do narzędzi AI się opłaca

Przede wszystkim — w pisaniu kodu: kiedy narzędzie zna projekt i agent zajmuje się pierwszym przeglądem, zespół pisze więcej i lepiej w tym samym czasie. W naszym przypadku narzędzia AI przyspieszyły pracę o około 30-40%.

Ponadto AI ułatwiło wdrożenie nowych osób. Kiedy nowa osoba dołącza do projektu, ktoś doświadczony zwykle musi odpowiedzieć na dziesiątki pytań o to, jak kod projektu jest zbudowany. Teraz agent zajmuje się tą rolą: jeśli projekt jest dobrze udokumentowany, nowy pracownik kieruje do 95% tych pytań do niego, zamiast do kolegów.

To samo dotyczy dokumentacji: szkic architektoniczny, który wcześniej zajmował godziny, jest teraz w większości pisany przez samego agenta — nasze szacunki mówią, że około 80% szkicu, jeśli da się mu wystarczająco dużo kontekstu. To, co pozostaje dla człowieka, to to, czego nie ma w repozytorium — decyzje, kompromisy, ekspertyza.

Tak samo ważne jest, aby być szczerym co do ograniczeń tego, co AI może zrobić, ponieważ to właśnie nadmiar oczekiwań powoduje rozczarowanie na początku. AI nie zajmuje się zgodnością — człowiek potwierdza dane medyczne lub finansowe, a firma, a nie model, ponosi odpowiedzialność za wyciek. Nie przyspiesza integracji z partnerami, gdzie dziesiątki godzin idą na rozmowy i koordynację.

Gotowe rozwiązanie AI jest naprawdę irytujące — ale tylko wtedy, gdy jest używane jako gotowe rozwiązanie. Cała różnica między frustracją a korzyścią leży w tym, co budujesz wokół niego: wspólny standard, kontekst Twojego projektu i nowa rola dewelopera.