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
EventStorming is a low-fi collaborative workshop technique invented by Alberto Brandolini for exploring complex business processes as a timeline of repeating elements. EventStorming was not supposed to be a digital tool. Its primary purpose is collective learning: business and technical experts discover and discuss how a domain works. The board is deliberately lightweight and tactile, allowing participants to rapidly add, move, group, question, and discard elements. The physical sticky-note medium is part of the method. The notation is not intended as a rigid formal modeling language.
Structured Event Storming
StormPilot is largely faithful to Event Storming concepts. It avoids CQRS terminology by using "View" instead of "Read Model", "Action" instead of "Command", "Rule" instead of "Policy". It adds "Term" as an explicit element for maintaining ubiquitous domain language. Structured Event Storming turns the learning technique into a specification system. It embeds formal notations directly into 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. The resulting software specification serves as a deterministic input to agentic code generation, enabling the domain knowledge to drive changes in software product delivered next-day.
AI Assistance
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.
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.