Aplikacje pisane przez AI — szanse i pułapki

Rozmowa, która w naszej skrzynce pojawia się coraz częściej, wygląda mniej więcej tak: „Nie jestem programistą, ale przez weekend zrobiłem z ChatGPT działającą aplikację. Ona naprawdę działa. Co dalej?". I wiesz co? To wcale nie jest zły start. Taki prototyp to najlepsza specyfikacja, jaką klient może przynieść — pokazuje dokładnie, o co mu chodzi. Problem zaczyna się dopiero wtedy, gdy weekendowy prototyp ma zostać produktem: z prawdziwymi użytkownikami, prawdziwymi danymi osobowymi i prawdziwymi pieniędzmi. Wtedy trzeba wiedzieć, co w nim zostawić, a co zbudować od nowa.

Prototyp z AI to świetna specyfikacja

Przez lata najtrudniejszą częścią wielu projektów było ustalenie, czego klient właściwie potrzebuje. Dokument na czterdzieści stron potrafił znaczyć co innego dla zamawiającego, a co innego dla zespołu — i wychodziło to w najgorszym momencie, po miesiącach pracy.

Klikalny prototyp ucina te dyskusje. Widzimy ekrany, przepływ, logikę: co użytkownik wpisuje, co się dzieje po zapisaniu, gdzie są wyjątki. Możemy rozmawiać o konkretach zamiast o wyobrażeniach. Z tej perspektywy narzędzia AI zrobiły dla komunikacji klient–wykonawca więcej niż niejedna metodyka prowadzenia projektów. Serio.

Dlatego jeśli masz pomysł i wieczór wolnego — zrób sobie taki prototyp. To tani sposób, żeby sprawdzić pomysł na sucho i pokazać go komuś, zanim wydasz pieniądze na porządną budowę. Najlepiej pokaż go od razu kilku osobom z grupy docelowej: tam, gdzie się gubią, tam masz do poprawy proces, nie kod. Taka wiedza zdobyta za darmo przed startem projektu bywa cenniejsza niż niejedna godzina płatnej analizy.

Dla nas jako wykonawcy prototyp ma jeszcze jedną zaletę: skraca etap ustaleń. Mniej spotkań o tym, „jak to sobie wyobrażamy", więcej pracy nad tym, co ma powstać. To realnie widać w budżecie.

Pułapki, które wyłażą po starcie

Sęk w tym, że kod z prototypu wygląda na gotowy, a gotowy nie jest. Kilka rzeczy powtarza się niemal w każdym takim projekcie, który trafia na nasze biurko.

Bezpieczeństwo. Modele generują kod, który działa w scenariuszu pozytywnym — dla grzecznego użytkownika. Rzadko same z siebie dbają o to, co zrobi użytkownik złośliwy: wstrzykiwanie zapytań, obchodzenie uprawnień, klucze API zapisane na sztywno w kodzie, brak limitów prób logowania. W prototypie to nie boli. W produkcie z realnymi kontami — boli bardzo.

Dane osobowe. Jeśli aplikacja zbiera choćby adresy e-mail, wchodzisz w obowiązki wynikające z RODO: podstawa przetwarzania, zgody, prawo do usunięcia danych, umowy z podwykonawcami przetwarzania. Weekendowy prototyp zwykle nie wie, że te przepisy istnieją.

Kod, którego nikt nie rozumie. To pułapka najbardziej podstępna. Aplikacja działa, ale gdy po trzech miesiącach trzeba coś zmienić, okazuje się, że nikt — łącznie z autorem — nie wie, jak ona właściwie działa w środku. Każda poprawka to loteria, a model, poproszony o zmianę, potrafi „przy okazji" przepisać pół aplikacji i zepsuć rzeczy, które działały.

Utrzymanie i skalowanie. Prototyp obsługuje jednego użytkownika naraz — autora. Produkt musi obsłużyć setki osób jednocześnie, przeżyć aktualizacje, mieć kopie zapasowe i kogoś, kto zareaguje, gdy w nocy coś padnie. Do tego dochodzi wydajność: zapytania do bazy, które przy dziesięciu rekordach śmigają, przy stu tysiącach potrafią położyć cały serwis. Tego w wygenerowanym kodzie po prostu nie ma, bo nikt o to nie poprosił.

Zwróć uwagę na wspólny mianownik tych punktów: żaden nie jest widoczny w demo. Prototyp klika się pięknie i właśnie dlatego tak łatwo uwierzyć, że jest gotowy.

Przepisać czy rozwijać?

Uczciwa odpowiedź: zależy, i da się to ocenić dość szybko. Z prototypu prawie zawsze zostaje to, co najcenniejsze — przemyślany proces biznesowy, układ ekranów, reguły, które autor cyzelował na własnym przykładzie. Czasem da się też zostawić fragmenty kodu, jeśli są proste i przejrzyste.

Do przebudowy niemal zawsze idą fundamenty: logowanie i uprawnienia, obsługa płatności, warstwa danych, wszystko dookoła bezpieczeństwa. Im bliżej pieniędzy i danych osobowych, tym mniej sentymentu do wygenerowanego kodu.

Dobra wiadomość dla budżetu: budowa na podstawie prototypu jest zwykle sprawniejsza niż budowa od zera, bo najdroższy etap — odkrywanie, czego naprawdę potrzeba — masz już za sobą. Przenosimy logikę, nie linijki.

Praktyczna reguła, którą stosujemy przy ocenie: jeśli aplikacja ma być używana przez obcych ludzi, przechowywać ich dane albo przyjmować płatności — traktujemy prototyp jako specyfikację i budujemy porządnie, przenosząc logikę, nie kod. Jeśli to narzędzie wewnętrzne dla trzech osób w firmie, bez wrażliwych danych — bywa, że wystarczy audyt, uszczelnienie i można rozwijać to, co jest. Skrajności w obie strony są błędem: przepisywanie wszystkiego „dla zasady" bywa wyrzucaniem pieniędzy, a rozwijanie każdego prototypu „bo działa" kończy się telefonem do nas rok później, tyle że w nerwach.

Nasza rola: cywilizowanie takich projektów

Przejmowanie cudzego kodu to dla nas chleb powszedni — od lat zajmujemy się modernizacją starszych systemów, których autorzy dawno zniknęli. Aplikacje pisane przez AI to w gruncie rzeczy nowa odmiana starego zjawiska: system, który działa, ale wymaga kogoś, kto weźmie za niego odpowiedzialność.

Taki proces wygląda u nas zwykle tak: przegląd kodu i architektury, lista ryzyk w kolejności od najgroźniejszych, decyzja co zostaje, a co budujemy od nowa — i plan rozwoju rozpisany na godziny, przy jawnej stawce 125 zł netto. Po ustabilizowaniu projektu można zejść do trybu utrzymaniowego z mniejszym pakietem godzin, więc koszty nie zostają wysokie na zawsze. Bez straszenia i bez wyśmiewania prototypu, bo naprawdę uważamy, że to dobry punkt wyjścia.

Masz taki projekt w szufladzie albo, co gorsza, już w internecie z prawdziwymi użytkownikami? Pokaż nam go — obejrzymy i powiemy szczerze, w jakim jest stanie, co zrobilibyśmy najpierw i ile godzin by to zajęło. Czasem odpowiedź brzmi „śpij spokojnie, wystarczy kilka poprawek". A czasem dobrze, że napisałeś dziś, a nie za pół roku.