Spec-driven development: gdy edytujesz spec, a nie kod

Jest pytanie, na które prędzej czy później natrafia każdy programista pracujący z agentami: jeśli agent pisze kod, to co właściwie piszę ja? Przez rok uczciwą odpowiedzią było „prompty i mnóstwo poprawek”. W 2026 roku wyłoniła się jaśniejsza odpowiedź, a ma ona swoją nazwę: spec-driven development. Piszesz specyfikację — precyzyjną, trwałą, wersjonowaną — a agent generuje z niej kod. Artefakt, który posiadasz, przesuwa się o poziom wyżej, z implementacji na intencję.

To już nie jest niszowy pomysł. Skoro około 84% programistów korzysta z narzędzi AI, a duża część nowego kodu jest dziś generowana maszynowo, dyscyplina ta przeszła z opcjonalnej w nośną. Powód to jedna celna obserwacja: „kod generowany przez AI jest z założenia wiarygodny, a nie z założenia poprawny”. Kompiluje się, dobrze się czyta, przechodzi oczywiste testy — i wciąż może po cichu odpłynąć od tego, co naprawdę miałeś na myśli. Spec to sposób, by przypiąć „to, co naprawdę miałeś na myśli” do formy, którą zarówno człowiek, jak i agent mogą sprawdzić.

Trzy etapy, kończące się w miejscu dość radykalnym

Ujęcie Martina Fowlera to najczystsza mapa tego, dokąd to zmierza — trzypoziomowy model dojrzałości:

Spec-first — piszesz spec dla zadania, używasz go do prowadzenia agenta, a gdy praca trafi do produkcji, spec zostaje odrzucony. Spec jest rusztowaniem. Większość zespołów zaczyna właśnie tutaj.
Spec-anchored — spec staje się żywym dokumentem, utrzymywanym przez całe życie funkcjonalności. Zmiany zaczynają się w spec; agent ponownie generuje kod, by się z nim zgadzał. Większość poważnych narzędzi do spec-driven development celuje dziś w ten poziom.
Spec-as-source — radykalny punkt docelowy: spec jest jedynym artefaktem, który edytują ludzie, a kod staje się ulotnym, skompilowanym wynikiem, którego nikt nie dotyka ręcznie. Źródło prawdy w repozytorium przenosi się o piętro wyżej.

Warto zatrzymać się nad tym, jak dziwny jest spec-as-source. Przez dekady traktowaliśmy kod źródłowy jako ten artefakt — rzecz pod kontrolą wersji, rzecz, którą recenzujemy, rzecz, którą posiadamy. Spec-as-source degraduje kod do statusu wyniku budowania, jak skompilowany plik binarny. Nie edytowałbyś ręcznie pliku wykonywalnego; w tej wizji nie edytujesz ręcznie również wygenerowanego kodu. Edytujesz spec i kompilujesz na nowo.

Spec jest dźwignią

To pokrywa się z czymś, co napisaliśmy w Orkiestrze agentów kodujących: gdy kierujesz zespołem agentów, Twój spec jest dźwignią — a niejasny spec nie tylko Cię spowalnia, lecz mnoży się przez każdego agenta, który na nim działa. Spec-driven development to ta intuicja zamieniona w przepływ pracy. Standardowa pętla ma cztery fazy: specify — co oprogramowanie ma robić, plan — jak je zbudować, implement w zwalidowanych przyrostach, validate, że kod spełnia spec. Każda faza wytwarza artefakt, który ogranicza następną, więc błąd ma mniej miejsc, gdzie może się ukryć.

I co kluczowe, spec przestaje być dokumentem, który piszesz raz i odkładasz do szuflady. Staje się żywą umową operacyjną, którą agent czyta przy każdym uruchomieniu — taką samą rolę opisywaliśmy dla kuratorowanego przez człowieka AGENTS.md. Wiodące frameworki czynią to wprost: GitHubowy Spec Kit utrzymuje constitution.md z nienegocjowalnymi zasadami, które stoją ponad każdym spec; OpenSpec organizuje pracę w foldery zmian zawierające propozycję, specyfikacje i zadania; BMAD przypisuje nazwane persony z własnymi regułami domenowymi. Różne kształty, jedna idea: spec to trwały, rządzący artefakt, a kod jest jego pochodną.

Krytyka, którą warto potraktować poważnie

Nieuczciwe byłoby sprzedawanie tego jako sprawy przesądzonej. Najostrzejszy sprzeciw pochodzi od Matta Pococka i zasługuje na rzetelne wysłuchanie: kierując wszystko przez „specyfikacje do kodu”, argumentuje on, „nie inwestujemy w projektowanie systemu. Wycofujemy z niego kapitał”. Obawa jest taka, że schludny spec może zatuszować brak prawdziwego myślenia architektonicznego — że da się wygenerować mnóstwo wiarygodnego kodu z spec, podczas gdy leżący u podstaw projekt po cichu gnije.

Dane dają tej krytyce zęby. Zmierzono, że doświadczeni programiści pracujący na dojrzałych bazach kodu są przy wsparciu AI o około 19% wolniejsi, co sugeruje, że w realnych systemach jakość bazy kodu i dyscyplina projektowa liczą się bardziej niż dopracowanie specyfikacji. Spec nie zastępuje wspólnego modelu mentalnego, czystej architektury ani wyczucia, które podpowiada, czego nie budować. Właściwe odczytanie nie brzmi „specyfikacje zastępują projektowanie” — brzmi „specyfikacje to miejsce, gdzie projekt zostaje spisany, żeby agenty nie mogły od niego odpłynąć”. Spec bez prawdziwego projektu za sobą pozwala jedynie szybciej wdrożyć niewłaściwą rzecz, co jest problemem złej pętli o poziom wyżej.

Dlaczego to właściwy zakład dla Azji Południowo-Wschodniej

Oto gdzie to ląduje dla regionu — i jest to to samo miejsce, w którym wciąż ląduje nasza teza. Spec-driven development przenosi wartościową, trwałą pracę do spisywania, co znaczy poprawnie — a to jest wiedza domenowa i jasne myślenie, nie wydatki na GPU.

Generyczny agent potrafi cały dzień generować wiarygodny kod. Czego nie potrafi, to wiedzieć, że kambodżańska lista płac musi obsłużyć konkretną regułę premii za staż, albo że formularz w języku khmerskim ma pole, które zagraniczny szablon pomija, albo jak lokalna spółdzielnia naprawdę księguje zbiory. Zakodowanie tych reguł w żywym spec to sposób, w jaki lokalna wiedza staje się trwałą, posiadalną własnością intelektualną — spec to najbardziej przenośna, trwała forma, jaką ta wiedza może przyjąć. Frontierowe laboratorium wygeneruje kod z Twojego spec za grosze. Nigdy nie napisze samego spec, bo nie zna Twojej domeny. Ta asymetria to miejsce przy stole, a jest to miejsce do pisania i myślenia — dokładnie takie, o którym wciąż twierdzimy, że region powinien je zająć.

Co z tego wynieść

Zacznij traktować spec jako pełnoprawny artefakt, a nie jednorazowy prompt. Przejdź od spec-first w stronę spec-anchored: utrzymuj spec przy życiu, zmieniaj go, zanim zmienisz kod, pozwól agentowi generować na nowo. Włóż swój prawdziwy wysiłek w projekt stojący za spec — bo spec jest tylko tak dobry, jak myślenie, które uchwyca. I zakoduj ciężko wywalczone reguły swojej domeny w specyfikacje i skille, które agent czyta przy każdym uruchomieniu, bo to tam Twoja przewaga się kumuluje.

Agent pisze teraz kod. Twoim zadaniem jest pisać — i nieustannie pisać — czym ten kod ma być. Edytuj spec, a nie kod.