Coraz więcej badań ostrzega: sztuczna inteligencja przyspiesza pisanie kodu, ale niekoniecznie go poprawia. A rachunek za to może nadejść później, kiedy legacy code wygenerowany przez modele zacznie żyć własnym życiem w produkcji.
Kluczowe fakty:
- W lipcu 2025 roku laboratorium METR opublikowało wyniki badania, według których narzędzia do kodowania z AI sprawiały, że doświadczeni deweloperzy pracowali o 19% wolniej, mimo że sami byli przekonani o 20% wzroście swojej szybkości.
- W lutym 2026 roku, przy próbie powtórzenia badania, rosnący odsetek deweloperów odmówił wykonywania zadań bez wsparcia AI – nawet w zamian za wynagrodzenie 50 dolarów za godzinę.
- W ankiecie z maja 2026 roku pracownicy techniczni deklarowali, że AI czyni ich 1,4 do 2 razy bardziej wartościowymi dla organizacji, jednak sami badacze z METR – prowadzący kontrolowane eksperymenty – raportowali wśród wszystkich grup najniższe zyski produktywności.
Odmowa pracy bez AI
Kiedy w lutym 2026 roku laboratorium badawcze METR próbowało powtórzyć swoje głośne badanie z 2025 roku dotyczące produktywności programistów, natknęło się na nieoczekiwany problem. Rosnący odsetek deweloperów zadeklarował, że nie chce wykonywać nawet połowy swoich zadań bez AI, mimo że METR oferował za udział w badaniu 50 dolarów za godzinę pracy nad zadaniami przez nich samych wybranymi.
To nie była demonstracja lenistwa. To coś poważniejszego: uzależnienie od narzędzia, które jeszcze rok wcześniej było przez tych samych badaczy kwestionowane jako potencjalnie… spowalniające pracę.
W lipcu 2025 roku METR opublikował zaskakujące wyniki: narzędzia do kodowania z AI sprawiały, że doświadczeni deweloperzy pracowali o 19% wolniej, mimo że ci sami deweloperzy byli przekonani, że są o 20% szybsi. Paradoks, który sam w sobie mówi wiele o tym, jak nierzetelna jest nasza własna ocena własnej produktywności.
Prawie co drugi pracownik w Polsce używa AI za plecami swojego szefa. 71% polskich pracowników oszczędza dzięki AI od pół godziny do ponad dwóch godzin dziennie …
Subiektywne poczucie vs. twarde dane
Jednak zamiast powtórzyć eksperyment z nową grupą kontrolną, METR zdecydował się w maju 2026 roku na opublikowanie ankiety, w której pracownicy techniczni sami raportowali swoje zyski produktywności dzięki AI. Wyniki były przewidywalne: deweloperzy twierdzili, że są 1,4 do 2 razy bardziej wartościowi dla swoich organizacji.
Problem w tym, że samoocena to kiepski miernik. Sami badacze z METR, którzy od lat prowadzą kontrolowane eksperymenty dotyczące rzeczywistego wpływu AI, raportowali wśród wszystkich grup najniższe zyski produktywności. Ten paradoks jest warty refleksji.
Komentarz Redaktora Naczelnego AIPORT.pl
Piotr Wolniewicz, Redaktor Naczelny AIPORT.pl
To badanie stawia fundamentalne pytanie, które branża wciąż omija: czy mierzymy to, co chcemy mierzyć, czy to, co jest wygodne do zmierzenia? Z jednej strony trudno odmawiać programistom prawa do korzystania z narzędzi, które subiektywnie podnoszą komfort i tempo pracy. Z drugiej strony niepokoi mnie coś innego: kiedy narzędzie staje się tak niezbędne, że profesjonalista odmawia wykonania swojej pracy bez niego nawet w warunkach eksperymentu, to już nie jest asystent. To jest proteza. I mam poważną wątpliwość, czy branża tech rozumie długoterminowe konsekwencje tej zmiany, szczególnie jeśli chodzi o utrzymanie systemów, które dziś generujemy w zawrotnym tempie. Warto też zapytać: czy kolejne pokolenie programistów w ogóle będzie umiało debugować kod, którego nie napisało i nie rozumie?
Tokenmaxxing: trend, który właśnie się kończy
Równolegle do debaty o produktywności rozwijał się inny fenomen roku 2026: tokenmaxxing, czyli mierzenie efektywności pracownika przez pryzmat liczby tokenów, które zużywa w narzędziach AI. Logika była prosta: więcej tokenów równa się więcej pracy z AI, a więcej pracy z AI równa się wyższa produktywność. Problem w tym, że ta logika okazała się błędna.
Amazon zamknął wewnętrzny ranking KiroRank, który śledził zużycie tokenów przez pracowników, po tym jak część z nich zaczęła wykonywać zadania nierozwiązujące żadnych problemów tylko po to, żeby wspiąć się wyżej w rankingu. „Proszę, nie używajcie AI tylko dla samego używania AI” – powiedział pracownikom Dave Treadwell, wiceprezes wyższy Amazon.
Meta wcześniej, bo w kwietniu, zamknęła podobny ranking o nazwie „Claudeonomics”. Z kolei Uber według własnych deklaracji zużył już cały roczny budżet tokenów w pierwszych czterech miesiącach 2026 roku.
Sytuacja jest kuriozalna: firmy wprowadzają mechanizmy grywalizacji, żeby zmotywować pracowników do korzystania z AI, a pracownicy gamifikują te mechanizmy tak, żeby wyglądać na produktywnych, nie będąc nimi.
Cena szybkości: dług techniczny na sterydach
Badania akademickie potwierdzają to, o czym praktycy mówią półgębkiem. Naukowcy z Singapurskiego Uniwersytetu Zarządzania opublikowali w kwietniu ostrzeżenie, że kod generowany przez AI może wprowadzać długoterminowe koszty utrzymania do rzeczywistych projektów programistycznych.
Dane z rynku są zbieżne:
- Entelligence AI przeanalizowała dane z 2444 firm i ustaliła, że na każdego dolara wydanego na tokeny tylko 18 centów trafia do produktu. Pozostałe 44 centy pochłania naprawianie błędów wprowadzonych przez AI, 27 centów przepisywanie kodu, który minął się z kontekstem, a 11 centów to strata na przeglądach kodu i przełączaniu kontekstu.
- CodeRabbit po przeanalizowaniu open source’owych pull requestów stwierdził, że kod generowany przez AI powoduje 1,7 razy więcej problemów niż kod ludzki.
Programista i autor James Shore podsumował ten problem lapidarnie: „You write code twice as quick now? Better hope you’ve halved your maintenance costs. Otherwise, you’re screwed. You’re trading a temporary speed boost for permanent indenture.” / „Piszesz kod dwa razy szybciej? Lepiej miej nadzieję, że twoje koszty utrzymania też są o połowę niższe. Inaczej jesteś w tarapatach. Zamieniasz chwilowe przyspieszenie na permanentne zniewolenie.”
Kto powinien pilnować kodu generowanego przez AI?
Scott Wu, prezes Cognition AI i twórca agenta kodującego Devin, przekonuje, że odpowiedzią na problemy z jakością kodu AI są… kolejne agenty AI, które będą ten kod naprawiać. Sam przyznaje jednak, że Devin plasuje się gdzieś pomiędzy poziomem juniora a mid-level dewelopera w zależności od zadania. To nie jest poziom, przy którym można zrezygnować z nadzoru człowieka.
Naukowcy z METR wskazują, że jakość finalnej pracy różniła się między warunkami „AI dozwolona” i „AI niedozwolona”, na przykład pod względem subiektywnej jakości kodu czy ilości dokumentacji i testów. Innymi słowy: AI nie tylko generuje kod, ale zmienia też to, co deweloper w ogóle uważa za „gotowe”.
Badacze z Singapuru sugerują bardziej pragmatyczne podejście: programiści powinni tak dobrze rozumieć, w jakich zadaniach AI radzi sobie dobrze, a w jakich słabo, jak rozumieją języki programowania. Potrzebne są silne systemy zapewnienia jakości zaprojektowane z myślą o AI. I niezmiennie potrzebny jest człowiek, który traktuje output AI jak pracę juniora: weryfikuje, poprawia, bierze odpowiedzialność.
Architektura oprogramowania, projektowanie bezpieczeństwa, decyzje systemowe: to wciąż musi należeć do człowieka. Przynajmniej na razie.
