Dlaczego wszyscy jarają się vibe codingiem i czemu to może skończyć się pożarem na produkcji
Scenariusz jest prosty. Programista otwiera czat z AI i pisze: „zrób mi apkę jak popularny komunikator, ale prostszą, na iOS i Androida”. Po chwili dostaje gotowy projekt z ekranami, flowami i logiką biznesową. Kompiluje, działa, demo wygląda świetnie. I już, bach, ląduje to na produkcji.
Brzmi jak marzenie founderów i liderów technicznych. Szybki time‑to‑market, małe koszty, brak konieczności budowania dużego zespołu mobilnego. Można mieć MVP zanim skończy się kawa. Wszystko jest super, dopóki nie dzwoni dział bezpieczeństwa… albo klient, że płatność przeszła dwa razy, a adres dostawy wyleciał w logach na serwer.
Coraz częściej pojawiają się więc pytania w stylu „is vibe coding safe for production?” czy „secure AI‑generated mobile apps”. I wcale nie chodzi o panikę, tylko o bardzo przyziemne problemy. AI‑agenci faktycznie potrafią wygenerować całe ekrany, przepływy i sporą część logiki dla aplikacji mobilnych – natywnych na iOS i Androida, ale też cross‑platform.
Problem w tym, że modele nie żyją w realnym świecie produkcji. One sklejają kod z przykładów. Trochę jak przy planowaniu wyjazdu do egzotycznego kraju na podstawie Instagrama: na zdjęciach jest raj, a potem okazuje się, że w sezonie jest 40 stopni, deszcze monsunowe i ceny hoteli z kosmosu. Rozsądny podróżnik zerknie najpierw na serwisy z danymi pogodowymi, bezpieczeństwem i cenami, choćby na analizy klimatu i kosztów życia w serwisach w stylu HikersBay, albo na poradnik Tajlandia w czerwcu: który region wybrać, aby złapać najwięcej słońca?.
Z vibe codingiem jest podobnie. Zamiast wierzyć w marketingowe slajdy, warto znać realne ograniczenia AI‑kodowania na mobile, typowe wpadki bezpieczeństwa i jakości oraz mieć pod ręką checklistę, która odsieje „ładne demo” od „gotowe na produkcję”.
Najczęstsze miny w AI‑generowanych apkach: od dziurawej walidacji po dramat offline
Brak walidacji danych wejściowych
AI bardzo lubi generować formularze, ale dużo mniej przejmuje się tym, co użytkownik w nie wpisze. Efekt? Pola bez limitu długości, brak sprawdzania formatu e‑maila, numery telefonu „jakiekolwiek cyfry”, pola kwoty bez kontroli zakresu. W najlepszym razie kończy się to crashami. W gorszym – wstrzyknięciem dziwnego tekstu prosto do logów lub backendu, gdzie błąd może się rozlać dalej.
Wyobraź sobie prosty ekran zamówienia jedzenia. Użytkownik wpisuje adres, kwotę napiwku i potwierdza. Bez walidacji można wstawić kwotę ujemną, gigantyczną liczbę albo adres z losowymi znakami. Nagle pojawiają się nadużycia, a system księgowy widzi rzeczy, których nie powinien.
Insecure auth flow
Modele lubią podglądać stare snippet’y z sieci. Raz trafią na nowoczesne wzorce, innym razem na poradnik sprzed siedmiu lat. Rezultat bywa kreatywny: tokeny twardo zakodowane w kodzie, brak mechanizmu odświeżania, żadnej reakcji na wygaśnięcie sesji, dane sesyjne przechowywane w pamięci urządzenia w sposób, który woła o pomstę do nieba.
Na poziomie demo to nie przeszkadza. Na poziomie prawdziwych użytkowników to już prosta droga do przejęcia kont, zwłaszcza jeśli aplikacja korzysta z tych samych tokenów w kilku różnych miejscach bez jasnych ograniczeń dostępu.
Niewidzialne dziury w komunikacji z API
Komunikacja sieciowa w vibe‑coded apps często jest „na skróty”. Brakuje TLS pinningu, obsługa błędów sieci ogranicza się do „print(error)” w konsoli, a odpowiedzi z API potrafią wylądować w logach w całości, razem z danymi użytkowników. Błędy dla użytkownika? Często jeden komunikat na wszystko: „coś poszło nie tak”. Świetnie, tylko co?
Offline? Jaki offline?
AI nie jeździ metrem, nie lata samolotem, nie gubi zasięgu na wsi. Więc domyślnie zakłada, że internet jest zawsze. Tymczasem w realu użytkownik odrywa się od sieci w połowie płatności albo próbuje coś zrobić w trybie samolotowym. Bez przemyślanej obsługi offline aplikacja po prostu się wysypuje lub wisi w nieskończoność.
Problemy z uprawnieniami
AI chętnie dodaje prośby o dostęp do lokalizacji, aparatu, plików – na wszelki wypadek. Użytkownicy widzą to i myślą: „po co ta aplikacja do zamawiania jedzenia chce dostęp do zdjęć?”. Sklepy z aplikacjami też są coraz bardziej wyczulone. Efekt: spadek zaufania, gorsze oceny, a czasem nawet odrzucenie wersji z recenzji.
Badania nad bezpieczeństwem vibe‑coded apps pokazują tu bolesną prawidłowość. Błędy są powtarzalne, nudne, takie, których doświadczony senior nie przepuściłby w code review. Model ich zwyczajnie nie widzi, bo jego zadanie to „napisać coś, co wygląda jak kod”, a nie „zbudować bezpieczny produkt”.
To trochę jak próba odtworzenia ulicznego jedzenia w domu na podstawie jednego zdjęcia. Niby podobne, ale brakuje sosu rybnego, prażonej cebulki i połowy przypraw. Jeśli ktoś czytał tekst Tajskie jedzenie na wynos: co przywieźć z Tajlandii, by w Polsce odtworzyć uliczne smaki, to wie, że w detalu jest cały smak. W kodzie mobilnym w detalu jest całe bezpieczeństwo.
A do tego dochodzi jeszcze jedna, mniej spektakularna, ale zabójcza rzecz: utrzymanie i rozwój tego wszystkiego w dłuższej perspektywie.
Kod z generatora dziś, dług techniczny jutro: co mówią eksperci o utrzymaniu vibe‑coded apps
Founders i liderzy techniczni zwykle myślą w perspektywie 6–24 miesięcy. Pytanie nie brzmi tylko „czy dowieziemy MVP do końca sprintu?”, ale też „kto to będzie rozwijał za rok i za ile?”. Z punktu widzenia utrzymania vibe‑coded apps mają kilka poważnych grzechów.
Po pierwsze, czytelność. Kod generowany przez AI bywa pełen powtórzeń, bez spójnej architektury, z dziwną mieszanką stylów, frameworków i bibliotek. Granice między warstwami UI, logiką biznesową i siecią zacierają się. Ekran logowania potrafi jednocześnie pobierać dane z API, trzymać stan sesji i obsługiwać walidację formularza.
Po drugie, brak testów. Modele rzadko generują sensowny zestaw testów jednostkowych czy integracyjnych. Jeśli już, to są to przykłady do dokumentacji, a nie realna siatka bezpieczeństwa. Przy pierwszej poważniejszej zmianie wszystko trzeba dopisać ręcznie.
Po trzecie, brak dokumentacji „dlaczego”. Nawet jeśli generator doda komentarze, zwykle opisują one „co” kod robi, a nie „po co” coś jest zrobione w ten, a nie inny sposób. Nowa osoba w zespole musi zgadywać intencje. Trochę jak geolog próbujący przewidzieć trzęsienia ziemi na podstawie jednego wykresu. Nieprzewidywalność rośnie, co świetnie obrazuje tekst Trendy 2026: czy naprawdę rośnie liczba silnych trzęsień ziemi na świecie? – tam chodzi o ziemię, tu o kod, ale mechanizm jest podobny: im system bardziej złożony, tym trudniej przewidzieć, gdzie coś pęknie.
Dołóżmy do tego rotację w zespole. Nowy developer otwiera plik i widzi ścianę kodu. Na code review wszyscy pytają: „kto to pisał?”. Cisza. W końcu ktoś rzuca: „agent AI”. I tak zaczyna się dwugodzinne code review, w którym nikt nie przyznaje się do autorstwa, a wszyscy próbują zgadnąć, co autor‑model miał na myśli.
To trochę jak planowanie sezonowej aplikacji turystycznej bez sprawdzenia klimatu rynku. Rozsądny produktowiec będzie opierał się na danych: statystykach użycia, analizie zachowań, przewidywanych warunkach działania – tak jak podróżnik przed wyjazdem sprawdzi w serwisach typu HikersBay klimat, bezpieczeństwo i koszty, a nie tylko jeden entuzjastyczny post na socialach.
Im więcej szybkich łatek z generatora, tym większzy dług techniczny i ryzyko, że za rok rozwój produktu stanie w miejscu, bo każdy nowy feature wymaga przepisywania połowy aplikacji.
Checklist dla ostrożnyh: jak przeglądać AI‑wygenerowany kod mobilny przed produkcją
Żeby nie kończyć czarnym scenariuszem, przejdźmy do konkretów. Oto praktyczna lista kontrolna dla founderów i liderów, którzy chcą korzystać z vibe codingu, ale bez brawury.
- Architektura i czytelność
Sprawdź, czy kod jest podzielony na sensowne moduły. Czy nie ma gigantycznych plików po kilka tysięcy linii. Czy nazwy klas, metod i plików coś mówią, czy brzmią jak losowe słowa. Jeśli ciężko prześledzić przepływ danych między ekranami, to sygnał ostrzegawczy. - Bezpieczeństwo i prywatność
Przejrzyj wszystkie miejsca, gdzie przetwarzane są dane wrażliwe: logowanie, płatności, dane osobowe. Upewnij się, że w repozytorium nie ma twardo zakodowanych kluczy API, tokenów, haseł. Włącz statyczną analizę bezpieczeństwa – narzędzia z tej kategorii wyłapią sporo oczywistych dziur zanim zrobi to ktoś z zewnątrz. - Walidacja danych i obsługa błędów
Każde pole formularza powinno mieć jasne zasady: format, długość, zakres. Przy błędach użytkownik musi dostać konkretny komunikat, a aplikacja nie może eksplodować przy pierwszym nullu. Zmiana perspektywy na „co może pójść źle” bywa tu bardzo zdrowa. - Autoryzacja i sesje
Zadaj kilka prostych pytań: gdzie są przechowywane tokeny? Czy użytkownik może się wylogować i czy to faktycznie czyści sesję? Co się dzieje po wygaśnięciu tokenu – aplikacja odświeża go poprawnie, czy po prostu przestaje działać? Jak wygląda ochrona przed przechwyceniem sesji na urządzeniu? - Offline i słaby internet
Przetestuj aplikację w trybie samolotowym. Przerwij połączenie w połowie płatności. Wejdź z powrotem do aplikacji po kilku godzinach bez sieci. Vibe‑coded apps bardzo często nie przechodzą takich scenariuszy, bo model zakłada stabilne łącze i zero niespodzianek. - Testy
Nawet jeśli AI nie wygenerowało testów, dopisz przynajmniej minimalny zestaw testów jednostkowych i end‑to‑end dla kluczowych ścieżek: logowania, płatności, krytycznych formularzy. AI może pomóc także tu, ale to człowiek powinien zdecydować, co dokładnie testować. - Threat modeling w wersji „light”
Weź kartkę i wypisz, które dane w aplikacji są najcenniejsze i kto mógłby chcieć je przejąć. Potem przejdź po ekranach i spróbuj znaleźć potencjalne „drogie ucieczki” tych danych. To uproszczona forma oceny ryzyka, ale dla wielu projektów zupełnie wystarczająca.
Przed udostępnieniem aplikacji użytkownikom warto więc ocenić ryzyko i „warunki na miejscu” równie starannie, jak sprawdza się kierunek wakacji w serwisach w rodzaju HikersBay czy poprzez poradniki podróżnicze pokroju Tajlandia w czerwcu: który region wybrać, aby złapać najwięcej słońca?. Dobre decyzje biorą się z danych, nie z vibe’u.
Podsumowując: AI‑wygenerowany kod mobilny może trafić na produkcję, ale dopiero po przejściu takiego filtra. Rozsądne podejście to traktowanie agenfów AI nie jak samodzielnych programistów, lecz jak bardzo szybkich stażystów, których praca zawsze trafia na biurko seniora. Vibe coding jest świetny do prototypów i piaskownicy. Natomiast gdy w grę wchodzą prawdziwi użytkownicy, lepiej, żeby kod był przygotowany i przetestowany, a nie jechał na produkcję na spontanie niczym bilet last minute bez sprawdzenia szczegółów podróży.