От диаграми до приложения
Редактор на диаграми структуриран Event Storming с ИИ асистент за екипи, разработващи бизнес софтуер. Той произвежда последователни софтуерни спецификации за агентни SDLC работни процеси. Без задачи, без спринтове.
Демо
Това е реален домейн за електронна търговия, „Customers“, моделиран в StormPilot: Actors, Actions, Aggregates, Events, Rules, Views и Terms, напълно свързани. Той беше реализиран от кодиращ агент и публикуван на https://github.com/codelev/stormpilot.
Доставка на софтуерен продукт на следващия ден
Това, което реално забавя Time to Market на един софтуерен продукт, рядко е самото писане на код. Това е всичко, което трябва да се случи, преди агент или инженер да може безопасно да промени продукта. След като екипите започнаха да прилагат мултиагентен SDLC, те продължаваха да се сблъскват все със същите четири проблема.
Фрагментирано знание
Знанието за продукта беше разпръснато между технически и нетехнически ръководители, приложения, тракери на задачи, кодови хранилища и документи. Обикновено то беше непълно, остаряло и се тълкуваше различно в зависимост от това кой го чете. Преди дори да се състави пакет от променящи задачи (спринт), цялото това фрагментирано знание трябваше първо да бъде синхронизирано.
Човекоцентрични оценки на задачите
Всяка променяща задача носеше човекоцентрична оценка (story points), която нямаше никаква роля, щом работата се вършеше от агент. Агентът не се нуждае от оценка в story points, за да започне. Оставаше само планова церемония: разпределяне на задачи и разплитане на зависимости между задачи или екипи, усилие, което съществуваше единствено защото задачите бяха оразмерени за хора, а не за агенти.
Обратно инженерство на съществуващото състояние
Променящата задача описва разликата между съществуващо и желано състояние. Това принуждаваше кодиращия агент първо да реконструира съществуващото състояние, преди изобщо да може да действа по разликата. Поради ограниченията на съвременните LLM, тази реконструкция понякога излизаше грешна или непълна, и продуктът се променяше по начини, които не бяха поискани.
Отклонение при тълкуване
Всяка променяща задача беше написана на естествен език, което носеше риск от отклонение при тълкуване: разликата между поведението на домейна, което е било замислено, и поведението, което реално е било реализирано, причинена от загуба на информация или неяснота. Поради ограниченията на съвременните LLM, една и съща задача, дадена на един и същ агент, можеше да произведе различен код всеки път, и отново продуктът се променяше по начини, които не бяха поискани.
Spec-Driven Development
За да решат това, екипите възприемат една от рамките за Spec-Driven Development (SDD): спецификационни файлове, написани на естествен или смесен естествено-формален език, изготвени преди кодирането, стават входни данни за агента. Съществува сравнение на 15 рамки за Spec-Driven Development, което ги подрежда в три нива.
Ниво 1 · Spec-First
Третират спецификацията като предварителен договор или писмо за намерение.
GitHub Spec Kit, Superpowers, Behavioral Meta-Architectural Design, Goal-Driven Development, SpecSwarm
Ниво 2 · Spec-Anchored
Поддържат спецификацията като жив документ през целия жизнен цикъл на проекта.
MUSUBI, Intent, OpenSpec
Ниво 3 · Spec-as-Source
Изграждат настройка без отклонение, при която спецификационният файл е абсолютният единствен източник на истина.
Tessl, Contractual Specification-Driven Development
Сравнение на 15 рамки за Spec-Driven Development
Опитахме този път. Спецификационните файлове наистина помогнаха да се събере знание на едно място, да се опише съществуващото и желаното състояние и да се намали отклонението при тълкуване. Но спецификационният файл беше все още още един документ, живеещ в кодовото хранилище, изискващ собствена синхронизация с останалите артефакти на продукта. И бизнес заинтересованите страни все още не можеха да сътрудничат по спецификационен файл: фрагментираното знание между технически и нетехнически хора оставаше нерешено.
Затова изградихме StormPilot, за да адресираме и четирите проблема наведнъж.
Event Storming
EventStorming е нискотехнологична съвместна работилница, измислена от Алберто Брандолини за изследване на сложни бизнес процеси като времева линия от повтарящи се елементи. EventStorming не е трябвало да бъде цифров инструмент. Основната му цел е колективно учене: бизнес и технически експерти откриват и обсъждат как работи един домейн. Дъската е умишлено лека и тактилна, позволявайки на участниците бързо да добавят, местят, групират, поставят под въпрос и премахват елементи. Физическата среда със стикери е част от метода. Нотацията не е предназначена да бъде строг формален език за моделиране.
Структуриран Event Storming
StormPilot е до голяма степен верен на концепциите на Event Storming. Той избягва терминологията на CQRS, като използва "View" вместо "Read Model", "Action" вместо "Command", "Rule" вместо "Policy". Добавя "Term" като изричен елемент за поддържане на общ бизнес език. Структуриран Event Storming превръща техниката за учене в система за спецификации. Тя вгражда формални нотации директно в елементите, за да намали разминаването в интерпретацията: пропастта между това, за което отговаря един домейн, и това, което действително се изгражда, причинена от изгубена или неясна информация. Получената софтуерна спецификация служи като детерминиран вход за агентно генериране на код, позволявайки на бизнес знанието да задвижва промени в софтуерния продукт, доставян на следващия ден.
Помощ от ИИ
ИИ асистентът чете вашия реален модел на домейна и предлага конкретни поправки: подобрения на наименуванията, липсващи елементи, дефиниции на роли, пропуски в потока, изяснения на ограниченията. Приемете каквото е полезно, отхвърлете останалото.
Версиониране
Задача като самостоятелен артефакт за управление на проекти няма смисъл в мултиагентен SDLC или в икономика на токени. Промените в знанието, уловено в диаграма на структуриран Event Storming, се отразяват директно върху промените в продукта, който искаме да пуснем. Затова StormPilot заменя задачите и пакетите от задачи с версиониране на продукта. Така се решават човекоцентричните оценки на задачите и обратното инженерство на съществуващото състояние.
Често задавани въпроси
Трябва ли да плащам, за да го изпробвам?
Не. Демото е безплатна, публична пясъчна среда без регистрация с всички налични роли. Тя се нулира ежедневно и е ограничена до 5 домейна с по 2 версии всеки.
Какво е версия на домейн?
Facilitator може да замрази текущото състояние на диаграма като версия. Версиите са неизменяеми, с времеви печат и само за четене.
Какво експортира?
StormPilot експортира User Interface, Application Programming Interface, модел на данните и Behavior сценарии.
ИИ пише ли код?
Не. ИИ на StormPilot определя КАКВО да се кодира: модела на домейна и неговото поведение. Технологичният стек остава решение на инженерния екип.
Защо OpenRPC?
Бизнес Actions надхвърлят REST семантиката. OpenRPC точно съответства на нотацията на Event Storming, избягва отклонението в интерпретацията и не зависи от протокола.
Защо Gherkin?
Given/When/Then отразява Event Storming Rules и избягва отклонението в интерпретацията, тъй като се поддържа директно от BDD екосистемата от инструменти.
Защо PlantUML?
Event Storming по природа е визуален, а PlantUML запазва това при износа. Синтаксисът се поддържа директно от екосистемата от инструменти.
Защо SSE?
Events протичат само в една посока, така че сложността на WebSockets остава неизползвана. Server-Sent Events остава обикновен HTTP и се възстановява автоматично.