De la diagrame la aplicații
Editor de diagrame Event Storming structurat asistat de AI pentru echipele de inginerie software de business. Produce specificații software consistente pentru fluxurile de lucru SDLC agentice. Fără task-uri, fără sprinturi.
Demo
Acesta este un domeniu real de comerț electronic, „Customers”, modelat în StormPilot: Actors, Actions, Aggregates, Events, Rules, Views și Terms, complet conectate. A fost implementat de un agent de codare și publicat la https://github.com/codelev/stormpilot.
Livrarea produsului software în ziua următoare
Ceea ce încetinește de fapt Time to Market-ul unui produs software este rareori codarea în sine. Este tot ce trebuie să se întâmple înainte ca un agent, sau un inginer, să poată schimba produsul în siguranță. Odată ce ați început să rulați un SDLC multiagent, ați continuat să întâlniți aceleași patru probleme, iar și iar.
Cunoștințe fragmentate
Cunoștințele despre produs erau fragmentate între responsabili tehnici și non-tehnici, aplicații, instrumente de urmărire a sarcinilor, repozitorii de cod și documente. De obicei erau incomplete, învechite și interpretate diferit în funcție de cine le citea. Înainte de a putea măcar alcătui un pachet de sarcini de schimbare (un Sprint), trebuia mai întâi să sincronizați toate aceste cunoștințe fragmentate.
Estimări ale sarcinilor centrate pe om
Fiecare sarcină de schimbare purta o estimare centrată pe om (story points) care nu mai juca niciun rol odată ce munca era făcută de un agent. Un agent nu are nevoie de o estimare în story points ca să înceapă. Ce mai rămânea era o ceremonie de planificare: distribuirea sarcinilor și descâlcirea dependențelor dintre sarcini sau dintre echipe, un efort care exista doar pentru că sarcinile fuseseră dimensionate pentru oameni, nu pentru agenți.
Ingineria inversă a stării existente
O sarcină de schimbare descrie diferența dintre o stare existentă și una dorită. Asta obliga agentul de codare să facă mai întâi ingineria inversă a stării existente, înainte de a putea acționa asupra diferenței. Din cauza limitărilor actuale ale LLM-urilor, această reconstrucție uneori ieșea greșită sau incompletă, iar produsul se schimba în moduri pe care nu le-ați cerut.
Deriva de interpretare
Fiecare sarcină de schimbare era scrisă în limbaj natural, ceea ce aducea riscul derivei de interpretare: decalajul dintre comportamentul domeniului intenționat și comportamentul care a fost efectiv implementat, cauzat de pierderea de informație sau ambiguitate. Din cauza limitărilor actuale ale LLM-urilor, aceeași sarcină dată aceluiași agent putea produce cod diferit de fiecare dată, iar produsul se schimba din nou în moduri pe care nu le-ați cerut.
Spec-Driven Development
Pentru a remedia asta, echipele adoptă unul dintre framework-urile Spec-Driven Development (SDD): fișierele de specificație, scrise în limbaj natural sau mixt natural și formal, redactate înainte de codare, devin intrarea pentru agent. Există o comparație a 15 framework-uri Spec-Driven Development care le încadrează în trei niveluri.
Nivelul 1 · Spec-First
Tratează specificația ca pe un contract preliminar sau o scrisoare de intenție.
GitHub Spec Kit, Superpowers, Behavioral Meta-Architectural Design, Goal-Driven Development, SpecSwarm
Nivelul 2 · Spec-Anchored
Păstrează specificația ca document viu pe tot parcursul ciclului de viață al proiectului.
MUSUBI, Intent, OpenSpec
Nivelul 3 · Spec-as-Source
Implementează o configurație fără derivă, în care fișierul de specificație este singura sursă absolută de adevăr.
Tessl, Contractual Specification-Driven Development
Comparație a 15 framework-uri Spec-Driven Development
Am încercat această cale. Fișierele de specificație au ajutat într-adevăr la strângerea cunoștințelor într-un singur loc, la descrierea stării existente și dorite și la reducerea derivei de interpretare. Dar fișierul de specificație era tot un document în plus care trăia în repozitoriul de cod, având nevoie de propria sincronizare cu restul artefactelor produsului. Iar factorii interesați din business tot nu puteau colabora la un fișier de specificație: cunoștințele fragmentate dintre oamenii tehnici și non-tehnici rămâneau nerezolvate.
Așa că am construit StormPilot pentru a rezolva toate cele patru probleme deodată.
Event Storming
EventStorming este o tehnică de atelier colaborativ low-fi, inventată de Alberto Brandolini pentru explorarea proceselor de afaceri complexe ca o cronologie de elemente repetitive. EventStorming nu a fost gândit ca instrument digital. Scopul său principal este învățarea colectivă: experții de afaceri și tehnici descoperă și discută împreună cum funcționează un domeniu. Tabla este în mod deliberat ușoară și tactilă, permițând participanților să adauge, mute, grupeze, pună sub semnul întrebării și elimine rapid elemente. Mediul fizic al notițelor adezive face parte din metodă. Notația nu este menită să fie un limbaj de modelare formal și rigid.
Event Storming Structurat
StormPilot este, în mare măsură, fidel conceptelor Event Storming. Evită terminologia CQRS folosind "View" în loc de "Read Model", "Action" în loc de "Command", "Rule" în loc de "Policy". Adaugă "Term" ca element explicit pentru menținerea unui limbaj unitar al domeniului. Event Storming structurat transformă tehnica de învățare într-un sistem de specificații. Încorporează notații formale direct în elemente pentru a reduce deriva de interpretare: decalajul dintre ceea ce este responsabil un domeniu și ceea ce se construiește efectiv, cauzat de informații pierdute sau ambigue. Specificația software rezultată servește ca intrare deterministă pentru generarea agentică de cod, permițând cunoștințelor de domeniu să conducă modificările din produsul software livrat a doua zi.
Asistență AI
Asistentul AI citește modelul dvs. real de domeniu și propune remedieri specifice: îmbunătățiri de denumire, elemente lipsă, definiții de roluri, lacune de flux, clarificări de constrângeri. Acceptați ce este util, respingeți restul.
Versionare
O sarcină ca artefact independent de management de proiect nu are sens într-un SDLC multiagent sau într-o economie de tokenuri. Schimbările în cunoștințele surprinse într-o diagramă Event Storming structurat se traduc direct în schimbări ale produsului pe care dorim să-l lansăm. De aceea StormPilot înlocuiește sarcinile și pachetele de sarcini cu versionarea produsului. Așa se rezolvă estimările sarcinilor centrate pe om și ingineria inversă a stării existente.
Întrebări frecvente
Trebuie să plătesc pentru a-l încerca?
Nu. Demo-ul este un sandbox public și gratuit, fără înregistrare, cu toate rolurile disponibile. Se resetează zilnic și este limitat la 5 domenii, cu 2 versiuni fiecare.
Ce este o versiune de domeniu?
Un Facilitator poate îngheța starea curentă a unei diagrame ca versiune. Versiunile sunt imuabile, marcate temporal și doar pentru citire.
Ce exportă?
StormPilot exportă User Interface, Application Programming Interface, modelul de date și scenarii Behavior.
AI scrie cod?
Nu. AI-ul StormPilot specifică CE trebuie codat: modelul de domeniu și comportamentul său. Stiva tehnologică rămâne decizia echipei de inginerie.
De ce OpenRPC?
Actions de business depășesc semantica REST. OpenRPC corespunde exact notației Event Storming, evită deriva de interpretare și rămâne agnostic față de protocol.
De ce Gherkin?
Given/When/Then reflectă structura Rules din Event Storming și evită deriva de interpretare, fiind susținut direct de ecosistemul de unelte BDD.
De ce PlantUML?
Event Storming este prin natura sa vizual, iar PlantUML păstrează acest lucru la export. Sintaxa este susținută direct de ecosistemul de unelte.
De ce SSE?
Events curg doar într-o singură direcție, astfel încât complexitatea WebSockets rămâne nefolosită. Server-Sent Events rămâne HTTP simplu și se reconectează automat.