Kod jest odlewem, speckit jego modelem

Przez dwadzieścia lat wersjonowaliśmy kod. Moja hipoteza jest taka, że za kilka lat będziemy wersjonować specyfikację, a kod stanie się produktem ubocznym, który się wyrzuca i generuje od nowa.

W poprzednim artykule, Nowa fala projektów - SDD kontra Agile, pisałem o skracającym się lead time i o tym, że to za szybkość dostarczenia biznes zapłaci. Wcześniej, w tekście SpecKit jako automatyczna procedura (SOP), opisywałem, jak przenieść speckit z IT do procesu biznesowego, żeby AI trzymała się firmowej procedury. Wtedy wydawało mi się, że to dwa osobne wątki. Teraz widzę, że to jeden i ten sam wniosek widziany z dwóch stron: jeżeli opis wystarczy, żeby powstało z niego działające rozwiązanie, to opis przestaje być dokumentacją. Staje się źródłem.

Zacznę od pewnej anegdoty przemysłowej. W dawnych odlewniach obok hali stała modelarnia. Trzymano w niej drewniane modele odlewnicze, czyli negatywy przyszłych korpusów, kół zębatych i pokryw. Model robiło się długo, ręcznie, z suszonego drewna, i pilnowało się go latami, bo odlew był tani, a model drogi. Jak odlew wyszedł krzywy, wyrzucało się odlew. A gdy w latach trzydziestych ktoś kupował od zakładu prawo do produkcji jakiejś maszyny, nie kupował konkretnych odlewów. Kupował dostęp do modelarni. Mam wrażenie, że w oprogramowaniu zbliżamy się do dokładnie takiego rozdzielenia i że kod właśnie przechodzi na stronę odlewów.

Skąd naszły mnie takie spostrzeżenia? Z obserwacji własnej pracy. Buduję Verbalu w pojedynkę i od wiosny robię to w podejściu spec-driven, o czym pisałem poprzednio. Zdecydowana większość czasu schodzi mi dziś na formułowaniu intencji: co to ma robić, dla kogo, jakie reguły obowiązują wszędzie, co ma się stać w przypadkach brzegowych. Kod powstaje w tle, w kilku agentach naraz, a ja zaglądam do niego przy przeglądzie planu technicznego i wtedy, gdy coś nie działa. I w pewnym momencie złapałem się na tym, że coraz rzadziej zmieniam kod. Zmieniam opis i każę napisać kod od nowa. W ten sposób wykonałem ponad 60 narzędzi i gier, aby zaimplementować je bez AI musiałbym poświęcić kilka lat.

Teza o regenerowaniu kodu brzmi rozrzutnie wyłącznie dopóty, dopóki uważamy kod za coś drogiego. Chirurgiczna zmiana w istniejącym kodzie wymaga, żeby ktoś ten kod najpierw zrozumiał, a rozumienie cudzego kodu to najdroższa czynność w całej naszej branży, tylko nikt jej tak nie nazywa w budżecie. Regeneracja modułu z opisu takiego kosztu nie ma. Przy spadających cenach tokenów zaczyna to być po prostu tańsze. Wyrzucamy odlew, zostawiamy model. Kod staje się stalą, którą wytapia się w piecu i można to robić wielokrotnie, a najwięcej pracy schodzi na przygotowani formy.

Tu mała dygresja osobista. W 2006 roku obroniłem doktorat z zarządzania wiedzą, dziedziny, o której swego czasu napisałem na tym blogu, że okazała się dość rozczarowująca. Ale jedna rzecz z niej została mi w głowie: cała ta mozolna historia z kodyfikacją wiedzy ukrytej. Nonaka nazwał to eksternalizacją, czyli momentem, w którym ktoś przekłada to, co umie, na coś zapisanego. Problem eksternalizacji zawsze polegał na tym, że była kosztowna i nikomu się nie opłacała. Programista wiedział, dlaczego ten warunek wygląda tak dziwnie, ale spisanie tego zajmowało pół dnia i nie dawało mu absolutnie nic. Dokumentacja była produktem ubocznym, a produkty uboczne często się zaniedbuje. To nie jest wada charakteru inżynierów, to całkiem racjonalna kalkulacja, oszczędność energii na rzeczy, które dają widoczną wartość.

I to jest, moim zdaniem, najciekawsza zmiana z całego tego zamieszania. Kiedy z opisu powstaje kod, to opis przestaje być produktem ubocznym i staje się produktem głównym. Nie piszę specyfikacji dlatego, że ktoś kazał, tylko dlatego, że bez niej nie mam czego zbudować. Po raz pierwszy od trzydziestu lat zachęta ekonomiczna do dokumentowania działa w tę samą stronę co zachęta do produkowania. Zarządzanie wiedzą przez dwie dekady próbowało zmusić ludzi do dzielenia się wiedzą warsztatami, wspólnotami praktyków i portalami intranetowymi, z efektami, jakie były. A wystarczyło, żeby wiedza spisana zaczęła się sama wykonywać, aby eksternalizacja wiedzy stała się procesem krytycznym w firmie.

Stwierdzenie, że „wysiłek się przesunie" to za mało konkretne, żeby dało się z tym cokolwiek zrobić, więc rozpiszę to na kawałki.

Wersjonowanie: dzisiaj tag wisi na commicie, zaś jutro będzie wisiał na wersji specyfikacji, a kod dostanie tylko notkę, z której wersji speckitu i na jakim modelu został wygenerowany.

Przegląd: code review zamienia się w spec review, czyli recenzujemy intencję zamiast implementacji i to recenzujemy po stronie biznesu a nie technologii, a to jest recenzja o dużo wyższej dźwigni, bo błąd w opisie reguły biznesowej kosztuje wielokrotnie więcej niż błąd w pętli.

Refaktoryzacja: przestaje mieć sens jako osobna czynność na kodzie, a zaczyna mieć sens na opisie, czyli rozbicie za dużego modułu albo wyciągnięcie powtarzającej się reguły do konstytucji.

Najciekawszy jest jednak diff. Diff kodu mówi, że zmieniła się linijka. Diff specyfikacji mówi, że zmieniła się reguła. Historia projektu przestaje być historią zmian technicznych, a staje się historią decyzji. Swoją drogą ciekawe, jak to wpłynie na zarządzanie projektami, zobaczymy sprinty intencji ułożone według limitu na tokeny?

I jeszcze testy, bo tu cała ta konstrukcja albo się trzyma, albo rozsypuje. Skoro kod jest wymienny, to jedynym niezmiennikiem między kolejnymi wersjami są testy akceptacyjne albo kryteria akceptacji. Przestają być weryfikacją implementacji, a stają się kontraktem. Podejrzewam, że będą jedynym artefaktem technicznym, który człowiek będzie chciał utrzymywać ręcznie.

Dług techniczny przy okazji nie znika, tylko zmienia adres. Dług specyfikacji to sprzeczne reguły, niedopowiedziane przypadki brzegowe, luki w wymaganiach i konstytucja, do której dopisano trzydziesty wyjątek. Jest równie kosztowny, ale jego naprawa może być wykonana szybciej, choć niekoniecznie taniej. Szybciej, albowiem tokeny LLM są konwertowalne na czas. Im więcej wydamy pieniędzy, tym szybciej otrzymamy rezultat. Tak to nie działa z zespołami ludzkimi dzisiaj.

Teraz uczciwie o tym, gdzie ta teza się wykłada, bo sobie dobrał przykłady. Po pierwsze dryf. W praktyce mnóstwo poprawek robi się na szybko w kodzie, bo tak jest w danej chwili wygodniej, a po dwóch miesiącach speckit opisuje system, którego już nie ma. To dokładnie ta sama choroba, która zabiła utrzymywanie dokumentacji, tylko pod nową nazwą. Jedno lekarstwo, jakie znam, to dyscyplina: zmiana wchodzi przez opis albo nie wchodzi wcale. Drugie lekarstwo to nadzór LLM/Architekta nad procesem produkcyjnym i wówczas to LLM/Architekt wyłapuje zmiany.

Po drugie stan produkcyjny. Aplikację zregenerujesz, bazy z danymi klientów nie. Migracje, wersje schematu, dane historyczne zostają po stronie kodu i infrastruktury i żaden opis tego nie zastąpi. Odpowiedzą na to może być architektura MCP, czyli rozmawianie ze sobą agentów z różnych obszarów i uzgadnianie wersji prawdy. Drugą odpowiedzią może być warstwa architektury, która planuje migracje danych i zgodność wsteczną.

Po trzecie skala, bo buduję rzeczy małe i średnie, i nie mam żadnych podstaw twierdzić, że ERP na kilkaset modułów da się opisać tak, żeby regeneracja miała sens. Podejrzewam, że gdzieś przebiega granica, przy której opis robi się równie skomplikowany jak kod, tylko mniej precyzyjny, i że nikt jeszcze nie wie, gdzie ta granica leży. Po czwarte niedeterminizm, bo model to nie kompilator i dwa uruchomienia tego samego speckitu dadzą dwa różne systemy, funkcjonalnie zbieżne, technicznie odmienne. Każda regeneracja wymaga więc pełnego przejścia testów.

Wracam jeszcze do wątku insourcingu z poprzedniego artykułu, bo speckit jako jednostka wymiany go wzmacnia. Dopóki wymienialiśmy się kodem, przejęcie cudzego rozwiązania oznaczało przejęcie cudzych decyzji technologicznych, czyli jego frameworka, jego bazy, jego konwencji, a przy okazji jego długu. Kiedy wymieniamy się opisem, przejmujemy samą intencję. Ten sam opis tablicy kanban zbudujesz w Angularze na Firebase albo w czymkolwiek innym, dołożysz pola, których wymaga twój dział, i wytniesz połowę funkcji, których nigdy nie użyłeś. I wtedy pytanie „ile kosztuje licencja na użytkownika" zaczyna brzmieć zupełnie inaczej. Nie dlatego, że własne rozwiązanie jest lepsze, bo zwykle nie jest, tylko dlatego, że jest twoje i kolejne miejsce kosztuje zero. Do tego służy konstytucja, to ona powinna trzymać w garści konwencję implementacji, standardy UI, czy struktury danych.

Sprawdziłem to na sobie i opisywałem już częściowo poprzednio. Zamiast Google Docs mam własną Wiki, napisaną w jeden dzień, w której piszę teraz ten tekst. Zamiast Trello mam własną tablicę kanban. Zamiast Miro własną tablicę do rysowania. Zamiast MS Project uproszczone narzędzie do harmonogramów kaskadowych. Zamiast Kahoot mam moduł quizzów. Zamiast ręcznego przygotowywania certyfikatów ma własny odpowiednik Canva. Dziesiątki licencji, które musiałbym zapłacić sprowadziłem do poziomu tokenów (łącznie około 1000 zł.) Żadne z nich nie wygrywa z oryginałem w porównaniu funkcja po funkcji, nawet nie próbuję tego twierdzić. Ale każde robi te dziewięćdziesiąt procent, których faktycznie używam, i daje się zmienić tego samego popołudnia, w którym przyszedł mi pomysł. Dzisiaj na przykład na wiki potrzebowałem możliwości czatowania z własnymi artykułami albo ich fragmentami. Trzy prompty i to mam.

I tu dochodzę do rzeczy, którą zrobiłem w praktyce. Skoro artefaktem mającym wartość jest opis, to potrzebne jest miejsce, w którym się go publikuje, wersjonuje i forkuje. Postawiłem takie miejsce: Open Speckit. Wszystko, co publiczne, jest na licencji MIT, do czytania i pobierania nie trzeba konta, nie ma planów płatnych i nie planuję ich mieć. W środku jest dokładnie ta struktura, o której piszę wyżej: README, konstytucja z regułami przekrojowymi, artykuły opisujące kolejne moduły, wersje semantyczne, niezmienne snapshoty, porównania wersji i forki z atrybucją. Pobiera się paczkę markdownu, wrzuca sekwencyjnie do swojego agenta i buduje.

Wystawiłem na start kilka rzeczy, w tym specyfikacje wspomnianej tablicy kanban, tablicy do rysowania i narzędzia do projektów kaskadowych. Verbalu ma dziś ponad sześćdziesiąt narzędzi zbudowanych w ten sposób, więc będę je publikował po kolei. I zapraszam każdego, kto zbudował coś z agentem i został mu po tym przyzwoity opis, żeby go wystawił, bo modelarnia jednego zakładu nikomu do niczego nie służy.

Podsumowując, stawiam poniższe hipotezy dotyczące tego, co się stanie z wysiłkiem wkładanym w wytwarzanie oprogramowania:

Proporcja odwróci się z przewagi implementacji na przewagę opisu i jego utrzymania. Repozytorium specyfikacji stanie się ważniejsze niż repozytorium kodu, a kod dostanie status odlewu. Testy akceptacyjne będą jedynym artefaktem technicznym utrzymywanym ręcznie, bo tylko one przetrwają regenerację. Dług techniczny zamieni się w dług specyfikacyjny i doczeka się własnych narzędzi pomiaru. Specyfikacja stanie się jednostką wymiany między organizacjami, czyli tym, co się kupuje, forkuje i publikuje. Granica opłacalności tego wszystkiego przebiega przy stanie i skali, więc im więcej danych produkcyjnych i im większy system, tym słabiej to działa.

Punkt ostatni uważam za najbardziej prawdopodobne miejsce, w którym cała ta konstrukcja się posypie, i chętnie posłucham, gdzie jeszcze. Ale i tak podejrzewam, że za kilka lat pytanie o to, ile linii kodu utrzymuje dany zespół, będzie brzmiało mniej więcej tak samo dziwnie, jak dzisiaj brzmiałoby pytanie odlewnika, ile odlewów trzyma w magazynie.