Delegując coraz większą część pracy programistycznej asystentom AI, zacząłem intensywnie zastanawiać się nad zjawiskiem długu technologicznego w tym kontekście. W tym artykule przedstawię Ci moje wnioski i jestem bardzo ciekaw, czy się z nimi zgadzasz, czy wręcz przeciwnie.

Czym jest dług technologiczny?

W idealnym świecie, tworząc kod, nie trzeba iść na żadne kompromisy. Niestety nie żyjemy w idealnym świecie. Krótkie terminy, wrzutki, pożary czy błędy w estymacjach to w wielu projektach proza dnia codziennego. Jednym z narzędzi, które pomagają w ogarnięciu tych sytuacji, jest umiejętne operowanie długiem technologicznym.

Dług technologiczny to metafora ukuta przez Warda Cunninghama, opisująca rozwiązanie, które przyspiesza dostarczenie wartości kosztem koniecznych zmian w przyszłości. Sam Cunningham opisywał to następująco:

Shipping first time code is like going into debt. A little debt speeds development so long as it is paid back promptly with a rewrite…. The danger occurs when the debt is not repaid. Every minute spent on not-quite-right code counts as interest on that debt. Entire engineering organizations can be brought to a stand-still under the debt load of an unconsolidated implementation, object-oriented or otherwise.

Ward Cunningham

Często możliwości zespołu nie pozwalają na dostarczenie idealnego rozwiązania. W takiej sytuacji możemy zwiększyć zespół, wydłużyć termin lub pójść na kompromisy. Jest to klasyczny problem: szybko, tanio, dobrze – wybierz dwa. Częstym wyborem w takiej sytuacji jest pójście na kompromisy, czyli zaciągnięcie długu technologicznego.

Dług technologiczny działa analogicznie do pożyczki w banku. Jeśli nie dysponujemy określonymi środkami, otrzymujemy dobro wcześniej, jednak zaciągamy dług, który prędzej czy później będzie trzeba spłacić. W kontekście tego artykułu przez dług technologiczny będę rozumiał każdą decyzję w projekcie, która wpisuje się w przedstawioną definicję. Niezależnie od tego, czy jest to drobny hack w kodzie, czy kompromis na poziomie architektury systemu. Choć wielu rozróżnia technical debt i architectural debt, na potrzeby tego artykułu będę traktował je łącznie.

Również analogicznie do pożyczek finansowych, w przypadku tworzenia kodu możemy obserwować zjawiska takie jak rolowanie długu czy spirala zadłużenia. Nieumiejętne zarządzanie długiem technologicznym może sprawić, że wymknie się on spod kontroli. Konsekwencją może być obniżenie komfortu pracy czy zwolnienie tempa dowożenia kolejnych funkcjonalności czy poprawek. W długim terminie dług, który wymknął się spod kontroli, może prowadzić do odchodzenia deweloperów z projektu, awarii czy dotarcia do ściany w rozwoju projektu. Takie sytuacje to czerwona lampka i jasny sygnał, że zajęcie się długiem staje się konieczne.

The cost of tech debt is borne daily by your team, and you risk damaging motivation and raising attrition by ignoring it.

Lou Franco – Paying down tech debt

Dług technologiczny sam w sobie nie jest jednoznacznie dobry ani zły. O tym, czy dług jest uzasadniony, decyduje kontekst, w jakim został zaciągnięty. Zarówno dług, jak i jego skutki będą miały długoterminowy wpływ na kondycję projektu. Jeśli zaciągamy go intencjonalnie, świadomi celu i konsekwencji oraz mamy plan jego docelowej spłaty, to niezależnie od tego, czy dług zaciągniemy sami, czy za pomocą AI, takie podejście jest jak najbardziej okej.

Także w finansach zadłużenie nie zawsze jest czymś negatywnym. Czasami kredyt wzięty na inwestycję może okazać się najlepszą możliwą decyzją, a zaciągnięcie długu pomoże nam znacznie pomnożyć majątek. Czasami też zwyczajnie nie ma wyjścia. Obecna sytuacja na rynku nieruchomości sprawia, że przeciętnej osobie trudno kupić mieszkanie lub dom za gotówkę. Wykorzystanie kredytu to dla wielu osób jedyna możliwość. Są jednak długi całkowicie bezsensowne lub, mówiąc bardziej dosadnie, idiotyczne, jak chwilówka na wakacje czy nowy telewizor. Takich długów należy unikać jak ognia.

AI pozwala łatwiej go zaciągać… ale czy spłata jest równie łatwa?

Moim zdaniem wykorzystanie AI do tworzenia kodu całkowicie zmienia to, jak należy podchodzić do postrzegania pisania kodu. Przez wiele lat wytwarzanie kodu było przyrównywane do rzemiosła, w którym programista-rzemieślnik skrupulatnie tworzy kod linia po linii.

Pojawienie się narzędzi AI umiejących generować sensowny i działający kod przypomina wynalezienie maszyny drukarskiej czy rozwój produkcji przemysłowej. Popularyzacja tych rozwiązań nie sprawiła, że rzemieślnicy zniknęli. Spowodowało jednak znaczne obniżenie kosztów i pozwoliło na masową produkcję. Obecnie wciąż przecież można kupić ręcznie szyte buty na miarę z prawdziwej skóry. Jednak w sklepach znaczną część ekspozycji zajmują niskiej jakości buty maszynowo produkowane w krajach trzeciego świata.

Mówiąc o długu technicznym w kontekście AI, moim zdaniem najbardziej oczywiste są zmiany w obszarze pojedynczych funkcji, klas czy testów. Mając do dyspozycji AI, trudno mi zrozumieć sytuację, w której świadomie pozostawiamy w kodzie niewielki dług w postaci np. nieczytelnego kodu, przypadkowej duplikacji kodu czy brakujących testów. Wyeliminowanie tych drobnych niedociągnięć to obecnie napisanie jednego lub kilku promptów. W czasach, gdy wszystkie te poprawki należało wykonać ręcznie, takie ustępstwa były łatwiejsze do uzasadnienia. Obecnie można je wyeliminować praktycznie od ręki.

Co więcej, zostawianie takich rzeczy w kodzie prowadzi do dalszej degradacji kodu. Agent AI prawdopodobnie będzie wzorował się na tym, co już istnieje, przez co chętniej będzie powielał zastane wzorce. Oczywiście w czasach ręcznego copy-paste-driven development zjawisko bezrefleksyjnego propagowania problematycznego kodu również występowało. Moim zdaniem działo się to jednak na mniejszą skalę i było łatwiejsze do wyłapania i wyeliminowania.

Wykorzystanie AI do dostarczania kodu to również świetna okazja, by posprzątać wszelkie już istniejące drobne zaniedbania. Wszelkie nieoptymalne algorytmy, brakujące testy czy niedokończone refaktoryzacje to idealne zadania dla agentów AI. Wystarczy wskazać im, jak powinien wyglądać efekt docelowy oraz co mają zmienić. Moje obserwacje potwierdzają, że AI całkiem dobrze radzi sobie z mechanicznymi, odtwórczymi zadaniami. Będzie to szczególnie efektywne, gdy uruchomimy agenta w tle czy równolegle, korzystając np. z Git worktree. Nawet jeżeli rezultat nie będzie wystarczająco dobry, to będzie to świetna baza pod dokończenie tego zadania samodzielnie.

Wdrożenie AI do procesu dostarczania kodu powinno również w pewnym stopniu ograniczyć nieintencjonalne zaciąganie długu technologicznego. Oprócz tworzenia kodu AI jest w stanie sprawdzać go i weryfikować poprawność rozwiązań. Obecnie niemal każdy pull request można automatycznie przeanalizować pod kątem niepoprawnych lub nieoptymalnych rozwiązań, brakujących testów czy potencjalnie problematycznych implementacji.

Mając w głowie obraz procesu tworzenia kodu z AI jako taśmy produkcyjnej, warto zastanowić się nad potencjalnymi konsekwencjami zaciągnięcia konkretnego długu. Jeśli w zautomatyzowanym procesie produkcyjnym gdzieś występuje błąd, to zostanie on powielony w każdym wytworzonym produkcie. Pisząc kod, można dostrzec analogię do tego zjawiska. Rzemieślnik tworzący ręcznie każdy nowy produkt niemal od razu wyłapuje niedoskonałości. W przypadku produkcji taśmowej mamy do czynienia z procesem kontroli jakości, a ewentualne defekty rzadko kiedy zostaną złapane natychmiast. Oczywiście warto dążyć do weryfikacji jak największej części produkcji, lecz w praktyce jest to coraz mniej wykonalne.

Sporym problemem jest zatrzymanie taśmy produkcyjnej, gdy pracuje na pełnych obrotach. Łatwo jest przyzwyczaić stakeholderów do tego, że dostarczamy coś w wielokrotnie większym tempie niż dotychczas. Przyzwyczajenie do większego tempa pracy również zwiększa oczekiwania, a w konsekwencji backlog z taskami. Znacznie trudniej będzie powiedzieć w takiej sytuacji, że przez zwiększenie tempa pracy obniżyliśmy jakość i teraz czeka nas wstrzymanie dowożenia nowych funkcjonalności na rzecz redukcji długu.

Słusznie można stwierdzić, że dzięki AI można łatwiej wycofać się z błędnej decyzji. Jednak nadal warto mieć w głowie to, że AI zwiększa oczekiwania biznesu i konkurencyjność rynku. Nawet jeśli przestój ze względu na refactor będzie krótszy, niż byłby przy ręcznym wycofywaniu się z błędnej decyzji, to nasza konkurencja również ma do dyspozycji narzędzia AI i prawdopodobnie skrupulatnie wykorzysta każde nasze potknięcie.

Jeszcze większa wartość dokumentacji projektowej

Uważam, że częścią procesu świadomego zaciągania długu technologicznego powinno być tworzenie ADR (Architecture Decision Records). ADR to dokument opisujący istotne decyzje architektoniczne. ADR opisuje kontekst problemu oraz rozważane warianty jego rozwiązania. Opisuje również wady i zalety podjętej decyzji i rozważanych alternatyw. Osobiście nie mam nic przeciwko rozszerzeniu pisania ADR-ów o decyzje nieco niższego poziomu, dotyczące np. wyboru jakiegoś określonego algorytmu, wzorca czy technologii.

Sam proces przygotowania ADR wymusza refleksję nad konsekwencjami decyzji, przez co zmniejsza ryzyko zaciągania przypadkowego lub nieopłacalnego długu technologicznego. Przecież nie napiszemy ADR do nieczytelnie napisanej funkcji czy braku kilku testów. Zdecydowanie jednak jest sens tworzyć ADR, gdy podejmujemy decyzję, że idziemy na świadome ustępstwo w kwestiach mogących rzutować na większą część systemu lub decyzji, z której potencjalnie trudno może być się wycofać. Konieczność przygotowania ADR wymusza również analizę konsekwencji takiej decyzji.

W kontekście zaciągania długu uważam, że taki ADR powinien zawierać również plan lub choćby pomysł, kiedy i jak chcemy dany dług spłacić. W teorii dług jest zobowiązaniem, które prędzej lub później należy uregulować. Praktyka pokazuje, że nie zawsze tak jest, ale myślę, że lepszy jest taki plan niż żaden.

ADR są też pomocne w kontekście cognitive debt i intention debt. To dwa zjawiska, które stały się szczególnie istotne wraz z rosnącym wykorzystaniem AI. Cognitive debt w kontekście AI powstaje, gdy tworząc kod, jednocześnie zatracamy zrozumienie, jak on działa i na jakich zasadach jest oparty. Cytując Margaret-Anne Storey:

Cognitive debt, a term gaining traction recently, instead communicates the notion that the debt compounded from going fast lives in the brains of the developers and affects their lived experiences and abilities to “go fast” or to make changes. Even if AI agents produce code that could be easy to understand, the humans involved may have simply lost the plot and may not understand what the program is supposed to do, how their intentions were implemented, or how to possibly change it.

Natomiast intent debt opisuje sytuację, w której trudno odtworzyć intencje autora kodu. Bez odpowiedniej dokumentacji i uzasadnienia podjętych decyzji, tworząc kod za pomocą AI, widzimy sam efekt. Addy Osmani opisuje to następująco:

Intent debt lives in artifacts. It’s the absence or erosion of the externalized rationale, goals, and constraints that explain why the system is the way it is. The key word is externalized. The rationale has to be written down where a teammate, a future you, or an agent can read it, not held in your head. When intent debt runs high, the system drifts from what you meant it to do, and nobody can say when it diverged or why.

Jednym ze sposobów na redukcję intent debt może być tworzenie dokumentacji, takiej jak na przykład ADR-y. Z kolei przygotowanie ADR-a czy RFC przed rozpoczęciem implementacji z wykorzystaniem AI może pozwolić na zmniejszenie cognitive debt. Dokumenty te można wykorzystać do narzucenia wytycznych implementacyjnych narzędziom AI.

Podsumowanie

Wykorzystanie AI do programowania, moim zdaniem, powinno znacząco ograniczyć występowanie drobnych długów, takich jak brakujące testy, nieoptymalny, nieczytelny lub trudno utrzymywalny kod. Jednak AI nie eliminuje długu technologicznego.

Na poziomie architektury czy systemu tempo dostarczania kodu z wykorzystaniem AI powoduje, że każda decyzja o zaciągnięciu długu technologicznego może mieć znacznie większe konsekwencje niż dotychczas. Na skutek tego podejmowane decyzje muszą być bardziej świadome, w czym bardzo pomocna jest dokumentacja, np. w formie ADR-ów.

Delegując pisanie kodu agentom AI, zyskujemy znacznie więcej czasu na planowanie i analizę. Nawiązując do cytatu Lincolna — dzięki agentom AI mamy znacznie więcej czasu na ostrzenie siekiery. Warto z tego przywileju korzystać.

Źródła i materiały dodatkowe

• Yoav Aviram – Zen of AI Coding
• Worktree w pracy z Claude Code
• Dokumentowanie decyzji projektowych – o ADR i RFC
• Code review z wykorzystaniem asystentów AI
• Martin Fowler – Technical Debt
• Addy Osmani – The Intent Debt
• Oskar Dudycz – Tech Debt doesn’t exist, but trade-offs do
• The Missing GitHub Status Page
• Anton Zaides – „20% for tech debt” doesn’t work
• The Pragmatic Engineer – Paying down tech debt
• Frederick Vanbrabant – Architectural debt is not just technical debt
• Bill Doerrfeld – How AI generated code compounds technical debt
• Uwe Friedrichsen – Forget technical debt
• Margaret-Anne Storey – How Generative and Agentic AI Shift Concern from Technical Debt to Cognitive Debt

Zaobserwuj mnie w mediach społecznościowych!

LinkedIn jest głównym medium, poza blogiem, gdzie publikuję swoje przemyślenia. Zachęcam też do zaobserwowania devszczepaniak.pl na Facebooku, gdzie oprócz informacji o nowych artykułach publikuję linki do ciekawych treści.

Udostępnij wpis

Szukasz taniego i dobrego VPS? Skorzystaj z Mikrusa i przy zakupie odbierz dodatkowy miesiąc usługi za darmo!

📖 Koniecznie sprawdź ofertę księgarni Helion oferującej tysiące książek dla programistów w dobrych cenach! Kupując z tego linku, pomagasz w rozwoju bloga.

📈 Szukasz księgowości dla swojej JDG? Skorzystaj z mojego polecenia i odbierz pierwszy miesiąc za 1zł netto!

Chcesz docenić moją pracę? Postaw mi kawę!