Dlaczego oprogramowanie generowane przez AI nadal wymaga przeglądu inżynierskiego

Andrej Karpathy ukuł termin vibe coding w lutym 2025 roku, aby opisać tryb tworzenia oprogramowania, w którym opisuje się to, czego się chce, akceptuje to, co AI produkuje, i nie czyta kodu. Jego ujęcie było łaskawe: weekendowy tryb hobbystyczny dla osobistych projektów. To, co nastąpiło później, takie nie było. Do połowy 2025 roku fala nieinżynierów opublikowała produkcyjne aplikacje SaaS zbudowane całkowicie w Cursor, Replit Agent, v0 i bolt.new, nigdy nie rozumiejąc, co zbudowali. Aplikacje wyglądały dobrze w demonstracjach. Niektóre zawodzą w produkcji.

Czym naprawdę jest vibe coding

Oryginalne sformułowanie Karpathy'ego jest precyzyjne: jest się «w strefie», mówi się AI, czego się chce, ona produkuje kod, przeważnie klika się akceptuj i nie rozumie się w pełni, co działa. Przyznał to wprost: «Nie czytam kodu, po prostu wibruję z nim.» Dla osobistego narzędzia lub jednorazowego prototypu jest to w porządku. Vibe coder nie udaje inżyniera. Problem polega na tym, że ekosystem narzędzi: «wyślij swój startup w weekend» Replit Agenta, wdrożenia jednym kliknięciem v0, błyskawiczna generacja full-stack bolt.new, zapakował ten tryb jako uzasadnioną ścieżkę do oprogramowania produkcyjnego.

Wynikający z tego dług techniczny jest jakościowo różny od zwykłego złego kodu.

Dlaczego vibe code jest gorszy niż źle napisany ręcznie kod

Gdy junior developer pisze zły kod, rozumie, co zamierzał zrobić. Można z nim usiąść, prześledzić logikę i to naprawić. Gdy AI generuje zły kod, którego operator nigdy nie czytał, nie ma modelu mentalnego do odtworzenia. Developer nie może wyjaśnić, dlaczego uwierzytelnianie jest zbudowane tak, jak jest, bo nigdy nie czytał uwierzytelniania. Nie może powiedzieć, która biblioteka zewnętrzna obsługuje płatności, bo zaakceptował plik bez otwierania go. Kod to czarna skrzynka, którą posiada, ale nad którą nie może rozumować.

Wzorce awarii, które konsekwentnie obserwujemy w aplikacjach produkcyjnych generowanych przez AI:

• Obejścia uwierzytelniania wbudowane w scaffold; sekrety JWT obecne w przykładach zmiennych środowiskowych zacommitowanych do publicznych repozytoriów. To częste ustalenia w przeglądach kodu projektów wspomaganych AI bez nadzoru inżynierskiego. Kod uwierzytelniania generowany przez AI często kopiuje wzorce z danych treningowych bez rozumienia modelu bezpieczeństwa. Bezpieczeństwo na poziomie wierszy wyłączone «tymczasowo» podczas development, pozostawione w produkcji. Sprawdzanie ról porównujące literały łańcuchów, które psuje się w momencie zmiany nazwy pola.
• Brak obsługi błędów poza ścieżką sukcesu. AI napisała przypadek sukcesu. Co się dzieje, gdy dostawca płatności zwraca 402? Co się dzieje, gdy połączenie z bazą danych spada w trakcie transakcji? W aplikacjach vibe-coded odpowiedzią jest zazwyczaj nieobsłużone odrzucenie promise, które pojawia się jako pusty ekran.
• Uzależnienie od dostawcy na wzorcach generowanych przez AI. Gdy AI wybrała konkretny sposób strukturyzacji modelu danych, vibe coder to zaakceptował. Teraz cała aplikacja jest zbudowana wokół tej struktury. Migracja z niej wymaga zrozumienia kodu, którego developer nigdy nie czytał.
• Brak testów. Vibe coder nigdy o nie nie prosił, a AI nie zaproponowała ich dobrowolnie. Gdy coś psuje się w produkcji, nie ma zestawu testów, który wykryje regresje w naprawie.

Przepaść między demo a produkcją

Narzędzia AI są naprawdę dobre w generowaniu kodu, który działa na ścieżce sukcesu z czystymi danymi wejściowymi, kooperatywną siecią i jednym równoległym użytkownikiem. To dokładnie warunki, w jakich działa demonstracja. Produkcja jest odwrotna: zniekształcone dane wejściowe, zerwane połączenia, równoległe zapisy, przypadki brzegowe, które nigdy nie zostały określone w prompcie.

Wzorzec rozgrywa się przewidywalnie. Aplikacja vibe-coded jest uruchamiana, wygląda dopracowanie, zdobywa wczesnych użytkowników. Następnie: użytkownik ze znakiem spoza ASCII w imieniu psuje zapytanie do bazy danych. Użytkownik mobilny z wolnym połączeniem wywołuje wyścig wątków w zarządzaniu stanem. Byliśmy świadkami scenariuszy, w których endpointy API ujawniają dane między kontami użytkowników z powodu nieobecnych lub niekompletnych sprawdzeń autoryzacji, będących konsekwencją wysyłania kodu, który nigdy nie był sprawdzany pod kątem egzekwowania po stronie serwera. Nie są to egzotyczne awarie. To podstawowa konsekwencja wysyłania kodu, którego się nigdy nie czytało.

AI czyni dobrych inżynierów lepszymi. Inżynierska wiedza podstawowa pozostaje niezbędna.

To jest twierdzenie, które narracja vibe coding odwraca. Narzędzia są prawdziwe i wzrost produktywności jest prawdziwy. webvise używa Claude Code, Cursor i orkiestracji multi-agent przy każdym dostarczanym projekcie. Doświadczeni inżynierowie korzystający z Claude Code zgłaszają znaczące oszczędności czasu przy zadaniach, które w innym przypadku zajęłyby dni. Te same narzędzia w rękach kogoś bez podstaw inżynierskich produkują demonstrację, która nie przeżyje pierwszego prawdziwego użytkownika.

Różnica tkwi w tym, co inżynier wnosi do narzędzia. Podstawy inżynierskie polegają na rozumieniu granic systemów, trybów awarii, modeli bezpieczeństwa i integralności danych. Inżynier korzystający z Claude Code czyta wygenerowany kod uwierzytelniania i rozpoznaje, gdy jest nieprawidłowy. Niedoświadczony programista akceptuje sugestię i ją wysyła.

Specyficzne ryzyko dla oprogramowania biznesowego

Konsumenckie aplikacje hobbystyczne mogą absorbować tryby awarii vibe codingu. Jeśli osobisty tracker finansów traci część danych, to irytujące. Jeśli B2B SaaS obsługujący dane klientów, przepływy płatności lub wewnętrzne przepływy pracy jest wysyłany z opisanymi powyżej problemami z uwierzytelnianiem i obsługą błędów, konsekwencje są prawne, umowne i reputacyjne. Odpowiedzialność wynikająca z GDPR stosuje się niezależnie od tego, jak kod został wygenerowany; kod przetwarzania danych wymaga przeglądu.

Kilka niedawnych produktów SaaS wspomaganych AI poszło podobną ścieżką: imponujące w demonstracji, zdobyły wczesnych klientów na obietnicę, następnie uderzyły w ścianę, gdy pierwszy potencjalny klient enterprise przeprowadził przegląd bezpieczeństwa lub gdy pierwszy dzień z dużym ruchem ujawnił brakującą obsługę błędów. Założyciele naprawdę nie wiedzieli, co zbudowali.

Na co zwrócić uwagę przy wyborze partnera development wspomaganego AI

Jeśli oceniają Państwo partnera development, który twierdzi, że używa narzędzi AI, proszę zadać następujące pytania:

• Czy przeprowadzają automatyczne testy kodu generowanego przez AI? Jeśli odpowiedzią jest «ufamy wynikom AI», należy odejść. Pokrycie testami to sposób na wykrycie obsługi błędów, którą AI pominęła.
• Czy przeprowadzają przeglądy bezpieczeństwa generowanego kodu uwierzytelniania i autoryzacji? Narzędzia AI kopiują wzorce auth z danych treningowych. Te wzorce zawierają prawdziwe podatności z prawdziwych baz kodu.
• Czy potrafią wyjaśnić architekturę tego, co zbudowali? Jeśli developer nie może przeprowadzić przez model danych i wyjaśnić, dlaczego jest zbudowany w taki sposób, nie zaprojektował go. Zaakceptował go.
• Czy wersjonują swoje prompty razem z kodem? Dyscyplina inżynierska stosowana do narzędzi AI oznacza traktowanie promptu jako części bazy kodu, a nie jednorazowego wejścia.
• Czy mają proces radzenia sobie z halucynacjami AI? Narzędzia AI pewnie generują nieprawidłowe wywołania API, przestarzałe metody i nieistniejące funkcje bibliotek. Doświadczony zespół ma dla tego pętlę przeglądów. Vibe coder odkrywa to w czasie wykonania.

Właściwe ujęcie: AI jako mnożnik siły, nie zastępstwo

Narracja vibe coding jest kusząca, bo jest częściowo prawdziwa. Narzędzia AI naprawdę obniżyły próg wejścia do tworzenia oprogramowania. Zmotywowany nieinżynier może w weekend dostarczyć działający prototyp. Jest to cenne dla walidacji, MVP, wewnętrznych narzędzi o niskiej stawce. Błąd polega na traktowaniu podłogi jako sufitu: zakładaniu, że ponieważ można coś uruchomić, można to uruchomić niezawodnie na skali, bezpiecznie i z możliwością utrzymania.

Inżynierowie, którzy najbardziej skorzystali z narzędzi do kodowania AI, to ci, którzy używają ich do eliminowania nudnych części inżynierii: boilerplate, scaffolding, powtarzalne refaktory, jednocześnie stosując swój osąd do części, które mają znaczenie: architektury, bezpieczeństwa, obsługi błędów i gotowości produkcyjnej. AI przyspiesza pracę. Inżynier zapewnia, że jest poprawna.

webvise używa developmentu wspomaganego AI przy każdym projekcie: Claude Code, Cursor, potoki multi-agent, z dyscypliną inżynierską, która sprawia, że wynik jest gotowy do produkcji. Jeśli budują Państwo oprogramowanie, które musi przetrwać prawdziwych użytkowników, prawdziwe przypadki brzegowe i prawdziwe wymagania bezpieczeństwa, porozmawiajmy o podejściu.