Utrzymanie aplikacji zbudowanych z AI: czego nikt nie mówi o drugim tygodniu

Pierwszego weekendu z Proyecta wypuszczasz coś realnego. Działa. Twoi użytkownicy (albo Twój zespół, albo Ty sam w przyszłości) zaczynają tego używać. A potem jest poniedziałek i klient pisze maila: „Czy możesz dodać listę rozwijaną do filtrowania po regionie?”.

Witaj w świecie utrzymania. To ta część budowania aplikacji z AI, o której nikt nie mówi, i ta część, w której większość projektów albo staje się długofalowym aktywem, albo po cichu spada z urwiska. Dobra wiadomość jest taka, że utrzymanie aplikacji zbudowanej z AI to inne doświadczenie niż utrzymanie tradycyjnego kodu. Szczera wiadomość jest taka, że „inne” nie znaczy „darmowe”.

Co tak naprawdę oznacza utrzymanie

Kiedy zawodowi programiści mówią „utrzymanie”, mają na myśli mniej więcej cztery rzeczy:

Dodawanie małych funkcji, o które ludzie proszą po starcie.
Naprawianie rzeczy, które się zepsuły albo były źle od początku.
Nadążanie za zmianami poza Twoją aplikacją — dostawca płatności aktualizuje swoje API, pojawia się nowa przeglądarka, zmienia się kształt Twoich danych.
Sprzątanie, żeby baza kodu powoli nie zamieniła się w bagno.

W przypadku aplikacji zbudowanej z AI wszystkie cztery wciąż się dzieją. Zmienia się to, kto je wykonuje i jak ta praca się czuje.

Dobra wiadomość: możesz z nią rozmawiać

Oto część, której nikt Ci nie powiedział, kiedy kopiowałeś kod ze starych poradników. Z kreatorem aplikacji z AI utrzymujesz aplikację tak samo, jak ją zbudowałeś: opisując, czego chcesz.

Prawdziwy przykład. Pewna founderka, którą znamy, zbudowała mały CRM do swojej praktyki coachingowej — klienci, sesje, śledzenie płatności, wszystko. Trzy tygodnie po starcie klientka wspomniała, że chętnie zobaczyłaby, ile sesji odbyła w tym roku. Otworzyła aplikację i powiedziała: „Dodaj licznik »sesje w tym roku« do każdej karty klienta, pobierając dane z tabeli sesji, gdzie data przypada na 2026 rok”. Dwanaście minut później było to na żywo. Wróciła do coachingu.

Ta historia brzmi normalnie, dopóki nie przypomnisz sobie alternatywy: zaczepianie freelancera, czekanie dwa dni, płacenie 300 dolarów, przeglądanie PR-a, którego do końca nie rozumiała, i modlenie się, żeby nic innego się nie zepsuło. Pętla utrzymania nie jest szybsza dlatego, że AI jest mądrzejsze od freelancera. Jest szybsza, bo w pętli jest mniej ludzi.

Trudniejsza wiadomość: małe rzeczy się kumulują

Oto część, która zaskakuje ludzi. Aplikacje zbudowane z AI wyglądają na łatwe do zmiany, bo dodawanie rzeczy jest łatwe. Tym, co nie jest łatwe, jest utrzymanie spójności całości w miarę jej rośnięcia.

Kilka schematów, które widzimy, jak idą źle:

Przypadkowy gąszcz. Prosisz o „dodanie pola rabatu do kasy”. Sześć wersji później logika rabatu mieszka w trzech miejscach, a poprawne jest tylko jedno z nich. Nic się jeszcze nie zepsuło, ale następna zmiana będzie myląca.
Zapomniany wymóg. W marcu dodałeś „darmowa wysyłka powyżej 50 dolarów”. W maju prosisz AI o „przerobienie kasy, żeby obsługiwała karty podarunkowe”. Robi to. Zasada darmowej wysyłki zniknęła. Nikt nie zauważył przez dwa tygodnie.
Dryf. Twoja aplikacja zaczęła jako „narzędzie dla mnie”. Teraz używa jej Twój zespół. Model mentalny, na którym pracuje AI, to wciąż „dla mnie”, bo to powiedziałeś na początku. Nowe funkcje czują się dziwnie nie tak, a Ty nie potrafisz wskazać palcem, dlaczego.

Żadna z tych rzeczy nie jest porażką kreatorów aplikacji z AI. To porażki pamięci i wspólnego kontekstu — te same problemy, które ma zespół ludzkich programistów, tylko w innym kształcie.

Jak się ustawić

Zespoły, którym dobrze idzie z utrzymaniem, mają kilka wspólnych nawyków. Przeważnie nie są to nawyki techniczne. To nawyki dotyczące tego, jak opisujesz, czym jest Twoja aplikacja i co się zmieniło.

Prowadź dokument „czym jest ta aplikacja”. Jedna strona. Odbiorcy, cele, zasady („darmowa wysyłka powyżej 50 dolarów”, „nigdy nie wysyłamy maili w niedziele”, „kluczem głównym jest telefon, a nie e-mail”). Kiedy prosisz AI o zmianę czegoś, wklej odpowiednią zasadę do prompta. Nie omijasz inteligencji AI — karmisz ją kontekstem, którego nijak nie może zapamiętać.

Opisuj zmiany w kategoriach zachowania, a nie kodu. „Chcę, żeby użytkownicy widzieli swój filtr regionu zapamiętany między sesjami” to znacznie lepsza prośba niż „dodaj localStorage do filtra”. Pierwsza opisuje, czego chcesz; druga przepisuje jeden z piętnastu sposobów, by to zrobić — i prawdopodobnie nie najlepszy.

Wprowadzaj zmiany pojedynczo. Dwie zmiany w jednym promptcie oznaczają, że jedna może po cichu się nie udać, a Ty nie będziesz wiedzieć która. Najszybszy sposób na utrzymanie aplikacji z AI to trzymanie iteracji na tyle małych, byś mógł na pierwszy rzut oka stwierdzić, czy wynik jest poprawny.

Patrz na to, co się zmieniło. Większość kreatorów aplikacji z AI pokazuje Ci podgląd. Korzystaj z niego. Trzydzieści sekund, które spędzisz, klikając wokół, żeby potwierdzić, że nowa funkcja działa i stare funkcje wciąż działają, to najtańsze ubezpieczenie, jakie kupisz w tym roku.

Czego nie możesz zrobić (i prawdopodobnie nie powinieneś)

Pojawia się pokusa, kiedy już zbudujesz aplikację z AI, by myśleć, że ono może też tę aplikację za Ciebie obsługiwać. Nie może, a luka jest realna:

Nie powie Ci, kiedy coś po cichu się zepsuło. Logi, monitoring, dyżury — to wciąż osobna kwestia. Większość kreatorów aplikacji z AI nie obserwuje Twojej produkcyjnej aplikacji tak, jak robiłby to inżynier backendu.
Nie wie o świecie poza Twoją aplikacją. Jeśli dostawca płatności wycofa jakieś API, AI nie wie o tym, dopóki mu nie powiesz. Zapisz się na changelogi swoich dostawców. Czytaj maile.
Nie może podejmować za Ciebie decyzji produktowych. Czy dodać funkcję, jaki kompromis wybrać, czego naprawdę chcą Twoi użytkownicy — to wciąż Ty. AI to bardzo szybkie ręce; mózg jest Twój.

Realistyczny obraz

Po sześciu miesiącach z aplikacją zbudowaną z AI większość ludzi, z którymi rozmawiamy, ląduje gdzieś tutaj: spędzają może dwie do czterech godzin miesięcznie na zmianach, niemal wyłącznie w formie rozmowy. Wielkie przebudowy, których kiedyś się bali — „chcę dodać cały nowy dział” — czują się jak jedno dobre popołudnie. Nudne rzeczy — „format daty jest zły w eksporcie” — czują się jak jeden dobry prompt.

Tym, czego nie mają, jest ciągły szum w tle tradycyjnej bazy kodu: aktualizacje zależności, migracje frameworków, łatki bezpieczeństwa, konfiguracje buildów. Ten szum został wchłonięty przez platformę. Płacisz platformie za to, by się tym zajmowała, co jest znacznie lepszym układem niż płacenie programiście, by się tym zajmował.

Jeśli zamierzasz zbudować swoją pierwszą aplikację, wpis o tym, czym powinna być Twoja pierwsza aplikacja zbudowana z AI warto przeczytać, zanim zaczniesz. A jeśli jesteś już kilka tygodni dalej i czujesz niektóre ze schematów powyżej — to normalne. Napisz swój dokument „czym jest ta aplikacja” w ten weekend. Ty z przyszłości, za trzy miesiące, proszący o nowy panel, będziesz bardzo zadowolony, że to zrobiłeś.