Naprawa aplikacji napisanej przez AI, zanim trafią do niej klienci
Prototyp zbudowany w Lovable, Bolt, v0 albo w edytorze z AI, jak Cursor, potrafi wyglądać jak gotowy produkt. Demo działa, ale pod spodem często brakuje rzeczy, które chronią dane i pieniądze klientów.
Autor: Szymon Łakomy. Aktualizacja:
Demo działa, ale klienci to inna sprawa
Coraz więcej firm i założycieli buduje prototypy narzędziami typu Lovable, Bolt czy v0 albo pisze je w edytorze z AI, jak Cursor. Potocznie mówi się na to vibe coding i do sprawdzenia pomysłu taki sposób pracy nadaje się dobrze. Kłopot zaczyna się, gdy prototyp ma przyjąć prawdziwych użytkowników, ich dane i płatności. Narzędzie robi to, o co je poproszono, a o kopie zapasowe, uprawnienia czy środowisko testowe rzadko ktoś prosi. Dlatego przed wpuszczeniem klientów taka aplikacja zwykle wymaga przeglądu.
Typowe luki w kodzie z narzędzi AI
| Problem | Czym grozi | Co robię |
|---|---|---|
| Klucze API i hasła w kodzie frontendu | każdy, kto otworzy narzędzia przeglądarki, może je odczytać i użyć | przenoszę je na serwer, a ujawnione klucze wymieniam na nowe |
| Baza bez reguł dostępu, na przykład wyłączone RLS w Supabase | zalogowany użytkownik może odczytać albo zmienić cudze rekordy | włączam zasady na poziomie wierszy i testuję je z kont różnych użytkowników |
| Brak walidacji danych na serwerze | formularz da się obejść i zapisać w bazie dowolne wartości | dodaję sprawdzanie danych po stronie serwera, nie tylko w przeglądarce |
| Płatności bez weryfikacji webhooków | zamówienie może zostać oznaczone jako opłacone bez zapłaty | weryfikuję powiadomienia z bramki na serwerze |
| Brak kopii i środowiska testowego | każda zmiana trafia prosto do klientów, a błąd może skasować dane | ustawiam kopie bazy i osobne środowisko do prób |
| Brak logów i monitoringu | o awarii dowiadujesz się od klienta | włączam rejestrowanie błędów i powiadomienia |
Konkretne ustawienia, na przykład reguły dostępu w Supabase, sprawdzam w dokumentacji danej usługi.
Weryfikacja płatności to osobny temat, który szerzej opisuję na stronie integracja płatności online.
Kolejność prac: od zagrożeń do porządku
- Przegląd kodu i konfiguracji. Repozytorium, baza, zmienne środowiskowe, hosting i bramka płatności. Potrzebuję dostępów, a nie tylko linku do demo.
- Lista ryzyk od krytycznych. Na górze to, co naraża dane klientów albo pieniądze, niżej rzeczy, które tylko utrudniają rozwój.
- Poprawki bezpieczeństwa. Klucze, reguły dostępu do bazy, walidacja na serwerze i weryfikacja płatności.
- Wdrożenia i kopie. Środowisko testowe, automatyczne kopie bazy i powtarzalny sposób publikowania zmian.
- Decyzja o dalszej drodze. Poprawiać kod stopniowo albo przepisać jego krytyczne części.
Porządkowanie kodu dobrze wygląda w raporcie, ale dopóki klucz do bazy leży w przeglądarce, nie jest priorytetem.
Długi, które wychodzą później
- Powielony kod. Ta sama logika w kilku miejscach, bo AI generowało ją od nowa przy kolejnych prośbach. Zmiana jednej reguły wymaga poprawek w kilku plikach.
- Zależności dodane i nieużywane. Biblioteki, które zostały po kolejnych próbach. Powiększają aplikację i listę rzeczy do aktualizowania.
- Brak testów. Poprawka w jednym miejscu może zepsuć coś w innym, a nikt tego nie zauważy przed klientem.
Łatanie czy nowy fundament
Zwykle wystarczą poprawki
Model danych ma sens, logowanie opiera się na sprawdzonej usłudze, a powielenia dotyczą kilku miejsc. Wtedy poprawiam kod stopniowo, a aplikacja działa dla klientów w trakcie.
Zwykle lepiej przepisać część
Struktura bazy nie pasuje do procesu, uprawnienia są rozrzucone po całym froncie albo nikt nie potrafi przeczytać wygenerowanego kodu. Wtedy przepisuję krytyczne części.
Decyzja nie musi dotyczyć całej aplikacji. Interfejs wygenerowany przez narzędzie można zachować, a przebudować tylko warstwę danych i uprawnień. Inny przypadek to program pisany latami przez ludzi, o którym piszę w poradniku modernizacja starego systemu firmowego. O systemach pod konkretną firmę piszę w dziale dedykowane oprogramowanie, a o tym, kiedy narzędzie bez kodu przestaje wystarczać, w poradniku no-code czy programista.
Najczęstsze pytania
Czy muszę przestać korzystać z Lovable albo Cursora?
Nie. Te narzędzia dobrze sprawdzają się przy budowie interfejsu i nowych funkcji. Chodzi o to, żeby zmiany przechodziły przez środowisko testowe i przegląd, zanim trafią do klientów.
Co przygotować przed przeglądem?
Dostęp do repozytorium, bazy danych, hostingu i bramki płatności oraz kilka zdań o tym, co aplikacja ma robić i kto z niej korzysta. Hasła przekaż przez menedżer haseł, a nie w treści maila.
Ile kosztuje naprawa takiej aplikacji?
Wycena po rozmowie, bo zakres zależy od tego, co wyjdzie w przeglądzie. Najpierw dostajesz listę ryzyk z podziałem na krytyczne i pozostałe, a potem decydujesz, które poprawki zlecasz.
Czy klucze, które były w kodzie, trzeba zmienić?
Tak. Klucz, który trafił do kodu frontendu albo do publicznego repozytorium, trzeba uznać za ujawniony. Generuję nowy, przenoszę go na serwer, a stary unieważniam w panelu usługi.
Powiązane strony
Masz aplikację z narzędzia AI i chcesz wpuścić klientów?
Napisz, w czym powstała i co ma robić. Zacznę od przeglądu i listy ryzyk.