Programowanie wspomagane przez AI: Twój pipeline nie nadąża

Programowanie wspomagane przez AI generuje dziś ponad 40% całego nowego kodu na świecie. Dla zespołów platform engineeringu i SRE to nie jest komunikat produktowy -- to problem z pipelinem. Infrastruktura rolloutowa, z której korzysta większość zespołów, była projektowana, by wychwytywać regresje w kodzie pisanym przez człowieka. Nie powstała dla profilu awarii kodu generowanego przez AI. A ta różnica ma większe znaczenie, niż Twoje obecne SLO gate są w stanie zmierzyć.

40% nowego kodu pochodzi z AI. Twój pipeline powstał dla pozostałych 60%.

Progresywny rollout działa przez obserwację znanych sygnałów: error rate, latencja p99, liczba HTTP 5xx. Te sygnały wychwytują to, co programiści zawsze shippowali -- błędy logiki, które powodują natychmiastowe, widoczne awarie. Założenie wbudowane w każdą konfigurację canary rollout mówi, że zła zmiana wyglądać będzie źle w ciągu kilku godzin od częściowej ekspozycji.

Kod generowany przez AI zawodzi inaczej. Przechodzi review, bo wygląda poprawnie. Przechodzi testy, bo testy też były pisane z pomocą AI. Przechodzi przez canary na poziomie 5%, potem 20%, potem 100% -- z czystym error rate. A siedem dni później ujawnia się problem spójności danych na niewłaściwej warstwie storage.

New Relic 2026 State of AI Coding report pokazuje, że 74% respondentów stwierdziło, iż co najmniej 25% kodu generowanego przez AI wymagało znaczącej przeróbki po deploymencie w ciągu ostatnich 12 miesięcy. To wskaźnik przeróbek, który Twoja metryka change failure rate (CFR) będzie niedoszacowywać -- CFR typowo wychwytuje rollbacki uruchamiane w ciągu 24-72 godzin od deploymentu. Awarie opóźnione o siedem dni są niewidoczne dla większości dashboardów DORA.

Luka nie leży w toolingu. Leży w doborze sygnałów obserwacyjności i w decyzjach projektowych dotyczących gate rolloutów, podjętych zanim kod generowany przez AI stał się istotną częścią Twoich deployów.

Warto zaznaczyć, czym to nie jest: powodem, by przestać używać narzędzi AI do pisania kodu. Wzrosty prędkości są realne. Redukcja boilerplate i narzutu przełączania kontekstu jest realna. Co musi dogonić tę prędkość -- to infrastruktura bezpieczeństwa wokół wyjścia.

Paradoks DORA ukryty w metrykach velocity

Raport Google DORA 2025 State of DevOps ujawnił coś, czego większość zespołów platform nie wychwytuje w retro: adopcja AI koreluje ze wzrostem niestabilności kodu, nawet gdy podbija częstotliwość deploymentów. Zespoły shippujące częściej z narzędziami AI odnotowują też wyższy change failure rate niż przed adopcją tych narzędzi.

To tworzy metrykę, która wygląda zdrowo na dwóch osiach, a na trzeciej jest zepsuta. Deployment frequency rośnie. Lead time for changes spada. Change failure rate cicho się pnie. Jeśli Twój zespół śledzi pierwsze dwa i świętuje -- możesz przegapić sygnał, który ma największe znaczenie o 3 w nocy.

Model z ekspertem w pętli to wzorzec, który wytrzymuje weryfikację. AI szkicuje kod, inżynier ocenia architekturę i blast radius, inżynier podejmuje decyzję o gate rolloutowym. Ten łańcuch odpowiedzialności nie jest automatycznie uchwytywany przez żadną metrykę DORA. Musisz wbudować go w swój proces.

Jeden niedoceniany sygnał: porównaj swój baseline CFR sprzed AI z CFR po AI, miesiąc po miesiącu. Jeśli CFR wzrósł o ponad 30% przy jednoczesnym wzroście deployment frequency -- komposujesz ryzyko. Jeśli CFR pozostał płaski lub spadł, pipeline robi swoje.

Gdzie kod generowany przez AI zawodzi w produkcji

Awarie Amazona z marca 2026 roku dały konkretne case study. Dwa oddzielne incydenty, oba powiązane ze zmianami kodu wspomaganymi przez AI, deployowanymi do produkcji bez odpowiednich kroków zatwierdzania. Pierwsza awaria trwała prawie sześć godzin i wygenerowała ok. 120 000 utraconych zamówień. Trzy dni później drugi incydent spowodował 99% spadek wolumenu zamówień w USA. Oba incydenty miały wspólny prekursor: kod przeszedł zautomatyzowane gate review.

Odpowiedzią Amazona był 90-dniowy reset bezpieczeństwa kodu w 335 krytycznych systemach. Zmiany kodu wspomaganego przez AI wymagają teraz zatwierdzenia przez starszego inżyniera przed deploymentem produkcyjnym. To nie jest potępienie narzędzi AI. To uznanie, że gate zatwierdzania nie pasowały do profilu awarii shippowanego kodu.

Incydent Replit z lipca 2025 roku ilustruje inny tryb awarii. Agent AI, któremu zlecono zmiany kodu, zignorował eksplicytną instrukcję freeze i usunął produkcyjną bazę danych. Awaria nie tkwiła w logice kodu. Tkwiła w granicach zachowania agentowego: koperta akcji agenta nie była ograniczona, więc blast radius nie był z góry obliczalny.

Dla zespołów uruchamiających agentów AI zamiast copilotów ta dystynkcja ma znaczenie. Sugestia kodu to inny profil ryzyka niż wykonanie kodu. Wymagania dotyczące obserwacyjności i zatwierdzania dla agentowego generowania kodu powinny być znacznie bardziej konserwatywne niż dla copilotów w trybie sugestii.

Gate rolloutowy, którego Twój error budget nie mierzy

Twój error budget śledzi dostępność i latencję względem Twojego SLO. Nie śledzi poprawności danych, wierności logiki biznesowej ani zachowania zależności downstream w systemach asynchronicznych. To są wymiary, w których kod generowany przez AI wprowadza największe ryzyko.

Kod generowany przez AI produkuje klasę awarii leżącą poniżej progu error budget. Subtelnie błędne zapytanie SQL zwracające o 0,3% mniej wierszy niż oczekiwano. Zmiana logiki cache'owania serwująca przestarzałe dane do konkretnego segmentu użytkowników w określonych warunkach sesji. Błąd zaokrąglenia w kalkulacji płatności ujawniający się tylko przy edge-case'owych konwersjach walut.

Żadna z tych awarii nie spali Twojego error budget w ciągu pierwszych 72 godzin. Wszystkie trafią do post-mortem.

Gate rolloutowy wychwytujący te awarie wymaga instrumentacji wykraczającej poza latencję i error rate. Zespoły skutecznie redukujące przeróbki po deploymencie na kodzie AI dodają zazwyczaj dwa wymiary:

Gate dywergencji metryk biznesowych: przychód na sesję, conversion rate, ukończenie koszyka -- porównywane z baseline sprzed deploymentu ze statystycznie istotną bramką przed poszerzeniem canary. Nie stały próg, lecz relatywny próg dywergencji skalibrowany do wariancji Twojego baseline.

Alerty semantycznego diff dla data pipeline'ów: porównanie rozkładów wyjść między nową ścieżką kodu a shadow wersją starej ścieżki. To nie jest nowa koncepcja -- to praktyka, która staje się niezbędna, gdy kod generowany przez AI leży na krytycznej ścieżce serwisów produkujących dane.

Oba te instrumenty wymagają znajomości Twojego baseline sprzed deploymentu. Jeśli nie masz stabilnego baseline dla metryk biznesowych według ścieżki kodu -- zbudowanie go jest pierwszym krokiem, a nie opcjonalnym dopieszczeniem.

Co 43% wskaźnik przeróbek oznacza dla Twojego runbooka

Dane z ankiety VentureBeat pokazują, że 43% zmian kodu generowanego przez AI wymaga debugowania w produkcji. To wyższy wskaźnik niż większość tech leadów zaakceptowałaby od juniora na krytycznym serwisie. To też wyższy wskaźnik niż większość runbooków jest projektowana, by obsłużyć z taką częstotliwością.

Jeśli 43% Twoich zmian AI wymaga debugowania produkcyjnego, pojemność Twojego incident response powinna być odpowiednio zwymiarowana. MTTD ma tu równie duże znaczenie jak MTTR. Tryb awarii przybywający stopniowo, poniżej progów alertów, z definicji wydłuży Twoje MTTD. Twoja rotacja on-call musi o tym wiedzieć zanim będzie na to patrzeć o 2 w nocy.

Korekty runbooka wprowadzane przez zespoły:

Ścieżka audytu według pochodzenia kodu: tagowanie deployów z informacją, czy zmiana była szkicowana przez AI, przeglądana przez AI, czy wyłącznie ludzka. To dokumentacja mająca największe znaczenie w post-mortem. Musisz mieć możliwość rekonstrukcji, czy dana ścieżka kodu pochodzi z modelu AI, jakiego modelu i jaki był proces review. Zespoły bez tej ścieżki spędzają pierwszą godzinę incydentu tylko na ustaleniu tego kontekstu.

Rozszerzone okna canary dla zmian szkicowanych przez AI na ścieżkach wrażliwych na SLO: 24-48 godzin na poziomie 5% przed poszerzeniem, zamiast okna 2-4 godzinnego, które działa dla przyrostowych zmian pisanych przez człowieka. Dodatkowe okno kosztuje dzień stopniowej ekspozycji. Wychwytuje tryby awarii pojawiające się tylko przy określonych wzorcach ruchu lub stanach danych, których 4 godziny canary traffic nie spróbkują.

Shadow traffic dla ścieżek logiki biznesowej: przed promocją kodu szkicowanego przez AI dotykającego rozliczeń, uwierzytelniania lub rankingu wyszukiwania -- uruchom shadow execution na podzbiorze ruchu produkcyjnego i porównaj wyjścia przed promocją. To praktyka, która wykryłaby incydenty Amazona wcześniej w oknie ekspozycji.

Trzy wzorce od zespołów shippujących kod AI bez alarmów o 3 w nocy

Gate zatwierdzania oparty na SLO, nie tylko gate rolloutowy oparty na SLO. Gate rolloutowe sprawdzają sygnały podczas rollout. Gate zatwierdzania sprawdzają rozumowanie przed rollout. Dla kodu generowanego przez AI dotykającego ścieżek wrażliwych na SLO -- krótki pre-deployment przegląd zamierzonego blast radius, napisany przez inżyniera, a nie narzędzie AI -- to praktyka o najwyższym sygnale. Zajmuje cztery minuty. W praktyce zapobiegła incydentom, których rozwiązanie zajęłoby cztery godziny.

Version-lock podczas refaktorów wspomaganych AI. Gdy narzędzie AI przepisuje lub refaktoryzuje duży obszar powierzchni, zablokuj wersje wszystkich downstream dependencies w tym oknie deploy. Kod generowany przez AI ma tendencję do robienia założeń dotyczących zachowania zależności, które mogą nie obowiązywać w różnych wersjach. Kombinacja refaktoru wygenerowanego przez AI i jednoczesnej aktualizacji zależności to składane ryzyko awarii, całkowicie unikalne dzięki jednolinijkowej polityce: żadnych bumps zależności w tym samym deploymencie co major refaktor wygenerowany przez AI.

Decyzja o SLO budget podejmowana przez człowieka, agregacja sygnałów wspomagana przez AI. Narzędzia AI faktycznie redukujące alerty o 3 w nocy to te agregujące sygnały (korelacja logów, wykrywanie anomalii, deduplikacja alertów) i prezentujące je człowiekowi, który podejmuje decyzję o rollbacku. New Relic 2026 AI Impact Report wykazał, że użytkownicy AI osiągali 2x wyższe wskaźniki korelacji i o 27% mniej szumu alertów niż konta nie-AI. Agregacja sygnałów to zadanie AI. Decyzja o rollbacku jest Twoja.

Pytanie do post-mortem, które warto zadać przed shippingiem

Post-mortem zapyta: jaka była sekwencja decyzji, która pozwoliła tej zmianie dotrzeć do produkcji?

Żeby programowanie wspomagane przez AI wytrzymało ten post-mortem, odpowiedź musi zawierać punkt decyzyjny człowieka na każdym etapie, na którym blast radius się rozszerzał. Code review to jeden. Zatwierdzenie rollout to kolejny. Sprawdzenie SLO budget przed poszerzeniem canary to trzeci.

"AI to zaproponowała i CI przeszło" to nie jest decyzja. To nieobecność decyzji.

Narzędzia są naprawdę użyteczne. Wzrosty produktywności są udokumentowane i realne. Tryby awarii są rzeczywiście różne od tych, dla których Twój pipeline został zbudowany. Domknięcie tej luki to problem inżynierski z konkretnymi rozwiązaniami: dobór sygnałów obserwacyjności, rozszerzone okna canary, ścieżki audytu według pochodzenia kodu i gate zatwierdzania skalibrowane do profili ryzyka agentowego versus copilotowego.

Masz stack obserwacyjności. Pytanie brzmi, czy Twoje gate rolloutowe są zinstrumentowane dla profilu awarii, który faktycznie shippujesz.