Co robić, gdy Twoja aplikacja zbudowana z AI psuje się o 2 w nocy (a nie jesteś programistą)

Zbudowałeś aplikację, nie pisząc ani linijki kodu. Działała przez cały tydzień. Potem o 1:47 w nocy pisze do Ciebie użytkownik, że przycisk rejestracji nic nie robi, a Ty budzisz się i widzisz świecący na szafce nocnej telefon.

Jeśli nigdy wcześniej nie musiałeś naprawiać działającej aplikacji, ten moment może być okropny. Nie czytasz kodu. Nie wiesz, co tak naprawdę znaczy „baza danych”. Nie masz pewności, czy to zepsute na poważnie, czy tylko dziwne, a ludzie, którzy normalnie by pomogli, śpią.

Oto spokojny, uporządkowany plan działania na to, co robić, gdy aplikacja zbudowana z AI się psuje, a Ty nie umiesz pisać kodu. Większość z niego dotyczy tego, żeby nie pogorszyć sytuacji — czyli tej części, przed którą nikt nie ostrzega.

Po pierwsze: nie redeployuj

Gdzieś w Twoim kreatorze aplikacji z AI jest przycisk z napisem w stylu „opublikuj ponownie”, „redeploy” albo „wyślij”. Zaraz będziesz mieć ochotę go nacisnąć. Na razie tego nie rób.

Naciśnięcie redeploya na na wpół zepsutej aplikacji może utrwalić zepsuty stan, wymazać wszelkie informacje diagnostyczne, które gdzieś się walały, i utrudnić każdemu — w tym samemu kreatorowi AI — ustalenie, co poszło nie tak.

Pierwszy ruch to zawsze patrzeć, a nie działać. Nie potwierdziłeś jeszcze nawet, co jest zepsute.

Krok 1 — Odtwórz problem samodzielnie

Otwórz aplikację w świeżym oknie przeglądarki — najlepiej w trybie incognito albo prywatnym, bo usuwa to wszelkie stare logowania czy pamięć podręczną, które mogą sprawiać, że u Ciebie coś działa inaczej niż u użytkownika.

Spróbuj zrobić dokładnie to, co zgłosił użytkownik. Jeśli napisał, że przycisk rejestracji nie działa, spróbuj się zarejestrować. Jeśli napisał, że panel jest pusty, spróbuj się zalogować i go otworzyć.

Szukasz jednej z trzech rzeczy:

Jest zepsute dla wszystkich. Trafiasz na ten sam problem. To w gruncie rzeczy najłatwiejszy do naprawienia rodzaj, bo jest powtarzalny.
Działa u Ciebie. To najtrudniejszy scenariusz, bo problemem jest coś w konkretnej sytuacji użytkownika (jego przeglądarka, jego konto, jego dane).
Jest niestabilne. Raz działa, a za drugim razem się psuje. To najbardziej stresujące, ale i najbardziej pouczające — zwykle oznacza, że coś przekracza limit czasu albo kończy się jakiś zasób.

Zapisz, którą z tych trzech rzeczy zaobserwowałeś. Będzie Ci potrzebna, gdy poprosisz o pomoc.

Krok 2 — Sprawdź oczywiste rzeczy zewnętrzne, zanim obwinisz swoją aplikację

Zaskakująco wiele momentów „moja aplikacja jest zepsuta” wcale nie dotyczy Twojej aplikacji. Zanim zaczniesz nurkować w kreatorze AI, sprawdź:

Czy sam internet działa? Otwórz kilka innych stron. Jeśli Twoje wifi szwankuje, Twoja aplikacja może być w porządku, a zepsuty możesz być Ty.
Czy sam kreator AI nie miał awarii? Większość kreatorów aplikacji z AI ma stronę statusu (wyszukaj nazwę produktu plus „status”). Jeśli mają kiepską noc, nie musisz rozgryzać niczego więcej.
Czy nie padło jedno z połączonych narzędzi? Jeśli Twoja aplikacja korzysta ze Stripe do płatności, usługi mailowej do powiadomień albo usługi bazodanowej do przechowywania danych, każde z nich może mieć awarię. Każde ma własną stronę statusu. Sprawdź te, od których zależy Twoja aplikacja.

Mniej więcej raz na pięć razy odpowiedź brzmi „to wcale nie moja aplikacja” i możesz wrócić do spania.

Krok 3 — Spójrz na komunikat błędu, nawet jeśli Cię przeraża

Jeśli Twoja aplikacja pokazuje ekran z tekstem — nawet wyglądającym na bełkot — przeczytaj go. Zrób zrzut ekranu. Zwłaszcza jeśli jest tam długi ciąg liter i cyfr (ludzie nazywają to „stack trace”; wygląda jak alfabetowa zupa, ale to najbardziej przydatna rzecz, jaką możesz mieć, gdy prosisz o pomoc).

Większość kreatorów aplikacji z AI ma też miejsce, w którym widać niedawne błędy. Może nazywać się Logs, Activity, Errors albo Console. Otwórz je. Nie musisz rozumieć większości tego, co widzisz — szukasz najnowszego czerwonego tekstu albo najnowszego błędu oraz godziny, o której się pojawił. Czas ma znaczenie: błąd z wczorajszego poranka raczej nie jest powodem, dla którego Twój użytkownik nie mógł się zarejestrować przed chwilą.

Skopiuj ten błąd. Za chwilę wkleisz go w pomocne miejsce.

Krok 4 — Zapytaj kreator AI, co się zmieniło

To ruch, którego nietechniczni twórcy używają najrzadziej. Otwórz czat z kreatorem AI i powiedz prostym językiem:

„Moja aplikacja jest zepsuta. Użytkownicy nie mogą się zarejestrować — przycisk nic nie robi. Oto błąd z logów: [wklej go]. Co zmieniło się w ciągu ostatnich 24 godzin i co może to powodować?”

Dobry kreator AI powie Ci, która z niedawnych zmian jest najbardziej prawdopodobnym sprawcą. Czasem rozpoznasz ją od razu („aha, wczoraj poprosiłem, żeby ładniej zrobił formularz, i to pewnie zepsuło logikę wysyłania”). Czasem wskaże coś, czego nie pamiętasz, żebyś dotykał, co też jest przydatne — oznacza, że zmieniło się coś automatycznie, na przykład zaktualizowało się połączone narzędzie.

Nie pozwól kreatorowi AI jeszcze zacząć wprowadzać poprawek. Wciąż jesteś w trybie diagnozy. Najczęstszy sposób, w jaki widziałem, jak ludzie pogarszają mały problem, to pozwolenie AI na „naprawianie” zanim ktokolwiek zrozumie, co jest zepsute.

Krok 5 — Zdecyduj, czy się cofnąć

Niemal każdy kreator aplikacji z AI pozwala wrócić do wcześniejszej wersji aplikacji. Czasem nazywa się to „history”, „versions”, „checkpoints” albo „rollback”.

Jeśli wyraźnie pamiętasz godzinę albo dzień, w którym aplikacja działała, cofnięcie się do tamtej wersji to najpewniejszy ruch. Kosztuje Cię to wszelkie zmiany, które wprowadziłeś w międzyczasie (a których być może i tak już nie chcesz), a daje działającą aplikację, do której się obudzisz.

Dobra zasada: jeśli zepsuta rzecz to coś, co użytkownicy robią codziennie (rejestracja, logowanie, płatność), najpierw się cofnij, a naprawiaj do przodu później. Działające-ale-nieaktualne zawsze bije zepsute-ale-bieżące.

Jeśli zepsuta rzecz to funkcja, którą dodałeś dzisiaj i od której nikt jeszcze nie zależy, możesz zostawić ją zepsutą do rana i naprawić z trzeźwą głową.

Krok 6 — Jeśli musisz pozwolić kreatorowi AI to naprawić

Jeśli cofnięcie nie jest możliwe albo postanowiłeś tego nie robić, pozwól kreatorowi AI zaproponować poprawkę. Dwie rzeczy do zapamiętania, gdy to robi:

Przeczytaj, co planuje zmienić, zanim zatwierdzisz. Nie zrozumiesz wszystkiego, ale rozpoznasz, czy edytuje jedną konkretną rzecz, czy przepisuje pół aplikacji. Małe, skupione zmiany są znacznie bezpieczniejsze niż rozległe o 2 w nocy.

Przetestuj poprawkę w najnudniejszy możliwy sposób. Nie pytaj po prostu „czy naprawione?” i nie ufaj odpowiedzi. Faktycznie wejdź sam do aplikacji w oknie incognito i zrób to, co było zepsute. Jeśli poprawka zadziałała, zepsuta rzecz teraz działa. Jeśli nie, nie akceptuj zmiany tylko dlatego, że kreator AI powiedział, że zadziałała.

Krok 7 — Odpisz użytkownikowi, nawet jeśli nie naprawiłeś

Użytkownik, który napisał do Ciebie o 1:47, nie oczekuje, że jesteś online. Ale jeśli jesteś, krótka odpowiedź znaczy więcej niż naprawa:

„Dzięki, że dałeś znać — właśnie się temu przyglądam. Napiszę, gdy tylko znów będzie działać.”

Jeśli to płacący użytkownik, ta jedna wiadomość decyduje o tym, czy będzie opowiadał ludziom, że odpowiadasz szybko, czy że go olałeś. Naprawa może poczekać do rana. Odpowiedź nie.

Większa lekcja: buduj aplikację tak, jakby mogła się zepsuć

Jeśli było to stresujące, jest jeden plus: to doświadczenie zmieni sposób, w jaki budujesz. Po pierwszym incydencie o 2 w nocy zaczniesz robić rzeczy inaczej:

Dodasz sprawdzanie statusu. Prosta strona, która mówi Ci, czy ważne części Twojej aplikacji działają, żebyś nie musiał logować się, by się tego dowiedzieć.
Będziesz trzymać kopię zapasową danych użytkowników. Większość kreatorów na życzenie wyeksportuje Twoje dane. Robienie tego raz w tygodniu zajmuje 30 sekund, a w najgorszym wypadku Cię ratuje.
Zapiszesz, od czego zależy Twoja aplikacja. Krótka lista każdego połączonego narzędzia (płatności, e-mail, baza danych, przechowywanie plików), żeby gdy coś się zepsuje o 2 w nocy, mieć listę kontrolną zamiast zgadywać.
Będziesz zmieniać jedną rzecz naraz. Gdy wprowadzasz 10 zmian jednocześnie i aplikacja się psuje, nie masz pojęcia, która zmiana ją zepsuła. Gdy wprowadzasz jedną zmianę naraz, wiesz.

Możesz zbudować aplikację bez kodowania. Możesz też utrzymać ją w działaniu bez bycia programistą — ale umiejętności, których to wymaga, różnią się od umiejętności budowania. Uczysz się ich głównie na własnej skórze, zwykle o niewygodnej porze.

Dobra wiadomość: za każdym razem, gdy się to zdarza, jest mniej straszne. Za trzecim razem jest irytujące zamiast przerażające. Za dziesiątym to po prostu zwykły wtorek.