Opublikowano
·
5 min
czytania
Jak rozpoznać aplikację webową napisaną przez AI (vibe coding)
Aplikacje webowe tworzone przez AI często działają w demie, a zawodzą w realnym użyciu. Oto sygnały w interfejsie, danych i bezpieczeństwie, które to zdradzają, oraz co zrobić, gdy widzisz je u siebie.
Podsumowanie dla zabieganych
Vibe coding aplikacji to zlecenie jej budowy AI, zwykle bez przeglądu przez programistę.
Strona prezentuje informacje. Aplikacja trzyma konta, uprawnienia i dane, więc psuje się w gorszy sposób.
Widoczne sygnały to brak stanów pustych i błędów, brak reakcji na kliknięcie i layout, który rozjeżdża się na telefonie.
Najdroższe sygnały są niewidoczne: walidacja tylko w przeglądarce, sprawdzanie uprawnień po stronie frontendu, klucze w kodzie klienta.
Większość z tego sprawdzisz sam w dziesięć minut. Pokazujemy jak.
Czym jest vibe coding, gdy powstaje aplikacja, a nie strona
Vibe coding to opisanie narzędziu AI, czego chcesz, i pozwolenie mu wygenerować produkt. Lovable, v0 i Cursor robią to tak szybko, że działająca aplikacja może powstać przed obiadem.
Strona i aplikacja webowa psują się inaczej. Strona prezentuje informacje. Aplikacja przechowuje stan: ludzie się logują, wprowadzają dane, zmieniają je i zakładają, że jutro nadal tam będą. Dochodzą do tego uprawnienia, walidacja, obsługa błędów i kilka osób pracujących jednocześnie. Nic z tego nie widać w demie. AI buduje ścieżkę, którą opisałeś. Reszta czeka na osobę, która otworzy aplikację po Tobie.
Używamy AI codziennie i polecamy je do prototypów. Problem zaczyna się wtedy, gdy wygenerowany prototyp zostaje potraktowany jak produkt.
Uwaga prawna
Jesteśmy agencją projektową, nie kancelarią prawną. Ten artykuł ma charakter wyłącznie informacyjny i edukacyjny i nie stanowi porady prawnej. Przepisy się zmieniają, a ich zastosowanie zależy od Twojej sytuacji, dlatego sprawdź oficjalne wytyczne podlinkowane poniżej lub skonsultuj się z prawnikiem. Nie ponosimy odpowiedzialności za decyzje podjęte na podstawie tego artykułu.
Dlaczego w aplikacji stawka jest wyższa
Słaba strona kosztuje Cię zapytanie. Słaba aplikacja kosztuje pracę, którą ktoś w niej wykonał. Klient traci dwadzieścia minut wpisywania w formularz, który po cichu nie zapisał danych, rezerwacja tworzy się dwa razy, albo dwie osoby nadpisują sobie zmiany i nikt nie wie, która wersja jest prawdziwa.
Jeśli aplikacja przechowuje dane klientów, masz też obowiązki wynikające z RODO, które obowiązuje od maja 2018 roku. Te obowiązki leżą po Twojej stronie, a nie po stronie narzędzia, które wygenerowało kod. Jeśli nie jesteś pewien, co dotyczy Twojej sytuacji, sprawdź wytyczne Komisji Europejskiej o ochronie danych.
Sygnały w interfejsie
Brak stanów pustych, ładowania i błędu. Z danymi demo aplikacja wygląda dobrze, bez nich jest pusta, więc nowy użytkownik trafia na biały ekran i nie wie, co dalej.
Akcje bez żadnej reakcji. Klikasz Zapisz, nic się widocznie nie zmienia, więc klikasz drugi raz.
Dwa komponenty do jednego zadania. Dwa wybieraki daty, trzy style przycisków, okna dialogowe działające inaczej na każdym ekranie.
Formularze, które gubią wpisane dane. Błąd walidacji czyści pola albo wyjście ze strony kasuje wszystko bez ostrzeżenia.
Tabele i okna, które rozjeżdżają się na telefonie. Szerokie tabele wychodzą za ekran, modale są w połowie niewidoczne, a główny przycisk jest poza zasięgiem.
Słaby kontrast na gęstych ekranach. Szary tekst na szarym panelu nie spełnia minimum 4,5 do 1 z wytycznych WCAG o kontraście, co w aplikacji używanej godzinami boli bardziej niż na stronie.
Sygnały w działaniu i danych
Walidacja tylko w przeglądarce. Interfejs blokuje błędne dane, API je przyjmuje, a baza zapełnia się śmieciami.
Ciche błędy. Żądanie się nie udaje, a ekran zachowuje się, jakby wszystko przeszło.
Brak cofania i potwierdzeń. Usuń kasuje rekord natychmiast, bez archiwum i bez drogi powrotnej.
Nieaktualne dane po edycji. Zmieniasz wartość, a lista pokazuje starą do przeładowania strony.
Odświeżenie i przycisk wstecz psują widok. Stan żyje tylko w pamięci, więc przeładowanie głębokiego ekranu czyści go albo wyrzuca błąd.
Duplikaty po podwójnym kliknięciu. Jedno wysłanie tworzy dwa rekordy, bo nic nie pilnuje drugiego żądania.
Sygnały w bezpieczeństwie i dostępach
Za sprawdzenie tych warto zapłacić, zanim wpuścisz prawdziwych użytkowników.
Uprawnienia sprawdzane tylko na frontendzie. Przycisk admina jest ukryty, ale endpoint za nim odpowiada każdemu, kto wywoła go bezpośrednio.
Klucze w kodzie klienta. Klucze API i dane serwisowe siedzą w paczce przeglądarki, widoczne dla każdego, kto otworzy narzędzia deweloperskie.
Każdy użytkownik faktycznie adminem. Jedna rola, jeden zestaw praw, brak rozdziału między Twoim zespołem a klientami.
Brak limitów żądań. Logowanie i reset hasła przyjmują nieograniczoną liczbę prób.
Pliki przyjmowane bez kontroli. Dowolny typ, dowolny rozmiar, wrzucone do publicznego katalogu.
OWASP Top 10 opisuje kategorie, w które wpadają te błędy, i jest sensowną listą do przekazania programiście.
Sprawdź swoją aplikację w dziesięć minut
Nie potrzebujesz do tego wiedzy technicznej:
Wyślij główny formularz pusty, a potem wyślij poprawny dwa razy pod rząd. Chcesz zobaczyć jasny błąd i jeden rekord.
Wyłącz wifi w trakcie akcji i sprawdź, co aplikacja Ci powie.
Odśwież stronę na głębokim ekranie, a potem kliknij wstecz.
Otwórz aplikację na telefonie i wykonaj jedno prawdziwe zadanie od początku do końca.
Zaloguj się jako użytkownik z ograniczonymi prawami i wpisz adres panelu admina wprost w przeglądarkę.
Przepuść główny ekran przez PageSpeed Insights od Google i porównaj wynik z Core Web Vitals.
Jeśli trzy z tych prób wypadną źle, problem jest strukturalny, a nie kosmetyczny.
Potrzebujesz profesjonalnej pomocy?
Co zrobić, gdy widzisz te sygnały
Podziel to na trzy poziomy.
Problemy powierzchniowe, czyli stany, reakcje interfejsu, kontrast i layout mobilny, to skupiona praca projektowa i frontendowa. Problemy z danymi i uprawnieniami wymagają programisty, który przeniesie walidację i kontrolę dostępu na serwer. Zajmie to więcej czasu, ale to nie jest przebudowa. Najtrudniejszy przypadek to fundamenty: brak realnego modelu danych, brak warstwy logowania, brak możliwości dodania drugiego typu użytkownika. Wtedy przebudowa zwykle wychodzi taniej niż łatanie przez kolejne lata.
Jedna szczera uwaga. Framer i Webflow, narzędzia w których budujemy, są znakomite do stron i złym wyborem do prawdziwej aplikacji. Jeśli Twój projekt potrzebuje kont, roli i przechowywanych danych, powiemy to od razu, zamiast naciągać kreator stron.
Najczęściej zadawane pytania
Czy vibe coding jest w porządku do MVP?
Tak, do sprawdzenia pomysłu z osobami, które wiedzą, że patrzą na prototyp. Przestaje być w porządku w momencie, gdy pojawiają się prawdziwi klienci i prawdziwe dane.
Czym aplikacja z vibe codingu różni się od takiej strony?
Wady strony są w większości widoczne, w odstępach, typografii i kontraście. Najgorsze wady aplikacji pozostają ukryte, dopóki ktoś nie straci danych albo nie trafi na ekran, którego nigdy nie powinien zobaczyć.
Da się naprawić taką aplikację, czy trzeba ją zbudować od nowa?
To zależy od modelu danych i warstwy logowania. Jeśli te dwie rzeczy są zrobione porządnie, resztę da się naprawić. Jeśli w praktyce ich nie ma, przebudowa jest zwykle szybsza i tańsza.
Czy taka aplikacja może narazić dane klientów?
Może. Uprawnienia sprawdzane tylko na frontendzie i klucze zostawione w kodzie klienta zdarzają się w generowanych aplikacjach często, a oba ujawniają dane. Zleć przegląd kontroli dostępu przed uruchomieniem.
Czy zbudować aplikację w Framerze albo Webflow?
Nie. Użyj ich do strony marketingowej, a samą aplikację zbuduj na platformie zaprojektowanej do kont, roli i przechowywania danych.
