From Diagrams to Applications
AI-assisted Structured Event Storming diagram editor for business software engineering teams. It produces consistent software specifications for agentic SDLC workflows. No tasks, no sprints.
Demo
This is a real e-commerce domain, "Customers," modeled in StormPilot: Actors, Actions, Aggregates, Events, Rules, Views, and Terms, fully connected. It was implemented by a coding agent and published at https://github.com/codelev/stormpilot.
Next-Day Software Product Delivery
What actually slows down a software product’s Time to Market is rarely the coding itself. It’s everything that has to happen before an agent, or an engineer, can safely change the product. Once you started running a multi-agentic SDLC, you kept hitting the same four problems, over and over.
Fragmented knowledge
Knowledge about the product was fragmented among tech and non-tech heads, applications, task trackers, code repositories and documents. It was usually incomplete, outdated and interpreted differently depending on who was reading it. Before you could even put together a package of changing tasks (a Sprint), you had to synchronize all of that fragmented knowledge first.
Human-centric task estimates
Every changing task carried a human-centric estimate (story points) that played no role once an agent was doing the work. An agent doesn’t need a story-point estimate to start. What was left was a planning ceremony: distributing tasks and untangling inter-task or cross-team dependencies, effort that only existed because the tasks were sized for people, not for agents.
Reverse-engineering the existing state
A changing task describes the difference between an existing state and a desired one. That forced the coding agent to reverse-engineer the existing state first, before it could even act on the difference. Given current LLM limitations, it sometimes got that reconstruction wrong or incomplete, and the product changed in ways you didn’t ask for.
Interpretation drift
Every changing task was written in natural language, which meant it carried the risk of interpretation drift: the gap between the domain behavior you intended and the behavior that actually got implemented, caused by information loss or ambiguity. Given current LLM limitations, the same task handed to the same agent could produce different code each time, and again, the product changed in ways you didn’t ask for.
Spec-Driven Development
To fix this, teams adopt one of the Spec-Driven Development (SDD) frameworks: specification files, written in natural or mixed natural and formal language, written before the coding, become the input for the agent. There’s a comparison of 15 Spec-Driven Development frameworks that sorts them into three levels.
Level 1 · Spec-First
Treat the specification as a preliminary contract or letter of intent.
GitHub Spec Kit, Superpowers, Behavioral Meta-Architectural Design, Goal-Driven Development, SpecSwarm
Level 2 · Spec-Anchored
Keep the specification as a living document across the whole project lifecycle.
MUSUBI, Intent, OpenSpec
Level 3 · Spec-as-Source
Implement a zero-drift setup where the specification file is the absolute single source of truth.
Tessl, Contractual Specification-Driven Development
Comparing 15 Spec-Driven Development frameworks
We tried this path. The specification files did help gather knowledge in one place, describe the existing and desired state and cut down interpretation drift. But the specification file was still one more document living in the code repository, needing its own synchronization with the rest of the product’s artifacts. And business stakeholders still couldn’t collaborate on a spec file: the fragmented knowledge between tech and non-tech people stayed unresolved.
So we built StormPilot to address all four problems at once.
Event Storming
Event Storming is a collaborative workshop technique invented by Alberto Brandolini for exploring complex business processes as a timeline of repeating elements. StormPilot is a web-based Event Storming diagram editor. This is how fragmented knowledge gets solved: one collaboration space for business and engineering stakeholders, one knowledge, one language to describe it.
Structured Event Storming
StormPilot embeds formal notations directly into Event Storming elements to reduce interpretation drift: the gap between what a domain is responsible for and what actually gets built, caused by lost or ambiguous information. This is how interpretation drift gets solved.
User Stories
Capture user intent but leave inner objects, relationships and behavioral constraints largely implicit.
BDD scenarios
Reduce ambiguity through behavior examples, but don’t fully formalize the underlying domain model.
EARS
Control the individual requirements, but don’t formalize the broader domain model or its relationships.
Structured Event Storming
Transforms the Event Storming diagram, expressed in natural language, into a formal notation.
Assisted Event Storming
The AI assistant reads your actual domain model and proposes specific fixes: naming improvements, missing elements, role definitions, flow gaps, constraint clarifications. Accept what’s useful, dismiss the rest.
How it works
1. Add elements
Drag an element onto the panel: Actor, Action, Aggregate, Event, Rule, View, External System, Hotspot or Term.
2. Connect them
Draw arrows to form the flow. Only certain connections are valid, and invalid ones get flagged automatically.
3. Verify the domain
Disconnected elements, incomplete flows, invalid arrows and undefined terms are flagged live as you edit.
4. Export
Export the domain as a PNG image, a JSON file or an application spec for your coding agent.
Versioning
Task as a standalone project management artifact makes no sense in a multi-agentic SDLC or in an economy of tokens. Changes to the knowledge captured in a Structured Event Storming diagram map directly onto changes in the product we want to release. That’s why StormPilot replaces tasks and packages of tasks with product versioning. This is how human-centric task estimates and reverse-engineering the existing state get solved.
FAQ
Do I need to pay to try it?
No. Demo is a free, public sandbox with no signup and all roles available. It resets daily and caps at 5 domains, 2 versions each.
What is a domain version?
A Facilitator can freeze the current state of a diagram as a version. Versions are immutable, timestamped, and read-only.
What does it export?
StormPilot exports User Interface, Application Programming Interface, Data Model, and Behavior scenarios.
Does the AI code?
No. StormPilot AI specifies WHAT to code: the domain model and its behavior. The technology stack is still the engineering team’s decision.
Why OpenRPC?
Business actions exceed REST semantics. OpenRPC matches Event Storming notation, avoids interpretation drift and stays protocol-agnostic.
Why Gherkin?
Given/When/Then mirrors Event Storming Rules and avoids interpretation drift, since it's directly supported by the BDD tooling ecosystem.
Why PlantUML?
Event Storming is inherently visual while PlantUML keeps that on export. The syntax is directly supported by the tooling ecosystem.
Why SSE?
Events only flow one way, so WebSockets' complexity goes unused. Server-Sent Events stays plain HTTP and reconnects natively.