Napisałem specyfikację, a agent napisał resztę. Eksperyment openspeckit.com

Skąd pomysł

Zacznę od obserwacji, która chodziła za mną od dłuższego czasu.

Kiedy pracuję z agentem kodującym, kod przestaje być tym, nad czym faktycznie pracuję. Pracuję nad opisem. Nad decyzjami. Nad kryteriami akceptacji. Kod jest tego konsekwencją i, co ważniejsze, jest odtwarzalny. Jeśli mam dobry opis systemu, mogę go wygenerować ponownie w innym frameworku, na innym hostingu, z innym modelem. Jeśli mam tylko kod, mam zamrożoną jedną z wielu możliwych implementacji.

To prowadzi do prostego wniosku: jeżeli kod jest odlewem, to specyfikacja jest formą. A formy warto przechowywać, wersjonować i wymieniać się nimi.

Tyle, że nie ma dziś miejsca, gdzie by się to robiło. GitHub przechowuje odlewy. Chciałem sprawdzić, jak wyglądałoby repozytorium form.

Czym jest Open Speckit

Open Speckit to katalog specyfikacji rozwiązań IT. Wszystkie na licencji MIT, wszystkie darmowe.

Pojedyncza specyfikacja to zestaw artykułów w markdownie ułożonych jako kroki wdrożenia albo moduły systemu. Do tego dołożyć można README ze zrzutami ekranu i opcjonalny artykuł CONSTITUTION z wymaganiami ogólnymi, które obowiązują w całym projekcie. Taką paczkę można pobrać i wkleić do dowolnego agenta w dowolnym środowisku. Ja akurat pracuję w Angular i Firebase, i przewodnik do ustawienia tego środowiska też załączam w Openspeckit.

Każdy, także niezalogowany, może przeglądać i pobierać publiczne specyfikacje. Zarejestrowani użytkownicy mogą dodawać własne, edytować je i tworzyć kolejne wersje. Są wersje, porównywanie wersji, duplikowanie cudzych specyfikacji, podział na prywatne i publiczne oraz na szkice i wersje produkcyjne. Jest też statystyka pobrań i aktualizacji, bo bez niej nie da się powiedzieć, czy cokolwiek z tego jest komukolwiek potrzebne.

Na czym polegał eksperyment

Chciałem sprawdzić dwie rzeczy naraz.

Pierwsza: czy da się zbudować kompletną aplikację, pisząc wyłącznie specyfikację. Nie „pomóż mi z tym komponentem", tylko jeden dokument opisujący cały produkt: model danych, reguły bezpieczeństwa, funkcje, kryteria akceptacji, kamienie milowe, a potem oddanie go agentowi.

Druga: czy specyfikacja jest wartościowym artefaktem sama w sobie. Czyli czy ktoś inny, mając mój opis, jest w stanie odtworzyć u siebie działający system, którego nie widział.

Sam dokument specyfikacji openspeckit.com miał dwadzieścia kilka sekcji: wymagania ogólne wyciągane na początku do osobnego pliku CONSTITUTION, ponumerowane wymagania funkcjonalne z kryteriami akceptacji, model danych w Firestore, intencję reguł bezpieczeństwa, spis funkcji chmurowych, strukturę katalogów aplikacji i dziewięć kamieni milowych ułożonych tak, żeby agent budował po kolei, a nie wszystko naraz.

To ostatnie okazało się najważniejsze.

Co wyszło, a co nie

Kolejność ma równe znaczenie co szczegółowość. Pierwsza intuicja jest taka, że im dokładniejszy opis, tym lepszy wynik. To tylko częściowo prawda. Dużo silniej działa podział na etapy z jasnym warunkiem zakończenia każdego z nich. Agent, który wie, że kamień milowy M1 kończy się działającym logowaniem i przetestowanymi regułami dostępu, robi znacznie mniej przypadkowych rzeczy niż agent, który dostał kompletną wizję produktu i wolną rękę.

Definition of done trzeba napisać wprost. U mnie brzmiała mniej więcej tak: kryteria akceptacji przechodzą, reguły bezpieczeństwa wymuszają autoryzację i mają testy, wszystko działa z klawiatury, istnieją stany ładowania, pustki i błędu, żadnego console.log i żadnego any w kodzie wysyłanym na produkcję. Bez tego dostaje się demo, nie produkt.

Decyzje architektoniczne trzeba podjąć przed, nie w trakcie. W specyfikacji zapisywałem jej wersje jako pełne opisy zamiast różnic. Tak było prościej a porównywanie staje się trywialne. Odbyło się to kosztem limitu rozmiaru dokumentu w Firestore. Gdybym tego nie rozstrzygnął zawczasu, agent podjąłby tę decyzję za mnie, w połowie pracy, i prawdopodobnie inaczej w dwóch różnych miejscach.

Czego nie da się zlecić oceny, czy produkt ma sens. Specyfikacja opisuje, co zbudować. Nie odpowiada na pytanie, czy warto. Nie powie nic na temat, tego, czy ktokolwiek kupi lub chociaż użyje danej funkcji lub całego systemu.

Od dużego do małego modelu Krytyczne jest, aby pierwszy prompt puszczony był na dużym modelu językowym, który potrafi sobie radzić z wielokrokowymi zadaniami. Taki model przewidzi odległe zależności i ograniczenia i od razu je wbuduje w logikę aplikacji. Później można stopniowo przełączać się na coraz mniejsze modele. Ja zaczynałem od Fable lub Opus, a przy dalszych mniejszych zmianach zwykle stosowałem Sonnet.

Druga hipoteza, ta ciekawsza

Jeżeli pierwsza część eksperymentu działa, to wynika z niej coś nieprzyjemnego dla całej branży.

Zbudowałem dla siebie tablicę kanban zamiast Trello. Whiteboard zamiast Miro. Narzędzie do zarządzania projektami zamiast MS Project. Bazę wiedzy z edytorem zamiast Google Docs. Wszystkie działają, wszystkie są dopasowane do tego, jak faktycznie pracuję, i żadnego z nich nie muszę odnawiać co rok. Co więcej, jak wczoraj przyszedł mi do głowy pomysł, aby w prywatnym edytorze tekstu zaznaczać kolorem, który użytkownik jest autorem danej linijki, to za pół godziny to miałem. Pewnie indywidualni użytkownicy nie są tak szaleni, aby pisać własne aplikacje do każdej potrzeby, ale już firmy mogą to rozważyć. I znam pierwsze korporacje, które zdecydowały się na tworzenie repozytorium procesów, systemu do zarządzania portfelem projektów, czy narzędzi do szkoleń.

W Verbalu mamy już ponad sześćdziesiąt takich narzędzi. I to wszystko w kilka miesięcy.

Jeżeli każdy użytkownik może odtworzyć rozwiązanie i dopasować je do siebie, ceny SaaSu pod presją pójdą mocno w dół. Nie zniknie oczywiście wszystko. To, co żyje z danych, skali, integracji i zgodności, zostanie. Ale kategoria „prosty produkt w abonamencie za 12 dolarów miesięcznie od użytkownika" wygląda z tej perspektywy krucho.

Nie twierdzę, że to się na pewno wydarzy. Twierdzę, że warto to sprawdzić, i openspeckit.com jest właśnie takim sprawdzeniem.