Produkt stworzony z AI: jak bezpiecznie wprowadzać zmiany

Więcej o pracy z modelami znajdziesz w dokumentacji Ailoot.

Dlaczego najdroższa praca zaczyna się po premierze?#

Zbudowałeś aplikację w jeden wieczór, opublikowałeś link i wysłałeś go znajomym. Działa. Tydzień później pojawia się pierwszy prawdziwy użytkownik, klika coś w niewłaściwy sposób i połowa funkcji przestaje działać. Prosisz Claude’a o naprawę — naprawia jedną rzecz, a psuje inną. Brzmi znajomo?

I właśnie wtedy pojawia się główne pytanie: co zrobić po uruchomieniu produktu, gdy minie euforia związana z pierwszym działającym prototypem, a ty nadal musisz jakoś go utrzymywać? Można to nazwać vibe codingiem dla dorosłych. Budowanie daje ekscytację i szybkość. Utrzymanie wymaga chłodnej głowy: rozumiesz, co zmieniasz, i trzymasz wszystko pod kontrolą. Większość osób ponosi porażkę w tej drugiej części, bo nikt ich do niej nie przygotowuje.

Jedno badanie branżowe przeanalizowało ponad milion zmian w kodzie wprowadzonych przez 2,444 zespoły i obliczyło, na co naprawdę idą pieniądze wydawane na rozwój z AI. Oto obraz sytuacji:

Więcej o tych liczbach wyjaśnia artykuł „Ukryty koszt vibe codingu”. Tam pytanie brzmiało: za co płacisz? Tutaj chodzi o coś innego: 44 centy z każdego dolara idą na naprawę błędów — cały ten artykuł dotyczy tego, jak nie dopuścić do wzrostu tego udziału. Praca nad jego kontrolowaniem nazywa się utrzymaniem.

Różnica między osobą, która uprawia vibe coding po dorosłemu, a osobą, która tylko niańczy sieć neuronową, ujawnia się po premierze. U pierwszej baza kodu rośnie, wprowadzane są ulepszenia, a nic się nie psuje. Miesiąc później produkt drugiej osoby zamienia się w przeciekający mechanizm, którego boi się dotknąć. Dalej wyjaśnię, jak znaleźć się w pierwszej grupie.

Co się naprawdę psuje: 5 katastrof po premierze#

Oto publiczne analizy rzeczywistych produktów zbudowanych z AI, z liczbami i datami. Pomyśl o nich jak o mapie pola minowego — każda mina wybuchła już u kogoś, a sposób jej ominięcia jest znany.

Wszystkie pięć przypadków ma tę samą przyczynę. Domyślnie AI sprawia, że coś działa teraz, a nie bezpiecznie za miesiąc pod obciążeniem. Podczas pracy na własnym komputerze nie widać różnicy. Staje się oczywista dopiero wtedy, gdy pojawia się pierwszy nieznajomy o złych zamiarach.

Problemem nie jest to, że kod nie powstaje ręcznie — wiele osób tak pracuje. Problemem jest brak pytania: „Czy baza danych jest zabezpieczona?”. Dalej pokażę prompt, który zada to pytanie za ciebie.

Pierwszą siatką bezpieczeństwa jest git i powrót do „wczorajszego stanu”#

Gdy Claude coś zepsuje, potrzebujesz przycisku „przywróć stan z wczoraj”. Technicznie ten przycisk nazywa się git i jest prostszy, niż się wydaje.

Trzy terminy, które powinien znać nieprogramista:

1. Repozytorium — folder projektu zapisany w chmurze (zwykle na GitHubie). Kopia całego kodu, która nie znajduje się wyłącznie na twoim komputerze.
2. Commit — punkt powrotu. W praktyce mówisz kodowi: „zapisz ten stan”. Każdy commit to znacznik, do którego możesz wrócić.
3. Deploy — wdrożenie. Kod był lokalnie, na twoim komputerze, i działał tylko u ciebie. Wdrożenie wysyła go na zewnętrzny serwer, żeby działał dla wszystkich.

Jeśli masz aktualne punkty w postaci commitów, możesz cofnąć każdą awarię jednym zdaniem. Dosłownie.

Coś zepsułem — wczoraj wszystko działało, a dziś już nie. Znajdź najnowszy commit, w którym wszystko było w porządku, pokaż mi, co się od tego czasu zmieniło, i przywróć projekt do tamtego stanu.

Dwie zasady, które należy od razu wprowadzić, zanim produkt zobaczą inni:

• Repozytorium musi być prywatne. Nie publiczne. W przeciwnym razie każdy może odczytać twój kod i wszystko, co się w nim znajduje.
• Dodaj plik z sekretami do listy ignorowanych. Klucze, hasła i dane dostępowe do bazy przechowuj w osobnym pliku (zwykle .env), który nigdy nie trafia do repozytorium. Dodaj wiersz z .env do .gitignore, a sekrety pozostaną u ciebie.

Osobny poradnik opisuje bezpieczne cofanie zmian w Claude Code: Jak cofnąć zmiany w Claude Code. Bez punktów powrotu idziesz po linie bez siatki bezpieczeństwa i prędzej czy później spadniesz.

Co cofa /rewind, a czego nie?#

Claude Code tworzy migawkę stanu przed każdą wprowadzoną przez siebie zmianą. Polecenie /rewind (lub dwukrotne naciśnięcie Esc) cofa zarówno pliki, jak i rozmowę do wybranego punktu. To przydatne: jeśli pięć minut temu zepsułeś funkcję, możesz cofnąć się o pięć minut.

Jest jednak pułapka, przez którą początkujący tracą dane. /rewind nie cofa wszystkiego:

Anthropic wyjaśnia to wprost: migawki są lokalnym przyciskiem „cofnij”, a git to trwała historia. Migawki uzupełniają kontrolę wersji, ale jej nie zastępują.

Praktyczny wniosek dla nieprogramisty: /rewind uratuje cię przed sytuacją „Claude właśnie zepsuł funkcję”. Jeśli jednak zdążył usunąć wiersz z bazy danych albo wysłać kod do chmury, przywrócić go mogą tylko git i kopia zapasowa bazy. Zachowaj więc obie warstwy: migawki do szybkiego cofania zmian, commity do trwałej historii projektu.

Jak wprowadzać ulepszenia, nie psując tego, co już działa?#

Co druga osoba wpada w tę pętlę. Prosisz AI o naprawę małego błędu. Proponuje rozsądną zmianę. Ta zmiana psuje coś innego. Prosisz o naprawę nowego problemu, a pojawiają się dwa kolejne. I tak dalej.

Pętla pojawia się, ponieważ vibe coding jest niedeterministyczny. Ten sam prompt może za każdym razem wygenerować inny kod. Dlatego każda edycja może po cichu zmienić sąsiednią logikę: próg rabatu przesuwa się z 10 do 12 procent albo zmienia się działanie reguły walidacji — bez żadnej kontroli z twojej strony i bez choćby jednego ostrzeżenia. Nazywa się to dryfem logicznym i po cichu uszkadza dokładnie te elementy, które przynoszą pieniądze: ceny, dostęp i płatności.

Przed takim dryfem chroni jedna zasada, na tyle prosta, że można ją powiesić na ścianie: nie zatwierdzaj kodu, którego nie potrafiłbyś wyjaśnić innej osobie słowo w słowo.

W praktyce można z tego zrobić gotową instrukcję, której użyjesz przed każdą zmianą działającego kodu. Dzięki niej AI wykonuje małe kroki i pokazuje dokładnie, co się zmieniło.

Zanim zmienisz kod, wykonaj te czynności:

Zapisz obecny działający stan jako osobny punkt powrotu (commit).

Opisz dokładnie słowami, co planujesz zmienić i w których plikach.

Wprowadź możliwie najmniejszą zmianę — tylko taką, która rozwiązuje moje zadanie, bez niczego więcej.

Pokaż mi, co się zmieniło, i wyjaśnij każdą zmianę tak, żebym mógł ją wytłumaczyć innej osobie.
Nie ruszaj cen, uprawnień dostępu ani logiki płatności, chyba że o to poproszę.

Kolejna zasada, która oszczędza tygodnie, to dyscyplina w trzymaniu się zakresu zadania. Jeden problem, jedna zmiana, szybka realizacja. Nie proś AI, by w jednym promptcie przepisało połowę projektu. Zdarza się, że profesjonalni programiści zaczynają budować całego Ubera, choć potrzebowali tylko jednego przycisku — i ciągną to miesiącami. Nie musisz tak robić.

Wszystko, co opisuję, opiera się na jednej rzeczy: zarządzaniu kontekstem. Żeby AI nie psuło sąsiedniej logiki, musi pamiętać zasady projektu.

Jak sprawdzić zmianę przed jej opublikowaniem?#

Między „działa na moim komputerze” a „działa dla wszystkich” jest etap pośredni, który początkujący pomijają: kopia testowa. To osobna migawka środowiska produkcyjnego, na której sprawdzasz zmianę, zanim zobaczą ją prawdziwi ludzie. Cykl pracy wygląda tak:

1. Tworzysz i samodzielnie sprawdzasz zmianę (development).
2. Wdrażasz ją na staging — kopię środowiska produkcyjnego bez prawdziwych użytkowników.
3. Uruchamiasz kluczowe scenariusze i upewniasz się, że nic się nie zmieniło.
4. Dopiero teraz wdrażasz ją na produkcję.

Po premierze ma to znaczenie, ponieważ każde wydanie niesie ryzyko. Niewielka zmiana kodu może zepsuć logowanie do konta. Brak jednego ustawienia może wyłączyć cały produkt. Staging wykrywa takie problemy bez konsekwencji; na produkcji tracisz klientów.

Żeby uniknąć ręcznego sprawdzania wszystkiego za każdym razem, daj AI prompt, by porównało działanie nowej wersji ze starą w kluczowych obszarach.

Zamierzam wdrożyć zmianę. Przejdź po kolei przez najważniejsze scenariusze działania produktu i sprawdź, czy każdy z nich nadal działa tak jak wcześniej:

Rejestracja i logowanie nowego użytkownika.

Płatność i przyznanie dostępu po płatności.

Uprawnienia dostępu — zwykły użytkownik nie może zobaczyć cudzych danych ani panelu administracyjnego.

Kluczowe wartości logiki biznesowej (ceny, rabaty, limity) nie uległy zmianie.
Jeśli cokolwiek działa inaczej niż w poprzedniej wersji, zatrzymaj się i pokaż mi dokładnie, co się zmieniło.

Gdzie są twoje sekrety? Największa luka początkujących#

Dokładniej wyjaśnię największą minę, bo to ona unieruchamia więcej produktów niż jakikolwiek inny problem. Gdy AI pisze kod, najłatwiej umieścić klucz tam, gdzie od razu zadziała — bezpośrednio w kodzie strony otwieranej w przeglądarce. Podczas programowania nie zauważysz różnicy. Jednak każdy może odczytać wszystko, co trafia do przeglądarki, otwierając narzędzia deweloperskie.

Założyciel, którego klientów obciążono kwotą $87,500, powiedział później, że można było temu zapobiec jednym promptem. Opłaty ostatecznie cofnięto, ale bezzwrotne prowizje i utrata spokoju pozostały. Oto ten prompt.

Sprawdź cały projekt i upewnij się, że żaden tajny klucz nie trafia do przeglądarki:

Znajdź wszystkie klucze do bazy danych, systemu płatności i usług zewnętrznych.

Upewnij się, że każdy z nich jest przechowywany wyłącznie na serwerze, w zmiennych środowiskowych, a nie w kodzie strony.

Sprawdź historię projektu — czy któryś klucz nie trafił tam wcześniej przez przypadek?
Pokaż mi listę wszystkich miejsc, w których znaleziono sekrety, i napisz, co należy zrobić w każdym przypadku.

Kolejna pobliska mina to sprawdzanie uprawnień dostępu wyłącznie po stronie przeglądarki. Jeśli produkt decyduje w kodzie strony, czy „pokazać panel administracyjny”, każdy może obejść tę decyzję. Uprawnienia dostępu należy zawsze sprawdzać na serwerze. Baza danych musi zwracać dane tylko osobom uprawnionym — do tego służy row-level security (RLS), które trzeba włączyć dla każdej tabeli.

Zanim zaczniesz sprzedawać dostęp lub wpuszczać innych użytkowników, przeprowadź ogólny audyt bezpieczeństwa produktu.

Przejrzyj projekt jak osoba atakująca i znajdź luki w zabezpieczeniach:

Czy jakiekolwiek tajne klucze są zapisane w kodzie wysyłanym do przeglądarki albo w historii projektu?

Czy w każdej tabeli bazy danych włączono zabezpieczenia na poziomie wierszy (RLS) i czy uprawnienia dostępu są sprawdzane na serwerze, a nie tylko w przeglądarce?

Czy skonfigurowano automatyczną kopię zapasową bazy danych i czy kiedykolwiek sprawdziłem, czy da się ją odtworzyć?

Czy produkcyjna baza danych jest odizolowana od środowiska, w którym działa agent AI?
Przy każdym punkcie powiedz, czy wszystko jest w porządku, czy dokładnie co trzeba naprawić.

Osobny, obszerny poradnik opisuje bezpieczeństwo vibe codingu: Jak zabezpieczyć aplikację stworzoną metodą vibe codingu. Zasada jest prosta: wszystko, co AI robi domyślnie, traktuj jako niezabezpieczone, dopóki nie sprawdzisz, że jest inaczej.

Gdzie hostować produkt: kolejne szczeble hostingu#

Nie musisz od razu wynajmować własnego serwera i ręcznie go konfigurować — na początku to skomplikowane zadanie, które pochłonie twój czas. Wraz z rozwojem produktu możesz wchodzić po kolejnych szczeblach:

1. Bezpłatny hosting (na przykład Vercel) — dla siebie, do testów i małych projektów. Sprawdzi się, jeśli platforma jest dostępna dla twoich odbiorców i nie przechowujesz danych osobowych.
2. Platforma z wdrożeniem jednym poleceniem (Railway) — gdy masz backend i bazę danych. Wdrażasz produkt jednym poleceniem, bez konfiguracji serwera. Próg wejścia jest minimalny.
3. Własny serwer dedykowany — gdy obciążenie jest duże i potrzebujesz pełnej kontroli. Przenieś się na niego później, gdy osiągniesz limit platformy.

Dla nieprogramisty, który właśnie uruchomił produkt, najłatwiejszą opcją jest platforma umożliwiająca wdrożenie jednym poleceniem, bez ręcznej konfiguracji serwera. Na własny serwer możesz przenieść się później. Jeśli chcesz przejść tę ścieżkę na konkretnym przykładzie, zobacz poradnik wdrażania projektu stworzonego metodą vibe codingu na własny serwer z Coolify.

Kiedy rozdzielić aplikację, bazę danych i kopie zapasowe?#

Trzech rzeczy nie należy trzymać w jednym koszyku: aplikacji, bazy danych i kopii zapasowych. Gdy użytkowników jest niewielu, wszystko może działać razem i to jest w porządku. Istnieje jednak wyraźny sygnał, że pora je rozdzielić.

• Umieść aplikację i bazę danych na różnych maszynach. Sygnałem jest sytuacja, w której przy szczytowym obciążeniu wykorzystanie procesora i pamięci utrzymuje się powyżej 70–80 procent, żądania zwalniają, a aplikacja i baza danych konkurują o te same zasoby. Po rozdzieleniu możesz wzmocnić bazę danych bez ingerencji w aplikację i odwrotnie.
• Stosuj zasadę kopii zapasowych 3-2-1. Trzy kopie danych, na dwóch różnych rodzajach nośników, z jedną poza lokalizacją. Chroni to przed awarią sprzętu i ransomware. Najważniejsze, by kopie zapasowe tworzyły się automatycznie.

Częstotliwość tworzenia kopii zależy od tego, jak kosztowna byłaby utrata danych z kilku godzin. Jeśli utrata godziny zapisów płatności w internetowej usłudze subskrypcyjnej jest niedopuszczalna, kopie muszą powstawać częściej niż co godzinę albo potrzebne są sprawdzone logi transakcji i odzyskiwanie do punktu w czasie (PITR). Dobierz interwał do maksymalnej akceptowalnej utraty danych i osobno sprawdź czas przywrócenia usługi. Blogowi wystarczy jedna dziennie. Logika jest prosta: określ, ile danych możesz stracić, i odpowiednio skonfiguruj kopie zapasowe.

Pomóż mi zdecydować, czy pora przenieść mój produkt na poważniejszą infrastrukturę. Sprawdź każdy punkt i zadaj mi pytania:

Jak obciążone są procesor i pamięć w szczycie — czy ich użycie utrzymuje się powyżej 70–80 procent?

Czy baza danych i aplikacja działają na tej samej maszynie, czy na różnych?

Czy skonfigurowano automatyczne kopie zapasowe bazy danych i czy sprawdziłem odtwarzanie z kopii?

Czy istnieje osobna kopia środowiska (staging) do sprawdzania zmian przed wdrożeniem?
Na podstawie wyników przedstaw jasną rekomendację: co zostawić bez zmian, co rozdzielić w pierwszej kolejności i dlaczego.

Jest jeszcze kwestia wyboru między bazą zarządzaną a własną. Dla małego zespołu zarządzana baza prawie zawsze będzie lepsza: własna jest tańsza pod względem sprzętu, ale pochłania godziny na utrzymanie. Jeśli działasz sam, a twój produkt nie jest infrastrukturą, te godziny kosztują więcej niż różnica w cenie serwera.

Jak zautomatyzować utrzymanie?#

Ręczne utrzymanie jest wyczerpujące. Możesz zdjąć część obowiązków z własnych barków na dwa sposoby: monitoringiem i agentem patrolującym.

Monitoring obejmuje dwa różne narzędzia do dwóch różnych zadań:

1. „Czy strona działa?” — monitor dostępności (na przykład UptimeRobot). Co kilka minut sprawdza produkt i wysyła alert, gdy przestaje działać. Jest dostępny bezpłatny plan.
2. „Co dokładnie się zepsuło?” — narzędzie do śledzenia błędów (na przykład Sentry). Zbiera błędy z aplikacji i pokazuje, gdzie oraz dlaczego coś nie zadziałało.

Pierwsze narzędzie wykrywa, że produkt przestał działać. Drugie pokazuje, która funkcja zawiodła i dlaczego. Razem odpowiadają na pytanie: „Czy dowiem się o awarii, zanim klient napisze do pomocy technicznej?”.

Drugim poziomem automatyzacji jest agent patrolujący. Wyobraź sobie biuro nieruchomości: o siódmej rano agent AI czyta wiadomości na stronie, zauważa, że formularz rezerwacji nie działa, znajduje przyczynę w kodzie i przynosi gotową poprawkę z wyjaśnieniem. Sprawdzasz ją i mówisz „tak” — wtedy zostaje wdrożona. Kolejność ma znaczenie: najpierw rozwiąż problem użytkownika (przyznaj dostęp, przeproś), a dopiero potem zbadaj przyczynę i pieniądze.

Jest jeszcze jedna zasada dotycząca dostępu AI do produkcyjnej bazy danych: przyznaj mu konto tylko do odczytu i ukryj dane osobowe za warstwą pośredniczącą, tak aby agent widział „imię” zamiast prawdziwego imienia i nazwiska. Wtedy nawet jeśli popełni błąd, fizycznie nie będzie w stanie usunąć ani uszkodzić danych produkcyjnych. Incydent z tabeli powyżej, w którym agent wyczyścił produkcyjną bazę danych, pokazuje dokładnie, do czego prowadzi brak tego ograniczenia. Poradnik Co zrobić, gdy AI usunęło twoją bazę danych wyjaśnia, jak postąpić, gdy katastrofa już nastąpiła.

Kiedy pora zamknąć produkt?#

Najbardziej niedocenianą częścią utrzymania jest wiedza, kiedy przestać się nim zajmować. Każdy, kto dużo buduje, ma cmentarz projektów: stworzył coś, trochę przy tym dłubał, a potem porzucił. To normalne i nie oznacza porażki. Porażką jest ciągnąć przez wiele miesięcy coś, czego nikt nie używa, tylko dlatego, że żal czasu włożonego w projekt.

Oto progi, które pomogą podjąć decyzję:

1. Dwa tygodnie — wystarczająco dużo, by sprawdzić, czy pomysł działa. Jeśli pierwsi prawdziwi użytkownicy wracają, działaj dalej. Cisza też jest odpowiedzią.
2. Trzy miesiące — twardy limit. Jeśli po trzech miesiącach produkt nie wypalił, zamknij go. Przy szybkości vibe codingu poświęcanie sześciu miesięcy na testowanie jednego pomysłu trwa zbyt długo.

Zamknięcie projektu jest psychologicznie trudne, więc potraktuj je jak decyzję, a nie uczucie. Rezygnacja z projektu, w który zainwestowałeś, przypomina zwolnienie pracownika, który nie potrafi wykonywać swojej pracy: to nieprzyjemne, ale dalsze zatrudnianie go kosztuje więcej niż rozstanie.

Utrzymanie to praca, dzięki której produkt pozostaje dostępny i użyteczny dla ludzi. Wszystko inne — git, kopie zapasowe, monitoring — to tylko narzędzia pomagające doprowadzić do momentu, w którym produkt zaczyna pracować dla ciebie każdego dnia.

Zbudowanie produktu z AI w jeden wieczór to połowa pracy. Utrzymywanie go przy życiu i zapewnianie mu bezpieczeństwa w miarę rozwoju — to właśnie oznacza vibe coding dla dorosłych.

Następny krok — Ailoot.