Prawdziwe przyczyny i konkretne rozwiązania. AI optymalizuje pod działające demo, nie pod system produkcyjny. Przy 15–30 cichych decyzjach architektonicznych na feature z dokładnością ~70% każdej, szansa że wszystkie są poprawne jest praktycznie zerowa.
«Działa na mojej maszynie» to najstarszy żart w inżynierii oprogramowania. Ale przy aplikacjach generowanych przez AI to nie jest żart — to stan domyślny. AI nie myśli o produkcji. Nie wie, czym jest load balancer, connection pool czy secrets manager. Widzi tylko jedno: Twój lokalny kontekst, Twój plik, Twoją próbę uruchomienia.
Kiedy AI buduje feature, podejmuje 15–30 cichych decyzji architektonicznych: jaka baza danych, jak łączyć się z API, gdzie trzymać klucze, jak obsługiwać błędy. Każda z tych decyzji ma mniej więcej 70% szans na bycie poprawną. Ale żeby cały feature działał na produkcji, wszystkie decyzje muszą być poprawne. Prawdopodobieństwo? Przy 20 decyzjach: 0.7^20 = 0.08%. Praktycznie zero.
Ten artykuł opisuje sześć najczęstszych powodów, dla których aplikacje AI działają lokalnie i padają na produkcji — z konkretnymi przykładami i rozwiązaniami. Jeśli budujesz z Cursor, Bolt, Lovable, Replit lub innym narzędziem AI, ten poradnik jest dla Ciebie.
To najbardziej banalny i jednocześnie najczęstszy powód awarii na produkcji: konfiguracja, która działa tylko lokalnie. Twój plik .env na laptopie ma prawdziwe klucze API, poprawne URL-e, działające sekrety. Na produkcji? Placeholdery, brakujące zmienne, albo zupełnie inne adresy.
AI nigdy nie myśli o zarządzaniu konfiguracjami — widzi tylko lokalny kontekst. Kiedy generuje kod, który łączy się z API, wpisuje http://localhost:3000 bezpośrednio w kodzie. Kiedy potrzebuje klucza API, tworzy zmienną z domyślną wartością. Kiedy buduje URL do bazy danych, hardcoduje string połączenia.
Typowe problemy:
http://localhost:3000/api zamiast zmiennej środowiskowej. Działa lokalnie, w produkcji wskazuje na nikąd..env. Musisz ustawić zmienne w panelu hostingu (Vercel, Railway, Render).http://, produkcja wymaga https://. Mieszanie protokołów powoduje blokowanie przez przeglądarkę (mixed content) i błędy CORS.Twój lokalny .env ma prawdziwe klucze. Produkcja może mieć placeholdery, błędne URL-e albo brakujące sekrety. AI nigdy nie myśli o zarządzaniu konfiguracjami — widzi tylko lokalny kontekst.
Externalizuj CAŁĄ konfigurację. Każdy URL, każdy klucz, każdy sekret powinien pochodzić ze zmiennej środowiskowej — nigdy z kodu źródłowego. Użyj secrets managera (np. Doppler, AWS Secrets Manager, Vercel Environment Variables). Stwórz plik .env.example z nazwą każdej wymaganej zmiennej (bez wartości) i dodaj go do repozytorium jako dokumentację.
AI kocha SQLite. Jest prosta, nie wymaga serwera, to tylko plik. Idealnie nadaje się do prototypu. Problem? Platformy serverless (Vercel, Netlify Functions, AWS Lambda) nie obsługują SQLite, bo każde zapytanie może trafić na inną instancję — nie ma współdzielonego systemu plików.
Ale baza danych to nie tylko silnik. To cały zestaw założeń, które AI robi cicho:
AI używa SQLite, bo nie wymaga serwera. Ale platformy serverless łamią SQLite — każde zapytanie może trafić na inną instancję bez współdzielonego systemu plików. Zapytania, które działają na 50 rekordach, trwają 30 sekund na 50 000 bez indeksów.
Użyj PostgreSQL lub MySQL na produkcji. Skonfiguruj connection pooling (PgBouncer, Supabase ma to wbudowane). Dodaj indeksy na kolumnach używanych w WHERE i JOIN. Zaplanuj strategię migracji — użyj narzędzia jak Prisma Migrate, Drizzle, albo zwykłych plików SQL z wersjonowaniem. Nigdy nie modyfikuj schematu produkcyjnego ręcznie.
Badanie Georgetown CSET wykazało, że 45% kodu generowanego przez AI zawiera luki bezpieczeństwa. To nie jest marginalny problem — to niemal połowa całego kodu. A kod, który «działa» na localhost, nie musi być bezpieczny.
Skan 5 600 aplikacji zbudowanych metodą vibecoding ujawnił ponad 2 000 luk o wysokim wpływie i ponad 400 ujawnionych sekretów. Platforma Moltbook ujawniła 1,5 miliona kluczy API — Row Level Security na Supabase nigdy nie zostało włączone. Lovable miał odwróconą kontrolę dostępu w 170 aplikacjach produkcyjnych (CVE-2025-48757): uwierzytelnieni użytkownicy byli blokowani, a nieuwierzytelnieni dostawali pełny dostęp.
Problemy, które widzę regularnie:
45% kodu AI zawiera luki bezpieczeństwa. Skan 5 600 vibe-coded aplikacji: 2 000+ luk o wysokim wpływie, 400+ ujawnionych sekretów. Lovable miał odwróconą kontrolę dostępu w 170 produkcyjnych aplikacjach.
Przeprowadź audyt OWASP Top 10. Włącz Row Level Security na Supabase. Waliduj wszystkie inputy po stronie serwera (nigdy nie ufaj klientowi). Przeskanuj repozytorium pod kątem ujawnionych sekretów (użyj gitleaks lub trufflehog). Dodaj rate limiting na wszystkich publicznych endpointach. Przenieś klucze API z frontendu do backendu.
Twoja aplikacja działa przez pierwsze 100 zapytań. Zapytanie numer 1 001 powoduje awarię — wszystkie połączenia z bazą są wyczerpane. Dlaczego? Bo AI nigdy nie zamknęło połączeń. Każde zapytanie otwierało nowe połączenie, ale żadne go nie zwalniało.
To samo dotyczy uchwytów plików, listenerów WebSocket, timerów i subskrypcji. AI tworzy zasoby, ale ich nie zwalnia. Na localhost nie widać tego, bo restartowanie serwera co kilka minut resetuje wszystko. Na produkcji serwer działa bez przerwy — i zasoby się kończą.
Jeszcze gorsze są ciche błędy:
try/catch — płatność nie przechodzi, webhook nie wystrzeliwuje, ale użytkownik nie widzi żadnego błędu. Dane znikają po cichu.Połączenia z bazą, które nigdy nie są zamykane. Uchwyty plików, które pozostają otwarte. Listenery WebSocket, które nie są sprzątane. Działa przez pierwsze 100 zapytań — zapytanie 1 001 powoduje awarię.
Dodaj error boundaries na frontendzie (React: ErrorBoundary). Dodaj globalny error handler na backendzie (process.on('uncaughtException')). Wdrażaj strukturalne logowanie (Sentry, LogRocket, Pino). Zamykaj połączenia z bazą po użyciu (albo użyj connection poolingu). Sprzątaj listenery i timery w useEffect cleanup. Testuj pod obciążeniem — nie wystarczy sprawdzić, że działa raz.
To nie są teoretyczne zagrożenia. To incydenty, które już się wydarzyły:
t3.micro kosztuje inaczej niż r5.4xlarge. Skalowanie kosztów to coś, o czym AI w ogóle nie myśli.plan zamiast price), podwójne naliczenia przez 2 tygodnie zanim ktoś zauważył.AI obiecało 10x developers. W praktyce: juniorzy zostali prompt engineerami, seniorzy zostali sprzątaczami kodu. Koszt naprawy kodu AI często przewyższa koszt napisania go od zera.
Wzorzec powtarza się: AI generuje kod, który wygląda dobrze. Przechodzi code review (bo jest czytelny). Przechodzi testy (bo testuje szczęśliwą ścieżkę). A potem wybucha na produkcji, bo nikt nie sprawdził wydajności pod obciążeniem, obsługi błędów, bezpieczeństwa ani kosztów infrastruktury.
Zanim wdrożysz swoją aplikację, przejdź przez te punkty. Każdy niespełniony punkt to potencjalna awaria na produkcji. Ta checklista powstała na podstawie dziesiątek audytów aplikacji AI, które przeprowadziłem dla klientów.
Dlatego, że localhost to idealne środowisko: same-origin (brak CORS), zerowa latencja sieciowa, tryb developerski maskuje ostrzeżenia, Ty jesteś jedynym użytkownikiem (brak race conditions, brak obciążenia). Na produkcji każdy z tych warunków jest inny — i każdy może spowodować awarię.
Brakujące zmienne środowiskowe i hardcoded konfiguracja. To banalne, ale odpowiada za większość awarii «działa lokalnie, nie działa na produkcji». Twój .env ma klucze — serwer produkcyjny nie. AI hardcoduje URL-e w kodzie źródłowym zamiast używać zmiennych środowiskowych.
Proste pytanie: jeśli nie potrafisz odpowiedzieć «co się stanie, kiedy X padnie?» dla każdej krytycznej ścieżki, Twoja aplikacja nie jest gotowa. Co się stanie, kiedy baza danych będzie niedostępna? Co się stanie, kiedy API Stripe zwróci błąd? Co się stanie, kiedy 100 użytkowników kliknie «Kup» w tej samej sekundzie? Jeśli nie masz odpowiedzi — masz pracę do zrobienia.
Zazwyczaj nie. Najpierw zrób audyt. Zidentyfikuj krytyczne luki (bezpieczeństwo, baza danych, konfiguracja). Napraw je punkt po punkcie. Przepisanie od zera ma sens tylko wtedy, kiedy architektura jest fundamentalnie błędna — ale w większości przypadków można naprawić istniejący kod iteracyjnie, bez utraty dotychczasowej pracy.
Platforma nie równa się produkcji. Vercel i Netlify to świetne narzędzia do hostingu, ale sam hosting to nie jest «produkcja». Nadal potrzebujesz poprawnej konfiguracji CORS, monitoringu, obsługi błędów, bezpieczeństwa, właściwej bazy danych i testów obciążeniowych. Przycisk «Deploy» to początek, nie koniec.
Pomożemy Ci zidentyfikować i naprawić każdy z tych problemów. Audyt, naprawa, wdrożenie — od prototypu do produkcji.
Zarezerwuj bezpłatną rozmowę →