# Dług techniczny AI: to nie ten problem, jaki myślisz

URL: https://codebasechat.com/pl/journal/dlug-techniczny-ai
Type: blog
Locale: pl
Published: 2026-07-14
Updated: 2026-07-14

---

> Dług techniczny AI: dwa problemy (dług kodu i poznawczy), dwie rozwiązania. 88% programistów zgłasza wpływ, ale mierzymy tylko kod. Jak zarządzać tym długiem i dlaczego juniorzy płacą go pierwszymi.

Dług techniczny AI to nie bałagan, który myślisz sobie wyobrażać. To nie zduplikowane funkcje i niespójne nazwy, które linter może oznaczyć. Połowa tego kodu wygląda idealnie w pull requeście, przechodzi review, trafia na produkcję: a dopiero sześć tygodni później okazuje się, że nikt z zespołu nie potrafi wyjaśnić, dlaczego zmiana w jednym miejscu złamała trzy rzeczy, których nikt się nie spodziewał. Ta druga połowa to właśnie ta część, którą większość zespołów w ogóle nie mierzy.

## Dług techniczny AI to dwa różne problemy, nie jeden

Zapytaj pięciu engineering managerów o definicję długu technicznego związanego ze sztuczną inteligencją, a dostaniesz pięć różnych odpowiedzi: ale wszystkie będą się skupiać wokół dwóch zupełnie różnych kategorii.

Pierwsza to dług kodu: duplikacja, niespójne wzorce, kod technicznie poprawny, ale zajmujący powierzchnię, o którą nikt nie prosił. To właśnie dla tej kategorii powstały narzędzia static analysis.

Druga to dług poznawczy: różnica między tempem, w jakim kod jest generowany, a tempem, w jakim zespół buduje wspólny model myślowy tego, co robi. Ankieta Sonara z 2026 roku pokazała, że 88% programistów zgłasza co najmniej jeden negatywny wpływ sztucznej inteligencji na dług techniczny, a 53% twierdzi, że AI generuje kod, który wygląda poprawnie, ale ukrywa błędy. To dług kodu. To, czego badanie nie w pełni ujmuje, to druga kategoria: a najlepsze omówienie tego pojęcia znajdziemy w [artykułach LeadDev](https://leaddev.com/ai/ai-coding-creates-two-kinds-of-debt-youre-only-measuring-one).

Trzy zespoły na pięć mylą te dwie kategorie. Oto co robią pozostałe dwa: mierzą dług kodu za pomocą narzędzi, a dług poznawczy za pomocą rozmów.

## Część długu kodu: kod, który wygląda poprawnie, a nim nie jest

Dług kodu to rodzaj, który znamy z doświadczenia. Kod generowany przez AI ma tendencję do duplikacji logiki, która już istnieje trzy pliki dalej, ponieważ asystent nie wie, że ta logika istnieje, chyba że znajduje się w kontekście. Ankieta Sonara podaje konkretną liczbę: 40% programistów twierdzi, że AI zwiększyła dług przez generowanie niepotrzebnego lub zduplikowanego kodu.

Niebezpieczny wariant to nie kod, który wygląda źle. To kod, który wygląda dobrze. Funkcja przechodzi testy, obsługuje happy path czysto i wygląda jak coś, co napisałby senior engineer: z wyjątkiem tego, że po cichu pomija edge case'a, który oryginalna implementacja obsługiwała. Review wyłapie literówki. Review jest znacznie gorzej w wyłapywaniu wiarygodnie wyglądającej funkcji, która jest po prostu niekompletna.

`// Wygenerowany przez AI: przechodzi testy, wygląda czysto
function getActiveUsers(users) {
  return users.filter(u => u.status === "active");
}

// To, co obsługiwała oryginalna wersja, trzy pliki dalej:
function getActiveUsers(users) {
  return users.filter(u => u.status === "active" && !u.deletedAt);
}`Nic tutaj nie wyrzuca błędu. Nic nie zawala CI. Przepaść ujawnia się dopiero, gdy miękko usunięty użytkownik pojawi się w raporcie trzy tygodnie później, a osoba, która weźmie stronę na siebie, musi grep'ować, szukać w historii i pytać wokół, aby znaleźć, która wersja jest prawidłowa i dlaczego. Ta pętla grep-i-pytania to rzeczywisty koszt, i można go zmierzyć w godzinach, a nie w niejasnym poczuciu, że coś się nie zgadza.

Narzędzia docs-as-code, które siedzą obok repo zamiast w osobnym wiki, zmniejszają częstość tej pętli, ponieważ rozumowanie stojące za funkcją znajduje się jeden klik od samej funkcji, zamiast bytować tylko w czyjeś pamięci.

![Zbliżenie rąk na klawiaturze z czerwono-zielonym diffem kodu widocznym na rozmytym ekranie w tle](https://fdzlnqpwsaniezitwiuw.supabase.co/storage/v1/object/public/cms-media/codebasechat/2026-07/eaeaef-inline1.webp)

## Część długu poznawczego: gdy zespół straci wątek

Dr Margaret-Anne Storey, profesor informatyki na Uniwersytecie Wiktorii, wymyśliła pojęcie "długu poznawczego" w październiku 2025 r., patrząc jak jej studenci wysyłają szybko do produkcji za pomocą AI, a potem zmagają się z działaniem na podstawie własnych opinii użytkowników. Jej diagnoza: studenci nie stracili wątek kodu, stracili wątek tego, co budowali i dlaczego, a także tego, kto w zespole co wie.

Ten punkt widzenia zapożycza się ze starego argumentu Petera Naura, że oprogramowanie to nie naprawdę kod, to wspólna teoria w głowach ludzi, którzy go budowali. Kiedy kod jest generowany szybciej niż zespół może zbudować tę teorię, teoria nigdy się nie formuje. Możliwe jest posiadanie czystego, w pełni testowanego codebase i wciąż mieć znaczący dług poznawczy, jeśli ludzie, którzy go wysłali, nie potrafią tego w pełni wyjaśnić, lub jeśli umie to zrobić tylko jedna osoba.

To właśnie ta część, którą standardowe metryki długu technicznego AI całkowicie pomijają, ponieważ dashboardy śledzą kod, nie zrozumienie. Pytanie warte zadania na następnej retro to banalnie: wyświetl diagram architektury i zapytaj, kto w zespole potrafi wyjaśnić każde pole. Jeśli odpowiedź brzmi "jedna osoba, a jest na urlopie w tym tygodniu", to masz dług poznawczy niezależnie od tego, co mówi Twój linter.

Żywa wewnętrzna wiki nie rozwiąze długu poznawczego sama przez się. Daje zespołowi miejsce do zapisania "dlaczego" zanim będzie to żyć tylko w głowie jednej osoby, co jest początkiem.

![Trzej inżynierowie stojący przy tablicy, szkicując razem diagram architektury systemu](https://fdzlnqpwsaniezitwiuw.supabase.co/storage/v1/object/public/cms-media/codebasechat/2026-07/e90110-inline2.webp)

## Dlaczego code review nie nadąża za tempem generowania

Oto mechaniczny problem leżący u podstaw obu rodzajów długu: AI pozwala jednemu inżynierowi wygenerować tydzień pracy kodu przed obiadem, ale pojemność review w ogóle się nie skaluje. Wąskie gardło przesunęło się z pisania na czytanie, a czytanie to ta część, którą nikt nie przyspieszył.

To właśnie tutaj porównanie narzędzi naprawdę się liczą, i warto być konkretny zamiast mglisty. Copilot i Cursor są szybkie w generowaniu kodu wewnątrz pliku, który już masz otwarty, dlatego właśnie są dobre w produkowaniu więcej kodu niż zespół może zrecenzować. Cody i Continue.dev bardziej opierają się na retrieval'u na całym repo przed generowaniem, co pomaga uniknąć problemu duplikacji wyżej, ale żaden z nich nie zastępuje ludzkiego kroku decydowania, czy nowy kod pasuje do tego, jak system ma działać. Żaden z nich nie mówi Ci, czy osoba merge'ująca PR naprawdę rozumie, co się zmieniło: to inne pytanie niż pytanie czy diff jest składniowo ok.

Narzędzia ask-your-codebase istnieją dokładnie ze względu na tę przepaść: najszybszy sposób dobrze zrecenzować kod generowany przez AI to móc zapytać w zwykłym języku, "gdzie indziej istnieje ten wzorzec" lub "co już obsługuje ten przypadek", zanim zatwierdźsz merge. To pytanie kiedyś zajmowało seniorowi inżynierowi dwadzieścia minut grep'u i blame. Nie powinno.

Jest również efekt rozmiaru repo, wart uwagi. W usłudze 5 000 linii kodu jeden reviewer potrafi trzymać większość systemu w głowie, więc wiarygodnie wyglądająca funkcja wyróżnia się, ponieważ nie pasuje do modelu mentalnego reviewera. W monorepo 80 000 linii obsługiwanym przez sześć zespołów żaden reviewer nie ma już tego modelu mentalnego, więc wiarygodnie wyglądający kod przejdzie po prostu dlatego, że nikt w pokoju nie ma kontekstu aby zauważyć, że jest źle. Im większe repo, tym bardziej wąskie gardło review zależy od narzędzi zamiast od pamięci jednego seniora.

## Juniorzy płacą ten dług pierwszy i najszybciej

Anthropic przeprowadził badanie kontrolowane w januarze 2026 r., randomizowaną próbę z 52 junior developerami, i odkrył, że ci, którzy korzystali z AI assistentów, uzyskali wyniki 17% niższe w testach zrozumienia kodu: mniej więcej dwie oceny niżej. Wewnętrzny zespół inżynieryjny Infobipa, prowadzący program staży od 2022 r. na 225 stagiairach, zobaczył ten sam wzorzec w rzeczywistych danych longitudinalnych: sprzed ery AI kohort wzrosła średnio o 2,50 punkcie w samoocenienie umiejętności technicznych na stażu; kohorty z ery AI wzrosły o 1,56.

Mechanizm to nie samo użycie AI. Dwaj stagiairzy w ostatniej kohorcie Infobipa korzystali z AI z taką samą częstotliwością, z przeciwnymi wynikami. Jeden zadawał pytania uzupełniające i potrafił w pełni wyjaśnić, co AI wyprodukowało; ich wzrost był najwyższy w kohorcie. Drugi zaakceptował output z minimalnym przeglądem, traktował to jako czarną skrzynię i wzrósł o zero. Narzędzie było identyczne. Stosunek do niego nie był.

Nagrywanie sesji parowania i spacerów po architekturze, i tworzenie ich przeszukiwalnym później, daje juniorom coś do czego mogą wrócić zamiast ponownie pytać tę samą osobę, która jest wolna. Nie zastąpi to mentora, ale obniża koszt zadania pytania drugi raz.

![Senior inżynier wskazujący na ekran laptopa, podczas gdy junior inżynier pochyla się, aby śledzić](https://fdzlnqpwsaniezitwiuw.supabase.co/storage/v1/object/public/cms-media/codebasechat/2026-07/ec3aa0-inline3.webp)

## Pomiń "zakaż AI dla juniorów"

Każdy przegląd na ten temat w końcu ląduje na tej samej rekomendacji: ograniczyć dostęp do AI dla junior inżynierów, dopóki nie "zarobią to sobie". Pomiń tę opcję. Nie zgadza się z tym, co znalazły zespoły, które faktycznie zmierzyły problem, i to handluje jeden tryb awarii za inny; juniorzy, którzy nie mogą korzystać z narzędzi, które ich zespół wysyła do produkcji, pozostają w tyle w inny, równie rzeczywisty sposób.

To, co zadziałało dla Infobipa, to sekwencjonowanie, nie zakazywanie: najpierw spróbuj problem samodzielnie, AI jako drugie, aby nawyk niezależnego myślenia się ukształtował zanim AI stanie się domyślnym ruchem. Dodali punkty wolne od AI, nie jako karę, ale jako kalibrację, aby zarówno stagiair jak i mentor wiedział, gdzie umiejętność faktycznie stoi. Mentorzy również przesunęli się z recenzowania pull requestów na śledzenie procesu: kto pytał co, gdzie ktoś się zablokował, kto wyjaśnił swoją zmianę bez pomocy.

Oceny satysfakcji wzrosły przez cały czas, gdy wzrost umiejętności spadał: co to jest prawdziwe ostrzeżenie w ich danych: jeśli śledzisz tylko to, co ludzie czują na temat narzędzi, nie zobaczysz tego nadchodzącego. Dwadzieścia procent stażystów z ostatniej kohorty Infobipa nie wiedziało, czego oczekuje się od juniorskiego inżyniera na ich poziomie na miejscu pracy, co sprawiło, że samoocena była prawie bezużyteczna. Nie możesz zmierzyć przepaści wobec punktu odniesienia, który nikt nie zapisał.

## Co naprawdę zmienialibyśmy w tym sprincie

Zacznij od pytania retro wyżej: kto potrafi wyjaśnić każdą część systemu, na głos, teraz. To jedno pytanie ujawni więcej długu poznawczego w dziesięć minut niż jakikolwiek dashboard.

W przypadku długu kodu, utrzymuj static analysis w pętli. [Ankieta Sonara z 2026 r.](https://www.sonarsource.com/blog/how-ai-is-redefining-technical-debt/) pokazuje, że 70% programistów już go używa, a zespoły, które go uruchamiają, zgłaszają znacznie lepsze wyniki w kosztach rework niż zespoły, które go pomijają. To nie jest kontrowersyjna rekomendacja, to po prostu ta, którą zespoły pomijają, kiedy się spieszyć, ponieważ output AI wyglądał na skończony.

Wysiłek, który AI usuwa z pisania kodu, nie znika. Sonar nazywa to "wielkim przesunięciem wysiłku": pojawia się poniżej, w zarządzaniu długiem i poprawianiem output AI. Zautomatyzowanie powtarzających się części tego triażu, oznaczenie starych PR'ów, routing'owanie żądań review, ściganie follow-upów, zwalnia czas seniora na część, która faktycznie wymaga człowieka: decydowanie, czy zespół rozumie, co właśnie wysłał.

Mierz trajektorię, nie satysfakcję. Zespół, który czuje się dobrze z AI i nie potrafił wyjaśnić własnej architektury za sześć miesięcy, nie oszczędzał czasu. Pożyczył go, przy oprocentowaniu, które nikt nie napisał.

## FAQ

### Czym się różni dług techniczny AI od normalnego długu technicznego?

Normalny dług techniczny to bałagan kodu, który linter może oznaczyć: duplikacja, niespójne wzorce, kod technicznie poprawny ale zbędny. Dług techniczny AI to dodatkowo dług poznawczy — między tempem generowania kodu a tempem w jakim zespół buduje wspólny model myślowy tego, co robi. Większość zespołów mierzy tylko pierwszy.

### Co to jest dług poznawczy i dlaczego go nie mierzymy?

Dług poznawczy to przepaść między szybkością generowania kodu a szybkością w jaką zespół rozumie, co zbudował. Nie mierzymy go, ponieważ dashboardy śledzą kod, nie zrozumienie. Jedno pytanie ujawnia go szybciej: kto w zespole potrafi wyjaśnić każdy element architektury, teraz, na głos?

### Ile procent programistów zgłasza problemy z długiem technicznym AI?

Ankieta Sonara z 2026 roku: 88% programistów zgłasza co najmniej jeden negatywny wpływ AI na dług techniczny. 53% twierdzi że AI generuje kod wyglądający poprawnie ale ukrywający defekty. 40% mówi że AI zwiększyła dług przez duplikację i kod niepotrzebny.

### Czy junior developerzy powinni korzystać ze sztucznej inteligencji?

Nie zakazuj. Badania Infobipa (225 stażystów, 2022-2026) pokazują że juniorzy korzystający z AI bez zaangażowania kognitywnego rosną wolniej (1.56 vs 2.50 punktów umiejętności). Rozwiązanie: sekwencjonowanie — spróbuj problem najpierw, AI jako drugie — i punkty wolne od AI do kalibracji.

### Jak kontrolować kod generowany przez AI w code review?

Jeden reviewer na repo 80K linii nie wyłapie subtelnych błędów w AI-generowanym kodzie. Używaj narzędzi ask-your-codebase aby szybko zapytać 'gdzie indziej ten wzorzec' lub 'co już to obsługuje'. Utrzymuj static analysis w pętli — 70% zespołów już to robi (Sonar 2026).

### Co to znaczy że Anthropic badało juniorów i AI?

Styczeń 2026: randomizowana próba 52 juniorów. Ci używający AI uzyskali wyniki 17% niższe w testach zrozumienia kodu (około dwie oceny niżej). Mechanizm: nie samo użycie AI, ale czy developer zadawał pytania i rozumiał output, czy traktował to jako czarną skrzynię.

### Czy powinienem dodać więcej kodu do static analysis czy inwestować w dokumentację?

Obie rzeczy, ale w tej kolejności: static analysis (tooling) wyłapuje dług kodu (duplikacja, edge case'i). Docs-as-code wiki wyłapuje dług poznawczy (team rozumie razem). Sonar pokazuje 70% teamów używających static analysis — to standard. Żywa wiki to początek zapisu 'dlaczego'.