Koniec kodowania „na czuja”! Niech żyje SDD!

Kilka miesięcy temu społeczność deweloperów została urzeczona nowym fenomenem: vibe codingiem. Założenie było upajająco proste — nie potrzebowałeś planu, schematu blokowego ani nawet głębokiego zrozumienia składni; wystarczyło opisać odczucie agentowi AI i patrzeć, jak kod się materializuje. To wydawało się magią, dopóki nie pojawił się pierwszy poważny błąd. Nagle to płynne doświadczenie zmieniło się w gorączkową pętlę „napraw to” i „teraz to się zepsuło”, pozostawiając programistę uwięzionego w rozmowie z maszyną, która straciła wątek.

Historycznie spędzaliśmy miesiące na dopracowywaniu wyczerpujących dokumentów wymagań, zanim napisano choćby jedną linię kodu — sztywny proces, który często tłumił innowacje; dziś często dostarczamy kod, zanim jeszcze zdecydujemy, co produkt ma właściwie robić — chaotyczny nawyk, który generuje ogromny dług techniczny. To napięcie zrodziło nowy paradygmat: programowanie sterowane specyfikacją (spec-driven development, SDD). Jest to pragmatyczny złoty środek, zaprojektowany, aby dać agentom AI tory, których potrzebują, bez powrotu do napompowanych metod kaskadowych (waterfall) z lat 90.

Kontrakt intencji

U podstaw programowania sterowanego specyfikacją leży tworzenie „źródła prawdy”, które mogą odczytać zarówno ludzie, jak i maszyny. Den Delimarsky z Microsoftu opisuje specyfikację jako „kontrolę wersji dla twojego myślenia”, a w praktyce funkcjonuje ona jako wiążący kontrakt. Zamiast rzucać w ekran niejasnymi promptami i liczyć na najlepsze, programista pisze zwięzły, ustrukturyzowany dokument, który dokładnie definiuje, jak kod powinien się zachowywać.

Z technicznego punktu widzenia ta zmiana rozwiązuje problem „dryfu kontekstu”. Agenci AI są genialni w egzekucji, ale mają tendencję do zapominania o „dlaczego” stojącym za funkcją po pięćdziesięciu rundach poprawek. Zakotwiczając proces rozwoju w specyfikacji, zapewniamy, że AI pozostaje asystentem, a nie nieprzewidywalnym elementem. Birgitta Böckeler z Thoughtworks identyfikuje trzy poziomy tej ewolucji: spec-first (najpierw specyfikacja), gdzie plan poprzedza kod; spec-anchored (zakotwiczony w specyfikacji), gdzie dokument pozostaje, by kierować utrzymaniem; oraz aspiracyjny spec-as-source (specyfikacja jako źródło), gdzie człowiek dotyka tylko specyfikacji, a kod bazowy pozostaje całkowicie „pod maską”.

Kiro: CLI architekta

Opracowany przez zdecydowany zespół wewnątrz AWS, Kiro to solidne narzędzie, które traktuje budowanie oprogramowania jak dyscyplinę inżynieryjną, a nie zgadywankę. Oferuje zarówno IDE, jak i CLI, ale jego prawdziwa moc tkwi w ustrukturyzowanych wymaganiach w formacie Markdown. Kiro wykorzystuje EARS (Easy Approach to Requirements Syntax), notację, która wymusza klarowność poprzez prosty wzorzec: KIEDY [warunek], SYSTEM POWINIEN [zachowanie].

Z perspektywy użytkownika pisanie wymagań EARS przypomina mniej „kodowanie”, a bardziej mapowanie logiki. Taka struktura pozwala Kiro generować testy oparte na właściwościach (property-based tests), które są znacznie bardziej kompleksowe niż standardowe testy jednostkowe, wychwytując przypadki brzegowe, które ludzki koder — lub AI sterowane „vibe’em” — prawdopodobnie by przeoczył. Co więcej, Kiro wprowadza koncepcję plików „sterujących”. Dokumenty te — product.md, tech.md i structure.md — działają jako niewidzialna infrastruktura projektu, zapewniając, że każdy fragment wygenerowanego kodu respektuje wybrany stos technologiczny i konwencje architektoniczne.

Spec Kit: Standaryzacja przepływu pracy agenta

Spec Kit od Microsoftu przyjmuje inne podejście, funkcjonując jako otwartoźródłowy most między trzydziestoma różnymi agentami kodującymi a ustrukturyzowanym, czterofazowym procesem. Podczas gdy vibe coding przypomina nieustrukturyzowaną burzę mózgów, Spec Kit przypomina profesjonalne warsztaty. Wprowadza zestaw komend typu slash — takich jak /speckit.plan i /speckit.analyze — które zmuszają agenta do zatrzymania się i pomyślenia przed rozpoczęciem pisania.

Paradoksalnie, dodając te „punkty oporu”, Spec Kit faktycznie przyspiesza rozwój. Zapobiega „pętlom halucynacji”, w których agent próbuje naprawić błąd, wprowadzając nowy, bardziej złożony błąd. Niezależnie od tego, czy budujesz nowy projekt od zera (greenfield), czy próbujesz rozplątać pofragmentowany kod spuścizny (legacy), Spec Kit stanowi konstytucję dla projektu. Przesuwa ludzkiego programistę z roli maszynisty do roli recenzenta, koncentrując się na logice wysokiego poziomu, podczas gdy agent zajmuje się topornymi szczegółami implementacji.

Tessl i rejestr umiejętności

Tessl wprowadza fascynującą warstwę do ekosystemu SDD: rejestr pakietów. Jeśli pomyślimy o kodzie jak o przepisie, Tessl dostarcza ustandaryzowane składniki i techniki gotowania poprzez swoje „kafelki” (tiles). Kafelki te zawierają proceduralne przepływy pracy (umiejętności), obowiązkowe standardy kodowania (zasady) oraz dokumentację, o którą agenci mogą pytać na żądanie.

W codziennych kategoriach używanie Tessl jest jak wręczenie agentowi AI karty bibliotecznej i zestawu zasad domowych. Instalując kafel SDD Tessl i po prostu prosząc agenta o „użycie programowania sterowanego specyfikacją”, przepływ pracy ulega zmianie. Agent przestaje zachowywać się jak służalcze autouzupełnianie i zaczyna działać jak młodszy inżynier, który zadaje pytania wyjaśniające i sporządza plan przed dotknięciem repozytorium. Ta przejrzystość jest kluczowa; przekształca nieprzejrzystą „czarną skrzynkę” generowania przez AI w widoczny, audytowalny proces.

Zenflow: Orkiestracja z weryfikacją

Jeśli inne narzędzia skupiają się na „co” i „jak”, Zenflow skupia się na „kto” i „gdzie”. Opracowany przez zespół Zencoder, Zenflow działa jako warstwa orkiestracji, koordynując wielu agentów AI do pracy równoległej bez uszkadzania bazy kodu. Traktuje każdą funkcję jako przepływ pracy, wykorzystując izolowane drzewa robocze Git (worktrees), aby zapewnić, że zmiany są testowane i recenzowane, zanim trafią do głównej gałęzi.

Patrząc szerzej na poziom branżowy, Zenflow reprezentuje ruch w stronę systemów „wieloagentowych”. W tym modelu jeden agent może pisać specyfikację, inny implementuje kod, a trzeci przeprowadza międzyagentowy przegląd kodu. Ten system kontroli i równowagi naśladuje wysokowydajny ludzki zespół inżynierski. Dla użytkownika rezultatem jest odporny cykl rozwoju, w którym nieudane testy wyzwalają automatyczne poprawki, a kod jest „dostarczany” dopiero po przejściu przez każdą bramkę weryfikacyjną.

Cicha zmiana w kompetencjach cyfrowych

Przejście od vibe codingu do programowania sterowanego specyfikacją ujawnia głęboką zmianę w naszej relacji z oprogramowaniem. Uświadamiamy sobie, że „magia” AI jest najskuteczniejsza, gdy kieruje nią ludzka intencjonalność. Tak jak zagraconą szafę łatwo zapełnić, ale niemożliwością jest się w niej odnaleźć, tak nieustrukturyzowaną bazę kodu łatwo wygenerować, ale nie sposób jej utrzymać.

Ostatecznie rozwój narzędzi takich jak Kiro, Spec Kit, Tessl i Zenflow sugeruje, że przyszłość programowania nie polega na zniknięciu rygoru technicznego, ale na jego ewolucji. Odchodzimy od ery „samotnego hakera” w stronę ery „architekta technicznego”. W tym nowym świecie nasza wartość jako ludzi nie tkwi w zdolności do zapamiętywania składni, ale w umiejętności definiowania jasnych, etycznych i wydajnych specyfikacji dla maszyn, które budują nasz świat.

Nawigując przez te zmiany, powinniśmy patrzeć na nasze cyfrowe narzędzia bardziej spostrzegawczym okiem. Następnym razem, gdy aktualizacja aplikacji wyda się przeładowana lub toporna, zadaj sobie pytanie: czy została zbudowana na podstawie specyfikacji, czy był to tylko vibe? Odzyskiwanie kontroli nad naszym oprogramowaniem zaczyna się od wymagania jasności, którą może zapewnić tylko dobrze napisana specyfikacja.

Źródła

• Dokumentacja AWS: Agent Kiro i standardy notacji EARS (2025-2026).
• Microsoft Open Source: Repozytorium Spec Kit i „Kontrola wersji dla myślenia” autorstwa Dena Delimarsky’ego.
• Thoughtworks Technology Radar: „Trzy poziomy programowania sterowanego specyfikacją” autorstwa Birgitty Böckeler.
• Oficjalny rejestr Tessl: Dokumentacja kafelków i umiejętności dla agentów AI.
• Blog inżynieryjny Zencoder: Orkiestracja Zenflow i mechanika bramek weryfikacyjnych.