Od diagramów do aplikacji
Edytor diagramów ustrukturyzowany Event Storming wspomagany przez AI dla zespołów tworzących oprogramowanie biznesowe. Tworzy spójne specyfikacje oprogramowania dla agentowych przepływów pracy SDLC. Żadnych zadań, żadnych sprintów.
Demo
To prawdziwa domena e-commerce, „Customers”, zamodelowana w StormPilocie: Actors, Actions, Aggregates, Events, Rules, Views i Terms, w pełni połączone. Zostało zaimplementowane przez agenta kodującego i opublikowane pod adresem https://github.com/codelev/stormpilot.
Dostawa produktu programistycznego na następny dzień
To, co naprawdę spowalnia Time to Market produktu programistycznego, rzadko jest samym kodowaniem. To wszystko, co musi się wydarzyć, zanim agent lub inżynier będzie mógł bezpiecznie zmienić produkt. Gdy tylko zaczęliście uruchamiać multiagentowy SDLC, wciąż natrafialiście na te same cztery problemy.
Rozproszona wiedza
Wiedza o produkcie była rozproszona między technicznymi i nietechnicznymi liderami, aplikacjami, narzędziami do śledzenia zadań, repozytoriami kodu i dokumentami. Zwykle była niekompletna, nieaktualna i interpretowana inaczej w zależności od tego, kto ją czytał. Zanim można było w ogóle zestawić pakiet zadań zmieniających (Sprint), trzeba było najpierw zsynchronizować całą tę rozproszoną wiedzę.
Szacunki zadań skoncentrowane na człowieku
Każde zadanie zmieniające niosło szacunek skoncentrowany na człowieku (story points), który nie odgrywał żadnej roli, gdy pracę wykonywał agent. Agent nie potrzebuje szacunku w story pointach, by zacząć. Pozostawała ceremonia planowania: rozdzielanie zadań i rozplątywanie zależności między zadaniami lub zespołami, wysiłek, który istniał tylko dlatego, że zadania były dopasowane rozmiarem do ludzi, a nie do agentów.
Inżynieria wsteczna istniejącego stanu
Zadanie zmieniające opisuje różnicę między istniejącym a pożądanym stanem. To zmuszało agenta kodującego do najpierw odtworzenia istniejącego stanu metodą inżynierii wstecznej, zanim w ogóle mógł zadziałać na różnicy. Ze względu na obecne ograniczenia LLM, ta rekonstrukcja bywała czasem błędna lub niekompletna, a produkt zmieniał się w sposób, o który nie proszono.
Dryf interpretacji
Każde zadanie zmieniające było napisane w języku naturalnym, co niosło ryzyko dryfu interpretacji: rozbieżności między zamierzonym zachowaniem domeny a zachowaniem faktycznie zaimplementowanym, spowodowanej utratą informacji lub niejednoznacznością. Ze względu na obecne ograniczenia LLM, to samo zadanie przekazane temu samemu agentowi mogło za każdym razem generować inny kod, a produkt znów zmieniał się w sposób, o który nie proszono.
Spec-Driven Development
Aby to naprawić, zespoły przyjmują jeden z frameworków Spec-Driven Development (SDD): pliki specyfikacji, napisane w języku naturalnym lub mieszanym naturalno-formalnym, przygotowane przed kodowaniem, stają się danymi wejściowymi dla agenta. Istnieje porównanie 15 frameworków Spec-Driven Development, które porządkuje je w trzy poziomy.
Poziom 1 · Spec-First
Traktują specyfikację jako wstępną umowę lub list intencyjny.
GitHub Spec Kit, Superpowers, Behavioral Meta-Architectural Design, Goal-Driven Development, SpecSwarm
Poziom 2 · Spec-Anchored
Utrzymują specyfikację jako żywy dokument przez cały cykl życia projektu.
MUSUBI, Intent, OpenSpec
Poziom 3 · Spec-as-Source
Wdrażają konfigurację bez dryfu, w której plik specyfikacji jest absolutnym jedynym źródłem prawdy.
Tessl, Contractual Specification-Driven Development
Porównanie 15 frameworków Spec-Driven Development
Wypróbowaliśmy tę drogę. Pliki specyfikacji rzeczywiście pomogły zgromadzić wiedzę w jednym miejscu, opisać istniejący i pożądany stan oraz ograniczyć dryf interpretacji. Ale plik specyfikacji wciąż był jeszcze jednym dokumentem żyjącym w repozytorium kodu, wymagającym własnej synchronizacji z pozostałymi artefaktami produktu. A interesariusze biznesowi nadal nie mogli współpracować nad plikiem specyfikacji: rozproszona wiedza między osobami technicznymi i nietechnicznymi pozostawała nierozwiązana.
Dlatego zbudowaliśmy StormPilot, aby rozwiązać wszystkie cztery problemy naraz.
Event Storming
EventStorming to niskonakładowa, wspólna technika warsztatowa wymyślona przez Alberta Brandoliniego do badania złożonych procesów biznesowych jako osi czasu powtarzających się elementów. EventStorming nie miał być narzędziem cyfrowym. Jego głównym celem jest wspólne uczenie się: eksperci biznesowi i techniczni razem odkrywają i omawiają, jak działa dana domena. Tablica jest celowo lekka i dotykowa, co pozwala uczestnikom szybko dodawać, przesuwać, grupować, kwestionować i usuwać elementy. Fizyczne medium karteczek samoprzylepnych jest częścią metody. Notacja nie jest pomyślana jako sztywny, formalny język modelowania.
Ustrukturyzowany Event Storming
StormPilot jest w dużej mierze wierny koncepcjom Event Storming. Unika terminologii CQRS, używając "View" zamiast "Read Model", "Action" zamiast "Command", "Rule" zamiast "Policy". Dodaje "Term" jako jawny element utrzymujący spójny język domeny. Ustrukturyzowany Event Storming zamienia technikę uczenia się w system specyfikacji. Osadza formalne notacje bezpośrednio w elementach, aby zmniejszyć dryf interpretacyjny: lukę między tym, za co odpowiada domena, a tym, co faktycznie zostaje zbudowane, spowodowaną utraconą lub niejednoznaczną informacją. Powstała specyfikacja oprogramowania służy jako deterministyczne wejście do agentowego generowania kodu, umożliwiając wiedzy domenowej napędzanie zmian w produkcie oprogramowania dostarczanym następnego dnia.
Wsparcie AI
Asystent AI odczytuje twój rzeczywisty model domeny i proponuje konkretne poprawki: usprawnienia nazewnictwa, brakujące elementy, definicje ról, luki w przepływie, wyjaśnienia ograniczeń. Zaakceptuj to, co przydatne, odrzuć resztę.
Wersjonowanie
Zadanie jako samodzielny artefakt zarządzania projektem nie ma sensu w multiagentowym SDLC ani w ekonomii tokenów. Zmiany w wiedzy zawartej w diagramie ustrukturyzowany Event Storming przekładają się bezpośrednio na zmiany w produkcie, który chcemy wydać. Dlatego StormPilot zastępuje zadania i pakiety zadań wersjonowaniem produktu. Tak rozwiązuje się szacunki zadań skoncentrowane na człowieku i inżynierię wsteczną istniejącego stanu.
FAQ
Czy muszę płacić, by to wypróbować?
Nie. Demo to darmowa, publiczna piaskownica bez rejestracji, z dostępem do wszystkich ról. Resetuje się codziennie i jest ograniczona do 5 domen, po 2 wersje każda.
Czym jest wersja domeny?
Facilitator może zamrozić bieżący stan diagramu jako wersję. Wersje są niezmienne, oznaczone znacznikiem czasu i tylko do odczytu.
Co eksportuje?
StormPilot eksportuje User Interface, Application Programming Interface, model danych i scenariusze Behavior.
Czy AI pisze kod?
Nie. AI StormPilota określa CO należy zakodować: model domeny i jego zachowanie. Stos technologiczny pozostaje decyzją zespołu inżynieryjnego.
Dlaczego OpenRPC?
Biznesowe Actions wykraczają poza semantykę REST. OpenRPC dokładnie odpowiada notacji Event Storming, unika dryfu interpretacyjnego i jest niezależny od protokołu.
Dlaczego Gherkin?
Given/When/Then odzwierciedla strukturę Event Storming Rules i unika dryfu interpretacyjnego, ponieważ jest bezpośrednio wspierane przez ekosystem narzędzi BDD.
Dlaczego PlantUML?
Event Storming jest z natury wizualny, a PlantUML zachowuje to przy eksporcie. Składnia jest bezpośrednio wspierana przez ekosystem narzędzi.
Dlaczego SSE?
Events płyną tylko w jedną stronę, więc złożoność WebSockets pozostaje niewykorzystana. Server-Sent Events pozostaje zwykłym HTTP i automatycznie łączy się ponownie.