Buduję od zera serwis internetowy, jakiego nigdy jeszcze nie udało mi się zbudować

W moim projekcie Summer of Code wszedłem właśnie w drugą fazę. Tym razem chcę nauczyć się tworzyć serwis internetowy od podstaw — taki, który ma własną bazę danych, konta użytkowników, rejestrację i płatności.

W pierwszej fazie stworzyłem znacznie prostszą aplikację: Focus Space, czyli pomodoro timer w kosmicznym klimacie. Nie miał kont użytkowników ani bazy danych. Wszystkie informacje zapisywał bezpośrednio w przeglądarce, w tzw. local storage. To było przede wszystkim ćwiczenie. Być może kiedyś jeszcze go rozbuduję.

Teraz zabieram się za coś znacznie większego.

Serwis nazywa się Captain Hook — Kapitan Hak. Nie chodzi jednak o bohatera z „Piotrusia Pana”, tylko o hook, czyli początek filmu, który ma przyciągnąć uwagę widza.

Captain Hook ma pomagać youtuberom tworzyć lepsze wstępy do filmów.

Jako twórca na YouTube dobrze wiem, jak ważne jest pierwsze 15, 30 czy 60 sekund materiału. W YouTube Analytics bardzo dobrze widać, jak wielu widzów odpada właśnie na samym początku. Ktoś zobaczył tytuł i miniaturkę, kliknął film, ale po kilkunastu sekundach stwierdził: „to jednak nie dla mnie” i wyszedł.

Dużo mówi się o tym, jak ważne są tytuł i miniaturka. I słusznie — można stworzyć najlepszy film na świecie, ale jeśli nikt go nie kliknie, niewiele z tego wynika. Powstało już sporo narzędzi pomagających twórcom wymyślać tytuły albo projektować miniaturki.

Znacznie mniej jest narzędzi pomagających w tym, co dzieje się już po kliknięciu.

A przecież wtedy zaczyna się drugi etap walki o uwagę widza: trzeba szybko pokazać mu, dlaczego warto oglądać dalej.

To jest też trudniejsze, niż się wydaje. My, twórcy, znamy cały film. Wiemy, co ciekawego wydarzy się za pięć minut i dlaczego temat jest interesujący. Przez to łatwo zapomnieć, że widz jeszcze tego nie wie.

Czasami już na początku wykładamy więc wszystkie karty na stół. To trochę tak, jakby rozpocząć recenzję książki od zdania: „To świetna książka, zdecydowanie warto ją kupić”. Widz dostał odpowiedź, więc po co ma oglądać resztę?

Nie chodzi oczywiście o sztuczne przeciąganie filmu. Chodzi o to, żeby dobrze opowiedzieć widzowi, dlaczego warto zostać — zaciekawić go, ale nie zdradzić wszystkiego od razu.

I właśnie w tym ma pomagać Captain Hook.

Najpierw specyfikacja

Przy okazji tego projektu uczę się też czegoś ważnego o programowaniu z AI.

Największą zaletą takich narzędzi jest to, że można powiedzieć AI: „zbuduj mi taką aplikację”, a ono naprawdę zacznie ją budować. Problem w tym, że może bardzo szybko zacząć tworzyć również rzeczy, których wcale nie chcieliśmy.

AI potrafi błyskawicznie pisać kod, ale równie szybko może pójść w złym kierunku.

Dlatego zanim zacznie się programowanie, warto dokładnie opisać, co właściwie ma powstać. Taki dokument nazywa się często PRD — Product Requirements Document. W prostych słowach: to szczegółowa instrukcja opisująca, co aplikacja ma robić, dla kogo jest przeznaczona i jak powinny działać jej najważniejsze elementy.

Przy Focus Space po prostu poprosiłem Claude'a, żeby pomógł mi stworzyć taki dokument, a później wspólnie go uzupełnialiśmy.

Tym razem chciałem podejść do tego bardziej metodycznie. Rozmawiałem z profesjonalnym programistą, który polecił mi wykorzystanie tzw. skills — gotowych zestawów instrukcji dla Claude'a, które prowadzą przez kolejne etapy projektowania produktu.

Zainstalowałem pięć takich skilli.

Pierwszy służy do dopracowania bardzo ogólnego pomysłu. Ja miałem już jednak dość konkretną wizję Captain Hooka, więc zacząłem od kolejnego: Interview Me.

I ten bardzo mi się spodobał.

Claude zadaje w nim pytanie po pytaniu, aż uzna, że ma około 95% pewności, że rozumie, co naprawdę chcę zbudować. Nie tylko to, co wydaje mi się, że powinienem mieć, ale jaki problem aplikacja ma właściwie rozwiązywać i jak powinna działać.

To okazało się bardzo przydatne, bo pomysł, który w mojej głowie wydaje się oczywisty, trzeba później przełożyć na znacznie bardziej precyzyjny język. Komputer nie domyśli się przecież, co miałem na myśli.

Dopiero wtedy przeszedłem do kolejnego etapu: Spec-Driven Development. Tutaj, jeszcze przed napisaniem pierwszej linijki kodu, powstaje bardziej techniczna specyfikacja całego serwisu.

Następny skill, Planning and Task Breakdown, bierze tę specyfikację i rozbija ją na konkretne zadania. Zamiast więc powiedzieć AI: „zbuduj Captain Hooka”, dostaję uporządkowaną listę małych kroków, które można realizować jeden po drugim.

Trochę odkładałem ten etap, bo wydawał mi się żmudny. I rzeczywiście trochę taki był. Ale bardzo dobrze, że go zrobiłem.

Jak nauczyć AI pisać dobre intro?

Pozostał jeszcze jeden ważny problem.

Captain Hook ma wykorzystywać AI do proponowania wstępów do filmów. Użytkownik opisuje na przykład: „Chcę zrobić film o tym, tym i tym. Jak mógłbym go zacząć?”.

Nie chciałem jednak, żeby AI po prostu wymyślało losowe, efektowne zdania. Zależało mi na tym, żeby korzystało ze sprawdzonych sposobów budowania narracji i zainteresowania widza — ale bez taniego clickbaitu.

Do researchu zaprzągłem więc najmocniejszy model Claude'a. Efektem było aż 14 różnych frameworków tworzenia intro.

I tutaj projekt trochę urósł.

Pierwotnie w specyfikacji zakładałem trzy czy cztery proste sposoby budowania wstępu. Nagle miałem czternaście frameworków, zasady wyboru odpowiedniego z nich oraz checklistę pilnującą, żeby wygenerowane intro nie było clickbaitem.

Musiałem więc wrócić do specyfikacji i ją przebudować.

Dopiero kiedy to wszystko było gotowe, zacząłem faktycznie pisać aplikację — zadanie po zadaniu, zgodnie z wcześniej przygotowanym planem.

Pierwsza działająca wersja

Pod koniec tygodnia Captain Hook już działał.

Oczywiście wyglądał koszmarnie: czarne tło, kilka szarych pól i praktycznie żadnego designu. Ale można było wkleić opis filmu, kliknąć przycisk i dostać propozycję intro.

Żeby było to możliwe, po raz pierwszy podłączyłem do własnej aplikacji API Claude'a. W praktyce oznacza to, że mój serwis może wysłać zapytanie do modelu AI i wykorzystać jego odpowiedź wewnątrz aplikacji.

To był dla mnie ważny moment, bo wcześniej czegoś takiego nie robiłem.

Musiałem też po raz pierwszy zacząć płacić za faktyczne używanie AI przez własny program. Na razie mówimy o kwotach rzędu kilkudziesięciu centów czy dolara podczas testów, ale szybko zrozumiałem, że przy budowaniu prawdziwej aplikacji każde takie zapytanie ma konkretny koszt. Dlatego podczas testowania przeszedłem na tańszy model.

Skoro mechanizm działał, mogłem przejść do przyjemniejszej części: projektowania wyglądu aplikacji.

Najpierw poprosiłem Claude'a o trzy różne propozycje identyfikacji wizualnej Captain Hooka. Wybrałem jedną z nich, ale zmieniłem główny kolor z kobaltowego niebieskiego na czerwony — skoro aplikacja jest skierowana do youtuberów, chciałem, żeby trochę kojarzyła się z YouTube'em.

Na podstawie tego systemu zaczęły powstawać pierwsze właściwe ekrany aplikacji.

Projektowanie z AI okazało się bardzo wygodne, ale też wyjątkowo „żarłoczne” pod względem limitów. Podczas jednej sesji prawie wykorzystałem cały dostępny limit i musiałem wrócić do projektu później, żeby dokończyć najważniejsze widoki.

Próbowałem też zrobić logo. Tutaj AI poradziło sobie znacznie gorzej. Mam dość konkretną wizję: prosty piracki hak, nawiązujący jednocześnie do nazwy Captain Hook i do „hooka” w filmie. Kolejne propozycje jakoś nie trafiały w to, co miałem w głowie.

Ale logo może poczekać.

Po pierwszym tygodniu — a właściwie około trzech niepełnych dniach pracy — miałem więc dwie rzeczy.

Pierwszą był gotowy projekt wizualny najważniejszych ekranów.

Drugą był brzydki, ale naprawdę działający Captain Hook, uruchomiony lokalnie na moim komputerze, który potrafił komunikować się z prawdziwym modelem AI i generować pierwsze testowe intra.

Na pierwszy rzut oka może się wydawać, że to niewiele.

Ale tak naprawdę zaszedłem już całkiem daleko. Duża część pracy nie polegała bowiem na samym pisaniu kodu, tylko na dokładnym przemyśleniu, co ten serwis ma robić i jak powinien działać.

Następny etap to baza danych, konta użytkowników i połączenie działającego „silnika” z zaprojektowanym wcześniej interfejsem. Czyli moment, w którym ten brzydki prototyp zaczyna powoli przypominać prawdziwy serwis internetowy.