SDD-Anchored: specyfikacja jako kotwica w erze agentów AI

To jest sedno SDD-Anchored.

Poniedziałek, 9 rano. Odpalam trzy agenty na jednym epicu. Pierwszy buduje moduł płatności, drugi pisze serwis powiadomień, trzeci generuje panel admina. Wracam po obiedzie. Trzy PR-y czekają. Jeden wymaga drobnych poprawek, ale formaty odpowiedzi identyczne. Konwencje nazewnictwa spójne. Dwa z trzech z obsługą błędów według wzorca. Oszczędzam trzy godziny debugowania integracji.

Piątek, 17:00. Bug na produkcji. Naprawiam endpoint, dodaję walidację  , testy przechodzą, deploy leci. W poniedziałek nowy developer otwiera spec kontraktu API i widzi starą wersję. Bez tej walidacji. Agent generuje kolejny moduł na bazie nieaktualnego kontraktu. Testy przechodzą, bo testują zgodność ze specem. Z błędnym specem.

Te dwa poniedziałki to ta sama historia, z dwóch stron. Pierwsza mówi: specyfikacja zmienia jakość pracy z agentami AI. Druga mówi: specyfikacja, która rozsynchronizowała się z kodem, jest gorsza niż brak specyfikacji. Obie są prawdziwe. Jednocześnie.

Punkt wyjścia: co mówią dane

Zaczniemy od danych. Bo tutaj mamy coś twardszego niż opinie.

CodeRabbit przeanalizował 470 pull requestów z publicznych repozytoriów GitHub. Kod współtworzony z AI generuje 10,83 problemów na PR versus 6,45 dla kodu pisanego wyłącznie przez ludzi. 1,7 razy więcej. Błędy logiki biznesowej? 1,75×. Podatności XSS? 2,74×. Jedyny obszar, gdzie AI wypadło lepiej? Literówki.

GitClear zbadał 211 milionów zmienionych linii kodu z lat 2020–2024. Refactoring spadł z 25% do poniżej 10% zmian. Kopiowanie kodu wzrosło z 8.3% do 12.3%. Code churn, procent nowego kodu wymagającego poprawki w ciągu dwóch tygodni, wzrósł.

Qodo w ankiecie wśród 609 developerów: 65% raportuje, że AI pomija istotny kontekst podczas refaktoringu — to najczęściej zgłaszany problem kontekstowy. Osobna statystyka z tego samego raportu: wśród tych, którzy uważają, że AI obniża jakość, 44% obwinia brak kontekstu. Nie halucynacje. Nie ograniczenia modelu.

Zastrzeżenia? Poważne. CodeRabbit to mała próba z publicznych repozytoriów. GitClear pokazuje korelację, nie przyczynowość (mogły zadziałać inne czynniki). Qodo to ankieta deklaratywna: ludzie mówią, co myślą, nie co robią. Każde źródło z osobna jest dyskusyjne.

Ale analiza PR-ów, mining repozytoriów i ankiety, trzy niezależne sposoby mierzenia, prowadzą do podobnego wniosku: kod AI-assisted ma więcej problemów, a brak kontekstu jest jednym z głównych podejrzanych. Raport DORA 2025 od Google dodaje do tego obrazu: 90% wzrost adopcji AI koreluje z 9% wzrostem bug rate i 154% wzrostem rozmiaru pull requestów. Kluczowy insight DORA? „AI doesn't fix a team; it amplifies what's already there." To nie jest jeden dowód, to zbieżność sygnałów z różnych źródeł, choć każde mierzy coś innego.

Dlaczego ten brak kontekstu jest tak powszechny? Bo narzędzia AI zachęcają do pracy bez niego. Andrej Karpathy nazwał to „vibe coding". Piszesz prompt, czujesz flow, akceptujesz wynik. MIT Technology Review nie bez powodu opisał 2025 jako moment przejścia od vibe codingu do context engineeringu.

SDD adresuje ten problem przez specyfikację. To jedna z form dostarczania kontekstu, nie jedyna i nie udowodniona jako najlepsza. Ale najbardziej ustrukturyzowana, jaką branża dotąd wypracowała.

Trzy poziomy, różne rachunki

Spec-Driven Development to spektrum, nie binarny wybór. Trzy poziomy dojrzałości, każdy z innym stosunkiem kosztów do korzyści.

Spec-First to lista zakupów. Piszesz specyfikację przed kodem, dajesz agentowi, po zakończeniu zapominasz. CLAUDE.md z konwencjami, stackiem, pięcioma zasadami. Pół godziny na początku projektu. Dane Greptile mówią, że 67% repozytoriów korzystających z Claude Code ma taki plik — choć trzeba uczciwie dodać: obecność pliku to nie to samo co jakość specyfikacji. Pusty plik z jednym zdaniem i rozbudowany zestaw konwencji to ta sama jedynka w statystyce.

Spec-as-Source to drugi koniec: specyfikacja jest jedynym plikiem, który edytujesz, kod generowany automatycznie. Tessl eksperymentuje z tym podejściem. Futurystyczne, obiecujące, dziś bardziej wizja niż codzienność.

A pośrodku? Spec-Anchored. I o tym rozmawiamy.

Różnica między nimi jest najlepiej widoczna na diagramie przepływu:

Spec-First to jednorazowy strzał. Spec-as-Source to pełna automatyzacja. A Spec-Anchored? To dwukierunkowa synchronizacja — spec żyje obok kodu, oba ewoluują razem.

Anatomia SDD-Anchored

SDD-Anchored to podejście, w którym specyfikacja i kod żyją jako równorzędne artefakty w repozytorium, synchronizowane dwukierunkowo i walidowane w procesie review. Rozbieżności są aktywnie zarządzane.

Różnica wobec zwykłej dokumentacji? Strukturalna.

Dwa poziomy — i dlaczego akurat dwa

Cała konstrukcja opiera się na podziale na dwie warstwy.

Spec projektowy to . Pamięć długoterminowa projektu. ADR-y

wyjaśniają, dlaczego wybraliście tę bazę danych. Kontrakty API definiują kształt interfejsów. Opisy domen rysują granice bounded contextów. Reguły cross-cutting mówią, jak obsługujecie błędy, logowanie, autentykację.

Spec taskowy to . Pamięć robocza. Konkretne zadanie z acceptance criteria, ograniczeniami i wskazówkami. Agent bierze taska, CLAUDE.md odsyła go do odpowiednich fragmentów speca projektowego, i nagle ma pełen obraz: co zrobić, jak to zrobić, czego nie robić.

Dlaczego dwa poziomy? Trzy powody. Skala: spec projektowy dojrzałego systemu to kilkadziesiąt plików, dołączanie go w całości do każdego taska utopi okno kontekstowe. Cykl życia: ADR z stycznia jest aktualny w czerwcu, spec taskowy żyje godziny. Odpowiedzialność: spec projektowy pisze senior, spec taskowy może napisać każdy developer.

Anthropic dodaje do tego ważny niuans: kontekst to zasób o malejącej krańcowej użyteczności. Każdy dodatkowy token w oknie kontekstowym rywalizuje o uwagę modelu z tymi, które już tam są. Dobry spec koncentruje kontekst. Zły rozmywa go. Dwupoziomowa architektura to mechanizm, który daje agentowi tyle kontekstu, ile potrzebuje. Nie za mało, nie za dużo.

Przykłady speców projektowych

Każdy plik w  to osobny, fokusowany dokument. Oto fragment

:

A tak wygląda :

Widzisz różnicę? To nie jest jeden wielki dokument. To zestaw fokusowanych plików, które sprawdzasz przy każdym PR.

Praktyczny przykład: spec taskowy

Załóżmy, że budujesz endpoint do rejestracji użytkownika. Oto spec taskowy na poziomie Spec-Anchored:

To nie jest dokumentacja API. To kontrakt. Ktoś może wziąć ten spec i zaimplementować endpoint. Albo dać go AI. Albo użyć do code review: „Czy kod robi to, co spec mówi?"

Ten spec taskowy zakłada, że istnieje spec projektowy. Nie muszę pisać, że hasło ma być

hashowane bcryptem (to jest w ). Nie muszę opisywać, gdzie idzie walidacja (to

wynika z ). Spec projektowy definiuje JAK budujecie. Spec taskowy definiuje

CO budujecie. Razem dają spójność.

Workflow na co dzień

Jak wygląda codzienna praca z SDD-Anchored?

Dostajesz nowy task. Zanim otworzysz edytor, piszesz spec taskowy. 10–15 minut. Co ma się stać, jakie dane wchodzą, jakie wychodzą, co może pójść nie tak. Linkujesz odpowiednie fragmenty speca projektowego.

Dajesz to agentowi. Agent otwiera CLAUDE.md, podąża za linkami, wczytuje spec taskowy i generuje kod. Weryfikujesz wynik. Nie na zasadzie „wygląda OK", ale „czy kod implementuje to, co spec opisuje".

I najważniejsze: dwukierunkowa synchronizacja. Zmieniasz wymaganie, najpierw spec, potem kod. Odkrywasz coś w trakcie implementacji, aktualizujesz spec w tym samym PR. Kod i speczmieniają się razem.

ADR-y istnieją od 2011 roku (Michael Nygard). User stories z acceptance criteria to standard Agile. Contract-First API to element specyfikacji od dekady. SDD-Anchored zebrało sprawdzone wzorce i złożyło w spójny system. To, że GitHub Spec Kit, Amazon Kiro i Tessl doszły do podobnych wniosków niezależnie od siebie? To albo niezależne odkrycie tego samego wzorca, albo herd behavior. Prawdopodobnie trochę jedno i drugie.

Różnica w praktyce? Bez speca prompt brzmi: „Dodaj endpoint do rejestracji użytkownika" — agent zgaduje architekturę, konwencje, obsługę błędów. Ze specem projektowym i taskowym agent czyta kontrakt, rozumie, że Identity to osobny bounded context, wie, że walidacja formatów idzie do kontrolera, a reguły biznesowe do domeny. Generuje kod, który pasuje do reszty projektu. Bez zgadywania.

Najsilniejszy argument: koordynacja wielu agentów

SDD-Anchored ma sporo argumentów na swoją korzyść: transfer wiedzy, łatwiejszy onboarding, obiektywne code review, mniejszy cognitive load. Ale jeden wyróżnia się siłą. Co ważniejsze, będzie rósł.

Wyobraź sobie trzech agentów pracujących równolegle. Jeden pisze serwis płatności, drugi powiadomienia, trzeci dashboard. Bez wspólnego kontraktu? Trzy różne formaty odpowiedzi, trzy konwencje, trzy dni debugowania integracji. Ze wspólnym specem projektowym? Każdy agent czyta ten sam kontrakt. Te same konwencje. Trzy moduły, które pasują do siebie, bo czytały tę samą instrukcję.

Gartner zanotował wzrost zapytań o systemy multi-agent o 1445% (z niskiej bazy wyjściowej) między Q1 2024 a Q2 2025. VS Code w lutym 2026 dostał wbudowaną orkiestrację wielu agentów. Dziś koordynujemy dwa, trzy agenty. Za dwa lata będziemy orkiestrować kilkanaście na jednym epicu.

Ta korzyść rośnie nieliniowo. Przy dwóch agentach brak kontraktu to drobna niedogodność. Przy dwudziestu? Katastrofa architektoniczna. Agenty dopiero zaczynają mieć kanały bezpośredniej komunikacji (Agent Teams, multi-agent messaging), ale te rozmowy są efemeryczne. Specyfikacja jest trwałym artefaktem. Jedynym, który przetrwa zamknięcie sesji.

To jest argument z najsilniejszymi fundamentami logicznymi, i jedyny, który rośnie w siłę z każdym nowym agentem w pipeline'ie.

Uczciwe zastrzeżenie: kontrakt nie musi mieć formy specyfikacji Markdown. Mógłby to być zestaw testów kontraktowych (Pact), shared types w monorepo, albo coś, czego jeszcze nie wymyśliliśmy. SDD-Anchored jest jednym rozwiązaniem tego problemu. Nie jedynym logicznie możliwym.

Ciemna strona: pięć problemów, o których trzeba mówić

Spec drift - lekarstwo z efektami ubocznymi

Paradoks, o którym za mało się mówi: nieaktualny kontekst jest gorszy niż brak kontekstu. Gdy agent nie ma specyfikacji, zgaduje, ale programista o tym wie i sprawdza. Gdy agent ma specyfikację z zeszłego miesiąca, generuje kod zgodny ze starym kontraktem z pełnym przekonaniem. A programista, przyzwyczajony że „spec jest, więc jest dobrze", może przepuścić to na review.

Dwa oczywiste tryby awarii i jeden podstępny. Phantom references: spec taskowy odwołuje się do ADR-a, który nie istnieje, agent halucynuje konwencje. Niejawne założenia: spec nie opisuje interfejsu repozytorium, agent zgaduje z kodu. I ten najgorszy, kaskadowy drift: piątkowy hotfix zmienia format odpowiedzi API, spec kontraktu nie jest zaktualizowany, w poniedziałek trzy agenty budują moduły na bazie starego formatu. Testy przechodzą, bo testują zgodność ze specem. Z błędnym specem.

Augment Code szacuje maintenance tax na 1,5–2,5 godziny tygodniowo na programistę, ale to anegdotyczna ocena, nie niezależny pomiar, i nie udało się zweryfikować konkretnego źródła tej liczby. Pięciu devów, dwie godziny, cztery tygodnie: czterdzieści godzin miesięcznie. To nie jest katastrofa, ale zero to też nie jest.

Kontrpytanie jest równie ważne: ile godzin tygodniowo tracisz BEZ speca na debugowanie niespójnego kodu AI? Nikt nie porównał obu stron tego rachunku.

Widmo waterfalla

Marmelab napisał „Spec-Driven Development: The Waterfall Strikes Back". Scott Logic testujący GitHub Spec Kit zauważył, że workflow „specify → plan → tasks → implement" potrafi być ciężki nawet dla drobnych zmian. Na GitHubie ktoś wprost pisze: „SDD is a Waterfall model for AI agents."

Mają punkt. Ale jest fundamentalna różnica. Waterfall zakładał kompletność i niezmienność specyfikacji. SDD zakłada iterację. Piszesz spec rano, agent implementuje, odkrywasz edge case, wracasz, doprecyzowujesz. Cykl trwa godziny, nie miesiące.

Problem w tym, że Winston Royce w oryginalnym artykule z 1970 roku też pisał o powrotach do wcześniejszych faz. Waterfall też miał być iteracyjny. A i tak skończyło się na kaskadowej katastrofie. Prawdziwe ryzyko nie jest w samej sekwencji. Jest w organizacji, która wdroży SDD zbyt sztywno. Każda zmiana wymaga aktualizacji specu, review, walidacji w CI, approval od architekta. Ludzie zaczynają obchodzić własny proces. Commitują bez aktualizacji speca. Robią hotfixy „ręcznie". Mówią „zaktualizuję potem" i nigdy tego nie robią.

Proces, który ludzie regularnie obchodzą, jest procesem martwym.

Paradoks kompetencji

Pisanie dobrych specyfikacji wymaga głębokiego rozumienia domeny i architektury. Junior nie napisze ADR-a o wyborze wzorca komunikacji. A senior, który potrafi napisać dobrą specyfikację, prawdopodobnie potrafi też napisać dobry kod bez niej.

Ale ten paradoks ma kontrargument. Senior nie pisze speca dla siebie, pisze go dla agenta i dla juniorów. To transfer wiedzy, nie redundancja. Junior czytający 20 ADR-ów seniora uczy się architektury szybciej niż na jakimkolwiek kursie. SDD tworzy artefakty edukacyjne jako efekt uboczny normalnej pracy.

Problem w tym, że artefakty edukacyjne są tak dobre, jak ich jakość. Złe spece tworzą dezinformację jako efekt uboczny. A większość speców w dużych organizacjach będzie miernej jakości, bo specification theater (o tym za moment).

Junior jako „ewaluator speców", ktoś, kto waliduje zgodność kodu ze specyfikacją, to bardziej dostępna rola niż „spec author". SDD może nie demokratyzować pisania specyfikacji, ale demokratyzuje ich walidację. I to nie jest mało.

Tacit knowledge — co spec nigdy nie uchwyci

Endpoint  zwraca 422 zamiast 400 przy nieprawidłowym requeście. Dlaczego? Bo dwa

lata temu mobilny klient interpretował 400 jako „serwer niedostępny". To była rozmowa na Slacku, potem hotfix, potem „tak już robimy". Żaden ADR tego nie opisuje. Agent generuje nowy endpoint z 400, bo tak mówi standard HTTP. I spec został spełniony. Duch — nie.

Specyfikacja wychwytuje wiedzę, którą da się wyartykułować. Znaczna część wiedzy zespołu jest nieartykułowana, osadzona w praktyce, przekazywana ustnie, zapisana w konwersacjach, których nikt nie przeszukuje.

Z drugiej strony, jeśli agenty przejmują coraz więcej implementacji, to tacit knowledge musi zostać wyartykułowane, albo zginie. SDD wymusza tę artykułację. Niedoskonale.

Niekompletnie. Ale lepiej niż nic. To ograniczenie fundamentalne i żadna ewolucja narzędzi go nie rozwiąże w pełni.

Specification theater

Znasz security theater? Procedury, które dają poczucie bezpieczeństwa bez faktycznego bezpieczeństwa. Specification theater to to samo. Trzydzieści plików ADR, dwadzieścia kontraktów API, piętnaście opisów bounded contextów. Pięknie sformatowane, wersjonowane, walidowane w CI. I kompletnie oderwane od tego, co system naprawdę robi.

Scott Logic testując GitHub spec-kit opisał to zjawisko — generowane pliki specyfikacji były nadmiarowe i pełne powtórzeń (2577 linii Markdowna), trudniejsze do review niż sam kod. Colin Eberhardt oszacował, że jest „około 10 razy szybszy" bez SDD, uwzględniając cały workflow

łącznie z review generowanych specyfikacji — choć to subiektywna ocena jednej osoby, nie kontrolowany pomiar.

Steve McConnell opisał to w Professional Software Development jako „process-imposter organizations" — firmy, które obserwują sukces organizacji zorientowanych na proces i dochodzą do wniosku, że sekret leży w ilości dokumentów. Ale dokumenty to efekty uboczne dobrej inżynierii, nie jej przyczyna.

Za 3 lata będziemy mieli organizacje z „pełnym SDD pipeline'em", które produkują tyle samo bugów co wcześniej, ale z lepszym poczuciem kontroli. To ryzyko psychologiczne, nie techniczne, i żaden tooling go nie rozwiąże. 

Co naprawdę mówią dane 

Zobaczmy, ile z tego faktycznie wiemy.

Te liczby podważają centralne twierdzenie SDD. Centralne pytanie metodologii, czy zysk z pisania i utrzymywania specyfikacji przewyższa koszt, nie ma odpowiedzi. Żadnego A/B testu. Żadnego kontrolowanego eksperymentu.

Warto też odnotować, że większość cytowanych raportów (CodeRabbit, GitClear, Qodo, Augment Code, Greptile) pochodzi od firm z komercyjnym interesem w wykazaniu problemu z jakością kodu AI, bo sprzedają narzędzia, które ten problem adresują. To nie dyskwalifikuje ich danych, ale kontekst motywacji jest ważny.

I jest powód, dla którego te dane mogą się jeszcze długo nie pojawić: kontrolowany eksperyment na SDD wymaga dwóch porównywalnych zespołów, porównywalnych projektów i 3–6 miesięcy pracy. Koszt: setki tysięcy dolarów. Nikt tego nie sfinansuje bez komercyjnego interesu. A firmy z komercyjnym interesem (GitHub, Amazon, Tessl) mają motywację, żeby wynik był pozytywny. To nie lenistwo branży. To strukturalna trudność.

Jest jeszcze paradoks METR, który powinien dać do myślenia. W jedynym znanym randomizowanym kontrolowanym eksperymencie z AI coding tools 16 doświadczonych developerów open-source było o 19% wolniejszych z AI niż bez. A przed eksperymentem przewidywali 24% przyspieszenie. Po eksperymencie, mając twarde dane, dalej wierzyli że AI pomogło o 20%. Percepcja rozjechała się z rzeczywistością o prawie 40 punktów procentowych. Kiedy ktoś mówi „spec się sprawdza" na podstawie osobistego doświadczenia, warto pamiętać o METR.

Czy to znaczy, że SDD nie działa? Nie. To znaczy, że nie wiemy, a „nie wiemy" to uczciwa odpowiedź, z którą da się pracować.

Birgitta Böckeler na blogu Martina Fowlera testowała trzy narzędzia SDD (Kiro, spec-kit, Tessl) i doszła do wniosku, że mimo rozbudowanych speców agenty nie podążały za instrukcjami i mylnie interpretowały opisy istniejących klas jako nowe specyfikacje do wygenerowania. To jedyny bezpośredni test narzędzi SDD w publicznej literaturze. Zasługuje na więcej uwagi niż pośrednie dane o jakości kodu AI. Böckeler użyła niemieckiego słowa Verschlimmbesserung — pogarszanie czegoś w trakcie próby ulepszenia. To kontrprzykład, który podważa centralny mechanizm SDD.

Thoughtworks umieścił SDD na Technology Radarze w pierścieniu Assess, z ostrzeżeniem, że branża „może ponownie uczyć się gorzkiej lekcji, że ręczne tworzenie szczegółowych reguł dla AI nie skaluje się".

SDD nie jest jedynym logicznym rozwiązaniem problemu kontekstu. TDD z agentem to też forma dostarczania kontekstu, i to maszynowo weryfikowalna. Iteracyjny dialog z AI też. Czysty kod z dobrym nazewnictwem też. Nikt nie porównał tych podejść ze sobą. Może TDD daje 80% korzyści za 20% kosztu formalnej specyfikacji. Może nie. Nie wiemy.

SDD i TDD nie muszą się jednak wykluczać. Spec mówi CO i DLACZEGO. Testy weryfikują JAK. Agent implementuje. Jeden pipeline, nie konkurencja.

Perspektywa przyszłości: most, nie cel

Jest teza, o której warto pomyśleć na koniec. Specyfikacja to nie lepsza dokumentacja. To pierwsza próba stworzenia protokołu komunikacji między ludzką intencją a maszynową realizacją.

Pomyśl o kontraktach API w mikroserwisach. Nie są „dokumentacją" serwisu — są interfejsem, bez którego serwisy nie rozmawiają. W świecie multi-agent to samo dzieje się ze specem.

Agent płatności i agent powiadomień nie muszą ze sobą rozmawiać. Muszą czytać ten sam kontrakt.

Problem w tym, że specyfikacja w Markdownie to nie HTTP. HTTP jest formalny, deterministyczny, walidowalny maszynowo. Markdown jest niejednoznaczny i zależny od interpretacji modelu. To nie jest protokół. To aspiracja do protokołu.

Trzy trendy zbiegają się. Autonomia agentów rośnie: Anthropic zaobserwował podwojenie długości najdłuższych sesji agentowych (z ~25 do ~45 minut) w ciągu trzech miesięcy (Q4 2025 — Q1 2026), a Codex potrafi pracować autonomicznie przez wiele godzin. Multi-agent staje się normą: MCP, A2A, orkiestracja w IDE, Agent Teams. Context engineering krystalizuje się jako odrębna dyscyplina.

Co to oznacza? Kilka scenariuszy, od optymistycznego do pesymistycznego.

SDD dojrzewa i staje się jak CI/CD. Spec-First staje się powszechne jak linter, Spec-Anchored jak code review. Narzędzia (Kiro, Spec-Kit, Tessl) dostarczają integracje, CI waliduje drift automatycznie. Problem: CI/CD miało 15 lat ekosystemu i jasny, mierzalny ROI. SDD nie ma jeszcze jednego kontrolowanego eksperymentu.

Modele stają się tak dobre, że SDD jest niepotrzebne. Agent czyta cały codebase i rozumie go jak senior z pięcioletnim stażem. Specyfikacja staje się redundantna jak mapa papierowa po GPS-ie. Obecne trendy idą raczej w kierunku dostarczania kontekstu z zewnątrz, ale modele robią postępy szybciej niż ktokolwiek prognozował. Scenariusz mało prawdopodobny w horyzoncie 3 lat, bo tacit knowledge i wieloagentowa koordynacja nie znikną nawet przy nieskończonym oknie kontekstowym. W horyzoncie 5–7 lat? Nie do wykluczenia.

Hybryda. Na to stawiałbym pieniądze. Spec projektowy zostaje, ale migruje z Markdowna do formalnych DSL-i. Spec taskowy zmienia autora: z pisanego przez człowieka na generowany przez agenta-orkiestratora i zatwierdzany przez człowieka. Human-in-the-loop zostaje, bo agenty nie osiągną 100% niezawodności w horyzoncie 5 lat.

Jak to może wyglądać za 2-3 lata?

Człowiek definiuje intencję. Agent dekomponuje na zadania. Człowiek waliduje dekompozycję. Agenty implementują. CI pilnuje spójności. Ludzka praca przesuwa się w górę stosu abstrakcji.

Jest jeszcze coś, co prawie wszyscy przegapili patrząc na teraźniejszość. Regulacje. EU AI Act zmierza ku pełnym wymaganiom dla systemów AI wysokiego ryzyka — Digital Omnibus package z listopada 2025 przesunął timeline do grudnia 2027 (Annex III) lub sierpnia 2028 (Annex I), ale kierunek jest jasny. Amazon Kiro jest już dostępny w AWS GovCloud — tooling SDD wchodzi do sektora regulowanego. Organizacje z udokumentowaną specyfikacją (ADR-y, historia intencji w Git) będą miały natywny audit trail. Za 2–3 lata to może nie być „nice to have", ale „compliance requirement" w fintechach, healthtech, govtech.

Ryzyko? Compliance-driven adoption prowadzi prosto do specification theater. Organizacje tworzące spece żeby przejść audyt, nie żeby dawać agentom kontekst. Tak jak polityki prywatności bywają copy-paste bez związku z rzeczywistością.

Gradient pewności: co robimy, co rozważamy, co obserwujemy

SDD to nie jedno „tak" lub „nie". To gradient.

Spec-First (CLAUDE.md + proste spece): ROBIMY. Bezkosztowe, bezryzykowne, natychmiastowa wartość. Nawet najostrzejszy sceptyk nie znajdzie kontrargumentu na pół godziny jednorazowej pracy.

Spec-Anchored (ADR-y, kontrakty, CI walidacja): ROZWAŻAMY. Logiczne, obiecujące, ale nieudowodnione ROI. Mierz na swoim projekcie. Twoje dane z twojego projektu są warte więcej niż wszystkie artykuły na ten temat. Ten włącznie.

Spec-as-Source (kod generowany ze speca): OBSERWUJEMY. Wizja bez danych. Narzędzia nie są gotowe.

Rekomendacja: zacznij inkrementalnie i mierz. Nie wierz, sprawdzaj.

Dzień 1. Stwórz CLAUDE.md. Pół godziny. Stack, konwencje, 3–5 zasad. To jest Spec-First i natychmiastowy efekt.

Tydzień 1. Przy następnym tasku napisz spec taskowy. 10–15 minut. Acceptance criteria, ograniczenia, linki do kodu wzorcowego. Daj agentowi zamiast gołego prompta. Porównaj jakość wyniku, ale porównaj mierząc, nie „czując". Paradoks METR mówi, że „czujesz" i „jest" to dwa różne wszechświaty.

Tydzień 2. Przy kolejnej decyzji architektonicznej napisz ADR. Pół strony. „Wybraliśmy PostgreSQL, bo X. Odrzuciliśmy MongoDB, bo Y." Żaden nowy developer nie będzie musiał pytać „dlaczego?". Agent też nie.

Miesiąc 1. Pełny obieg: spec taskowy → implementacja → review vs spec → aktualizacja. Zmierz: ile poprawek ze specem vs bez? Ile czasu zajął spec vs ile zaoszczędziłeś?

Dla CTO myślących długoterminowo: inwestycja w                                   dziś to fundament

pod orkiestrację kilkunastu agentów za dwa lata. Koszt jest umiarkowany. Wartość będzie rosła z każdym kwartałem, w miarę jak agenty stają się bardziej autonomiczne i liczne.

Równie ważne: nie rób z SDD religii. Hotfix piątku o 17:00? Napraw, spec zaktualizuj w poniedziałek. Dwuosobowy startup budujący MVP? CLAUDE.md wystarczy. System bankowy z dwudziestu developerami? Pełne Spec-Anchored ma sens. Dopasuj rygor do kontekstu.

Trzydzieści plików ADR dla CRUD-a z dwoma endpointami to specification theater w czystej postaci.

Jeden spec. Piętnaście minut. Zmierz wynik

Wróćmy do tych dwóch poniedziałków. W pierwszym trzy agenty wygenerowały spójny kod, bo czytały ten sam spec. W drugim nieaktualny spec doprowadził do kaskadowego błędu. Obie historie mówią coś istotnego.

Specyfikacja to narzędzie. Z realnymi korzyściami, realnymi kosztami i zaskakująco małą bazą twardych dowodów. Logika stojąca za nią jest mocna: kod AI bez kontekstu jest gorszy, wieloagentowa orkiestracja wymaga kontraktu, artykułowanie intencji wymusza myślenie. Ale logika to nie dowód. Przez dekady logicznym rozwiązaniem na złożoność oprogramowania były szczegółowe specyfikacje up-front. Nazywaliśmy to waterfall. Nie zadziałało. Nie dlatego, że było nielogiczne, ale dlatego, że koszty praktyczne przewyższały teoretyczne korzyści.

Czy SDD-Anchored powtórzy ten błąd? Może. Różnica, iteracyjność zamiast kompletności up-front, może okazać się fundamentalna. Albo niewystarczająca. Nie wiemy.

Co wiemy: idea artykułowania intencji jest trwała, nawet jeśli forma specyfikacji jest przejściowa. SDD-Anchored to most między światem, w którym ludzie piszą kod, a światem, w którym ludzie definiują intencje, a maszyny je realizują. Most potrzebny właśnie teraz, bo agenty są wystarczająco dobre żeby kodować, ale nie wystarczająco dobre żeby samodzielnie rozumieć kontekst.

Co jest po drugiej stronie? Tego nie wiemy z pewnością, ale kierunek jest czytelny: od pisania kodu do definiowania intencji, od Markdowna do formalnych języków, od review kodu do review zamiarów. Ludzka praca przesuwa się w górę stosu abstrakcji — od JAK, przez CO, do DLACZEGO.

Mosty mają to do siebie, że jak przejdziesz na drugą stronę, nie wracasz po most. Nie dlatego, że był zły. Dlatego, że spełnił swoją funkcję.

Następny task. Jeden spec. Piętnaście minut. Zmierz wynik. To jedyny sposób, żeby dowiedzieć się, czy ten most jest dla ciebie.

Źródła danych: CodeRabbit (470 PR), GitClear (211M linii), Qodo (609 devs), DORA 2025 (Google), METR RCT (16 devs), Greptile, Anthropic, Thoughtworks Technology Radar, Martin Fowler / Böckeler, Marmelab, Scott Logic, Red Hat Developer, Augment Code, GitHub Spec Kit, Amazon Kiro, JetBrains Junie.