Ukryty podatek od kodu generowanego przez AI: gdzie vibe coding zawodzi

Opowiem ci o rozmowie, którą odbyłem w zeszłym tygodniu z jednym założycielem startupu. Dostarczał funkcje z niewiarygodną prędkością — trzy razy szybciej niż w jego poprzedniej firmie. „Robimy vibe coding na okrągło" — powiedział z dumą. Potem wspomniał, że jego system uwierzytelniania został wykorzystany dwukrotnie w ciągu ostatniego miesiąca.

To nie jest przypadkowy zbieg okoliczności.

Pułapka prędkości

Oto niewygodna prawda, o której nikt nie mówi na konferencjach dla programistów AI: ten niesamowity wzrost szybkości ma swoją cenę w postaci mierzalnego podatku od błędów. Badania konsekwentnie pokazują, że około 45% kodu generowanego przez AI zawiera luki bezpieczeństwa. Nie drobne problemy — prawdziwe, wykorzystywalne błędy, które mogą narazić dane użytkowników, ominąć uwierzytelnianie lub stworzyć ścieżki dla atakujących.

Mechanizm nie polega na tym, że AI produkuje zły kod. Mechanizm polega na tym, że vibe coding usuwa bramki, które wyłapują zły kod.

Kiedy piszesz prompt dla agenta AI i wysyłasz wynik bez dokładnego przeczytania, omijasz cały swój SDLC. Bez przeglądu specyfikacji. Bez audytu bezpieczeństwa. Bez weryfikacji pokrycia testami. Bez dokumentacji. Usuwasz dokładnie te punkty kontrolne, które istnieją, aby chronić użytkowników i twoją reputację.

Gdzie AI się myli (przewidywalnie)

Oto co sprawia, że to jest szczególnie niebezpieczne: AI nie zawodzi losowo. Defekty koncentrują się dokładnie w najgorszych miejscach.

Luki typu cross-site scripting pojawiają się 2,74 razy częściej niż w kodzie pisanym przez ludzi. Błędy logiczne występują 1,75 razy częściej niż baseline. To nie są kwestie estetyczne ani problemy z obsługą przypadków brzegowych — to luki, które mają znaczenie dla uwierzytelniania, przetwarzania płatności i każdego systemu obsługującego niezaufane dane wejściowe.

Niezależna telemetria bezpieczeństwa potwierdza ten wzorzec. Raporty branżowe przypisują teraz rosnącą liczbę luk bezpośrednio zwiększonej adopcji generatywnej AI w procesach deweloperskich. Severity tych luk również rośnie.

Trzy właściwości, które czynią to niebezpiecznym

To nie jest tylko o indywidualnych błędach. Problem się komponuje z powodu tego, jak agenci AI fundamentalnie działają:

Prędkość wyprzedza przegląd. Agent może wygenerować tysiąc linii kodu w sekundach. Człowiek recenzent nie jest w stanie w sensowny sposób sprawdzić ten kod w tym samym tempie. To tworzy strukturalną presję na pominięcie kroku przeglądu.

Niedeterminizm udaremnia reprodukcję. Ten sam prompt może wygenerować różne wyniki. Ten bug, który zauważyłeś? Powodzenia z odtworzeniem dokładnie tej wersji kodu, która go spowodowała. To sprawia, że debugging to ruchomy cel, a ślady audytu są ненадёжные.

Presja kosztowa zachęca do skrótów. Tokeny AI kosztują pieniądze. Uruchamianie kompleksowych testów kosztuje więcej tokenów. Presja ekonomiczna pcha w kierunku cięcia weryfikacji — dokładnie odwrotnie niż wymaga bezpieczeństwo.

Prawdziwe szkody, prawdziwe przykłady

Możesz myśleć, że to jest teoretyczne. Nie jest.

Badacze bezpieczeństwa udokumentowali złośliwe oprogramowanie generowane przez AI z krytycznymi błędami implementacyjnymi — kod, który miał być niebezpieczny, ale zawiódł w podstawowej implementacji kryptograficznej. Co bardziej niepokojące: dobrzy programiści wysłali do produkcji frameworki z lukami umożliwiającymi omijanie uwierzytelniania, które zostały wygenerowane przez narzędzia AI. W obu przypadkach porażka nie wynikała ze złych intencji ani niekompetencji — polegała na traktowaniu outputu AI jako gotowego do produkcji bez normalnej ścieżki weryfikacji.

Ścieżka pośrodku

Nie mówię, żeby nie używać narzędzi do kodowania AI. To byłoby jak doradzanie programistom w 2015 roku, żeby unikali GitHuba, bo hosting kodu może umożliwić złe praktyki. Zyski produktywności są realne i technologia nie zniknie.

Ale musimy być szczerzy co do tego, gdzie przesuwają się bottlenecky.

Wygrana w throughput z kodowania AI jest autentyczna. Ale przesuwa bottleneck z pisania na weryfikację. Jeśli nie uwzględniasz tej zmiany, akumulujesz technical debt szybciej niż dostarczasz funkcje.

Oto jak to wygląda w praktyce:

Traktuj AI jako szybkiego stażystę, nie senior engineera. Junior developer może szybko generować kod. Senior developer może ci powiedzieć, dlaczego ten kod jest bezpieczny do wysłania. Narzędzia AI są świetne w tym pierwszym. Potrzebujesz ludzi do tego drugiego.

Zaimplementuj kontrakt PR. Każdy pull request powinien dokumentować: Jaki był zamiar? Jakie dowody potwierdzają, że działa? Jaki jest poziom ryzyka? Czy AI zostało użyte do wygenerowania tego, i jeśli tak, to gdzie? To wymusza odpowiedzialność, którą vibe coding usuwa.

Zdecentralizuj krytyczne sprawdzenia bezpieczeństwa. Nie ufaj middleware'owi uwierzytelniania jako twojej jedynej bramce. Implementuj sprawdzenia autoryzacji bezpośrednio w route handlerach. Przenieś logikę krytyczną dla bezpieczeństwa poza pojedyncze punkty awarii, które narzędzia AI mogą subtelnie źle skonfigurować.

Zarezerwuj vibe coding dla odpowiednich kontekstów. Szkielet CLI? Prototypowanie UI? Eksploracja podejść do optymalizacji przed zobowiązaniem do architektury? Idealne przypadki użycia. Wysyłanie bezpośrednio do produkcji z obsługą niezaufanych danych wejściowych? Tam potrzebujesz specyfikacyjnego podejścia z bramkami przeglądu.

Zainwestuj w threat modeling przed merge. Każda ścieżka kodu obsługująca niezaufane dane wejściowe potrzebuje ludzkiego przeglądu threat model przed dotarciem do produkcji. Nie opcjonalne. Nie do pominięcia, gdy masz opóźnienia.

Właściwa zasada

Linia między „bezpieczne do vibe" a „musisz inżynierować" nie jest ostra. Przesuwa się wraz z poprawą modeli i wraz ze wzrostem złożoności twojego systemu. Zasada nie może brzmieć „nigdy nie używaj AI do kodowania." Zasada musi brzmieć: „wiedz, w jakim trybie jesteś i ustalaj bramki według stakes."

Ale tutaj wszyscy się zgadzają: gdy twój bug może skrzywdzić kogoś innego, prompt-and-ship to regresja. Gdy twój kod obsługuje prawdziwe pieniądze, prawdziwe dane osobowe lub prawdziwe decyzje dotyczące bezpieczeństwa, zyski prędkości vibe codingu nie mogą uzasadnić usunięcia infrastruktury weryfikacyjnej chroniącej twoich użytkowników.

Programiści i zespoły odpowiedzialnie wysyłający kod generowany przez AI nie poruszają się wolniej. Poruszają się ze świadomością, gdzie teraz znajduje się bottleneck weryfikacji — i uczciwie na to budżetują.

Twoi użytkownicy liczą na to, że złapiesz to, co AI przegapi.

W NameOcean wierzymy, że potężne narzędzia zasługują na przemyślaną implementację. Niezależnie od tego, czy rejestrujesz domain dla swojego następnego projektu, czy wdrażasz kod z asystą AI, fundamenty odpowiedzialnego inżynierowania mają zastosowanie. Buduj szybko, ale buduj dobrze.