Dług techniczny AI (dług techniczny kodu generatywnego)

1. Przegląd koncepcji i problem systemowy

Termin „dług techniczny”, wprowadzony przez Warda Cunninghama, początkowo opisywał świadomy kompromis: wypuścić funkcję szybciej dziś, aby uzyskać informację zwrotną z biznesu, a jutro wrócić i przepisać kod w sposób jakościowy.

W erze generatywnego kodowania koncepcja ta uległa mutacji. AI Technical Debt (Dług techniczny AI) to nie świadomy kompromis doświadczonego inżyniera, lecz niekontrolowana akumulacja kodu, którego pełny model mentalny nie jest utrzymywany przez żadną żywą osobę w zespole.

Gdy startup lub zespół enterprise zachwyca się nadzwyczajną początkową prędkością („napisaliśmy backend w weekend!”), zaciąga wysokoprocentowy kredyt:

• Prędkość pierwszych release’ów: 10x.
• Prędkość rozwoju po pół roku: 0.1x.
• Każda próba aktualizacji wersji biblioteki lub dodania nowej reguły biznesowej zamienia się w kaskadę niezrozumiałych awarii w niepowiązanych zakamarkach repozytorium.

Trajektorii prędkości rozwoju:
Prędkość
   ^
   |       /--- Zdrowa kultura inżynieryjna (Stabilna prędkość)
   |      /
   |  /\ /
   | /  X
   |/    \
   |      \___ Niekontrolowany dług techniczny AI (Szybki start -> Paraliż architektoniczny)
   +----------------------------------------------------> Czas (miesiące)

2. Taksonomia architektoniczna i model mentalny

Anatomia generatywnego długu technicznego obejmuje cztery poziomy:

1. Dług poznawczy (Cognitive / Comprehension Debt):
   • Kod działa, ale nikt w zespole nie rozumie wewnętrznej mechaniki algorytmu.
   • Programiści boją się dotykać kodu i przy wystąpieniu błędów po prostu „karmią” plik modelem z promptem „napraw to”, pogłębiając dług jeszcze bardziej.
2. Dług braku pojedynczego źródła prawdy (Single Source of Truth Decay):
   • Model nie pamięta, że walidacja numeru telefonu jest już zaimplementowana w pakiecie @shared/validation, i tworzy własną implementację w module autoryzacji, podczas gdy inny model robi to samo w module zamówień.
   • Reguły biznesowe zaczynają się rozchodzić.
3. Dług słabych lub brakujących inwariantów:
   • Użycie słabych typów (any, unknown, Record<string, any>), ignorowanie warunków wyścigu (Race Conditions) oraz blokad transakcji w bazie danych.
4. Dług nadmiarowych zależności (Dependency Creep):
   • Dodawanie ciężkich bibliotek zewnętrznych dla wykonania elementarnych operacji, które można rozwiązać trzema liniami natywnego kodu bieżącej wersji platformy.

3. Pipeline techniczny i wewnętrzna mechanika

Tabela porównawcza objawów długu technicznego

Architektoniczny pipeline ochrony przed długiem

[Agent proponuje zmiany]
         |
         v
[Krok 1: Analiza AST złożoności cyklomatycznej (ESLint/Biome)]
         |
         v
[Krok 2: Weryfikacja granic architektonicznych (Dependency Cruiser)]
         |
         v
[Krok 3: Sprawdzanie typów tsc --noEmit z flagą noImplicitAny]
         |
         v
[Krok 4: Uruchomienie testów mutacyjnych (Stryker Mutator)]
         |
         v
[Krok 5: Ręczny audyt architektoniczny: czy problem można rozwiązać przez usunięcie kodu?]

4. Praktyczne scenariusze inżynierskie na produkcji

01. Likwidacja długu poznawczego poprzez refaktoryzację „Delete-First”

Zespół napotyka mikrousługę obliczającą rabaty o długości 2500 linii, napisaną przez agenta podczas hackathonu. Usługa zawiera dziesiątki gałęzi warunkowych, które nigdy nie są wykonywane. Architekt rejestruje wymagania biznesowe w 15 zwięzłych testach integracyjnych, całkowicie usuwa stary plik i zmusza agenta do wygenerowania czystej funkcji tabelarycznej (Lookup Table) o długości 120 linii, likwidując 95% zbędnego kodu.

02. Wykrywanie cyklicznych zależności za pomocą dependency-cruiser

Przez chaotyczne rekomendacje agentów moduły projektu okazały się splątane w cykliczne importy (A -> B -> C -> A), co powodowało spontaniczne błędy undefined podczas inicjalizacji środowiska na produkcji. Inżynierowie konfigurują regułę no-circular w CI, poprawiają strukturę na warstwową (Layered Architecture) i blokują dalsze próby tworzenia krzyżowych połączeń przez agentów.

03. Audyt kontraktów mikrousługowych przez Zod / OpenAPI

Agenci generowali wywołania klienckie do backendu ze starszymi wersjami pól. Wdrożenie surowej schemy Zod na wejściu każdego endpointu API oraz automatyczna generacja typów TypeScript dla frontendu eliminuje ukryte błędy niespójności danych, gwarantując, że żadna zmiana nie złamie aplikacji klienckiej.

5. Pułapki, typowe błędy i bezpieczeństwo

1. „Fixing Slop with More Slop” (Leczenie szlamu nowym szlamem): Gdy w wygenerowanym kodzie pojawia się błąd, najgorszą rzeczą, jaką można zrobić, jest wysłanie błędu do modelu ze słowami „napraw”. Model po prostu doda kolejny if lub try-catch, tworząc „goły plaster” na gnijącej architekturze. Zatrzymaj się, przeanalizuj przyczynę źródłową (Root Cause) i uprość pierwotny design.
2. Ignorowanie wycieków zasobów w procesach tła: Wygenerowane skrypty często zapominają o zamknięciu połączeń z bazą danych, deskryptorów plików lub pul wątków. Na maszynie lokalnej jest to niezauważalne, ale pod wysokim obciążeniem serwer wyczerpuje limity otwartych plików (Too many open files) i pada.
3. Błędna ocena produktywności zespołu: Jeśli management ocenia deweloperów na podstawie szybkości zamykania tasków lub liczby commitów, inżynierowie przechodzą na niekontrolowaną generację kodu AI. Mierz stabilność release’ów, liczbę regresji oraz łatwość modyfikacji systemu, a nie brutto ilość napisanego tekstu.