Bernard van der Esch

🤖 Sztuczna inteligencja w kodzie: iluzja produktywności i automation bias

Od generatywnej sztucznej inteligencji oczekiwano skokowego przyspieszenia pracy zespołów inżynierskich. Narzędzia oparte na dużych modelach językowych (LLM) faktycznie skracają czas pisania pojedynczych funkcji o 25–55%, ale równocześnie wydłużają czas potrzebny na weryfikację tego kodu.

To Productivity-Validation Gap: asymetria między szybkim generowaniem tekstu programu a ograniczoną przepustowością naszych umysłów podczas audytu.

Odpowiada za nią automation bias, czyli psychologiczna tendencja do bezkrytycznego ufania sugestiom automatycznych systemów (Zhou et al., 2026). Dalej opisuję, co pokazują badania nad tym zjawiskiem i jak zabezpieczyć przed nim zespół.

📌 Część 1. Trzy pułapki pracy z AI

1. Iluzja prędkości i spadek jakości

W eksperymencie kontrolowanym METR (Becker et al., 2025) programiści rozwiązujący złożone zadania z agentami AI pracowali o 19% wolniej niż grupa bez wsparcia AI. Przed badaniem zakładali przyspieszenie o 24%, a po teście wciąż byli przekonani, że zaoszczędzili czas.

Wygenerowany kod niesie przy tym mierzalne ryzyko:

  • Luki bezpieczeństwa: w badaniach nad GitHub Copilot (Pearce et al.) 39,3–40% wygenerowanych fragmentów w scenariuszach wysokiego ryzyka zawierało krytyczne podatności, m.in. SQL Injection i Buffer Overflow.
  • Fałszywa pewność: programiści używający AI piszą mniej bezpieczny kod, a jednocześnie wyżej oceniają jego poprawność niż osoby pracujące tradycyjnie (Perry et al.).
  • Erozja bazy kodu: w analizie 153–211 mln linii kodu GitClear wskaźnik krótkoterminowego wyrzucania i przepisywania kodu (code churn poniżej 14 dni) wzrósł z 3,3% do 7,1%, udział refaktoryzacji spadł z 25% do 13,4%, a udział kodu kopiowanego wzrósł z 8,3% do 12,3%.
  • Błędy logiczne: w generowanym kodzie pojawiają się średnio o 75% częściej niż w kodzie pisanym ręcznie.

2. Jak AI usypia czujność

  • Błąd elokwencji (eloquence bias): gdy AI dołącza do kodu płynne, profesjonalne wyjaśnienie w języku naturalnym, czujność spada. Obecność takich objaśnień nie zmniejsza ślepego zaufania, lecz zwiększa bezkrytyczną akceptację błędnych sugestii.
  • Służalczość modelu (sycophancy): modele mają wbudowaną tendencję do przytakiwania użytkownikowi (SycEval, Fanous et al., 2025). W badaniach Fahad et al. (2026), gdy programista sugerował w pytaniu błędną tezę, model porzucał poprawną analizę i potwierdzał wersję człowieka w 72% przypadków (Decision Flip Rate).
  • Podwójne potwierdzenie: kod i testy wygenerowane w tej samej sesji zapisują ten sam błąd dwa razy: w implementacji i w asercjach. Testy przechodzą w potoku CI/CD i dają wysokie pokrycie kodu przy fałszywym poczuciu bezpieczeństwa. (Tu zachęcam do zapoznania się z moim poprzednim artykułem, który rzuca nam światło na to, jak to poprawić).

3. Dług zrozumienia i atrofia juniorów

Korzystanie z AI obniża wysiłek poznawczy, ale pozbawia nas głębokiego przetwarzania informacji. Badania neurokognitywne (EEG) wykazały spadek konektywności neuronalnej o 55% podczas zadań pisania kodu z AI, a 83% badanych nie potrafiło zacytować ani wyjaśnić kodu, który zaakceptowali kilkanaście minut wcześniej. Tak powstaje dług zrozumienia (comprehension debt): w repozytorium ląduje kod, którego nikt w zespole nie rozumie.

Najbardziej podatni na automation bias są juniorzy. Akceptują sugestie AI o 20% częściej niż seniorzy, a ucząc się w asyście AI, przyswajają wiedzę koncepcyjną i zdolności diagnostyczne o 40–50% wolniej.

🛠️ Część 2. Pięć zasad dla zespołu

Pasywne ostrzeżenia typu „pamiętaj o weryfikacji kodu z AI” nie działają. Potrzebne są interwencje wbudowane w proces.

1. Poznawcze funkcje wymuszające (Cognitive Forcing Functions)

Zamiast natychmiastowego wyświetlania podpowiedzi skonfiguruj IDE tak, aby wymagało od inżyniera wstępnego zobowiązania: programista najpierw sam wpisuje oczekiwany typ zwracany, przypadek brzegowy albo nazwę testu, a dopiero potem widzi propozycję AI. Mózg musi wtedy zbudować własny model logiczny przed zapoznaniem się z sugerowanym kodem.

2. Rozdzielenie generowania kodu i testów

To odpowiedź na błąd podwójnego potwierdzenia. Nigdy nie generuj kodu produkcyjnego i testów jednostkowych w tej samej sesji z AI. Odwróć przepływ: na podstawie wymagań biznesowych najpierw powstają i są weryfikowane testy, a dopiero po ich zatwierdzeniu AI pisze kod, który je spełnia.

3. Zasada unaided-first dla juniorów

Nowo zatrudnieni i początkujący programiści pracują przez pierwsze 3–6 miesięcy bez asystentów autouzupełniania kodu. Budują w tym czasie własne modele mentalne i nawyk krytycznego czytania kodu, bez których bezpieczna współpraca z AI nie jest możliwa.

4. Ukryty opis PR na starcie code review

Ten sam błąd elokwencji da się zaadresować na poziomie procesu. Podczas pierwszej fazy inspekcji w GitHubie czy GitLabie automatycznie zwijaj wygenerowane przez AI podsumowania Pull Requestów. Recenzent ocenia wtedy najpierw czysty kod i wyniki testów, więc nie ulega iluzji poprawności wywołanej płynnym opisem.

5. Code Turnover Rate zamiast samej prędkości

Zmień wskaźniki sukcesu. Zamiast liczby zamkniętych zadań mierz odsetek linii usuwanych lub przepisywanych w czasie krótszym niż 14–30 dni od wdrożenia. Wzrost tego wskaźnika jest sygnałem, że w zespole narasta dług weryfikacyjny.

💬 Co z tego wynika dla zespołu

Sztuczna inteligencja przyspiesza pisanie składni. Bez procedur opisanych wyżej inżynieria oprogramowania zmienia się w powierzchowne zatwierdzanie cudzych propozycji.

Źródła

Dyskusja na LinkedIn