Von Diagrammen zu Anwendungen
KI-gestützter strukturierter Event-Storming-Diagrammeditor für Business-Software-Engineering-Teams. Er erzeugt konsistente Softwarespezifikationen für agentische SDLC-Workflows. Keine Tasks, keine Sprints.
Demo
Dies ist eine echte E-Commerce-Domäne, „Customers“, modelliert in StormPilot: Actors, Actions, Aggregates, Events, Rules, Views und Terms, vollständig verbunden. Sie wurde von einem Coding-Agenten implementiert und veröffentlicht unter https://github.com/codelev/stormpilot.
Softwareprodukt-Auslieferung über Nacht
Was die Time to Market eines Softwareprodukts wirklich ausbremst, ist selten das Programmieren selbst. Es ist alles, was passieren muss, bevor ein Agent oder ein Ingenieur das Produkt sicher ändern kann. Sobald man einen multi-agentischen SDLC betrieb, stieß man immer wieder auf dieselben vier Probleme.
Fragmentiertes Wissen
Wissen über das Produkt war fragmentiert über technische und nicht-technische Verantwortliche, Anwendungen, Task-Tracker, Code-Repositories und Dokumente verteilt. Es war meist unvollständig, veraltet und wurde je nach Leser unterschiedlich interpretiert. Bevor man überhaupt ein Paket von Änderungsaufgaben (einen Sprint) zusammenstellen konnte, musste man all dieses fragmentierte Wissen erst synchronisieren.
Menschzentrierte Aufwandsschätzungen
Jede Änderungsaufgabe trug eine menschzentrierte Schätzung (Story Points), die keine Rolle mehr spielte, sobald ein Agent die Arbeit übernahm. Ein Agent braucht keine Story-Point-Schätzung, um zu beginnen. Übrig blieb eine Planungszeremonie: Aufgaben verteilen und Abhängigkeiten zwischen Aufgaben oder Teams entwirren, Aufwand, der nur existierte, weil die Aufgaben für Menschen zugeschnitten waren, nicht für Agenten.
Reverse-Engineering des bestehenden Zustands
Eine Änderungsaufgabe beschreibt den Unterschied zwischen einem bestehenden und einem gewünschten Zustand. Das zwang den Coding-Agenten, zunächst den bestehenden Zustand zurückzuentwickeln, bevor er überhaupt auf den Unterschied reagieren konnte. Angesichts aktueller LLM-Beschränkungen geriet diese Rekonstruktion manchmal fehlerhaft oder unvollständig, und das Produkt änderte sich auf Weisen, die man nicht beabsichtigt hatte.
Interpretationsdrift
Jede Änderungsaufgabe war in natürlicher Sprache verfasst, was das Risiko einer Interpretationsdrift barg: die Lücke zwischen dem beabsichtigten Domänenverhalten und dem tatsächlich implementierten Verhalten, verursacht durch Informationsverlust oder Mehrdeutigkeit. Angesichts aktueller LLM-Beschränkungen konnte dieselbe Aufgabe, demselben Agenten übergeben, jedes Mal anderen Code erzeugen, und wieder änderte sich das Produkt auf Weisen, die man nicht beabsichtigt hatte.
Spec-Driven Development
Um das zu beheben, setzen Teams eines der Spec-Driven-Development-(SDD)-Frameworks ein: Spezifikationsdateien, geschrieben in natürlicher oder gemischt natürlich-formaler Sprache, vor dem Programmieren verfasst, werden zur Eingabe für den Agenten. Es gibt einen Vergleich von 15 Spec-Driven-Development-Frameworks, der sie in drei Stufen einteilt.
Stufe 1 · Spec-First
Behandelt die Spezifikation als vorläufigen Vertrag oder Absichtserklärung.
GitHub Spec Kit, Superpowers, Behavioral Meta-Architectural Design, Goal-Driven Development, SpecSwarm
Stufe 2 · Spec-Anchored
Hält die Spezifikation über den gesamten Projektlebenszyklus hinweg als lebendes Dokument.
MUSUBI, Intent, OpenSpec
Stufe 3 · Spec-as-Source
Setzt eine driftfreie Konfiguration um, bei der die Spezifikationsdatei die einzige verbindliche Quelle der Wahrheit ist.
Tessl, Contractual Specification-Driven Development
Vergleich von 15 Spec-Driven-Development-Frameworks
Wir haben diesen Weg ausprobiert. Die Spezifikationsdateien halfen tatsächlich, Wissen an einem Ort zu sammeln, den bestehenden und gewünschten Zustand zu beschreiben und Interpretationsdrift zu reduzieren. Aber die Spezifikationsdatei war immer noch ein weiteres Dokument im Code-Repository, das eine eigene Synchronisation mit den übrigen Artefakten des Produkts benötigte. Und Business-Stakeholder konnten weiterhin nicht an einer Spezifikationsdatei mitarbeiten: Das fragmentierte Wissen zwischen technischen und nicht-technischen Personen blieb ungelöst.
Also haben wir StormPilot gebaut, um alle vier Probleme auf einmal zu lösen.
Event Storming
EventStorming ist eine Low-Fi-Workshop-Technik zur Zusammenarbeit, erfunden von Alberto Brandolini, um komplexe Geschäftsprozesse als Zeitachse sich wiederholender Elemente zu erkunden. EventStorming war nicht als digitales Werkzeug gedacht. Sein Hauptzweck ist kollektives Lernen: Fach- und IT-Experten entdecken und diskutieren gemeinsam, wie eine Domäne funktioniert. Das Board ist bewusst leichtgewichtig und taktil gestaltet, sodass Teilnehmende Elemente schnell hinzufügen, verschieben, gruppieren, hinterfragen und verwerfen können. Das physische Medium der Haftnotizen ist Teil der Methode. Die Notation ist nicht als strenge, formale Modellierungssprache gedacht.
Strukturiertes Event Storming
StormPilot ist den Event-Storming-Konzepten weitgehend treu. Es vermeidet die CQRS-Terminologie, indem es "View" statt "Read Model", "Action" statt "Command" und "Rule" statt "Policy" verwendet. Es fügt "Term" als explizites Element hinzu, um eine einheitliche Fachsprache zu pflegen. Strukturiertes Event Storming macht aus der Lerntechnik ein Spezifikationssystem. Es bettet formale Notationen direkt in die Elemente ein, um Interpretationsabweichungen zu reduzieren: die Lücke zwischen dem, wofür eine Domäne zuständig ist, und dem, was tatsächlich gebaut wird, verursacht durch verlorene oder mehrdeutige Informationen. Die resultierende Softwarespezifikation dient als deterministische Eingabe für die agentische Codegenerierung und ermöglicht es, dass das Domänenwissen Änderungen am Softwareprodukt vorantreibt, das am nächsten Tag ausgeliefert wird.
KI-Unterstützung
Der KI-Assistent liest Ihr tatsächliches Domänenmodell und schlägt konkrete Korrekturen vor: Namensverbesserungen, fehlende Elemente, Rollendefinitionen, Ablauflücken, Bedingungsklärungen. Übernehmen Sie, was nützlich ist, verwerfen Sie den Rest.
Versionierung
Eine Aufgabe als eigenständiges Projektmanagement-Artefakt ergibt in einem multi-agentischen SDLC oder in einer Token-Ökonomie keinen Sinn. Änderungen am Wissen, das in einem strukturierten Event-Storming-Diagramm festgehalten ist, bilden sich direkt auf Änderungen im Produkt ab, das man veröffentlichen möchte. Deshalb ersetzt StormPilot Aufgaben und Aufgabenpakete durch Produktversionierung. So werden menschzentrierte Aufwandsschätzungen und das Reverse-Engineering des bestehenden Zustands gelöst.
FAQ
Muss ich zahlen, um es auszuprobieren?
Nein. Die Demo ist eine kostenlose, öffentliche Sandbox ohne Registrierung mit allen verfügbaren Rollen. Sie wird täglich zurückgesetzt und ist auf 5 Domänen mit je 2 Versionen begrenzt.
Was ist eine Domänenversion?
Ein Facilitator kann den aktuellen Zustand eines Diagramms als Version einfrieren. Versionen sind unveränderlich, mit Zeitstempel versehen und schreibgeschützt.
Was wird exportiert?
StormPilot exportiert User Interface, Application Programming Interface, Datenmodell und Behavior-Szenarien.
Programmiert die KI?
Nein. Die StormPilot-KI spezifiziert, WAS zu programmieren ist: das Domänenmodell und sein Verhalten. Der Technologie-Stack bleibt weiterhin die Entscheidung des Engineering-Teams.
Warum OpenRPC?
Business-Actions sprengen REST-Semantik. OpenRPC folgt exakt der Event-Storming-Notation, vermeidet Interpretationsdrift und bleibt protokollagnostisch.
Warum Gherkin?
Given/When/Then spiegelt Event-Storming-Rules wider und vermeidet Interpretationsdrift, da es vom BDD-Tooling-Ökosystem direkt unterstützt wird.
Warum PlantUML?
Event Storming ist von Natur aus visuell, und PlantUML bewahrt das beim Export. Die Syntax wird direkt vom Tooling-Ökosystem unterstützt.
Warum SSE?
Events fließen nur in eine Richtung, sodass die Komplexität von WebSockets ungenutzt bleibt. Server-Sent Events bleibt reines HTTP und verbindet sich automatisch neu.