Pierwszy dzień aplikacji z vibe codingu to najlepsze demo, jakie kiedykolwiek zaprezentowałeś. Prompt zadziałał, ekrany są czyste, baza danych ma rekordy, a Ty opublikowałeś tweeta z nagraniem ekranu. Wielokrotnie przeżyliśmy ten dzień. Nie chcemy Ci go odbierać.
Jesteśmy tu, aby porozmawiać o drugim dniu, ponieważ nikt nie wspomina o nim w wątkach z launchu. Drugi dzień to moment, w którym prawdziwy użytkownik loguje się, robi coś, czego nie pomyślałeś, by przetestować, a Twoja aplikacja zderza się z przepaścią między „wygenerowaniem” a „zaprojektowaniem”.
Jak w rzeczywistości wygląda drugi dzień
Rzadko zaczyna się od całkowitego crashu. Zaczyna się od dziwnych rzeczy: formularza, który przyjmuje błędne dane, strony, która psuje się dla jednego konkretnego użytkownika, liczby, która jest błędna w sposób, którego nikt nie potrafi zreplikować. Wklejasz błąd do czatu. AI pewnie go naprawia. Poprawka psuje coś innego.
Witaj w grze w „uderz w kret” za pomocą promptów. Ponieważ AI naprawia objawy, a nie przyczyny, każda łatka ląduje na poprzedniej, a baza kodu cicho staje się tym, co twórcy nazywają „kodem Frankensteina”: łatką sprzecznych stylów, duplikujących się funkcji i splątanej logiki, gdzie zapytania do bazy danych żyją wewnątrz kodu interfejsu. Gdy projekt przekracza okno kontekstowe AI, model zaczyna zapominać o swoich wcześniejszych decyzjach i proponuje kod, który im zaprzecza. Nie utrzymujesz już aplikacji. Ty z nią negocjujesz.
Istnieje jeszcze okrutniejszy wariant: cicha awaria wdrożenia. Build Twojego hostingu kończy się niepowodzeniem z powodu drobnego błędu, aktywny URL nadal wyświetla starą wersję, a Ty – nie widząc zmian – mówisz AI, że jej poprawka „nie zadziałała”. W efekcie AI generuje zupełnie inne, bardziej złożone rozwiązanie problemu, który był już rozwiązany. Po kilku rundach masz przeładowaną wersję v5 kodu, którego wersja v1 była w porządku.
Część, której nie widać
Bieżnia debugowania jest przynajmniej widoczna. Problemy z bezpieczeństwem nie są, i to jest powód, dla którego jesteśmy tak surowi w kwestii aplikacji biznesowych.
Badania w tym zakresie są naprawdę niepokojące. Kod generowany przez LLM kompiluje się pomyślnie w około 90% przypadków, ale około 45% z niego zawiera podatności z listy OWASP Top 10 – m.in. możliwe do obejścia sprawdzanie logowania czy luki typu injection. Narzędzia AI optymalizują kod pod kątem działania demo, co prowadzi do przewidywalnych dróg na skróty: kontrola dostępu zaimplementowana w przeglądarce (gdzie każdy użytkownik może ją obejść, edytując stronę), szeroko otwarte uprawnienia bazy danych, aby nic nie zgłaszało błędów podczas budowy, oraz klucze API wpisane na sztywno w plikach, ponieważ twórca nie wie, czym jest zmienna środowiskowa. Te pliki trafiają następnie do publicznych repozytoriów GitHub, gdzie skanery poświadczeń znajdują je w mgnieniu oka.
Oto co sprawia, że jest to specyficznie problem drugiego dnia: podatna na ataki aplikacja działa idealnie. Nie ma komunikatu o błędzie treści „klient A może technicznie odczytać rekordy klienta B”. Dowiadujesz się o tym od użytkownika, jeśli masz szczęście, lub w znacznie gorszy sposób, jeśli go nie masz. A standardowa rada („po prostu to przetestuj!”) zderza się z rzeczywistością: nietechniczni twórcy testują „happy path”, podczas gdy awarie kryją się w przypadkach brzegowych – błędzie współbieżności czy zapomnianym przepływie resetowania hasła, którego AI nigdy nie wygenerowało, bo demo go nie wymagało.
Dług w utrzymaniu, którego nikt nie wycenia
Jeśli zsumujesz te mechanizmy przez miesiące, otrzymasz coś, co nazywamy „chwilówką długu technicznego”: natychmiastowe oprogramowanie teraz, procent składany później. Każdy skrót, który podjęło AI, jest przyszłą poprawką. Każda poprawka to kilka kolejnych kredytów i nieco więcej nadmiarowego kodu. Aktualizacje platformy psują rzeczy, których nie dotykałeś – długoterminowi twórcy na platformach prompt-to-app zgłaszają, że pobierają od klientów miesięczne opłaty za utrzymanie tylko po to, by radzić sobie z regresjami wynikającymi z samej platformy.
To gorzki żart w centrum tego wszystkiego: vibe coding obiecywał demokratyzację oprogramowania, a w przypadku aplikacji produkcyjnych głównie zdemokratyzował dług techniczny. Nietechniczny twórca kończy z dokładnie tym, czego chciał uniknąć dzięki AI – bazą kodu wymagającą oceny programisty – z tą różnicą, że teraz jest ona fundamentem jego biznesu, a on nie potrafi jej przeczytać.
Uczciwy wybór
Zatem co właściwie zrobić? Po wielu projektach i kilku bliznach uważamy, że sprowadza się to do wyboru między dwiema uczciwymi drogami, a „nieuczciwy środek” jest jedyną błędną odpowiedzią.
Droga pierwsza: naucz się utrzymywać kod. Jeśli kochasz to na tyle, by wejść głębiej, vibe coding stanie się realnym akceleratorem zamiast pułapką. Czytaj to, co pisze agent. Dowiedz się, co oznacza RLS, zanim wdrożysz aplikację, która na tym polega. Przejdź z narzędzi opartych wyłącznie na promptach na Cursor lub Replit, gdzie kod jest interfejsem i możesz wypracować realny osąd techniczny. Ta droga jest naprawdę świetna – to po prostu ścieżka, która wymaga miesięcy marszu, a udawanie, że na niej jesteś, podczas wysyłania nieprzeczytanego kodu do klientów, jest pułapką.
Droga druga: oprzyj niebezpieczne elementy na fundamencie, który nie jest generowany. Przyznaj szczerze, że Twoja aplikacja to narzędzie biznesowe – portal klienta, tracker, wewnętrzny CRM – i zauważ, że 80% z niej to dokładnie ta „hydraulika”, którą AI generuje najgorzej: autoryzacja, uprawnienia, resetowanie haseł, dostęp do danych. Buduj tę kategorię na platformie no-code, takiej jak Softr, gdzie hydraulika jest przetestowaną infrastrukturą, którą konfigurujesz wizualnie, a AI Co-Builder wciąż zapewnia Ci szybkość pierwszego dnia. Gdy chcesz dodać customowy sznyt, blok vibe-coding ogranicza generowany kod do pojedynczego komponentu, dzięki czemu AI może „dekorować dom”, nie ryzykując zawaleniem dachu. Drugi dzień na tej drodze to edycja, a nie wykopaliska archeologiczne – dlatego Softr zajmuje pierwsze miejsce w naszym rankingu portali dla klientów.
Korzystaj z vibe codingu do zabawnych rzeczy bez opamiętania – prototypy, zabawki, weekendowe eksperymenty to dokładnie to, w czym te narzędzia są genialne. Po prostu zdecyduj, zanim pojawią się prawdziwi użytkownicy, po której stronie rozwidlenia stoisz. Drugi dzień nie prosi o pozwolenie.