Idea jako kod

Trzy tygodnie temu Antirez - twórca Redisa - opublikował wpis pod tytułem “Control the ideas, not the code”. Zawrzało. Sedno tego wpisu było takie: jeśli panujesz nad ideami stojącymi za twoim oprogramowaniem, przeglądanie kodu linia po linii w zatrważającej większości przypadków mija się z celem. Mówiąc bardziej dosadnie - jest zwyczajną stratą czasu. Przeglądanie 5000 linii wygenerowanego przez LLM kodu dziennie to nie jest kwintesencja inżynierii oprogramowania - to Ty stajesz się wąskim gardłem w procesie, który dobrze ułożony może przyspieszyć Twoją pracę w niesłychany sposób.

I moim zdaniem autor tego wpisu ma rację. A wpisem tym poruszył temat, o którym każdy w branży rozmawia w kuluarach, ale mało kto ma odwagę głośno powiedzieć, że to, chcąc nie chcąc, przyszłość inżynierii oprogramowania.

Po co właściwie był ten kod?

Czysty kod. Wzorce projektowe. Opisowe nazwy zmiennych, funkcji, klas czy metod. Cały ten narzut nazywany przez wielu “software craftsmanship” powstał z jednego prostego powodu: żeby ludzie mogli zrozumieć, co robi maszyna. Maszyny nigdy nie potrzebowały języka wysokiego poziomu. Wymyśliliśmy je dla siebie - jako pomost między naszym sposobem myślenia a tym, jak wykonuje kod maszyna.

I teraz tą warstwą zajmuje się coś innego.

Gdy agenci piszą większość kodu, “czytelny dla ludzi” przestaje być głównym kryterium. Kod oczywiście nadal musi być poprawny, bezpieczny, wydajny - ale to są cechy, które się waliduje z wykorzystaniem odpowiednich narzędzi i procesów, a nie cechy, które ktoś wypracowuje uważnym czytaniem linijka po linijce. I żeby była jasność - rzemiosło nie znika. Przenosi się gdzieś indziej.

Dokąd przenosi się ciężar

Skoro nie spędzasz już całych dni na czytaniu kodu, to co właściwie robisz?

Opisujesz ideę - na tyle precyzyjnie, żeby agent mógł ją zbudować. Definiujesz decyzje architektoniczne, user stories, kryteria akceptacji, faktyczne zachowanie, którego oczekujesz. Dobierasz narzędzia, które zwalidują to, co powstanie - testy, lintery, skanery bezpieczeństwa, benchmarki wydajności. Projektujesz workflowy, które wyłapią to, w czym model się pomyli.

To dokładnie ta sama pętla, o której pisałem w Dzień, w którym Twoje AI przestaje myśleć:

To, co redukuje ryzyko, to nie lepszy model. To lepsze narzędzia, klarowniejsze procesy i środowisko zbudowane tak, żeby wchłaniać niedoskonałości, a nie udawać, że ich nie ma.

Ta sama zasada, inna skala. Tam chodziło o ochronę przed modelem, który się pogarsza. Tutaj o budowanie oprogramowania, które od początku działa zgodnie z oczekiwaniami.

Środek ciężkości w inżynierii oprogramowania się przesuwa. Od pisania kodu do opisywania idei - oraz budowania środowiska, które te idee zamienia w działające systemy.

Idea - spójna i precyzyjna

Od kilku miesięcy buduję wokół tego założenia narzędzie o nazwie forge-md. Razem z zespołem testujemy też lżejszą, bardziej przenośną wersję tego samego modelu działania - sdd-starter, który jest swoistym drogowskazem jak budować software, żeby nie być wąskim gardłem. Jeden plik Markdown opisujący intencję, zestaw workflowów, które zamieniają go w specyfikację, i proces budowy, w którym każdą linię można powiązać z decyzją, którą de facto już podjąłeś.

„Idea” to nie kilka zdań w README. To zwięzły, ale kompletny artefakt: co budujesz, dla kogo, przy jakich warunkach brzegowych, z jakimi wyborami architektonicznymi, z jakimi narzędziami do zapewnienia jakości, z jaką definicją kompletności produktu. Przygotowana we właściwy sposób - produkuje kod, który spełnia te same standardy jakości, które do tej pory nazywaliśmy „czystym kodem”. Nie dlatego, że człowiek napisał go „pięknie”, ale dlatego, że dodaliśmy tam nieco determinizmu, a taki proces nie mógł wyprodukować niczego innego.

To właśnie mam na myśli mówiąc “Idea jako kod”. Nie „Napisz prompt i miej nadzieję”. Idea, doprecyzowana, jest źródłem. Kod jest artefaktem - efektem kompilacji.

Dokąd to wszystko może zmierzać

Niedawno Elon Musk doprowadził tę myśl do logicznego ekstremum, odpowiadając na podobny wątek:

Kod źródłowy zaczyna zmierzać tam, gdzie dziś jest assembler, a kolejnym krokiem będzie całkowite pominięcie kodu źródłowego - generowanie wydajnych binarek bezpośrednio przez AI.

Musk ma w zwyczaju definiować kierunki rozwoju, którymi branża zaczyna podążać dopiero po latach. Warto go potraktować poważnie, gdy nazywa kolejny.

Grady Booch - człowiek, który współtworzył UML - odbił piłkę w tym samym wątku:

Język o wystarczającej ekspresywności, precyzji i powtarzalności, żeby budować wykonywalne artefakty, to z definicji język programowania.

I on także ma po części rację.

Prawda jak zwykle leży pewnie gdzieś pośrodku. Czy pośrednia reprezentacja pozostanie kodem czytelnym dla człowieka, zmieni się w coś bardziej zwięzłego, czy ostatecznie zniknie w plikach binarnych - kierunek jest ten sam. Źródło prawdy przesuwa się wyżej: od znaków w pliku do intencji w specyfikacji. A im bardziej finalny artefakt staje się nieczytelny dla ludzi, tym bardziej idea musi być precyzyjna, bo czytanie tego, co powstało, przestaje być planem awaryjnym. To nie jest argument przeciwko temu kierunkowi. To argument, żeby poważnie potraktować specyfikację już teraz, zanim siatka bezpieczeństwa w postaci czytelnego kodu zniknie.

To wcale nie jest łatwiejsze

Chcę tutaj postawić sprawę jasno. Narracja, że AI sprawia, iż tworzenie oprogramowania staje się łatwe, jest błędna - i skrzywdzi tych, którzy w nią uwierzą.

Zrobienie tego dobrze wymaga więcej, nie mniej. Potrzebujesz architektury. Musisz rozumieć bezpieczeństwo, wydajność, testowanie, metodyki wdrożenia. Musisz wiedzieć, jakie narzędzia zestawić i jakie procesy egzekwować. Generaliści - ludzie, którzy potrafią łączyć kropki między warstwami - zyskują w tym modelu. Specjaliści dziedzinowi, których praca polegała na pisaniu konkretnego rodzaju kodu, tracą na tym.

Kluczowa umiejętność przesuwa się z implementacji w stronę specyfikacji i orkiestracji. I to jest inna praca - nie łatwiejsza, tylko inna.

Dlaczego to dotyczy czegoś więcej niż oprogramowania

Znajomy opowiadał mi kiedyś o rekruterze z jednej z firm FAANG, który zrobił na nim ogromne wrażenie swoją wiedzą i ekspertyzą. Potem dowiedział się, nad czym ta osoba faktycznie pracuje na co dzień: nad śmiesznymi uszkami i filtrami, które można doczepić do wideo w aplikacji społecznościowej.

Nie odbieraj tego jako krytyki człowieka ani produktu. Chodzi o to, co branża zrobiła z największymi umysłami. Ogromna energia - lata nauki, prawdziwa moc intelektualna - została wykorzystana do rozwiązywania problemów, które w szerszej perspektywie nie mają wielkiego znaczenia.

Ludzki mózg najlepiej pracuje na wysokim poziomie abstrakcji. Język naturalny to nasze podstawowe narzędzie komunikacji i rozumowania. Jeśli większość mechanicznego tłumaczenia z intencji na wykonywalny kod może wziąć na siebie agent, to pytanie nie brzmi, czy tracimy rzemiosło. Brzmi: co zrobimy z energią, którą dzięki tym zmianom odzyskamy.

Na świecie są znacznie pilniejsze problemy niż kolejny filtr na Instagramie. Jeśli opisywanie idei zastąpi pisanie kodu jako główna umiejętność, być może w końcu się nimi zajmiemy.

I to jest to, na co czekam z największą ekscytacją.