Miałem pomysł na aplikację. Znajomy pokazał mi Lovable. Nie jestem programistą. Nie umiem programować. W dwa miesiące uruchomiłem swoją pierwszą aplikację. Ale po kolei…

Korzystanie z Lovable było przełomowym doświadczeniem. Dzięki funkcjonalności text-to-code zobaczyłem pierwszy prototyp swojej strony tytułowej  (landing page). Euforia skończyła się po kilku dniach. Dostępne tokeny znikały po kilkunastu minutach pracy z aplikacją. Trzeba było czekać do następnego dnia żeby kontynuować. Plan, że będę tworzył aplikację w weekendy skończył się tak szybko jak się zaczął. Ten sam znajomy podesłał filmik na YouTube, gdzie ktoś opowiadał o bardziej efektywnym sposobie tworzenia kodu z wykorzystaniem text-to-code.

Przełom.

Po obejrzeniu filmu było jasne, że ten alternatywny do Lovable proces tworzenia aplikacji nie będzie tak łatwy jak wcześniej. Ciekawość była jednak większa niż obawy. Zainstalowałem Visual Studio Code. Doinstalowałem Codex. Otworzyłem okno z Chat’em GPT i… czas przestał istnieć. Po 10 godzinach miałem landing page, założony lokalny serwer  i pierwszy zarys kolejnej strony z zalążkami logiki aplikacji.

Pierwsza istotna różnica w tym trybie tworzenia kodu, to brak ograniczeń czasowych. Budowałem aplikację tak długo jak chciałem. Jedynym ograniczeniem była długość pojedynczych czatów z Chatem GPT – ale o tym za chwilę.

Druga różnica. W tym trybie tworzenia uczyłem się nowych dla mnie określeń, używanych w świecie IT. Miałem wrażenie, że mój zasób specjalistycznego słownictwa podwaja się każdego dnia. Euforia powróciła. Rozwój aplikacji był wyraźnie zauważalny. 

Inżynier i System Architekt

Po kilku intensywnych sesjach odniosłem wrażenie, że w procesie tworzenia aplikacji uczestniczą inne „osoby”. Jakkolwiek dziwnie to zabrzmi, siadając do kolejnej sesji miałem wrażenie, że łączę się zdalnie z „zespołem”, który mnie wspiera. Zespołem dwuosobowym. Inżynierem – koderem oraz system architektem.

Z system architektem (Chatem GPT) ustalałem najlepszą w danej chwili strategię rozwoju aplikacji, otrzymywałem prompty przygotowane w oparciu o moje pomysły, wymagania i uwagi. Gotowe prompty przekazywałem Inżynierowi, który fizycznie tworzył kod, informował o zrealizowanych zadaniach oraz proponował kolejne etapy ewolucji kodu z punktu widzenia budowy aplikacji. 

Z każdym z nich komunikacja miała inny charakter. Chat GPT był bardziej „rozmowny”, proponował scenariusze, wskazywał na wady i zalety konkretnych rozwiązań. Reagował na emocje zawarte w komunikacji. W sytuacji kiedy kolejna zmiana powodowała regres, i pisałem że jestem tym zniecierpliwiony i nie widzę progresu, Chat GPT przyznawał rację, zmieniał podejście. Już nie proponował kolejnej modyfikacji „w ciemno” ale „zastanawiał” się nad sposobami w jaki można zdiagnozować zaistniałą sytuację, przed kolejnym promptem modyfikującym kod. Chaty przypominały kreatywną rozmowę prowadzaną w formie warsztatów. Czasem prosił o feedback z Codex, oceniał i akceptował albo sugerował kolejną zmianę „patcha”, który „doszczelniał’ to co zrobił Codex. 

Inżynier / Codex, jest bardzo oszczędny w komunikacji, „skupiony” na wykonaniu konkretnego zadania. Komunikacja z nim przypominała pracę z ekspertem, który dużo wie i potrafi, ale nie dzieli się wiedzą w tak spontaniczny sposób jak Chat GPT.

Emocjonalny roller coaster

Późne godziny nocne, kolejny prompt, wysyłka na Vercel, weryfikacja jak działa – satysfakcja. Działa tak jak zaplanowałem – mogę iść spać. 

Drugi scenariusz. Podobna pora, kolejny prompt, wysyłka na Vercel – biały ekran… wszystko się rozsypało, a zmiana polegała na dodaniu kolejnej, zdawałoby się drobnej zmianie funkcjonalności. Już nie mam siły ani ochoty tego analizować – trzeba iść spać. Ale sen nie przychodzi szybko. Jak bardzo to się rozsypało? Co będzie działać po naprawie, co przestanie, a co zacznie działać inaczej?

Kolejny dzień, kolejne prompty. Sukces, radość, błędy, rozdrażnienie… a może zacząć wszystko od początku? A może jeszcze spróbuję dodać kolejne narzędzie diagnostyczne? I tak bez końca. Ważne żeby się nie zniechęcić. Kolejne doświadczenia, wychodzenie z sytuacji, które wyglądały na beznadziejne pomogły utrzymać optymizm i chęć kolejnych poprawek. 

Zmęczony współpracownik

Komunikacja z chatem GPT oraz Codex’em odbywa się za pomocą czatu. Im dłuższy pojedynczy czat – tym wolniejsza komunikacja. Miałem wrażenie że mój „współpracownik’ odczuwa zmęczenie…Dotyczy to szczególnie chata GPT. Codex wydaje się być bardziej odporny na długą komunikację. Rozwiązaniem może być zamknięcie chata i otworzenie nowego. To pomaga powrócić do szybkiej wymiany na czacie ale… no właśnie, ale zawsze wiąże się to z ryzykiem zgubienia wątku z zamkniętego wcześniej czatu. Tak długo jak jesteśmy w jednym czacie, możemy „liczyć” na to, że nasz system architekt będzie pamiętał to, o czym „rozmawialiśmy” na początku czatu. Mam wrażenie, że trochę pomaga przeniesienie powiązanych czatów do jednego katalogu i otwieranie nowych w tym samym katalogu. To co działa, to przypomnienie ważnych zasad w pierwszym prompcie nowego czatu. Na przykład: „To jest kontynuacja pracy nad aplikacją XYZ, ograniczeniem są zasady polityki Vercel oraz ograniczona ilość funkcji, nie zmieniaj logiki aplikacji, przed wprowadzeniem nowej funkcjonalności zapytaj o wszystko co pomoże zbudować spójny prompt bez ryzyka regresu, itp.” To poprawiało jakość promptów tworzonych przez Chat GPT dla Codex w nowym czacie. 

Praca z niepoprawnym optymistą

Jeśli chat pisze, ze to jest finalny, precyzyjny, domykający, ostateczny prompt – nie wierz w to. Najczęściej nie jest – ale któryś z kolejnych taki właśnie będzie. Nie pozwól żeby Cię to zniechęciło – „on tak się komunikuje”. Nie trać czasu na czytanie wszystkich komentarzy chata, które podaje po wygenerowaniu promptu, takich jak: „Trzy powody dlaczego to zadziała …” – z reguły nie działa, szkoda twojego czasu. 

Czasem łatwiej rozwiązać problem z Codex’em, czasem z chatem GPT – eksperymentuj. Zmiany wizualne aplikacji szybciej zrobisz na czacie z Codex, wyświetlając zmiany na lokalnym serwerze. Zmiany są widoczne natychmiast. Budowanie logiki aplikacji, jej struktury, łatwiej przygotować z chatem GPT, który zrobi to bardziej kompleksowo.

Niech cie nie zmyli jego optymizm. Czasem poprosi o wklejenie jakiejś informacji zwrotnej i komentuje: „Super, Świetnie, to wystarcza w 100%, to jest to, tego szukaliśmy, teraz naprawiamy to raz i dobrze…” no i zaskakująco często, to jest dopiero pierwszy mały krok w procesie naprawiania lub tworzenia aplikacji.  

Niemożliwe jest realne

Z różnych stron i źródeł docierają do nas informacje o zagrożeniach i szansach jakie niesie za sobą popularyzowanie i szybki wzrost jakości sztucznej inteligencji. Jedną z niewątpliwych korzyści jest umożliwienie tworzenia aplikacji osobom takim jak ja, które nie mają pojęcia o tworzeniu aplikacji, kodowaniu… a dziś mogę to robić i czerpać z tego dużo radości i satysfakcji. A co Ty dzięki AI robisz dziś, co jeszcze niedawno było poza Twoim zasięgiem…?