Jak złe użycie AI w kodzie generuje dług techniczny? 3 przypadki
Słyszysz to na każdym konferencyjnym panelu: „AI zwiększa produktywność programistów”, „Generatywna AI pisze kod 10x szybciej”, „Przyszłość to asystenci AI”. Prawda jest bardziej skomplikowana. Owszem, narzędzia takie jak GitHub Copilot czy ChatGPT potrafią przyspieszyć rutynowe zadania. Ale bez odpowiedniego nadzoru wpuszczasz do kodu coś znacznie gorszego niż przeciętny junior – dług techniczny w formie pozornie działającego, ale trudnego w utrzymaniu kodu.
W JurskiTech od lat patrzymy na kod pisany przez AI i widzimy te same błędy. Nie chodzi o to, żeby z AI nie korzystać – tylko żeby robić to świadomie. Oto trzy sytuacje, w których AI zamiast pomóc, realnie szkodzi.
1. Kopiowanie kodu bez kontekstu – „działa, więc jest dobrze”
Najczęstszy błąd: programista prosi AI o rozwiązanie konkretnego problemu, dostaje blok kodu, wkleja go i idzie dalej. Problem w tym, że AI nie zna architektury Twojego systemu, konwencji nazewniczych, użytych bibliotek ani stylu kodu. To trochę jak poproszenie losowego developera z internetu o napisanie funkcji – raz zadziała, ale po miesiącu okazuje się, że ten kawałek kodu jest niespójny z resztą, używa innego patternu i łamie reguły ESLint.
Przykład z życia: Klient przyszedł do nas z aplikacją Node.js, w której jedna z usług używała async/await w stylu callback hell, inna korzystała z Promise.all bez obsługi błędów, a jeszcze inna miała synchronizację na sztywno. Wszystko działało – ale refactoring zajął dwa tygodnie, bo każda część była napisana w innym „idiolekcie” wygenerowanym przez AI.
Konsekwencje: Każda zmiana wymaga więcej analizy, testy są mniej przewidywalne, a onboarding nowych członków zespołu staje się koszmarem. Dług techniczny rośnie wykładniczo.
2. Generowanie duplikatów – „AI nie wie, że już to masz”
AI nie ma pamięci długoterminowej (chyba że dasz jej kontekst). Jeśli poprosisz o funkcję walidacji emaila, dostaniesz ją – nawet jeśli taka funkcja istnieje już w projekcie. W efekcie powstają setki linii zduplikowanego kodu, który różni się drobnymi szczegółami. Potem, gdy trzeba zmienić logikę walidacji, programista musi pamiętać o poprawieniu jej w trzech miejscach.
Obserwacja z rynku: W jednym z naszych audytów znaleźliśmy 7 różnych implementacji sortowania tablicy obiektów – każda wygenerowana przez AI w odpowiedzi na podobne zapytanie. Żadna nie była całkowicie zła, ale wszystkie były niepotrzebne.
Konsekwencje: Większe ryzyko błędów (np. zapomnisz o jednej kopii), trudniejsze testowanie, większy rozmiar kodu do utrzymania. To prosta droga do spaghetti.
3. Brak obsługi błędów i krawędzi – „AI zakłada świat idealny”
AI często generuje kod, który działa w 90% przypadków – tych standardowych. Ale pomija obsługę błędów, sytuacje brzegowe, timeouty, wyjątki sieciowe czy nieprawidłowe dane wejściowe. Programista, który wkleja taki kod bez modyfikacji, wprowadza do systemu cichą bombę.
Przykład z życia: Wygenerowana funkcja fetch z await response.json() – bez sprawdzenia response.ok. W środowisku deweloperskim API zawsze odpowiada poprawnie. Na produkcji, po zmianie API, aplikacja padała z błędem parsowania JSON. AI nie przewidziało, że odpowiedź może być pusta lub mieć status 500.
Konsekwencje: Niestabilność, trudne do zdiagnozowania błędy, większe koszty operacyjne. Ktoś to musi potem poprawić – a to już nie jest darmowe.
Podsumowanie: AI jako narzędzie, nie zastępstwo
AI w kodzie nie jest złem. Jest fantastycznym narzędziem do generowania boilerplate’ów, pisania testów jednostkowych, refaktoryzacji prostych fragmentów czy szybkiego prototypowania. Problem zaczyna się, gdy traktujemy je jak zastępstwo dla myślenia – gdy wklejamy kod bez zrozumienia, bez dostosowania do kontekstu, bez testów.
Dług techniczny generowany przez AI jest podstępny, bo nie objawia się od razu. Wygląda jak działający kod. Ale po kilku miesiącach, gdy zespół próbuje dodać nową funkcję, okazuje się, że połowa kodu wymaga przepisania.
Rekomendacja: Ustalcie w zespole zasady korzystania z AI – np. każdy wygenerowany fragment musi być przejrzany przez drugiego developera, nie wolno wklejać kodu bez testów, a AI ma być używane tylko do zadań, które zespół dobrze rozumie. W JurskiTech sami korzystamy z AI, ale zawsze z krytycznym okiem. Bo kod, który „tylko działa”, to jeszcze nie dobry kod.
