Ten post opisuje, jak wziąć aplikację zbudowaną narzędziami do vibe coding (Lovable, Bolt lub podobne AI buildery, które typowo dostarczają na Supabase i Netlify/Vercel) i zmigrować ją do AWS z procesami, zabezpieczeniami i architekturą, jakich wymaga Well-Architected Framework.
Jeśli wywodzisz się konkretnie z Heroku, nasz przewodnik po migracji z Heroku do AWS opisuje tę ścieżkę szczegółowo. Ten post adresuje inny punkt startowy: kod wygenerowany przez AI, który nigdy nie był projektowany z myślą o dojrzałości operacyjnej.
Co vibe coding faktycznie produkuje
Termin “vibe coding”, ukuty przez Andreja Karpathy’ego na początku 2025, definiuje workflow, w którym opisujesz, czego chcesz w języku naturalnym, a AI generuje aplikację. Narzędzia jak Lovable, Bolt i v0 zamieniły to w kategorię produktową. Opisujesz, AI tworzy szkielet frontendu w React lub Next.js, podłącza go do Supabase po auth, bazę danych i storage, i dostarcza na Netlify lub Vercel. W mniej niż dzień masz działającą aplikację z rejestrującymi się użytkownikami.
Rezultat jest naprawdę imponujący i wystarczający do walidacji pomysłu. Typowe środowisko wygląda tak:
To doskonale uzasadniona architektura dla prototypu lub MVP z ograniczonym ruchem. Problem pojawia się, gdy produkt działa, użytkownicy przychodzą i musisz go utrzymywać na poważnie.
Gdzie aplikacje vibe coded nie wystarczają
Luka nie tkwi w kodzie aplikacji. Tkwi we wszystkim, czego AI nie wygenerował, bo o to nie poprosiłeś i platformy to abstrahują.
Brak separacji środowisk. Większość aplikacji vibe coded działa na jednym projekcie Supabase. Nie ma środowiska przedprodukcyjnego (staging), nie ma izolowanej bazy dev, nie ma sposobu na testowanie migracji bazy bez ryzykowania danych produkcyjnych. AI generuje polityki RLS, ale nie ma procesu ich weryfikacji ani testowania, zanim trafią do żywych użytkowników.
Brak infrastructure as code. Projekt Supabase został stworzony przez dashboard. Deployment Vercel podłączony przez UI. Nic nie jest reprodukowalne. Jeśli musisz odbudować środowisko (disaster recovery, audyt compliance, nowy region), klikasz przez dashboardy i masz nadzieję, że pamiętasz konfigurację.
Brak CI/CD poza deploy-on-push. Vercel i Netlify dostarczają przy każdym wypchnięciu do głównej gałęzi (branch main). I to tyle. Nie ma etapu testów, nie ma skanowania bezpieczeństwa, nie ma bramki akceptacji, nie ma canary deployment. Każdy commit trafia prosto na produkcję. Dla prototypu to szybkość. Dla produktu z płacącymi użytkownikami to ryzyko.
Brak monitoringu i alertów. Supabase oferuje podstawowe dashboardy. Vercel pokazuje wykonanie funkcji. Ale nie ma ustrukturyzowanego logowania, nie ma observability (distributed tracing), nie ma alertów na skoki błędów (error rate) czy degradację czasu odpowiedzi. Kiedy coś się psuje o 2 w nocy, dowiadujesz się ze skargi klienta na X lub LinkedIn.
Brak granic bezpieczeństwa. Klucz serwisowy Supabase (pełny dostęp do bazy) jest często wystawiony w zmiennych środowiskowych bez polityki rotacji. Nie ma WAF, nie ma izolacji sieciowej, nie ma zasady najmniejszego uprawnienia w komunikacji między serwisami. AI wygenerował polityki RLS, ale nikt nie zweryfikował, czy faktycznie zapobiegają wyciekowi danych między tenantami.
Brak strategii backupu i odtwarzania. Supabase Cloud robi dzienne backupy, ale point-in-time recovery jest dostępne tylko w planach Pro, a testowanie odtwarzania to proces manualny. Nie ma udokumentowanego RTO/RPO, nie ma przetestowanej procedury odzyskiwania, nie ma failover w wielu regionach.
Brak kontroli kosztów. Supabase i Vercel rozliczają na podstawie zużycia. Gdy ruch skacze (co jest celem), koszty rosną nieprzewidywalnie. Nie ma zarezerwowanej pojemności, nie ma alertów budżetowych, nie ma sposobu na right-sizing zasobów, bo nie kontrolujesz warstwy infrastruktury.
Ścieżka migracji: od platform zarządzanych do AWS
Celem nie jest przepisanie aplikacji. Kod wygenerowany przez Lovable działa. Celem jest owinięcie go w infrastrukturę, procesy i praktyki operacyjne, które zamieniają prototyp w system produkcyjny. Każdą migrację weryfikujemy względem AWS Well-Architected Framework, bo to nie akademicka checklista. To minimalna poprzeczka dla niezawodnego uruchamiania oprogramowania w skali.
Tak typowa infrastruktura vibe coded mapuje się na AWS:
Stosowanie Well-Architected Framework
Każdy filar adresuje konkretną lukę, którą aplikacje vibe coded dziedziczą po swoich zależnościach platformowych:
Budowanie warstwy DevOps, którą vibe coding pominął
Nasza zweryfikowana przez AWS ekspertyza w zakresie nowoczesnych praktyk DevOps mówi nam, jak powinien wyglądać dojrzały pipeline dostarczania. Aplikacje vibe coded nie mają nic z tego. Nie dlatego, że narzędzia są złe, ale dlatego, że platformy celowo ukrywają tę warstwę, żeby zmniejszyć tarcie. Gdy przenosisz się na AWS, budujesz to właściwie od początku.
Projektowanie pipeline CI/CD
Na Lovable/Vercel model deployment to: wypchnięcie do głównej gałęzi (branch main) → deployment na produkcję. Bez bramek, bez testów, bez akceptacji. Odpowiednik na AWS to nie tylko pipeline. To bramka jakości i bezpieczeństwa.
Pipeline produkcyjny dla zmigrowanej aplikacji vibe coded typowo wygląda tak:
2. Build stage: Aplikacja jest konteneryzowana (Docker build), zależności są zablokowane, artefakty buildów wersjonowane.
3. Test stage: Testy jednostkowe, testy integracyjne na tymczasowej bazie testowej, testy kontraktowe dla granic API.
4. Security stage: Skanowanie SAST (Semgrep lub SonarQube), sprawdzanie podatności zależności (Trivy, Snyk), skan obrazu kontenera przed wypchnięciem do ECR.
5. Deployment na staging: Automatyczne dostarczenie na środowisko przedprodukcyjne (staging), które odzwierciedla produkcję. Testy dymne (smoke tests) uruchomione na tym środowisku.
6. Bramka akceptacji: Manualna lub automatyczna akceptacja przed deployment na produkcję. Dla zespołów, które tego potrzebują, tu QA zatwierdza.
7. Deployment na produkcję: Rolling update przez ECS z walidacją health check. Automatyczny rollback, jeśli nowa wersja nie przechodzi weryfikacji stanu.
8. Walidacja po dostarczeniu: Synthetic monitoring potwierdza, że krytyczne ścieżki użytkownika nadal działają. Alerty strzelają, jeśli ilość błędów (error rate) skacze w pierwszych 15 minutach.
My budujemy to w GitHub Actions z federacją OIDC do AWS. Bez długożyjących kluczy dostępowych, bez współdzielonych sekretów. Każde środowisko (dev, przedprodukcyjne, produkcja) żyje na własnym koncie AWS dla izolacji zasięgu awarii.
Preview environments (zamiennik Vercel preview deploys)
Jedna rzecz, którą zespoły cenią w Vercel: każdy PR dostaje live preview URL. To jest koniecznością dla większości zespołów migrujących. Na AWS budujesz to sam, ale rezultat jest mocniejszy.
Wzorzec: workflow GitHub Actions uruchamia się na otwarciu/aktualizacji PR. Stawia krótkotrwały serwis ECS (lub dedykowaną dystrybucję CloudFront wskazującą na S3 bucket dla aplikacji statycznych) z unikalną subdomeną. Preview environment łączy się z dedykowanym schematem bazy danych lub branch-specific projektem Supabase, jeśli zachowujesz Supabase dla prędkości developmentu. Gdy PR jest zmergowany lub zamknięty, inny workflow usuwa środowisko preview.
To wymaga wysiłku na początku, ale gdy jest wdrożone, developer experience dorównuje lub przekracza to, co oferował Vercel, z dodatkiem uruchamiania na prawdziwej infrastrukturze AWS zamiast abstrakcji platformy.
Infrastructure as Code
Każdy zasób, od którego zależy aplikacja (VPC, subnety, security groups, instancja RDS, klaster ECS, load balancery, dystrybucje CloudFront, role IAM, sekrety), jest zdefiniowany w Terraform lub Terragrunt. Nic nie jest tworzone przez konsolę AWS.
To daje Ci:
- Reprodukowalność: postawienie kompletnej kopii środowiska w kilka minut, do disaster recovery lub ekspansji regionalnej
- Audytowalność: każda zmiana infrastruktury przechodzi przez pull request z peer review
- Wykrywanie driftu: automatyczne weryfikacje wychwytują, gdy ktoś modyfikuje zasoby poza kodem
- Dowody compliance: audytorzy mogą weryfikować Twoją konfigurację infrastruktury jako kod zamiast klikać przez konsole
Dla zespołów przychodzących ze świata vibe coding to największy upgrade operacyjny. Twoja infrastruktura przestaje być tajemnicą i staje się wersjonowanym, udokumentowanym, weryfikowalnym artefaktem.
Monitoring i observability
Aplikacje vibe coded typowo mają zero observability. Dowiadujesz się, że coś jest zepsute, gdy użytkownik Ci powie. Na AWS budujesz observability od dnia pierwszego:
- Ustrukturyzowane logowanie: logi aplikacji wysyłane do CloudWatch Logs lub platformy zewnętrznej (Datadog, Grafana Cloud) ze spójnymi formatami i correlation ID
- Metryki: CloudWatch lub Prometheus dla czasu odpowiedzi, ilości błędów (error rate), wykorzystania puli połączeń do bazy, głębokości kolejek
- Alerty: integracja z PagerDuty lub Opsgenie z wielopoziomową severity. Krytyczne alerty budzą kogoś. Warningi tworzą tickety.
- Dashboardy: dashboardy na poziomie serwisu pokazujące cztery golden signals (latency, traffic, errors, saturation) na pierwszy rzut oka
- Observability (distributed tracing): X-Ray lub OpenTelemetry do śledzenia żądań między serwisami, niezbędne gdy monolit zaczyna dzielić się na mikroserwisy
Proces migracji w praktyce
Faktyczna migracja przebiega fazowo. Nie rekomendujemy big-bang cutover dla aplikacji vibe coded, bo zazwyczaj jest nieudokumentowane zachowanie, które ujawnia się dopiero pod prawdziwym ruchem.
Całkowity harmonogram dla typowej aplikacji vibe coded: 5-8 tygodni. Bardziej złożone środowiska z wieloma serwisami lub wymaganiami compliance rozciągają to do 8-12 tygodni.
Kiedy zostać na Lovable/Supabase Cloud
Nie każda aplikacja vibe coded musi być migrowana. Platformy są dobrym wyborem, gdy:
- Nadal walidujecie product-market fit i szybkość dostarczania jest ważniejsza niż dojrzałość operacyjna
- Ruch jest niski i przewidywalny (setki, nie tysiące, równoczesnych użytkowników)
- Nie macie wymagań compliance (SOC 2, ISO 27001, Cyber Essentials Plus, HIPAA)
- Zespół jest mały i nie ma możliwości zarządzania infrastrukturą
- Aplikacja jest wewnętrzna lub niekrytyczna
Migracja ma sens, gdy którekolwiek z tych staje się prawdziwe:
- Macie płacących klientów, którzy oczekują gwarancji dostępności, jakich nie możecie zagwarantować na współdzielonej platformie
- Potrzebujecie izolacji sieciowej, prywatnych subnetów lub łączności VPN z systemami partnerów
- Wymagania compliance lub regulacyjne wymagają kontroli infrastrukturalnych, których platformy nie zapewniają
- Koszty rosną nieprzewidywalnie i potrzebujecie planowania pojemności i cen zarezerwowanych
- Potrzebujecie właściwego pipeline CI/CD ze skanowaniem bezpieczeństwa, bramkami testowymi i kontrolowanymi dostarczeniami
- Chcecie posiadać swoją infrastrukturę jako zasób biznesowy, zdefiniowany i wersjonowany w kodzie
Vibe coding nie jest problemem
Żeby było jasne: nie jesteśmy przeciwko vibe coding. Narzędzia jak Lovable czy Bolt robią naprawdę imponującą robotę, pozwalając przejść od pomysłu do działającego oprogramowania w godziny zamiast tygodni. Kod wygenerowany przez AI jest często czysty, dobrze ustrukturyzowany i funkcjonalny. Problem nie leży w jakości kodu.
Problem polega na tym, że przejście od “działa” do “jest production-ready” wymaga warstwy inżynierii, której żaden AI builder dziś nie zapewnia: własność infrastruktury, automatyzacja dostarczania, zabezpieczenia, observability, disaster recovery i zarządzanie kosztami. Ta warstwa zamienia side project w biznes.
Prototyp vibe coded to Twój punkt startowy, nie Twój dług techniczny. Traktuj wygenerowany kod jako zwalidowaną specyfikację tego, co produkt powinien robić, a potem zbuduj fundament operacyjny, którego potrzebuje, żeby działać niezawodnie w skali.
Zbudowałeś coś w Lovable lub Bolt, co jest gotowe do skalowania?
Umów bezpłatną 30-minutową rozmowę. Omówimy Twój setup i przygotujemy roadmapę migracji.
Jak możemy pomóc
Migrowaliśmy aplikacje z Heroku, DigitalOcean, Vercel i Supabase Cloud do AWS. Każda migracja jest dostarczana z infrastructure as code, zautomatyzowanym CI/CD, monitoringiem i udokumentowanymi runbookami. Docelowa architektura jest projektowana zgodnie z AWS Well-Architected Framework. Nowe środowisko spełnia najlepsze praktyki bezpieczeństwa, niezawodności, wydajności i kosztów od pierwszego dnia.
Jako AWS Advanced Tier Partner mamy dostęp do programów finansowania, które mogą pokryć znaczną część kosztów migracji. W zależności od skali i sytuacji programy takie jak Proof of Concept (PoC) czy Migration Acceleration Program (MAP) mogą pokryć 50-80% kosztu zaangażowania. Kwalifikowalność oceniamy w ramach wstępnej rozmowy.
Zobacz nasze case study migracji z Heroku do AWS po szczegółowy przykład, jak podchodzimy do migracji platformowych. Chcesz ocenić, czy migracja ma sens dla Twojej aplikacji vibe coded? Nasze usługi migracji do chmury zaczynają się od niezobowiązującej oceny Twojego obecnego środowiska.
