История о том, как Fleans — движок workflow на .NET Orleans и BPMN 2 — родился из упрямства, фрустрации, Camunda-которая-стала-платной и одного не самого очевидного разговора с ИИ.

Предыстория: четыре причины, по которым я вообще полез в это болото

Если у разработчика долго чешется одно и то же место, рано или поздно он возьмёт и сделает. У меня таких «чешущихся мест» было четыре, и они сошлись в одной точке:

1. Я всегда хотел собрать что-то серьёзное на .NET Orleans. Это ведь почти единственный зрелый actor-фреймворк в дотнет-мире, на нём построены Halo и Skype, а живых продакшн-проектов в открытом доступе — по пальцам пересчитать. Руки чесались.

2. Я люблю делать проекты. Не читать про них, не мечтать, а именно кодить. Это моё любимое состояние, в котором я согласен сидеть по ночам.

3. Camunda 8 стала платной. Для многих команд это внезапно сделало вопрос «а на чём мы оркеструем наши бизнес-процессы» снова открытым. А когда рынок оголяется — самое время туда зайти.

4. На работе я уже имел дело с Camunda. И кое-что из её архитектуры мне не нравилось настолько, что хотелось переделать. Не потому что я умнее создателей Camunda — а потому что у меня было конкретное видение, как сделать движок более масштабируемым, если положить в основу actor-модель вместо традиционного движка с БД-центричным исполнением.

Плюс ко всему я на собственной шкуре прочувствовал, насколько BPMN 2 удобен как язык моделирования. Когда бизнес-аналитик рисует прямоугольнички и стрелочки, а разработчик потом буквально исполняет эту диаграмму, а не «имплементирует по мотивам» — это кайф, который сложно описать человеку, не работавшему с ним.

Так родился Fleans. Название не несёт глубокого смысла — звучит, запоминается, не занято. Суть — open-source workflow engine на Orleans, который умеет исполнять стандартный BPMN 2 и горизонтально масштабироваться по схеме «добавил силосов — получил пропускную способность». Сейчас он раздаётся как полный релиз: подписанные NuGet-пакеты для авторов плагинов, multi-arch контейнерные образы на ghcr.io (amd64 + arm64), Helm-чарт с cosign-подписью, docker-compose-бандл одной командой. К конкретике я ещё вернусь — сначала про то, как мы туда дошли.

Первая попытка: команда, которая не взлетела

Любой честный рассказ о pet-проекте начинается с провала. Мой начался с двух.

Попытка №1. Я собрал команду из знакомых. Нашлись ребята, которым идея была в общем-то интересна. Но pet-проект без зарплаты держится только на энергии и ощущении, что ты рядом с чем-то живым. А у меня самого тогда ещё не было ни архитектуры в голове, ни MVP в репозитории — только тезисы. Мотивировать людей в таком состоянии я не смог. Через пару недель всё тихо угасло.

Попытка с ИИ (ранняя). Больше года назад я попробовал разобраться в предметной области с помощью ChatGPT. Казалось логичным: я не воркфлоу-эксперт, пусть ИИ расскажет. Получил много отдельных кусков — как устроен BPMN, что такое token в Camunda, как моделируют boundary events. Но собрать из этих кусков цельное понимание я тогда не смог. ИИ отвечал ровно на тот вопрос, который я задавал, а я не всегда знал, какой вопрос правильный.

Попытка №2 (команда). Я решил, что понимаю уже достаточно, чтобы вести проект технически, и собрал новый состав. К этому времени у меня были первые доменные модели: Activity, цикл, который вызывает метод активити и передвигает процесс к следующей, что-то вроде state machine поверх акторов. Но итог — тот же. Люди приходят, делают пару коммитов, исчезают.

Я оставил всё как есть и несколько месяцев вообще не трогал репозиторий. Проект казался слишком большим для одного. Я изучал аналоги (Elsa, WorkflowCore, Zeebe), и каждая из этих систем напоминала, сколько работы мне ещё предстоит.

Декабрь 2025: я вернулся к ИИ — и удивился

В декабре 2025 я решил ещё раз дать шанс ИИ-инструментам. К этому времени в ленте всё чаще проскакивали новости о том, что уровень моделей для кода стал совсем другим. Меня зацепили разговоры вокруг Claude Code — CLI-инструмент, заточенный именно под агентную разработку.

Я поставил. Попробовал. И удивился.

Это было не «приятно удивился, как в первый раз попробовал ChatGPT». Это было «сел за вечер, а через два дня у меня работающий прототип новой версии движка». Масштаб разницы с моделями годичной давности был такой же, как между «я ищу в Google, чтобы вспомнить синтаксис Task.WhenAll» и «я разговариваю с инженером, который уже 20 минут читает мой код».

Первым делом я, как и советовала документация, написал CLAUDE.md — файл с инструкциями для агента по проекту. И вот тут выяснилось важное: моя инвестиция в архитектурные принципы сделала это легко. Я изначально строил Fleans по DDD + Clean Architecture. Это значит, что описание проекта звучало не как «у нас такая-то папка, такая-то папка, вот этот класс делает то», а как «домен отделён от инфраструктуры, юзкейсы в application, персистентность за интерфейсами, Orleans-акторы — адаптеры для доменных агрегатов, грейн WorkflowInstance — event-sourced через JournaledGrain, все мутации идут через единый pipeline DrainAndRaiseEvents». Это язык, который ИИ понимает безошибочно, потому что он обучен на тоннах такого же кода.

Со временем CLAUDE.md сам себя перерос. Я разделил его (issue #649): корневой файл — это рулебук «как себя вести в этом репо»; всё остальное ушло в docs/conventions/ (как добавить новый BPMN-элемент, как написать кастомный плагин, как устроены стримы Orleans) и docs/runbooks/ (как выпустить релиз, как откатиться, как собрать compose-бандл). Это не косметика — без такого разделения один файл вырастает в монстра, который агент перечитывает на каждом запросе, и инструмент платит за это латентностью.

Ещё я решил использовать готовые скиллы для разработки — набор под названием superpowers. Коротко: это шаблоны процесса, которые заставляют агента не сразу бросаться писать код, а проходить этапы — анализ задачи, design doc, план, реализация, ревью, тесты. Для одиночного разработчика с амбициями это как нанять себе внешний процесс, которого иначе не бывает.

Первые фичи я делал вместе с Claude в режиме строгой проверки. Каждый шаг — от документа дизайна и плана до кода и тестов — я читал и ревьюил. Меня постоянно удивляло, насколько агент всегда находился в контексте моего проекта, как помнил договорённости прошлой сессии и предлагал идеи, к которым я сам пришёл бы через день размышлений.

Доменная активити в Fleans — это Orleans-сериализуемый record. У каждой активити есть ActivityId и метод ExecuteAsync, который возвращает список команд исполнения (что движок должен делать дальше) и публикует доменные события через контекст исполнения. Базовый класс выглядит так:

[GenerateSerializer]
public abstract record Activity([property: Id(0)] string ActivityId)
{
    internal virtual bool IsJoinGateway => false;

    internal virtual async Task<List<IExecutionCommand>> ExecuteAsync(
        IWorkflowExecutionContext workflowContext,
        IActivityExecutionContext activityContext,
        IWorkflowDefinition definition)
    {
        await activityContext.Execute();
        await activityContext.PublishEvent(new WorkflowActivityExecutedEvent(
            await workflowContext.GetWorkflowInstanceId(),
            definition.WorkflowId,
            await activityContext.GetActivityInstanceId(),
            ActivityId,
            GetType().Name));
        return [];
    }

    internal abstract Task<List<ActivityTransition>> GetNextActivities(
        IWorkflowExecutionContext workflowContext,
        IActivityExecutionContext activityContext,
        IWorkflowDefinition definition);
}

А вот, например, кастом-таск активити — она наследуется от базовой TaskActivity, добавляет TaskType (например, "rest-call" или "hello-world"), мапинги переменных и поверх базового ExecuteAsync публикует событие ExecuteCustomTaskEvent, на которое подпишется плагин-хост со своим грейном-обработчиком:

[GenerateSerializer]
public record CustomTaskActivity : TaskActivity
{
    [Id(1)] public string TaskType { get; init; }
    [Id(2)] public List<InputMapping> InputMappings { get; init; }
    [Id(3)] public List<OutputMapping> OutputMappings { get; init; }

    internal override async Task<List<IExecutionCommand>> ExecuteAsync(
        IWorkflowExecutionContext workflowContext,
        IActivityExecutionContext activityContext,
        IWorkflowDefinition definition)
    {
        var commands = await base.ExecuteAsync(workflowContext, activityContext, definition);

        var variablesId = await activityContext.GetVariablesStateId();
        await activityContext.PublishEvent(new ExecuteCustomTaskEvent(
            await workflowContext.GetWorkflowInstanceId(),
            definition.WorkflowId,
            definition.ProcessDefinitionId,
            await activityContext.GetActivityInstanceId(),
            ActivityId,
            TaskType,
            InputMappings,
            OutputMappings,
            variablesId));

        return commands;
    }
}

Оркестратором над всем этим выступает грейн WorkflowInstance — он event-sourced через Orleans JournaledGrain, с кастомным storage-провайдером поверх EF Core. Все мутации идут через единый pipeline DrainAndRaiseEvents → RaiseEvent → ConfirmEvents, чтобы между событиями не было «полуразобранных» состояний. Объявление грейна (он разбит на три partial-файла; ниже только корневой):

public partial class WorkflowInstance :
    JournaledGrain<WorkflowInstanceState, IDomainEvent>,
    IWorkflowInstanceGrain,
    ICustomStorageInterface<WorkflowInstanceState, IDomainEvent>
{
    public ValueTask<Guid> GetWorkflowInstanceId()
        => ValueTask.FromResult(this.GetPrimaryKey());

    public override Task OnActivateAsync(CancellationToken ct) { /* replay journal, restore timers */ }

    public async Task SetWorkflow(IWorkflowDefinition workflow, string? startActivityId = null) { /* ... */ }
    public async Task StartWorkflow() { /* ... */ }
    public async Task CompleteActivity(string activityId, ExpandoObject variables) { /* ... */ }
    public async Task FailActivity(string activityId, Exception exception) { /* ... */ }

    // Custom event-sourcing storage
    public Task<KeyValuePair<int, WorkflowInstanceState>> ReadStateFromStorage() { /* ... */ }
    public Task<bool> ApplyUpdatesToStorage(IReadOnlyList<IDomainEvent> updates, int expectedVersion) { /* ... */ }
}

Variables в workflow — это ExpandoObject с динамическими полями: переменные процесса появляются и исчезают по ходу исполнения, BPMN-моделирование не любит жёсткую типизацию на уровне движка. Сериализация ExpandoObject через Orleans — отдельный сюрприз, для которого пришлось писать собственный суррогат-конвертер (он, кстати, изначально жил в engine-сборке, и из-за этого внешние плагин-хосты падали с CodecNotFoundException — пришлось переезжать в leaf-package; тоже история).

Это именно тот слой, который я раньше пилил неделями, спотыкаясь то о персистентность, то о boundary events, то о дедлоки в корреляции сигналов. С ИИ-партнёром эти недели схлопнулись в дни — но повторюсь: не за счёт магии, а за счёт того, что у меня уже была нормальная архитектура, в которую можно было просто класть код.

Регрессионные тесты: когда разработка обогнала моё внимание

Через неделю после старта новой волны вышло браузерное расширение Claude — Claude in Chrome. И тут у меня щёлкнуло.

У Fleans есть админ-панель (Fleans.Web) и REST API (Fleans.Api). А что, если отдать регрессионный прогон ИИ-агенту, который сам тыкает в интерфейс, сам дёргает API, сам проверяет, что поведение не сломалось? Я попробовал. Сработало.

Разработка к этому моменту шла так быстро, что я перестал успевать всё тщательно проверять руками. И тут был выбор: либо тормозить скорость ради своей способности проверить, либо менять сам процесс проверки.

Я выбрал второе. И это был момент, после которого что-то во мне внутренне сместилось.

Я начал думать не как программист, а как продакт-оунер. Вместо вопроса «какой код мне написать, чтобы это работало» я стал задавать другой: «какие свойства системы мне важно гарантировать, и как организовать процесс, чтобы эти гарантии держались без моего ручного участия». Это другой слой мышления. Роль программиста у меня в проекте забрал Claude — и, положа руку на сердце, он справляется с ней быстрее меня.

Параллельно я попросил Claude написать для Fleans собственный MCP-сервер — Model Context Protocol, через который другие агенты могут читать и менять состояние моего движка напрямую. Получилось изящно: вместо того чтобы ИИ кликал по кнопкам в моей же админке, он обращается к проекту через программный интерфейс, который этот же ИИ и написал. Петля замкнулась. Сейчас fleans-mcp — один из четырёх контейнеров в релизном бандле, наравне с API, Web и Worker.

К процессу регрессии добавились ещё два слоя автоматики. Первый — обычный CI: build, unit, integration, pg-tests, отдельная джоба для Playwright E2E. Второй — каталог manual-test-планов в tests/manual/. Сейчас в нём больше 25 автоматизированных Playwright-сценариев, и каждая фича обязана положить туда test-plan.md и .bpmn-фикстуру. Это правило живёт в CLAUDE.md, и агенты-исполнители его соблюдают без напоминаний.

OpenClaw и команда маленьких агентов

Где-то в это же время в ленте хайпанул OpenClaw — агент из серии «вот вам автономный работник, дайте ему задачу и забудьте». Я посмотрел на это и понял: мне нужны такие же маленькие агенты, работающие над задачами моего проекта, но уходить с Claude я не хочу.

Как раз в тот момент Claude добавил возможность запускать scheduled tasks — регулярно или по триггеру, без моего участия за клавиатурой. Этого оказалось достаточно.

Я сел и распределил роли. Создал в GitHub проектную доску (Claude, кстати, очень хорошо работает именно с GitHub — issues, PR, labels, milestones, вся эта машинерия для него родной язык). Доска — это полноценная конечная state-machine: Backlog → In Analysis → Review Analysis → Ready → In Progress → In Review → Testing → Review by Human → Done. Завёл отдельных «агентов» с разными профилями и инструкциями:

• Worker — диспетчер. Каждые 10 минут смотрит на доску, по приоритетной таблице выбирает один задачник и роутит его в специализированный скилл. Берёт блокирующий per-машинный lock, чтобы два запуска не подрались.

• Analytic — берёт сырой issue, разбирает требования, пишет design & plan, формулирует blocking-вопросы и оставляет задачу ждать ответа.

• Analysis-review — критически читает дизайн, отделяет блокеры от важного и мелкого, возвращает на доработку, если нашёл регрессии.

• Developer — реализует одобренный план: ветка, коммиты, PR.

• Hourly-code-review — ревьюит свежие PR, ставит маркер bot-approve или bot-block в первой строке отзыва. Worker читает этот маркер и автоматически промоутит зелёный PR в Testing, если CI зелёный и маркер свежее последнего коммита.

• Manual-regression-testing — для всего, что прошло code-review: гоняет регрессию против PR-ветки и подписывает вердикт.

Задачи теперь стали делаться быстрее и без моего непосредственного участия. Звучит как мечта, но у этого есть обратная сторона, о которой я скажу честно.

Scalability Auditor: самая нужная роль из всех

Чем больше кода писалось без моего прямого участия, тем больше я боялся одного: что в какой-то момент мы сделаем архитектурный выбор, который через три месяца приведёт к тому, что всю эту махину придётся перепиливать.

Я создал отдельную роль — Scalability Auditor. Его задача проста: регулярно смотреть на кодовую базу с высоты птичьего полёта и отвечать на вопросы: «где тут узкое место», «где мы заложили не-масштабируемое решение», «где стейт живёт не там, где должен», «где у нас будут проблемы на 10× нагрузке». И главное — он не сам всё чинит, а заводит задачи на ту же самую доску.

Это оказалось той ролью, без которой вся система агентов скатилась бы в технический долг за пару недель. Отдельный агент, который умеет говорить «нет, это так делать нельзя», — это не про скорость, это про сохранение проекта во времени.

Хороший живой пример из недавнего: пока я гонял свежесобранную версию локально, я наткнулся на интермиттент-ошибку в управленческой Web. Сам нажимал «Старт» на процесс — иногда летело Unable to load Fleans.Application.Grains.IWorkflowInstanceGrain, Fleans.Application, иногда нет. Дальше дело пошло так: за полчаса агент-аналитик локализовал баг (плагин-силос регистрировался как Orleans gateway, хотя Fleans.Application он не загружает), агент-разработчик собрал PR на одну строку плюс регрессионный тест, я провёл self-review с маркером bot-approve, оба PR — engine-фикс и обходное решение в репозитории шаблона — улетели в main. В старой парадигме «один человек + ночь» такое бы заняло часа три минимум.

После этого я честно скажу: я всё меньше понимаю конкретный код в каждом уголке проекта. Его стало много, его становится больше быстро. Я сконцентрировался на архитектуре и меньше слежу за строчками.

Это страшновато. И одновременно это и есть тот самый сдвиг, про который все говорят, но который сложно прочувствовать, пока не окажешься внутри. Ты не перестаёшь контролировать систему — ты просто контролируешь её на другом уровне абстракции.

Что внутри Fleans (так, чтобы было понятно, чем тут вообще можно пользоваться)

Если выкинуть всё лишнее, Fleans стоит на десяти вещах. Это ровно те тезисы, которые я выложил на главную страницу сайта, потому что они и есть продукт:

• Акторы, а не оркестраторы. Каждый workflow — независимый Orleans-грейн. Нет общего координатора, нет lock-contention. Добавил силос — получил линейный прирост пропускной способности.

• Чтение масштабируется отдельно от записи. В движок встроен CQRS-split: read-traffic ходит через NoTracking-query context, при желании — в отдельную Postgres-реплику. Админка и поллеры не мешают исполнению.

• Event-sourced, crash-safe. Append-only журнал событий с детерминированным replay. Силос упал посреди процесса? Orleans поднимет грейн на другом силосе с того же места, осиротевшего состояния не будет.

• BPMN-восстановление как первоклассные конструкции. Compensation, error boundaries, escalation — это явные семантики языка, а не ad-hoc try/catch. Ошибочные ветки моделируются так же, как успешные, и видны бизнесу на той же диаграмме.

• Hot path работает из памяти. Активные workflow живут в RAM, промежуточные шаги в БД не ходят. События одного грейн-вызова батчатся в одну транзакцию в конце — а не пишутся по штуке.

• Материализованные проекции для чтения. Админка и REST-запросы про состояние читают предварительно собранную EF-проекцию. Никакого replay-журнала ради рендера списка или поллинга «уже завершилось?».

• Поднимаешь у себя — точка. Fleans поставляется одним контейнерным образом, который запускается на ноутбуке, виртуалке или в Kubernetes. Данные не уходят за периметр, SaaS-зависимости нет.

• Своя база на выбор. SQLite для разработки, PostgreSQL для прода — переключается одним ключом конфига, без правок кода. Провайдер-модель открытая: нужна другая БД — пишешь свой адаптер.

• Свой стрим-провайдер тоже на выбор. Доменные события идут через Orleans Streams. По умолчанию — in-memory; флаг Fleans:Streaming:Provider=kafka переключает на встроенный Kafka-адаптер для cross-silo durability. Можно подсунуть свой — точка расширения та же.

• Свои таски и свои воркеры. REST-вызов, очередь, любая кастомная интеграция оформляются как BPMN-таск через шаблонный repo fleans-custom-worker-example. Хост плагинов масштабируется независимо от engine — один workflow может разлетаться по твоему собственному флоту воркеров.

Установка одной командой:

# скачивает docker-compose-бандл из последнего релиза
gh release download --repo nightBaker/fleans -p 'docker-compose-*.zip'
unzip docker-compose-*.zip && docker compose up -d

Это поднимает api (8081), management web (8080), worker, mcp, Postgres, Redis и Aspire-дашборд. Через минуту можно деплоить .bpmn через REST или дизайнить процессы прямо в Web. Helm-чарт лежит там же в релизе, подписан cosign-ом.

Постоянное обучение: ИИ, который учится на своих ошибках

ИИ всё ещё ошибается. Мне бы очень хотелось написать, что Claude у меня ни разу не завалил задачу, но это было бы неправдой. Иногда он предлагает решение, которое на бумаге нормальное, а в контексте моего проекта ломает какой-то неочевидный инвариант. Иногда забывает про договорённости, которые мы приняли две недели назад.

Я сделал с этим вот что: попросил агента обучаться на своих ошибках. После каждой задачи, где были проблемы, он обновляет свои же инструкции — добавляет пункт «в этом проекте так делать нельзя, потому что [причина]». Со временем получается растущий свод правил, который по сути является историей граблей, на которые мы наступали вместе. Сейчас в CLAUDE.md есть отдельная секция «load-bearing invariants» — там перечислены вещи, которые сломать = прислать прод-баг: «каждая активити инстанс исполняется ровно один раз», «handlers компенсации работают в изолированных скопах переменных», «registration-vs-cleanup error asymmetry» и так далее. Эти правила писались не из любви к порядку — каждое из них стоит конкретного инцидента в истории.

Ещё я попросил его поддерживать сайт проекта с документацией — и обновлять документы с каждой задачей. Чтобы человек, пришедший в проект сегодня, видел не «README от трёх месяцев назад», а актуальное описание того, как всё устроено. Для разделения аудиторий ввели жёсткое правило: репо-документация (README.md, docs/conventions/) — для контрибьюторов с исходниками; сайт (website/...) — для пользователей, которым достаточно релизного артефакта. CI-проверка pin-guard отдельно следит, чтобы в публичную документацию не утекли inline-ссылки на исходники с привязкой к номерам строк. Потом я пошёл дальше и попросил сделать 3D-сцену на главной странице сайта, которая визуально показывает сильные стороны Fleans — акторную модель, исполнение BPMN, распределённость. Это перебор с точки зрения «а надо ли», но выглядит эффектно и собирает внимание. А для проекта, который ищет первых пользователей, внимание важнее, чем умеренность.

Что я понял за эти полгода

Мне неловко писать «выводы» — это всегда звучит пафосно. Но без них рассказ про AI-разработку превращается в репортаж. Попробую честно, без оптимизма «всё будет супер» и без апокалипсиса «все умрут».

ИИ развивается быстрее, чем мы успеваем это осознать. Я не шучу. Между «ChatGPT год назад не смог собрать мне картину предметной области» и «Claude сейчас работает в моей кодовой базе лучше, чем я сам» прошло меньше 18 месяцев. Я не знаю, что будет ещё через 18. И, судя по всему, никто не знает.

Первый рабочий релиз я выкатил за три месяца. К концу полугода у меня были подписанные артефакты, документация, шаблон плагина и автоматизированная регрессия. Это не похвала мне, это констатация факта про инструмент. Я всё тот же разработчик, что и год назад. Разница — в инструменте, в моей готовности перестроить под него процесс и в том, что у меня уже была архитектура, на которую можно было опираться.

ИИ с контекстом проекта превосходит уровень сеньора. Это самое спорное утверждение, и я готов его защищать. Не «ИИ вообще умнее сеньора» — нет. А именно «ИИ, который читал ваш CLAUDE.md, ваш домен, ваши commit-сообщения и ваши прошлые разговоры, предлагает решения лучше, чем опытный инженер, которого вы онбордили неделю». Потому что инженеру нужно несколько месяцев, чтобы начать думать «в вашей системе координат». ИИ впитывает контекст за минуты.

Архитектура и принципы становятся критичнее, чем когда-либо. Если у вас нет нормального контекста, ИИ усилит и умножит ваш бардак. Если у вас есть DDD, Clean Architecture, чёткие границы модулей — ИИ полетит по ним, как поезд по рельсам. Инвестиции в архитектуру окупаются с множителем.

Компетенции умножаются, но неопытный разработчик может вылететь из собственного проекта. Это тёмная сторона. Скорость ИИ такова, что если вы не успеваете понимать, что делается в вашем коде, то через месяц вы уже не хозяин проекту. Это не страшилка, это реальный риск. Единственная защита — держать голову на уровне архитектуры, а не строчек.

Нужно мыслить как продакт-оунер, а не просто инженер. Это следствие предыдущего. Ваша ценность смещается из «я напишу» в «я определю, что и зачем должно быть написано, и организую проверку».

Идея становится важнее, чем раньше. Средние специалисты — менее. Это жёстко, но честно. Раньше идея без исполнителей была просто болтовнёй. Сейчас идея с нормальной архитектурной головой и ИИ-агентом — это работающий продукт за квартал. Для тех, у кого есть идеи, это великолепное время. Для тех, кто жил на исполнительском звене, — тревожное.

ИИ заменит наши роли, но не нас. Пока. Я правда так думаю. Роль программиста в моём проекте забрал Claude. Но меня как человека, у которого есть вкус к архитектуре, понимание предметной области и желание вести проект, он не заменил. Роль — это функция. Человек — это что-то другое. Пока.

ИИ здесь, и никуда не денется. Адаптация произойдёт быстрее, чем думают скептики. И не так быстро, как думают новаторы. Где-то посередине, как всегда и бывает.

Зачем я это всё написал

Честно — чтобы рассказать про Fleans. Проект живой, открытый, мне нужны первые разработчики, которые хотят с ним поиграть, погонять, покритиковать. Если вы работали с Camunda и у вас есть конкретное «а почему это не сделали так», я хочу это услышать. Если хотите написать свой первый кастом-таск — есть шаблон-репо fleans-custom-worker-example, который собирается с актуальными NuGet-пакетами и стартует одной командой. Если вы оперируете Orleans-кластерами в проде и видите, что я что-то делаю не так — пишите, перебивайте, поправляйте.

Но в процессе писания я понял, что статья не про движок. Она про то, как вообще устроена разработка в 2026 году, когда ты один и у тебя есть инструмент, которым ещё недавно никто не умел пользоваться. И что этот инструмент уже не «помощник», а полноценный участник процесса, у которого ты отбираешь задачи, которому ты делегируешь подсистемы и которого ты иногда ругаешь за архитектурные решения.

Если кому-то это поможет решиться на свой проект, который давно лежит в папке «когда-нибудь», — я буду рад. Начинать сейчас правда хорошее время.

---

Fleans — open-source workflow engine на .NET Orleans и BPMN 2. Репозиторий: github.com/nightBaker/fleans. Шаблон плагин-хоста: github.com/nightBaker/fleans-custom-worker-example. Документация — в профиле. Вопросы, критика и идеи — в комментариях, я читаю каждый.