Dos diagramas às aplicações
Editor de diagramas Event Storming estruturado assistido por IA para equipas de engenharia de software empresarial. Produz especificações de software consistentes para fluxos de trabalho SDLC agênticos. Sem tarefas, sem sprints.
Demo
Este é um domínio real de comércio eletrónico, "Customers", modelado no StormPilot: Actors, Actions, Aggregates, Events, Rules, Views e Terms, totalmente ligados. Foi implementado por um agente de codificação e publicado em https://github.com/codelev/stormpilot.
Entrega do produto de software no dia seguinte
O que realmente atrasa o Time to Market de um produto de software raramente é a própria codificação. É tudo o que precisa de acontecer antes de um agente, ou um engenheiro, poder alterar o produto com segurança. Assim que começou a operar um SDLC multiagente, continuou a deparar-se com os mesmos quatro problemas, vezes sem conta.
Conhecimento fragmentado
O conhecimento sobre o produto estava fragmentado entre responsáveis técnicos e não técnicos, aplicações, ferramentas de acompanhamento de tarefas, repositórios de código e documentos. Normalmente estava incompleto, desatualizado e era interpretado de forma diferente consoante quem o lia. Antes de sequer conseguir reunir um pacote de tarefas de alteração (um Sprint), era preciso primeiro sincronizar todo esse conhecimento fragmentado.
Estimativas de tarefas centradas no ser humano
Cada tarefa de alteração trazia uma estimativa centrada no ser humano (story points) que não desempenhava qualquer papel assim que um agente passava a fazer o trabalho. Um agente não precisa de uma estimativa em story points para começar. O que restava era uma cerimónia de planeamento: distribuir tarefas e desembaraçar dependências entre tarefas ou entre equipas, um esforço que só existia porque as tarefas tinham sido dimensionadas para pessoas, não para agentes.
Engenharia inversa do estado existente
Uma tarefa de alteração descreve a diferença entre um estado existente e um estado desejado. Isso obrigava o agente de codificação a fazer primeiro engenharia inversa do estado existente, antes de sequer poder agir sobre a diferença. Dadas as limitações atuais dos LLM, essa reconstrução por vezes saía errada ou incompleta, e o produto mudava de formas que não tinham sido pedidas.
Desvio de interpretação
Cada tarefa de alteração era escrita em linguagem natural, o que trazia o risco de desvio de interpretação: a lacuna entre o comportamento do domínio pretendido e o comportamento que foi efetivamente implementado, causada por perda de informação ou ambiguidade. Dadas as limitações atuais dos LLM, a mesma tarefa entregue ao mesmo agente podia produzir código diferente de cada vez, e mais uma vez o produto mudava de formas que não tinham sido pedidas.
Spec-Driven Development
Para resolver isto, as equipas adotam uma das frameworks de Spec-Driven Development (SDD): ficheiros de especificação, escritos em linguagem natural ou mista natural e formal, escritos antes da codificação, tornam-se o input para o agente. Existe uma comparação de 15 frameworks de Spec-Driven Development que as organiza em três níveis.
Nível 1 · Spec-First
Tratam a especificação como um contrato preliminar ou uma carta de intenções.
GitHub Spec Kit, Superpowers, Behavioral Meta-Architectural Design, Goal-Driven Development, SpecSwarm
Nível 2 · Spec-Anchored
Mantêm a especificação como um documento vivo ao longo de todo o ciclo de vida do projeto.
MUSUBI, Intent, OpenSpec
Nível 3 · Spec-as-Source
Implementam uma configuração sem desvio em que o ficheiro de especificação é a única fonte absoluta de verdade.
Tessl, Contractual Specification-Driven Development
Comparação de 15 frameworks de Spec-Driven Development
Experimentámos este caminho. Os ficheiros de especificação ajudaram, de facto, a reunir conhecimento num só lugar, a descrever o estado existente e o desejado e a reduzir o desvio de interpretação. Mas o ficheiro de especificação continuava a ser mais um documento a viver no repositório de código, precisando da sua própria sincronização com os restantes artefactos do produto. E os stakeholders de negócio continuavam a não conseguir colaborar num ficheiro de especificação: o conhecimento fragmentado entre pessoas técnicas e não técnicas permanecia por resolver.
Por isso construímos o StormPilot para resolver os quatro problemas de uma só vez.
Event Storming
EventStorming é uma técnica de workshop colaborativa low-fi, inventada por Alberto Brandolini para explorar processos de negócio complexos como uma linha do tempo de elementos repetidos. O EventStorming não foi concebido para ser uma ferramenta digital. O seu objetivo principal é a aprendizagem coletiva: especialistas de negócio e técnicos descobrem e discutem em conjunto como um domínio funciona. O quadro é deliberadamente leve e tátil, permitindo que os participantes adicionem, movam, agrupem, questionem e descartem elementos rapidamente. O suporte físico de notas autocolantes faz parte do método. A notação não pretende ser uma linguagem de modelação formal e rígida.
Event Storming Estruturado
O StormPilot é, em grande medida, fiel aos conceitos de Event Storming. Evita a terminologia CQRS ao usar "View" em vez de "Read Model", "Action" em vez de "Command", "Rule" em vez de "Policy". Adiciona "Term" como um elemento explícito para manter uma linguagem de domínio unificada. O Event Storming estruturado transforma a técnica de aprendizagem num sistema de especificação. Incorpora notações formais diretamente nos elementos para reduzir o desvio de interpretação: o fosso entre aquilo pelo qual um domínio é responsável e aquilo que é efetivamente construído, causado por informação perdida ou ambígua. A especificação de software resultante serve como entrada determinística para a geração de código agêntica, permitindo que o conhecimento do domínio conduza alterações no produto de software entregue no dia seguinte.
Assistência de IA
O assistente de IA lê o seu modelo de domínio real e propõe correções específicas: melhorias de nomenclatura, elementos em falta, definições de papéis, lacunas de fluxo, clarificações de restrições. Aceite o que for útil, descarte o resto.
Versionamento
Uma tarefa como artefacto de gestão de projetos autónomo não faz sentido num SDLC multiagente nem numa economia de tokens. As alterações ao conhecimento capturado num diagrama Event Storming estruturado mapeiam-se diretamente em alterações no produto que queremos lançar. É por isso que o StormPilot substitui tarefas e pacotes de tarefas por versionamento do produto. É assim que as estimativas de tarefas centradas no ser humano e a engenharia inversa do estado existente são resolvidas.
Perguntas frequentes
Preciso de pagar para experimentar?
Não. A Demo é uma sandbox pública e gratuita, sem registo e com todos os papéis disponíveis. É reposta diariamente e tem um limite de 5 domínios, com 2 versões cada.
O que é uma versão de domínio?
Um Facilitator pode congelar o estado atual de um diagrama como uma versão. As versões são imutáveis, com data e hora e apenas de leitura.
O que é exportado?
O StormPilot exporta User Interface, Application Programming Interface, modelo de dados e cenários Behavior.
A IA escreve código?
Não. A IA do StormPilot especifica O QUE codificar: o modelo de domínio e o seu comportamento. A stack tecnológica continua a ser decisão da equipa de engenharia.
Porquê OpenRPC?
As Actions de negócio excedem a semântica REST. O OpenRPC corresponde exatamente à notação Event Storming, evita o desvio de interpretação e é agnóstico quanto ao protocolo.
Porquê Gherkin?
O Given/When/Then reflete a estrutura das Rules do Event Storming e evita o desvio de interpretação, pois é diretamente suportado pelo ecossistema de ferramentas BDD.
Porquê PlantUML?
O Event Storming é inerentemente visual, e o PlantUML mantém isso na exportação. A sintaxe é diretamente suportada pelo ecossistema de ferramentas.
Porquê SSE?
Os Events fluem apenas numa direção, pelo que a complexidade dos WebSockets fica por usar. O Server-Sent Events mantém-se em HTTP simples e reconecta-se automaticamente.