Vibe Coding to pułapka - Dlaczego oprogramowanie budowane przez AI nadal potrzebuje inżynierów

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 niesinż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. Teraz w tej chwili padają 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.

Nie jest nią. A 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. 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. Sekrety JWT zakodowane na stałe w przykładach zmiennych środowiskowych zacommitowanych do publicznych repozytoriów. 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. Nie dlatego, że testy są trudne, ale dlatego, że 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. Konkurent rejestruje się i odkrywa, że endpointy API zwracają dane innych użytkowników, bo sprawdzanie autoryzacji było po stronie frontendowej, nie na serwerze. 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 - nie czyni złych inżynierów zbędnymi

To jest twierdzenie, które narracja vibe coding odwraca. Narzędzia są prawdziwe i wzrost produktywności jest prawdziwy. W webvise używamy Claude Code, Cursor i orkiestracji multi-agent przy każdym projekcie, który dostarczamy. Senior inżynier z Claude Code dostarcza w godzinach to, co wcześniej zajmowało 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 nie leży w narzędziu - lecz w tym, co inżynier wnosi do narzędzia. Podstawy inżynierskie nie polegają na ręcznym pisaniu kodu. 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. Vibe coder klika akceptuj i to 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. RODO nie zwalnia użytkownika z odpowiedzialności, bo nie przeczytał własnego kodu przetwarzania danych.

Fala aplikacji SaaS generowanych przez AI z lat 2025-2026 wyprodukowała przewidywalną klasę startupów: 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 nie są oszustami - 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łądem jest traktowanie podłogi jako sufitu - zakładanie, ż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.

W webvise używamy development wspomaganego AI przy każdym projekcie - Claude Code, Cursor, potoki multi-agent - ale 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 tym, jak pracujemy.