Kto przejmie i rozwinie aplikację napisaną przez AI? Przejęcie kodu po vibe codingu krok po kroku

Tak, aplikację napisaną z pomocą AI da się przejąć i rozwijać dalej, i zwykle nie trzeba jej pisać od nowa. Przejmujemy narzędzia zbudowane w Lovable, Bolt, v0, Replit, Cursorze, Claude Code albo składane „z ChatGPT kawałek po kawałku”: najpierw przepinamy dostępy na firmę i robimy pełną kopię, potem przegląd (co działa, gdzie są dziury, gdzie leżą dane), łatamy rzeczy pilne, porządkujemy kod i dopiero wtedy dokładamy nowe funkcje. Firma dostaje aplikację, którą da się bezpiecznie zmieniać, i ludzi, którzy za nią odpowiadają.

Typowo wygląda to tak. Właściciel firmy instalacyjnej zbudował w kilka weekendów kalkulator wycen z panelem dla handlowców. Wygląda dobrze, liczy poprawnie, trzy osoby używają go codziennie. Potem przychodzi prośba: „dodajmy rabaty dla stałych klientów”. AI dopisuje rabaty i przy okazji psuje eksport do PDF. Poprawka PDF psuje logowanie. Po tygodniu nikt nie wie, która wersja była dobra, a właściciel boi się dotknąć czegokolwiek, bo narzędzie, na którym stoi sprzedaż, wisi na jego prywatnym koncie w serwisie, którego nikt inny w firmie nie zna.

To nie jest porażka. To normalny moment w życiu aplikacji zrobionej z AI: pomysł się sprawdził, ludzie z niej korzystają, a sposób budowania, który świetnie działał na starcie, przestał wystarczać. Poniżej opisujemy, co wtedy zwykle znajdujemy w kodzie, jak decydujemy, czy ratować, czy przepisywać, i jak wygląda przejęcie krok po kroku.

Dlaczego aplikacja zrobiona z AI w pewnym momencie przestaje się dawać rozwijać?

Pierwsze tygodnie są zachwycające. Opisujecie, co ma być na ekranie, i to po prostu jest. Kłopot zaczyna się, gdy aplikacja rośnie.

• AI nie widzi całości. Model pracuje na tym, co ma przed sobą w danej chwili. Przy kilkudziesięciu plikach przestaje pamiętać, że funkcja liczenia rabatu już istnieje, i pisze drugą, trochę inną. Po miesiącu są trzy wersje tej samej logiki, a każda poprawka trafia tylko do jednej.
• Poprawia objaw, nie przyczynę. „Przycisk nie działa” kończy się dopisaniem warunku, który omija błąd, a nie usunięciem błędu. Takie obejścia się nawarstwiają.
• Nikt nie podejmował decyzji o konstrukcji. Jak ułożone są dane, kto ma do czego dostęp, co się dzieje, gdy dwie osoby edytują to samo. Te rzeczy „wyszły same”, a wychodzą różnie.
• Nie ma historii zmian. Bez repozytorium z historią nie da się wrócić do wersji sprzed tygodnia. Każda zmiana jest skokiem bez asekuracji.
• Twórca nie ma już czasu. Często to właściciel, stażysta albo znajomy freelancer. Projekt, który był weekendową zabawą, stał się systemem firmowym, a nikt nie dostał etatu na jego utrzymanie.

Znajomy objaw: rozmowa z AI kręci się w kółko. „Naprawiłem błąd”, a błąd jest dalej. Pięć prób, każda z pewną siebie odpowiedzią. To znak, że problem przestał być do naprawienia na poziomie pojedynczej zmiany.

Co najczęściej znajdujemy w kodzie napisanym przez AI?

Każdy projekt jest inny, ale pewne rzeczy powtarzają się na tyle często, że sprawdzamy je zawsze, w pierwszej kolejności.

• Klucze i hasła w kodzie. Klucz do API modelu AI, do bramki płatności albo do bazy wpisany wprost w plik. Najgroźniej, gdy w części, którą pobiera przeglądarka: wtedy każdy odwiedzający może go skopiować i używać na Wasz rachunek.
• Otwarta baza danych. Aplikacje z generatorów często korzystają z gotowych baz w chmurze (Supabase, Firebase). Jeśli nikt nie ustawił reguł dostępu do wierszy, zalogowany użytkownik może odczytać dane innych użytkowników, a czasem może to zrobić każdy, kto zna adres. To głośny i bardzo częsty problem aplikacji z generatorów.
• Uprawnienia sprawdzane tylko na ekranie. Handlowiec nie widzi przycisku „usuń klienta”, ale serwer chętnie wykona to polecenie, jeśli ktoś wyśle je ręcznie. Ukryty przycisk to nie zabezpieczenie.
• Brak kopii bazy. Kod da się odtworzyć. Dane klientów, wyceny i zamówienia z ostatniego roku już nie.
• Martwy i zdublowany kod. Pliki z końcówkami „-old”, „-v2”, „-final-poprawione”, funkcje, których nic nie wywołuje, ta sama logika w kilku wersjach.
• Paczki z przypadku. Biblioteki dodane „bo AI tak zaproponowało”, część przestarzała, część z poprawkami bezpieczeństwa, których nikt nie wgrał. Zdarza się też, że AI podpowiada paczkę o nazwie, która nie istnieje albo należy do kogoś obcego, i to jest realna droga ataku.
• Brak obsługi błędów. Gdy zewnętrzna usługa nie odpowie, aplikacja pokazuje pusty ekran albo, co gorsze, liczy dalej z zerem w miejscu brakującej wartości.
• Wszystko na prywatnym koncie twórcy. Hosting, domena, baza, konto płatności, poczta wysyłkowa, klucz do AI. Jeśli ta osoba odejdzie albo zapomni hasła, firma traci system.
• Rosnący rachunek za AI. Aplikacja pyta model AI przy każdym odświeżeniu strony o to samo, bez zapamiętywania wyniku. Przy kilku użytkownikach nie widać. Przy kilkudziesięciu widać na fakturze.

Żeby było uczciwie: w takim kodzie jest też dużo dobrego. Ekrany są zwykle czytelne, a logika biznesowa trafiona, bo autor zna swój proces lepiej niż jakikolwiek zewnętrzny programista. Właśnie dlatego przejęcie najczęściej opłaca się bardziej niż start od zera. Zabieramy wiedzę o procesie, która już jest zapisana w działającej aplikacji, i dokładamy do niej to, czego brakuje.

Ratować czy przepisać od nowa? Jak o tym decydujemy

Decyzję podejmujemy po przeglądzie, nigdy przed. Na pierwszej rozmowie nie da się uczciwie powiedzieć „to do wyrzucenia” ani „to wystarczy podrasować”.

Ratujemy, gdy aplikacja działa i ma użytkowników, dane są ułożone w miarę sensownie, a technologia jest popularna (React, Next.js, Vue, Supabase albo Postgres, Laravel, Python). To większość przypadków. Łatamy, porządkujemy, rozwijamy.

Przepisujemy fragment, gdy jeden moduł jest wyraźnie gorszy od reszty. Często to rozliczenia, uprawnienia albo import danych. Reszta zostaje, a ten kawałek budujemy porządnie i podmieniamy.

Budujemy od nowa, gdy aplikacja jest zamknięta w platformie bez możliwości eksportu kodu, gdy sposób zapisu danych uniemożliwia dalszy rozwój albo gdy dziur bezpieczeństwa jest tyle, że łatanie byłoby droższe niż nowa konstrukcja. Nawet wtedy stara wersja nie idzie do kosza. Jest najlepszą specyfikacją, jaką można mieć: pokazuje ekrany, przypadki szczególne i reguły, o których nikt by nie pomyślał przy pisaniu wymagań. Dane przenosimy w całości.

Po przeglądzie dostajecie jasną rekomendację z uzasadnieniem i zakresem prac. Wybór należy do Was.

Jak wygląda przejęcie kodu krok po kroku

1. Rozmowa. Co aplikacja robi, kto z niej korzysta i jak często, co boli najbardziej, co chcecie dodać w najbliższych miesiącach. Nie musicie znać technicznych nazw. Wystarczy, że pokażecie, jak się z niej korzysta.

2. Dostępy na firmę. Repozytorium z kodem, hosting, domena, baza danych, konta usług zewnętrznych: płatności, wysyłka maili, klucz do AI. Przepinamy je na konta firmy. Nie na nasze. Aplikacja ma być Wasza także formalnie, żebyście nigdy nie byli zakładnikiem ani poprzedniego twórcy, ani nas.

3. Kopia i punkt zero. Pełna kopia kodu i bazy, zanim ktokolwiek cokolwiek zmieni. Zakładamy repozytorium z historią zmian. Od tej chwili każdą zmianę da się cofnąć.

4. Przegląd. Czytamy kod, sprawdzamy bazę, uprawnienia, klucze, zależności i koszty. Raport piszemy po polsku, bez żargonu, w trzech kolorach: czerwone (grozi wyciekiem danych albo ich utratą, robimy od razu), żółte (spowalnia rozwój albo podnosi rachunki), zielone (działa dobrze, zostawiamy).

5. Łatki pilne. Klucze wyjmujemy z kodu, przenosimy do bezpiecznego miejsca i wymieniamy na nowe, bo stare trzeba uznać za ujawnione. Ustawiamy reguły dostępu do bazy, kontrolę uprawnień po stronie serwera, automatyczne kopie bazy, aktualizacje paczek z lukami.

6. Porządek. Środowisko testowe obok tego, na którym pracuje zespół, żeby zmiany nie szły od razu „na żywo”. Testy na ścieżkach, które zarabiają pieniądze: wycena, zamówienie, logowanie, eksport. Usunięcie zdublowanej logiki. Krótka dokumentacja: jak to uruchomić, gdzie co leży, jak dodać nową funkcję.

7. Rozwój. Nowe funkcje w krótkich etapach. Każda zmiana najpierw na środowisku testowym, Wy sprawdzacie, dopiero potem trafia do zespołu. Rabaty dla stałych klientów wchodzą i niczego przy okazji nie psują.

8. Opieka. Monitoring błędów, aktualizacje, kopie, reakcja, gdy coś przestanie działać. Aplikacja ma opiekuna, a nie autora, który „kiedyś to zrobił”.

Czy po przejęciu dalej piszemy z AI?

Tak. Sami piszemy kod z AI na co dzień i nie zamierzamy udawać, że da się tego nie robić. Różnica nie polega na tym, czy AI pisze, tylko na tym, kto pilnuje całości.

• O konstrukcji aplikacji decyduje człowiek, który rozumie, jak to wszystko się łączy.
• Każda zmiana zaproponowana przez AI jest czytana, zanim trafi do aplikacji.
• Testy sprawdzają, że to, co działało wczoraj, działa dalej, więc „naprawiłem” można zweryfikować, a nie przyjąć na słowo.
• Projekt ma opisany kontekst: jak ułożone są dane, jakie są zasady w kodzie, czego nie ruszać. AI dostaje go przy każdej pracy i nie zgaduje.

Jeśli chcecie dalej sami dokładać drobiazgi z pomocą AI (nowe pole w formularzu, inny tekst maila), nie ma problemu. Ustalamy proste zasady: Wasze zmiany idą na osobną gałąź i środowisko testowe, a my rzucamy na nie okiem przed wdrożeniem. Dzięki temu zachowujecie tempo, które dało Wam AI, bez ryzyka, że jedna poprawka położy całą sprzedaż.

Z jakich narzędzi przejmujemy kod?

Z praktycznie wszystkich, którymi dziś buduje się aplikacje z AI. Każde zostawia po sobie trochę inny ślad, więc przy przeglądzie wiemy, gdzie szukać najpierw.

Lovable, Bolt, v0. Generatory, w których opisujecie aplikację słowami, a one budują ekrany i logikę. Pod spodem jest zwykle React, często z bazą Supabase albo podobną usługą w chmurze. Kod da się z nich wyeksportować albo zsynchronizować z GitHubem, więc przejęcie zaczyna się od przeniesienia go do repozytorium firmy. Najczęstsze kłopoty: reguły dostępu do bazy, logika trzymana w przeglądarce i klucze w kodzie frontu. Po przeniesieniu możecie dalej korzystać z generatora do drobnych zmian w wyglądzie albo zostawić go całkiem.

Replit i podobne środowiska w przeglądarce. Kod, baza i serwer w jednym miejscu, wygodne na start. Przy przejęciu przenosimy aplikację na hosting, który firma kontroluje, albo zostawiamy ją tam, gdzie jest, jeśli to ma sens, tylko na koncie firmy i z kopiami poza platformą.

Cursor, Claude Code, Copilot. Tu kod zwykle jest już w normalnym repozytorium i na zwykłym serwerze, a pisał go ktoś, kto choć trochę zna programowanie. Częściej trafiamy na zdublowaną logikę i brak testów niż na otwartą bazę. Przejęcie bywa szybsze.

„Z ChatGPT kawałek po kawałku”. Ktoś wklejał fragmenty kodu do czatu i z powrotem do plików na serwerze. Najtrudniejszy przypadek, bo zwykle nie ma ani historii zmian, ani jednej spójnej wersji, a czasem kod istnieje tylko na serwerze produkcyjnym. Zaczynamy od zabezpieczenia tego, co działa, dosłownie od skopiowania plików z serwera, zanim ktoś coś nadpisze.

Makra, skrypty i arkusze. Excel z makrami napisanymi przez AI, skrypt w Google Sheets, automat w Pythonie uruchamiany ręcznie z laptopa księgowej. To też jest kod, od którego zależy praca firmy. Często przenosimy go do zwykłego narzędzia z harmonogramem, żeby działał bez włączonego komputera konkretnej osoby.

Kiedy warto zgłosić się po pomoc, a kiedy jeszcze nie?

Nie każda aplikacja zrobiona z AI potrzebuje przejęcia. Prosty kalkulator dla jednej osoby, bez danych klientów, może spokojnie żyć tak, jak powstał. Sygnały, że pora na przejęcie, są inne:

• z aplikacji korzysta więcej niż kilka osób albo korzystają z niej Wasi klienci,
• są w niej dane osobowe, ceny, umowy albo pieniądze (płatności, faktury, rozliczenia),
• od niej zależy sprzedaż lub obsługa klienta, więc dzień przestoju realnie kosztuje,
• każda zmiana coś psuje, a rozmowy z AI o poprawkach kręcą się w kółko,
• tylko jedna osoba wie, jak to działa i gdzie jest, a ta osoba właśnie odchodzi albo nie ma czasu,
• rachunki za hosting albo za AI rosną szybciej niż liczba użytkowników.

Jeśli pasują dwa albo trzy punkty, przegląd zwraca się szybko. Jeśli pasuje jeden, a aplikacja jest mała, czasem wystarczy kilka godzin pracy: przeniesienie kont na firmę, kopia bazy i wyjęcie kluczy z kodu.

Na co uważać przy kodzie z AI: własność, dane osobowe, umowy

Do kogo należy aplikacja? W praktyce do tego, kto kontroluje konta: repozytorium, hosting, domenę i bazę. Dlatego przepinanie dostępów na firmę robimy w drugim kroku, a nie „kiedyś”. Jeśli aplikację budował freelancer albo zewnętrzna firma, sprawdźcie umowę, czy przenosi na Was prawa do kodu. Status praw autorskich do kodu wygenerowanego przez AI nie jest w Polsce jednoznacznie przesądzony, więc tym bardziej liczy się, kto ma klucze i co mówi umowa.

Dane osobowe. Jeśli w aplikacji są dane klientów albo pracowników, trzeba wiedzieć, gdzie fizycznie leży baza, czy dostawca hostingu i bazy ma z Wami umowę powierzenia przetwarzania i kto w firmie ma do tych danych dostęp. Przy aplikacjach z generatorów te pytania zwykle nikt sobie nie zadał.

AI wbudowane w aplikację. Jeśli aplikacja wysyła dane do modelu AI (na przykład streszcza maile od klientów), robi to na firmowym kluczu i według zasad dostawcy, inaczej grozi to blokadą konta i zatrzymaniem narzędzia. Opisaliśmy to szerzej w artykule o tym, za co można dostać bana na koncie AI. Jeśli aplikacja przekazuje modelowi treści z zewnątrz, takie jak maile czy pliki od klientów, model nie powinien mieć wtedy uprawnień do zapisu ani wysyłki. Taka treść może zawierać ukryte polecenia, które AI z uprawnieniami chętnie by wykonało.

Co przygotować przed pierwszą rozmową

Nie musicie wiedzieć, czym jest repozytorium ani reguła dostępu do wierszy. Wystarczy, że zbierzecie to, co macie:

• adres aplikacji i konto testowe, na którym możemy się rozejrzeć,
• informację, gdzie jest kod: platforma, w której powstał (Lovable, Bolt, Replit), GitHub, plik ZIP, serwer, komputer autora,
• listę kont i usług, z których aplikacja korzysta, nawet niepełną, i informację, na czyj mail są założone,
• kto z aplikacji korzysta i do czego,
• trzy rzeczy, które bolą najbardziej, i to, co chcecie dodać w najbliższych miesiącach.

Jeśli poprzedni twórca jest jeszcze w kontakcie, dobrze, żeby był pod telefonem przy przekazaniu dostępów. Jeśli nie jest, też sobie poradzimy, tylko pierwszy krok potrwa dłużej.

Macie aplikację, która działa, ale każda zmiana jest loterią? Umówcie 15 minut rozmowy. Pokażecie nam, co zbudowaliście, a my powiemy, jak przejąć to bez przerwy w pracy zespołu i co trzeba załatać najpierw. Zobaczcie też nasze realne wdrożenia. Która funkcja czeka u Was najdłużej, bo nikt nie odważył się jej dopisać?