W skrócie

Vibe coding to supermoc w weryfikacji pomysłów. W weekend powstaje produkt, który świetnie wypada na prezentacji, użytkownicy mogą się rejestrować, a ktoś jest gotów zapłacić. To prawdziwy postęp — nie daj sobie wmówić, że jest inaczej.

Pułapka pojawia się później. „Wygląda na wdrożone” i „można bezpiecznie skalować” to dwie zupełnie różne rzeczy, a luka między nimi zwykle pozostaje niewidoczna, dopóki większy klient, inwestor lub regulator nie zacznie zadawać pytań. Audyt gotowości produkcyjnej wyjaśnia prostym językiem, która z pięciu luk da Ci się we znaki jako pierwsza — i ile będzie kosztować ich usunięcie, zanim stracisz przez nie kontrakt.

Paradoks produktu stworzonego metodą vibe codingu

Twój produkt wygląda na ukończony. Strona docelowa konwertuje. Wdrożenie użytkowników przebiega płynnie. Użytkownicy logują się, korzystają z funkcji i zostają. Pierwsi klienci płacą. Zespół jest dumny — i słusznie.

Wtedy pojawia się większy klient. Chce SSO. Przesyła kwestionariusz bezpieczeństwa ze 120 pytaniami. Jego dział prawny prosi o umowę powierzenia przetwarzania danych (DPA) i chce wiedzieć, gdzie są przechowywane dane. Dział zakupów pyta, czy jesteście w trakcie procesu uzyskiwania zgodności z SOC 2. Nagle Twój piękny produkt sprawia wrażenie, jakby stał na szczudłach. Założyciele często opisują ten moment tak samo: „Wszystko działa. Po prostu nie potrafię udowodnić, że działa bezpiecznie”.

Na tym polega paradoks produktu stworzonego metodą vibe codingu. Funkcje są prawdziwe. Przychody są prawdziwe. Brakuje wszystkiego, co poważny nabywca uznaje za oczywisty standard — a dopóki nie wiesz dokładnie, czego brakuje, nie możesz wycenić prac naprawczych, ustalić ich kolejności ani obiecać terminu.

Czym właściwie jest audyt gotowości produkcyjnej

Audyt gotowości produkcyjnej to ograniczona czasowo ocena produktu, przeprowadzana wyłącznie w trybie odczytu, pod kątem standardów wymaganych przez płacącego klienta B2B lub korporacyjnego. W co.brick realizujemy go w ciągu jednego–dwóch tygodni, zależnie od rozmiaru bazy kodu. Analizujemy repozytorium, konsolę chmurową, bazę danych, proces uwierzytelniania, CI/CD (jeśli istnieje) oraz instrukcje operacyjne (jeśli istnieją).

Nie ingerujemy w środowisko produkcyjne. Nie proponujemy przepisania produktu od nowa. Dostarczamy jeden dokument: listę ustaleń uporządkowanych według priorytetów, z których każde zawiera poziom istotności, szacowany nakład pracy i wyjaśnienie prostym językiem, co oznacza dla Twojej firmy — oraz krótką listę rzeczy do naprawienia przed kolejną rozmową z klientem korporacyjnym.

Poniżej przedstawiamy pięć kategorii, w których MVP tworzone metodą vibe codingu regularnie nie przechodzą audytu.

Ustalenie nr 1 — RBAC, który tak naprawdę nie jest RBAC

Kontrola dostępu oparta na rolach to zasada mówiąca: „ta osoba może wykonać tę czynność”. Brzmi nudno, dopóki nie zawiedzie — wtedy staje się komunikatem o incydencie na Twojej stronie głównej.

W prawidłowo zbudowanym systemie każda wrażliwa operacja jest sprawdzana na serwerze względem roli przechowywanej oddzielnie od rekordu użytkownika, a kontrola dostępu jest egzekwowana na poziomie bazy danych. W MVP stworzonym metodą vibe codingu zwykle znajdujemy coś zupełnie innego:

• Pole logiczne isAdmin w rekordzie użytkownika, które może edytować każdy, kto ma możliwość aktualizacji własnego profilu.

• Sprawdzanie ról wyłącznie we frontendzie — ukrycie przycisku to nie to samo co zablokowanie żądania, które ten przycisk wysyła.

• Jedną rolę „admin”, która daje wszystkie uprawnienia, więc każdy użytkownik wewnętrzny ma dostęp do danych każdego klienta.

• Brak śladu audytowego pokazującego, kto co zrobił, przez co nie możesz odpowiedzieć na pytanie klienta: „kto uzyskał dostęp do moich danych?”.

Objaw widoczny dla założyciela jest niepokojący. Inżynier wsparcia otwiera zgłoszenie i podczas „pomagania” trafia na dane innego klienta — nie dlatego, że tego chciał, lecz dlatego, że narzędzia uczyniły tę ścieżkę najprostszą. W raporcie z audytu zawsze otrzymuje to status krytyczny, ponieważ jest to najkrótsza droga do tego, by produkt stworzony metodą vibe codingu stał się tematem wiadomości o naruszeniu ochrony danych.

Ustalenie nr 2 — Wielodostępność, która prowadzi do wycieków

Jeśli sprzedajesz więcej niż jednej firmie, prowadzisz system wielodostępny, niezależnie od tego, czy tak go zaprojektowano. Każdy wiersz w bazie danych należy do konkretnej organizacji klienckiej, a cały produkt opiera się na tym, by nigdy — przenigdy — nie pokazać danych jednej organizacji innej.

Produkty tworzone metodą vibe codingu niemal nigdy nie egzekwują tego w warstwie, która ma kluczowe znaczenie. Oto często spotykane wzorce:

• Współdzielone tabele z kolumną tenant_id, po której filtrowanie odbywa się tylko w interfejsie użytkownika lub w jednej funkcji pomocniczej do zapytań — wystarczy raz je pominąć, by doszło do wycieku.

• Brak zabezpieczeń na poziomie wierszy w bazie danych, więc każdy, kto zdobędzie ważny token uwierzytelniający, może odczytywać dane innych organizacji za pomocą ręcznie przygotowanego żądania.

• Narzędzia administracyjne i wewnętrzne panele, które z założenia odpytują dane wielu organizacji, bez izolacji między nimi.

• Zadania w tle i webhooki działające bez kontekstu organizacji, przez co błąd w danych jednej organizacji może po cichu uszkodzić dane innej.

To ustalenie najczęściej przekreśla kontrakty korporacyjne. Zespół bezpieczeństwa poważnego nabywcy nie chce słyszeć: „filtrujemy to w zapytaniu”. Chce usłyszeć: „sama baza danych odmawia zwrócenia wiersza należącego do innej organizacji”. Wczesne usunięcie tej luki jest tańsze niż praca pod presją kontraktu, gdy na stole leży już podpisany list intencyjny.

Ustalenie nr 3 — Brak fundamentów SaaS

Poza uwierzytelnianiem i obsługą wielu organizacji istnieje krótka lista elementów oczekiwanych od każdego poważnego produktu SaaS. MVP tworzone metodą vibe codingu pomijają większość z nich, ponieważ nie widać ich podczas prezentacji:

• Dziennik audytowy. Niezmienny zapis tego, kto, co i kiedy zrobił. Wymagany przez większość standardów zgodności oraz każdego klienta z własnym zespołem bezpieczeństwa.

• Limity liczby żądań dla każdej organizacji. Bez nich jeden klient nadmiernie obciążający system pogarsza działanie produktu wszystkim pozostałym, a jedno złośliwe żądanie może spowodować niedostępność usługi.

• Synchronizacja rozliczeń i uprawnień do funkcji. Produkty tworzone metodą vibe codingu często przechowują stan subskrypcji w jednym miejscu (Stripe), a dostęp do funkcji w innym (ręcznie napisanej konfiguracji), co prowadzi do rozbieżności. Klienci płacą za funkcje, z których nie mogą korzystać, lub korzystają z funkcji, za które przestali płacić.

• Tworzenie kopii zapasowych i odtwarzanie danych, które faktycznie przetestowano. Kopia zapasowa, której nigdy nie odtworzono, to nadzieja, nie plan. Podczas audytu prosimy o datę i godzinę ostatniego udanego testu odtwarzania.

• Zdefiniowana polityka przechowywania i usuwania danych. Wymagają jej RODO i każda umowa DPA z klientem korporacyjnym.

Żaden z tych elementów nie jest efektowny. Wszystkie pojawią się w pierwszym poważnym kwestionariuszu bezpieczeństwa, który otrzymasz.

Ustalenie nr 4 — Sekrety, klucze i łańcuch dostaw oprogramowania

Najszybszym sposobem na utratę kontroli nad produktem jest utrata kontroli nad danymi uwierzytelniającymi. MVP tworzone metodą vibe codingu mają ich wiele i zwykle znajdują się one w niewłaściwych miejscach:

• Klucze API wklejone do paczki frontendowej, widoczne dla każdego, kto otworzy kartę sieciową w narzędziach przeglądarki.

• Klucze roli serwisowej i adresy URL baz danych zapisane w repozytorium lub udostępniane na czacie podczas nocnego debugowania.

• Integracje z usługami zewnętrznymi uwierzytelniane długoterminowym tokenem osobistym należącym do osoby, która jako pierwsza je skonfigurowała.

• Brak polityki rotacji, przez co w dniu odejścia kogoś z zespołu nikt nie wie, które klucze ta osoba nadal posiada.

• Zależności pobierane bez przypięcia konkretnych wersji, brak konsekwentnego stosowania plików blokady wersji, brak automatycznego skanowania zależności i brak powiadomień, gdy pojawia się nowe CVE dotyczące używanego komponentu.

Audyt obejmuje inwentaryzację wszystkich danych uwierzytelniających i zależności zewnętrznych, wskazuje ujawnione elementy oraz dostarcza plan rotacji i skanowania, który możesz powierzyć jednemu inżynierowi do realizacji w tydzień.

Ustalenie nr 5 — Brak testów, brak CI/CD, brak bezpiecznej ścieżki wdrażania

Ostatnia kategoria budzi największy opór założycieli, ponieważ sprawia wrażenie zbędnego narzutu procesowego. Tak nie jest. To różnica między wdrożeniem poprawki w dwadzieścia minut a wdrażaniem jej przez trzy dni z duszą na ramieniu.

Co regularnie znajdujemy w MVP tworzonych metodą vibe codingu:

• Brak testów jednostkowych, integracyjnych i end-to-end. Każda zmiana jest weryfikowana przez klikanie i liczenie na szczęście.

• Brak ciągłej integracji — nic nie uruchamia się automatycznie po wysłaniu kodu do repozytorium, więc regresje trafiają na produkcję i zauważają je dopiero klienci.

• Wdrożenia wykonywane z laptopa, czasem przez Wi-Fi w kawiarni, bez rejestru tego, co i kiedy wdrożono.

• Brak środowiska przedprodukcyjnego odzwierciedlającego produkcję, więc zmiana po raz pierwszy styka się z rzeczywistymi danymi dopiero wtedy, gdy korzysta z niej klient.

• Brak planu wycofania wdrożenia poza „cofnij commit i licz na szczęście”.

Nie potrzebujesz infrastruktury na skalę Google, by to naprawić. Potrzebujesz zestawu testów obejmujących krytyczne ścieżki, potoku CI uruchamianego przy każdym wysłaniu kodu, środowiska przedprodukcyjnego działającego jak produkcja oraz wdrażania jednym poleceniem i wycofywania jednym poleceniem. To tydzień skoncentrowanej pracy doświadczonego inżyniera, dzięki któremu cały zespół śpi spokojniej.

Jak wygląda raport z audytu

Każde ustalenie trafia do raportu z czterema elementami: poziomem istotności (krytyczny, wysoki, średni, niski), szacowanym nakładem pracy (w godzinach lub dniach, nie w punktach złożoności), wyjaśnieniem ryzyka biznesowego prostym językiem oraz konkretnym pierwszym działaniem naprawczym. Na początku raportu otrzymujesz dwie krótkie listy:

• Do naprawienia przed kolejną rozmową z klientem korporacyjnym. Kilka kwestii, które nie przejdą rzetelnej weryfikacji bezpieczeństwa.

• Lista kontrolna bezpiecznego skalowania. Pełny zestaw warunków, które trzeba spełnić, zanim będzie można bez obaw dziesięciokrotnie zwiększyć liczbę klientów.

Raport powstaje przede wszystkim z myślą o założycielach, a dopiero w drugiej kolejności o inżynierach. Masz móc go przeczytać, zrozumieć i wykorzystać na posiedzeniu zarządu — a nie tylko przekazać liderowi technicznemu.

Kiedy go zamówić

Najlepszy moment na audyt gotowości produkcyjnej jest wtedy, gdy jeszcze go nie potrzebujesz. W praktyce oznacza to: przed kolejną rundą finansowania, zanim pierwszy kwestionariusz bezpieczeństwa trafi do Twojej skrzynki, przed pierwszym pilotażem u klienta korporacyjnego lub już teraz, jeśli rzeczywiste dane klientów przepływają przez system, którego nikt nigdy nie audytował.

Vibe coding pozwolił Ci stworzyć produkt, którego ludzie chcą. Krótki, rzetelny audyt pozwoli Ci stworzyć produkt, któremu ludzie ufają.

Umów konsultację dotyczącą audytu gotowości produkcyjnej →