Spec-Driven Development
Kolega Łukasz K. pokazał mi w piątek wieczorem, jak w swojej firmie mają skonfigurowany design system razem z AI. Tak się składa, że spędziłem dwa osatatnie dni z moim tech leadershipem właśnie na tym, aby jeszcze bardziej przyspieszyć tworzenie produktów.
Zadałem na start naszych dwudniowych warsztatów jedno pytanie:
Wspólny panel pracodawcy ma powstać w kolejne trzy miesiące - na koniec maja. Czy jest mi w stanie ktoś udowodnić, że nie da się tego napisać nie w trzy miesiące, tylko w miesiąc?
Jest to prowokacyjne, bo tak jak nie da się udowodnić nieistnienia czegokolwiek (np. nie da się udowodnić nieistnienia Boga), tak samo tutaj, nie da się zaprzeczyć temu, że teoretycznie można zrobić coś szybciej.
W związku z tym czas zacząć to robić jeszcze mocniej z naszym kodem legacy.
W dobie AI, na teraz prawdopodobnie najlepszy sposób budowania dużych ficzerów to podejście spec-based: zacznij od minimalnego specu lub promptu, poproś Claude'a żeby przeprowadził z Tobą wywiad przez AskUserQuestionTool, a potem otwórz nową sesję do egzekucji specu.
A z perspektywy enterprise: SDD to workflow który separuje planowanie od egzekucji. Zamiast wchodzić od razu w kod, tworzysz serię dokumentów specyfikacji definiujących co budujesz, jak to zbudujesz i jakie kroki podejmiesz. Dopiero po review i aprobacie speców wchodzisz w implementację - i podczas tej fazy możesz pracować z minimalną ilością przerw.
Przed nami czas na wypracowanie naszego AI-workflow dla wszystkich zespołów, a przede wszystkim przygotowania specyfikacji dla siebie i AI. Teoretycznie ma to działać tak:
Faza 1 — Spec review (człowiek) Tech Lead + PM aprobują spec zanim napisana jest jedna linia kodu. To jedyny gate quality przed implementacją.
Faza 2 — Task decomposition (Claude) Claude rozbija spec na izolowane taski z zależnościami. Każdy task = osobna sesja = izolowany context window.
Faza 3 — Parallel execution Sub-agenci są wyspecjalizowanymi asystentami AI obsługującymi specyficzne typy zadań. Każdy działa w osobnym context window — to zapobiega "zanieczyszczeniu" głównej rozmowy i utrzymuje każdego agenta skupionego na jego odpowiedzialności.
Dla legacy: jeden subagent implementuje, drugi pisze testy, trzeci robi code review pod kątem kompatybilności z istniejącym kodem.
Konkretna różnica vs. jak działa teraz większość teamów
Bez systemu: Dev otwiera Cursor, pisze prompt "dodaj filtr lokalizacji", AI koduje opierając się na domysłach o architekturze, robi code review który znajdzie 5 problemów, 2 iteracje poprawek, merge za 3 dni.
Z systemem: /spec-init → Claude pyta "czy filtr ma działać po stronie FE czy BE?", "czy to dotyczy JJI, Rocket czy obu?", "co z legacy API?", "jak obsługujemy brak lokalizacji?" → spec gotowy w 20 min → legacy-safe-coder implementuje z pełnym kontekstem → /write-tests generuje testy regresji → PR-reviewer sprawdza pod kątem obu produktów → merge tego samego dnia.
brzmi ciekawie, zobaczymy, jak to wyjdzie w praktyce...
Back to blog