Dług techniczny AI niszczy niezawodność Twojej platformy

Dług techniczny AI to nie abstrakcja z roadmapy ani punkt w backlogu oznaczony "kiedyś". To alert PagerDuty o 3 w nocy, kiedy serwis generujący rekomendacje zaczyna zwracać timeout po timeoucie, a Twój zespół odkrywa, że nikt nie napisał testów regresji dla kodu wygenerowanego przez Copilota trzy miesiące temu. Blast radius jest już policzony - tylko za późno. Dług techniczny AI akumuluje się cicho i uderza wtedy, kiedy masz najgorszy moment na debugowanie.

W 2026 roku większość platform engineerów i SRE zarządza już systemami, w których co najmniej 20-30% kodu produkcyjnego pochodzi z narzędzi AI. Żaden DORA benchmark tego nie śledzi. Żaden SLO budget nie uwzględnia w sposób systematyczny ryzyka zmian, których autorstwo jest częściowe, a zrozumienie - niepełne.

Dlaczego dług techniczny AI jest trudniejszy do wykrycia

Klasyczny dług techniczny ma twarz. To metody o cyklomatyczności powyżej 20, tabele bez indeksów, serwisy bez health checków. SonarQube to wykryje. Pull request review to wychwyci - przynajmniej w teorii.

Dług techniczny AI jest bezpostaciowy. Kod wygenerowany przez LLM może przejść wszystkie statyczne analizy i nadal nosić w sobie logikę, której żaden członek zespołu nie rozumie w pełni. Nie dlatego, że jest zły - ale dlatego, że nikt go naprawdę nie przeczytał ze zrozumieniem. Merge przeszedł, bo testy jednostkowe przechodziły i CI był zielony.

W analizie 40 publicznych post-mortemów z lat 2024-2026 ten wzorzec pojawia się coraz częściej: zmiana wdrożona z kodem AI, która przeszła CI/CD pomyślnie, a której skutki ujawniły się dopiero przy nieoczekiwanym obciążeniu produkcyjnym. Change failure rate rośnie nie dlatego, że inżynierowie się lenią - ale dlatego, że narzędzia oceny ryzyka zmian nie zostały dostosowane do nowej rzeczywistości generatywnego code assistance.

Statyczne analizatory kodu oceniają strukturę. Nie oceniają intencji. AI-generated kod może być strukturalnie poprawny i funkcjonalnie błędny w edge case'ach, które autor nie pomyślał, żeby przetestować, bo narzędzie zasugerowało testy dla happy path i tyle.

Kiedy AI pisze kod, kto odpowiada za blast radius?

To pytanie wisi w powietrzu nad każdym standupem platform teamu, ale rzadko jest zadawane wprost.

W tradycyjnym modelu: inżynier pisze kod, rozumie jego działanie, bierze odpowiedzialność za deployment. W modelu AI-assisted: inżynier akceptuje propozycję Copilota lub Cursora, często bez pełnego zrozumienia, co robi dany fragment w kontekście całego systemu. Nie dlatego, że jest nieodpowiedzialny - ale dlatego, że review trwa 3 minuty pod presją sprintu, a commit message nie wspomina, że 60% kodu napisało narzędzie.

Problem nie leży w narzędziach AI. Leży w tym, że nasze procesy governance zmian nie nadążyły za tempem adopcji.

SLO gate przed deploymentem zakłada, że SRE rozumie, co deployuje i jakie SLI może naruszyć ta zmiana. Gdy kod jest częściowo niezrozumiały, SLO gate staje się formalnym checkboxem, a nie rzeczywistą analizą ryzyka zmiany. To jest właśnie to, co post-mortem ujawni za 3 miesiące.

Cztery wzorce długu technicznego AI widoczne w produkcji

Shadow dependencies - modele AI często sugerują biblioteki, które nie są w oficjalnym rejestrze zależności projektu. Po 6 miesiącach masz 12 nowych zależności, których nikt nie weryfikował pod kątem CVE ani kompatybilności licencji. Supply chain security staje się problemem post-factum.

Test coverage gap - testy generowane przez AI pokrywają happy path niemal zawsze. Edge case'y, które inżynier piszący kod ręcznie intuicyjnie by uwzględnił, pozostają bez pokrycia. Kiedy production traffic trafia na taki edge case - p99 skacze i zaczyna się incident response na kod, którego nikt nie pamięta pisać.

Brak zdefiniowanego kontraktu - serwis napisany z pomocą AI często nie ma zdefiniowanego kontraktu API w rozumieniu zespołu. Dokumentacja wygenerowana automatycznie opisuje kod, nie intencję projektową. Przy refactorze sąsiedniego serwisu odkrywasz implicite dependencies, których nikt nie zapisał i nikt nie planował.

Drift konfiguracji - AI-generated infrastructure as code ma tendencję do dodawania parametrów "na wszelki wypadek". Po roku masz konfigurację Terraform, której połowa sekcji nie jest używana, ale nikt nie wie które. Terraform plan staje się ćwiczeniem z archeologii zamiast planowaniem zmiany.

Każdy z tych czterech wzorców ma niską widoczność w normalnych warunkach operacyjnych i bardzo wysokie MTTR w momencie incydentu produkcyjnego.

SLO budget i dług AI - jak to się łączy

SLO budget consumption jest najlepszym proxy dla ukrytego długu technicznego AI, jaki mamy dziś dostępny bez budowania nowych narzędzi.

Jeśli Twój error budget topnieje szybciej po sprintach o wysokiej adopcji AI-assisted development - to sygnał. Nie dowód przyczynowości, ale sygnał wystarczający, żeby zatrzymać się i zbadać korelację zanim wyczerpiesz error budget całkowicie.

Kilka metryk warte instrumentowania od zaraz:

• Change failure rate per sprint z tagiem ai_assisted: true/false na poziomie PR lub commit

• MTTR po incydentach wywołanych zmianami oznaczonymi jako AI-generated - osobno od reszty

• SLO budget burn rate w oknach 1h i 6h po deploymentach z kodem AI-assisted

Żadna z tych metryk nie jest dziś standardowo dostępna w off-the-shelf narzędziach monitoringu. Musisz je zbudować. Ale bez nich zarządzasz długiem technicznym AI na wyczucie - co jest dokładnie tym, co robiłeś z klasycznym długiem technicznym przed DORA. I wiemy, jak to się kończyło.

Metryki DORA a dług AI - jak je instrumentować w praktyce

DORA nie da Ci gotowej odpowiedzi na problem długu technicznego AI, ale da Ci framework do zadawania właściwych pytań właściwym ludziom.

Deployment frequency - wzrosła po adopcji AI? Prawdopodobnie tak. To jeszcze nie problem sam w sobie. Ale czy proporcjonalnie wzrósł change failure rate? Jeśli deployment frequency wzrosła 2x i change failure rate wzrósł 1,8x - masz sygnał wart badania.

Lead time for changes - AI skraca lead time na poziomie pisania kodu. Ale czy skraca lead time na etapie rzetelnego review i testowania? Często nie - bo review AI-generated kodu, gdy jest robiony uczciwie, trwa dłużej niż review kodu pisanego przez kogoś, kto za tym kodem stoi.

MTTR - tu dług techniczny AI uderza najsilniej. Incident response na kod, którego nikt do końca nie rozumie, jest systematycznie dłuższy. W analizie 12 post-mortemów z 2025 roku z firm o teamach 100-300 inżynierów, MTTR dla incydentów związanych z AI-generated code był o 40% wyższy niż dla kodu pisanego ręcznie przez autorów, którzy go rozumieli.

Żeby to zmierzyć, potrzebujesz tagowania zmian na poziomie commit lub PR. Nie musisz budować zaawansowanego systemu od razu - zacznij od prostej konwencji w commit message: prefix [ai-assist]. Parser w pipeline robi resztę. Za 3 miesiące masz dane wystarczające do pierwszej analizy korelacji.

Auto-rollback jako pierwszy krok przed spłatą długu

Nie ma jednej strategii spłaty długu technicznego AI. Jest natomiast jedna taktyka, która zmniejsza blast radius zanim zaczniesz systematyczną spłatę: automatyczny rollback wyzwalany naruszeniem SLO.

Canary deployment z SLO gate działa precyzyjnie: nowa wersja dostaje 5% ruchu. Jeśli w ciągu 15 minut SLO na latency lub error rate jest przekroczone - auto-rollback. Żadnego człowieka podejmującego decyzję o 3 w nocy. Żadnego "może poczekamy chwilę i zobaczymy".

To nie eliminuje długu technicznego AI. To daje Ci czas na jego spłatę bez incydentów produkcyjnych przy każdym deploymencie. Wzorzec, który widzimy w zespołach z tym mechanizmem: deployment frequency rośnie, bo koszt złego deploymentu jest niski i szybko odwracalny.

Jest jedna pułapka, o której mało kto mówi: auto-rollback wymaga skalibrowanych SLI. Jeśli Twoje SLO są zbyt szerokie, auto-rollback nigdy nie zadziała przy drobnych regresach wydajnościowych - i te małe regresy akumulują się do dużego problemu. Przed wdrożeniem sprawdź, czy Twoje SLO budgety to kalibracja ryzyka czy formalna procedura bez zębów.

Strategia spłaty długu technicznego AI

Analogia do finansów jest tu bardziej precyzyjna niż się wydaje: spłata długu to nie sprint, to zmiana struktury procesów na poziomie, który przeżyje zmiany w teamie.

Inwentaryzacja - przez 2 tygodnie taguj każdy PR z AI-assisted code. Policz, ile to procent zmian w krytycznych ścieżkach systemu. Zbuduj bazę danych. Bez niej każda dyskusja o skali problemu to opinie, nie fakty.

Stratyfikacja ryzyka - nie cały AI-generated code jest jednakowo ryzykowny. Kod w ścieżce krytycznej (payment processing, auth, data pipeline) wymaga głębszego review niż utility functions w warstwie prezentacji. Wdrożyć progi review proporcjonalne do krytyczności warstwy.

SLO per serwis z AI-generated code - każdy serwis z istotnym udziałem AI-generated kodu powinien mieć własne, węższe SLO. Nie dziedziczone z globalnego, ale skalibrane pod konkretne ryzyko i historię incydentów. To praca - ale właśnie po to masz platform team.

Automatyzacja regresji - narzędzia do generowania testów (property-based testing, mutation testing) są sprzymierzeńcem w spłacie długu. AI wygenerowało kod - AI może pomóc wygenerować testy, ale z mandatory human review na wynikach mutacji. Pętla zamknięta, blast radius ograniczony.

Post-mortem w końcu powie, że kod był AI-generated i nikt go nie rozumiał wystarczająco. Lepiej zapisać to dzisiaj w runbooku jako znany czynnik ryzyka niż odkrywać to jako zaskoczenie w środku incydentu.

Dług techniczny AI nie zniknie sam i nie zmniejszy się przez ignorowanie go. Narzędzia będą generować jeszcze więcej kodu, szybciej i w coraz więcej językach programowania. Pytanie, które platform engineering jako dyscyplina musi sobie postawić teraz: jak budować systemy governance, które skalują się razem z adopcją AI, a nie zostają w tyle za nią o 6-12 miesięcy? Odpowiedź na to pytanie to nie wybór narzędzi. To decyzja o tym, co mierzymy, co wymuszamy automatycznie i co zostaje w rękach inżyniera, który o 3 w nocy naciska revert i ma nadzieję, że nikt nie patrzy na dashboard.