С помощью ИИ вполне можно сгенерировать сайт‑визитку или игру в крестики‑нолики, составить план отпуска или сделать более сложные вещи. А как насчёт того, чтобы сгенерировать ПО для управления атомной станцией или самолётом? Или как насчёт планирования не отпуска, а проекта на сотни человеко‑лет? Это в принципе возможно и можно ли доверять результатам работы ИИ?

В статье сначала будет немного теоретических рассуждений на эту тему, идея банальная: сложные задачи нужно декомпозировать. Затем рассмотрим это на конкретном примере, разобьём разработку приложения для HR отдела на три шага: 1) описание процесса приёма сотру��ников на работу, 2) описание модели состояний для кандидата при прохождении собеседований, 3) генерация кода.

В заключении опишем профит от моделирования, если вы используете ИИ. И профит от ИИ, если вы занимаетесь моделированием.

Как на наш взгляд люди решают такие задачи

Что отличает человека, который хорошо разбирается в своей области, быстро и качественно принимает решения от человека, который только погружается в эту область и не может похвастаться всем этим? На мой взгляд, это мыслительные паттерны, которые сформировались у него с опытом.

Представьте ИТ архитектора, которому нужно оценить трудозатраты на реализацию приложения. Он может сделать это следующим образом:

• Разобьёт приложение на функциональные блоки (подсистемы)

• Для каждого блока определит перечень выполняемых им функций

• Если функции сложные, то он декомпозирует их на более простые

• Разобьёт эти функции на категории по трудозатратам

• Для каждой категории прикинет сколько времени в среднем понадобится на реализацию: день, неделя, месяц

• По непонятным функциям задаст вопросы

• Добавит к оценке риски

• Приоритезирует функции по степени важности

• На выходе получит минимальную, среднюю и максимальную оценку затрат на реализацию

• Ещё получит заготовку требований на дальнейшую проработку аналитиками

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

Что включает в себя этот паттерн? Последовательность шагов? Наверное, да, но на мой взгляд на первом месте всё‑таки не процесс, а понимание специалистом своей предметной области. Он понимает следующее:

• Приложение можно представить как совокупность функциональных блоков

• Каждый блок выполняет функции

• Функции можно декомпозировать

• У функций могут быть параметры

• Функции можно разбивать на категории по степени сложности

• Для функций можно определять приоритет реализации

Если обобщить, то у специалиста есть представление о следующем:

• Основные понятия в этой предметной области: приложение, функциональный блок, функция

• Отношения между понятиями: выполнение, декомпозиция

• Атрибуты понятий и отношений: трудозатраты, приоритет

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

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

• Цель: выбрать оптимальную работу

• Критерии достижения цели: высокая зарплата, интересные проекты, карьерные перспективы, свободное время, качество жизни в городе, если планируется переезд

• Возможные варианты: компания 1, компания 2, своя компания, фриланс

Определяю отношения между этими понятиями:

• Критерии влияют на достижение цели (чем выше зарплата или чем интереснее проекты, тем ближе я к правильному выбору работы)

• Каждый из вариантов более или менее привлекателен с точки зрения каждого из критериев

Определяю атрибуты:

• Важность критерия: например, для зарплаты важность 7 из 10, а для интересных проектов 8 из 10

• Оценка вариантов с точки зрения каждого критерия: например, в компании 1 будет высокая зарплата на 9 из 10, но не особо интересные проекты на 2 из 10

Затем, имея в голове такую ментальную карту, я могу последовательно:

• Оценить важность критериев

• Оценить каждый вариант по каждому из критериев

• Получить итоговую оценку для каждого варианта

• Выбрать вариант с максимальной оценкой

Иными словами, схема точно такая же как и в примере с ИТ архитектором. Сначала у меня в голове формируется пространство понятий, затем я последовательно наполняю его данными.

Ещё один пример. Допустим я хочу сварить суп. Для этого у меня в голове сначала должна быть такая ментальная карта:

• Понятия:

  • Ингредиент: морковка, картофель, вода, соль, ...

  • Действие над ингредиентом: нарезать, налить, помешивать, ...

• Отношения между понятиями:

  • Отношение между действием и объектом: нарезать морковку, нарезать картофель, налить воду, ...

  • Отношение последовательности между действиями: сначала нарезать морковку, а затем высыпать в кастрюлю

• Атрибуты:

  • Количество

  • Длительность

Абсолютно любая область знаний может быть разложена на эти три составляющие: понятия, отношения, атрибуты.

Если подытожить этот раздел, то люди на наш взгляд мыслят при решении своих задач следующим образом:

• Сначала формируют в голове пространство понятий, отношений и атрибутов

• Затем планируют шаги по наполнению этого пространства конкретными фактами и данны��и

Например, для ИТ архитектора это выглядит так:

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

На каждом шаге этот понятийный шаблон наполняется фактами:

Как такие задачи решают два человека

Теперь представим, что задача более сложная и с ней не справится один человек.

Например, ИТ архитектор может делегировать часть своей работы другому сотруднику. При этом когда он ставит задачу, то описывает всё ту же ментальную карту из своей головы: нам нужно будет реализовать приложение, в нём будут такие‑то функциональные блоки, для части блоков я уже описал и оценил функции, сделай то же самое для оставшихся блоков. Иными словами, вот, тебе шаблон, заполни его. Затем ИТ архитектор оценивает что сделал его коллега, на сколько правильно он понял задачу, он описал и оценил функции или сделал что‑то совершенно другое. Если всё нормально и результат работы коллеги укладывается в шаблон (пространство понятий), то ИТ архитектор дополняет общую картину этими результатами.

Или карьерный консультант задаёт клиенту наводящие вопросы: что вам вообще важно в работе (зарплата, карьера, интересные проекты, свободное время). Предлагает варианты развития. На основе полученных ответов консультант дополняет своё представление о желаемой карьере человека. А если человек отвечает что‑то совсем невпопад, например «на моей прошлой работе у коллеги на столе был кактус, который меня нереально бесил, потому что у меня аллергия на цветение кактусов», то консультант возвращает клиента в конструктивное русло. Информацию о кактусах просто некуда положить в карьерную карту человека.

Или если в книге рецептов кроме информации об ингредиентах и последовательности действий вы напишите, что морковку должен нарезать мужчина имя которого начинается на букву «Д» и обязательно левой рукой, а картофель должна нарезать девушка с именем на букву «А» и обязательно правой рукой, то читатели усомнятся это 1) книга рецептов или 2) магических зелий. Потому что для 2-ой предметной области вся эта информация выглядит более релевантной чем для 1-ой.

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

• У каждого из них в голове есть своё представление о предметной области (своё пространство понятий, свой шаблон)

• Они ставят задачу другим людям исходя из этого представления

• Затем соотносят результат полученный от другого человека со своим представлением

• Если они видят, что результат отличается от ожидаемого, то выравнивают между собой свои пространства понятий

• И затем объединяют свои представления о предметной области

Для ИТ архитектора и аналитика этот процесс совместного решения задачи может выглядеть следующим образом:

В этом гипотетическом примере у аналитика изначально было неправильное представление о решаемой задаче. Он понял так, что необходимо описать целевую аудиторию для приложения и описать риски для первого функционального блока. А затем они с ИТ архитектором выравняли своё представление о предметной области, и аналитик описал уже функции.

Как и в предыдущем разделе, здесь гораздо важнее, чтобы у всех участников процесса было совместимое представление о предметной области. А конкретная последовательность шагов уже вторична.

Как такие задачи решают группы людей

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

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

Как такие задачи могут решаться с помощью ИИ

Разобрались с людьми, а как это делает ИИ? Наверное так:

Если задача простая и от результата не зависят человеческие жизни, то почему бы и нет. Так вполне можно сгенерировать простое приложение или написать статью на хабр. Если результат похож на что‑то осмысленное, то не так важно каким образом он был получен.

Но если задача сложная и нужна гарантия, что результат будет адекватным, то конечно схема должна быть такая же как и для проектов, выполняемых людьми:

Задача разбивается на отдельные шаги, на каждом шаге есть понятный артефакт, который может быть проверен людьми или с помощью формальных методов, да, или пусть даже с помощью самого же ИИ.

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

Как это может выглядеть на практике?

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

Допустим мне нужно разработать приложение для отдела кадров, чтобы резюме потенциальных кандидатов не терялись, сотрудники HR отдела отслеживали на какой стадии находится взаимодействие с каждым из кандидатов, отслеживали ключевые показатели своего подразделения. Я могу ровно такой промпт и использовать для ИИ, могу попросить его детализировать требования. И это даже сработает, если приложение достаточно простое, ИИ вполне сгенерирует что‑то осмысленное.

Но представим, что этот HR отдел не в абы какой провинциальной шараге с одним собеседованием на кандидата, а где, как и в любой приличной BigTech‑компании, есть хотя бы десяток‑другой этапов собеседований. Такое приложение ИИ нормально уже не сгенерирует. Во‑первых, он будет бесконечно путаться после какой секции интервью какая секция и при каких условиях должна следовать. Во‑вторых, даже если он всё это каким‑то чудом реализует правильно, то потом в жизни никто не разберется какая бизнес‑логика скрывается за этим лапшакодом.

Шаг 1. Описываем процесс прохождения собеседований

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

Запускаю VS Code (или любой другой MCP‑клиент с поддержкой OAuth 2.0, например, Windsurf или Cursor).

В VS Code открываю настройки MCP‑серверов. Для этого нажимаю Ctrl+Shift+P и выбираю в списке «MCP: Open User Configuration».

Открывается файл mcp.json, в который добавляю настройки нашего MCP‑сервера:

{
  "servers": {
    "Architeezy": {
      "url": "https://architeezy.com/mcp",
      "type": "http"
    }
  }
}

В Windsurf или в Cursor будет похожий по смыслу файл.

Затем открываю чат и список MCP‑серверов:

Подключаюсь к серверу:

После успешной аутентификации можно убедиться, что найдены MCP инструменты для работы с моделями:

Пишем промпт:

Создай в Architeezy проект моделирования HR demo и опиши в нём процесс прохождения сотрудником собеседований в BigTech компании

Наблюдаем за ходом рассуждений ИИ:

Скрытый текст

GitHub Copilot: I'll help you create an HR demo project in Architeezy and model the interview process for employees at a BigTech company.

Let me start by exploring the available scopes and then create the project.

Ran listScopes

Completed with input: {}

Ran createProject

Completed with input: {
"scopeId": "0194efd0-43f9-7fa6-93f8-5e75f0a91c22",
"name": "HR Demo"
}

Great! Now let me check what model types are available for this project.

Ran listAllowedModelKinds

Completed with input: {
"projectId": "019a72ee-add5-7655-a990-e046978ecba3"
}

I'll create a BPMN-like process model using the Event-Driven Process Chain (EPC) model type, which is suitable for modeling business processes like the interview process.

Ran createModel

Completed with input: {
"projectId": "019a72ee-add5-7655-a990-e046978ecba3",
"kind": "instance-model:019540f3-2600-7ca1-81ae-9a8d2ec13023:019540f3-487b-71c0-bfa1-90c37717198b:EventDrivenProcessChain",
"name": "Процесс собеседования в BigTech"
}

Now let me check the metamodel to understand what objects I can create in this EPC model.

Ran listAllowedObjectKinds

Completed with input: {
"projectId": "019a72ee-add5-7655-a990-e046978ecba3",
"parentObjectId": "019a72ee-eb93-779e-ae85-1f96aac4131b"
}

Let me check the metamodel structure to understand the required properties for each object type.

Ran readMetamodel

Completed with input: {
"projectId": "019a72ee-add5-7655-a990-e046978ecba3",
"namespaceUri": "https://architeezy.com/metamodel/epc/dev/epc"
}

Now I understand the structure. Let me generate IDs and create a comprehensive interview process. I'll model the typical BigTech interview process with multiple stages.

Ran generateId

Completed with input: {
"count": 40
}

Now I'll create the complete interview process model with events, functions, participants, and gateways. Let me build the model content with all the process steps.

Ran updateModel

Completed with input: {
"id": "019a72ee-ebb8-75fa-835b-c1182422e629",
"content": "{...здесь огромный JSON...}"
}

Perfect! I've successfully created an HR Demo project in Architeezy with a comprehensive interview process model for BigTech companies. Here's what was created:

## Проект "HR Demo" в Architeezy

URL проекта: https://architeezy.com/demo/hr-hiring/dev

### Модель процесса собеседования в BigTech компании

Я создал детальную модель процесса, которая включает:

#### Основные этапы процесса:

1. Подача заявки и проверка резюме

- Кандидат подает заявку

- Рекрутер проверяет резюме

- Принимается решение о соответствии требованиям

2. Телефонный скрининг

- Назначение телефонного интервью

- Проведение скрининга рекрутером

- Оценка кандидата

3. Техническое интервью (Coding)

- Назначение технического интервью

- Проверка навыков программирования

- Оценка технических знаний

4. System Design ��нтервью

- Проверка способности проектировать системы

- Оценка архитектурного мышления

5. Behavioral интервью

- Оценка поведенческих компетенций

- Проверка культурного соответствия

- Проводится Hiring Manager

6. Hiring Committee Review

- Комитет по найму рассматривает все результаты

- Принимается финальное решение

7. Оффер

- Подготовка и отправка предложения о работе

- Решение кандидата (принять/отклонить)

#### Участники процесса:

- Рекрутер - проверка резюме, телефонный скрининг, подготовка оффера

- Технический интервьюер - проведение технических интервью и System Design

- Hiring Manager - проведение Behavioral интервью

- Hiring Committee - финальное решение о найме

#### Точки принятия решений:

Модель включает 6 контрольных точек (XOR Gateway), где процесс может завершиться отказом кандидату или продолжиться на следующий этап.

Вы можете просмотреть и отредактировать модель по ссылке: https://architeezy.com/demo/hr-hiring/dev/process-sobesedovania-v-bigtech

Открываем модель процесса и смотрим что получилось:

Больше всего я был поражён фразой «Let me check the metamodel structure to understand the required properties for each object type», после которой ИИ отправил запрос на чтение метамодели, понял что в ней описано и с первого раза сгенерировал валидный JSON с моделью процесса! Причём изначально я добавил этот инструмент на чтение метамодели просто на всякий случай, чтобы был, и ИИ без подсказок догадался его использовать.

Я потратил всего пару дней на реализацию этого MCP‑сервера и сходу получил такой замечательный результат. Всё, аналитики и архитекторы больше не нужны, ИИ отлично справится с их работой, — подумал я. Но радость моя был не долгой. После этого я попробовал то же самое сделать на более примитивных моделях (GPT 4.1, GPT 5 mini) и они сожрали миллионы моих нервных клеток, добавили седых волос и забрали месяц жизни.

Во‑первых, для GPT 4.1, GPT 5 mini и аналогов пришлось добавить несколько более простых инструментов. Например, инструменты для создания, обновления и удаления отдельных объектов, потому что сгенерировать валидный JSON со всей моделью целиком эти варианты GPT не могут. Также пришлось добавить отдельные инструменты, чтобы двигать фигуры на диаграмме и изменять их размер. Я сразу отмечу, что модель (JSON с данными) и диаграмма (JSON с информацией о расположении фигур, цветах и так далее) — это две отдельные вещи.

Во‑вторых, в комментариях к MCP‑инструментам пришлось добавить инструкции типа того, что структура модели описана в метамодели и получить её можно таким‑то образом. Более примитивные ИИ сами до этого не догадываются.

В‑третьих, пришлось добавить тонны правил валидации и в наш код, и пропатчить нижележащие библиотеки, и добавить разные костыли, потому что Spring AI пока ещё достаточно сырой. Будьте уверены, что ИИ отправит такие корявые данные, которые ваш самый изощрённый тестировщик даже представить не может (кстати, это интересный сценарий использования ИИ). Или в какой‑то момент ИИ может просто «отупеть» и отправлять параметры, которых у MCP‑инструментов даже нет. Spring AI, который мы используем для реализации, тоже усложняет жизнь не особо информативными сообщениями об ошибках. Например, если в одном из параметров нужен UUID, а ИИ передаёт просто произвольную строку, то Spring AI почему‑то не пишет в каком именно параметре ожидается UUID. Будьте готовы к тому, что вам придётся делать достаточно детальные сообщения об ошибках, например «Объект с типом ... не может быть создан в объекте с идентификатором ..., доступны только следующие типы объектов: ...». В этом случае есть большой шанс, что ИИ исправит запрос.

Отлично, какая‑то модель есть, но почему диаграмма в одну линию? Пишем следующий промпт:

Расположи объекты на диаграмме оптимальным образом, чтобы процесс шёл сверху вниз. Между фигурами должен быть достаточный отступ. Если есть, то участники процесса должны быть справа, а ресурсы слева

Наблюдаем за рассуждениями:

Скрытый текст

GitHub Copilot: Я создам визуальное представление процесса с оптимальным расположением элементов. Сначала проверю, есть ли уже диаграмма для этой модели.

Ran listRepresentationsByModel

Completed with input: {
"modelId": "019a72ee-ebb8-75fa-835b-c1182422e629"
}

Отлично! Диаграмма уже существует. Теперь прочитаю её содержимое, чтобы увидеть текущее расположение элементов.

Ran readRepresentation

Completed with input: {
"id": "019a72ee-ec50-75c0-b1a0-5b9bf56b03f1"
}

Отлично! Теперь я вижу текущее расположение элементов. Все элементы расположены горизонтально в одну линию (все на y=0). Мне нужно перестроить диаграмму так, чтобы:

1. Процесс шёл сверху вниз (вертикально)

2. Участники были справа от основного потока

3. Был достаточный отступ между элементами

Давайте создам оптимальное расположение:

Ran moveDiagramNodes

Completed with input: {
"diagramId": "019a72ee-ec50-75c0-b1a0-5b9bf56b03f1",
"nodePositions": {...здесь новые координаты...}
}

Отлично! Я успешно расположил все элементы диаграммы оптимальным образом:

Результат оптимизации диаграммы:

✅ Процесс теперь идёт сверху вниз:

• Начинается с "Кандидат подал заявку" в верхней части

• Проходит через все этапы интервью последовательно

• Заканчивается решением о принятии/отклонении оффера внизу

✅ Участники процесса расположены справа:

• Рекрутер (справа, связан с первыми этапами)

• Технический интервьюер (справа, на уровне технических интервью)

• Hiring Manager (справа, на уровне Behavioral интервью)

• Hiring Committee (справа, на финальном этапе)

✅ Достаточные отступы между элементами:

• Вертикальный шаг: 150 пикселей между основными элементами

• Горизонтальное расстояние: 350 пикселей между основным потоком и участниками

• События отказа смещены влево для визуального разделения успешного и неуспешного путей

✅ Визуальная структура:

• Центральный поток процесса в середине

• Точки принятия решений (XOR Gateway) слегка смещены вправо

• События отказа слева от основного потока

• Все связи между элементами автоматически перерисовываются

Вы можете просмотреть обновлённую диаграмму по ссылке: https://architeezy.com/demo/hr-hiring/dev/process-sobesedovania-v-bigtech

И видим результат:

Лично я в восторге! Почти нормальная диаграмма. Немного корявые связи, но я и не просил менять их расположение. Ещё надписи с условиями отображаются внутри логических операторов, но это уже наша багофича.

Вообще автоматическое расположение фигур на диаграмме — это не самая тривиальная задача. И для нас реализация этого была головной болью. Конечно есть готовые движки, но они часто работают не так как нужно и, уж, точно в них не так просто для всех текущих и будущих нотаций добавлять правила типа «участники процесса должны быть справа», «ресурсы должны быть слева», «основное событие слева, а дополнительные — справа» и так далее. В общем, идеального движка не существует. Но для ИИ это как‑раз отличная задача, и мы можем сэкономить время на реализации.

Поправлю несколько стрелочек руками, в итоге процесс выглядит вполне осмысленным:

Эта модель мне показалась слишком простой и в итоге получилось что‑то такое:

Здесь уже три вида ветвлений:

• Исключающее ИЛИ (крестик) — процесс может идти только по одной из веток

• Неисключающее ИЛИ (галочка вниз) — процесс может идти по произвольному количеству веток, не обязательно по одной

• И (галочка вверх) — процесс параллельно идёт по всем веткам

Что нам даёт эта модель?

• Модель можно показать специалисту, а он оценит правильно описан процесс или нет. На мой взгляд, это на много лучше и проще, чем показывать людям тонны текста, сгенерированного ИИ, или тем более тонны кода

• Модель формальная в отличие от текста на русском языке:

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

  • Также можно проверить модель на соответствие более сложным правилам. Например, в EPC‑моделях перед ветвелением ИЛИ обязательно должна быть функция, в которой принимается решение, по каким веткам будет продолжаться процесс. Или нам важно, чтобы у каждой функции был указан исполнитель. Эти правила могут быть реализованы в самом инструменте моделирования, либо можно попросить ИИ проверить модель

• Модель сохраняется в репозитории, к ней можно легко вернуться. В отличие от чата с ИИ, в котором тонны текста

• Модель можно обрабатывать программно и для этого не требуется ИИ. Можно через API получить JSON, с помощью скрипта преобразовать его в другой JSON, в документ, сгенерировать код

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

Шаг 2. Описываем модель состояний для кандидата

Можно было бы попросить ИИ уже на основе этого процесса сгенерировать приложение, но к сожалению он это не осилил. Он путается в переходах между функциями и в ветвлениях. Но это не удивительно, потому что и не каждый человек в этом сходу разберётся. Семантика выполнения EPC моделей не такая тривиальная.

В приложении мне не нужны функции, события, ветвления. Я хочу, чтобы оно было на много проще. У каждого кандидата должно быть текущее состояние, должны быть кнопки для перевода его в следующее состояние. Уже на этом этапе есть два варианта реализации:

• События — это состояния, а при выполнении функций кандидат переходит в новые состояния. Например, изначально он в состоянии «Появилось новое резюме», затем нажимаю кнопку «Оценка резюме», появляется форма, в которой я отмечаю релевантное это резюме или нет. В зависимости от выбора кандидат переходит в состояние «Резюме релевантно» или «Резюме нерелевантно». Это достаточно естественный способ реализации процессов

• Функции — это состояния, а события — это переходы. Изначально кандидат находится в состоянии «Оценка резюме», для него показываются две кнопки «Резюме релевантно» и «Резюме нерелевантно». При нажатии на «Резюме релевантно» кандидат переходит в следующее состояние «Проведение первичного интервью», а при нажатии на «Резюме нерелевантно» переходит в конечное состояние

В обоих случаях мы преобразуем процесс в упрощенный граф с вершинами и дугами. Только в первом случае вершины графа — это события, а дуги — функции. А во втором случае наоборот: вершины графа — это функции, а дуги — события. На практике используются оба варианта, они обладают своими преимуществами. Если вам интересна эта тема можете почитать про PERT, GERT, метод критического пути.

Мы хотим реализовать очень упрощенное приложение и второй вариант будет более удобным.

Теперь следующая сложность. С функциями, событиями, исключающими ИЛИ разобрались. А что делать с параллельными ветками в процессе? В этом случае для каждой ветки нужно будет в приложении реализовать отдельное подсостояние со своими переходами. Например, «Подготовка документов» и «Проверка службой безопасности» в нашем процессе выполняются параллельно. Любая из этих функций может начаться раньше другой или завершиться раньше. В приложении необходимо показать отдельные кнопки начала и завершения для каждой ветки. А чтобы процесс найма мог продвинуться дальше необходимо завершить обе ветки процесса. Забегая вперёд, мы реализуем это через подсостояния.

Ещё большая сложность с ветвлениями типа неисключающее ИЛИ. Для них может выполняться только одна ветка или все ветки или какая‑то часть веток. Например, в нашем процессе найма предполагается, что аналитики могут быть многопрофильными (бизнес‑аналитик, системный аналитик или аналитик данных). В зависимости от количества профилей мы запустим необходимое количество секций собеседования. Самое сложное, в том, что процесс может продолжиться только после того как все запущенные ветки завершатся. Есть разные способы реализовать это в коде. Самый очевидный вариант — это показывать человеку формочку, в которой он отмечает галочками профили аналитика, допустим он отметил «Бизнес‑аналитик» и «Системный аналитик». Затем при слиянии веток мы проверяем завершены ли эти две ветки и если да, то продвигаем процесс дальше. Но это усложнение реализации, нужно запоминать значения галочек и потом проверять их. Мы реализуем это через вложенные состояния, дальше увидите как.

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

Пишем серию промптов, я не буду детально останавливаться на каждом из них. Я скармливал их более примитивной GPT 5 mini, поэтому просил создавать отдельные объекты, а не всю модель целиком, просил не делать ничего лишнего, плюс ИИ внезапно отупел и стал отправлять вообщ�� какие‑то рандомные данные в MCP‑сервер. Наверное для более мощного ИИ можно было бы написать более простые промпты:

Найди процесс найма сотрудников в проекте HR в Architeezy. Создай в этом же проекте новую модель состояний.

Для каждого AND ветвления в процессе создай составное состояние, в котором количество регионов равно количеству веток. Придумай обобщающее название для этого состояния на основе функций в ветках. В каждом регионе добавь начальное и конечное состояние. И между ними промежуточное состояние с названием как у функции в этой ветке. Добавь переходы между состояниями. Они должны принадлежать регионам. Обрабатывай все AND ветвления. Не создавай ничего для AND слияний. Используй для этого только модели, а не диаграммы. При отправке запросов используй правильные параметры для MCP инструментов. Создавай объекты в модели по одному.

Для каждого OR ветвления в процессе создай составное состояние, в котором количество регионов равно количеству веток. Придумай обобщающее название для этого состояния на основе функций в ветках. В каждом регионе добавь начальное и конечное состояние. И между ними промежуточное состояние с названием как у функции в этой ветке. Добавь переходы между состояниями. Они должны принадлежать регионам. Переход из начального состояния в основное состояние назови также как событие перед функцией. Добавь переход в каждом регионе переход из начального состояние в конечное состояние с названием «Пропустить». Обрабатывай все OR ветвления. Не создавай ничего для OR слияний. В каждой ветке есть хотя бы одна функция. Для XOR ветвлений не делай ничего. Используй для этого только модели, а не диаграммы. При отправке запросов используй правильные параметры для MCP инструментов. Создавай объекты в модели по одному. Не запрашивай лишние подтверждения.

Для каждой функции создай состояние с таким же названием. Пропусти функции, которые находятся внутри AND или OR ветвлений. После каждого AND или OR ветвления может идти сразу функция, в этом случае её нужно пропустить. Ещё после каждого AND или OR ветвления может идти событие, а затем уже функция — такие функции тоже нужно пропустить. Не пропускай функции, которые идут после завершения AND или OR ветвлений, то есть функции, которые идут после AND или OR слияний. Не пропускай функции из XOR ветвлений. Между функциями может быть только событие или только XOR или и событие, и XOR. В любом из этих случаев добавь переход между соответствующими состояниями. Назови этот переход как промежуточное событие. Если промежуточного события нет, то оставь переход безымянным. Используй для этого только модели, а не диаграммы. При отправке запросов используй правильные параметры для MCP инструментов. Создавай объекты в модели по одному. Не запрашивай лишние подтверждения.

Добавь одно безымянное начальное состояние для начального события. Добавь переход из него в первое состояние, соответствующее первой функции процесса. Назови этот переход как начальное событие. Добавь отдельное безымянное конечное состояние для каждого конечного события. Добавь переходы в эти состояния и назови их как конечные события. Используй для этого только модели, а не диаграммы. При отправке запросов используй правильные параметры для MCP инструментов. Создавай объекты в модели по одному. Не запрашивай лишние подтверждения.

Добавь связи с составными состояниями, основанными на AND или OR ветвлениях. Если в процессе после функции идёт AND или OR ветвление, то добавь связь из состояния, соответствующего этой функции, в составное состояние, соответствующее этому ветвлению. Если перед функцией идёт AND или OR слияние, то добавь связь из составного состояния, соответствующего этому ветвлению, в состояние, соответствующее этой функции. Связь должна быть с самим составным состоянием, а не с вложенными состояниями. Между функцией и ветвлением/слиянием могут быть промежуточные события. Если они есть, то назови переход так же как событие. Используй для этого только модели, а не диаграммы. При отправке запросов используй правильные параметры для MCP инструментов. Создавай объекты в модели по одному. Не запрашивай лишние подтверждения.

Я поправил результат ещё немного руками и в итоге получил такую модель состояний:

Мне очень нравится как реализованы ветвления типа неисключающее ИЛИ, получилось обойтись без сложной логики с запоминанием запущенных веток.

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

Я генерировал эту модель с помощью ИИ, но более правильно и надёжно было бы сгененировать с помощью ИИ, например, Python скрипт, который уже выполняет само преобразование. Во‑первых, это надёжнее, есть гарантия что скрипт всегда будет выдавать одинаковый результат, что он справится с произвольным количеством вложенных веток и так далее. Во‑вторых, это просто более быстро и эффективно, скрипт будет отрабатывать за миллисекунды, а не минуты, и его можно запускать локально, а не на кластере GPU. В‑третьих, запуск локального Python‑скрипта бесплатный. Я думаю, что такой подход будет часто использоваться.

Шаг 3. Реализуем приложение

С такой моделью состояний ИИ уже вполне справится. Пишем промпт:

Найди и используй модель состояний найма сотрудников в проекте HR в Architeezy. Запроси только модель, диаграмму или другие представления запрашивать не нужно. Создай новый локальный HTML файл с JavaScript кодом, в котором отображается таблица «Процесс найма» со списком кандидатов. У каждого кандидата должно быть имя (используй случайные имена из предопределенного списка мужских и женских имён, фамилия не нужна), специализация (посмотри в модели какие могут быть специализации), состояние, действия. Через случайный интервал времени от 3 до 10 секунд новый кандидат добавляется в конец таблицы с состоянием «Оценка резюме». Новые кандидаты при добавлении должны красиво анимироваться. Состояния соответствуют модели состояний из проекта HR. Действия соответствуют переходам в модели состояний. При нажатии на действие выполняется переход в следующее состояние и список доступных действий обновляется. Действия, приводящие к отказу кандидату, должны отображаться красным цветом и должны быть последними. При переходе в составное состояние для каждого региона должна создаваться вложенная строка в таблице. Действия для регионов отображаются во вложенных строках. При завершении вложенного состояния вложенная строка удаляется. Пока есть вложенные состояния переход дальше на верхнем уровне невозможен. Когда все вложенные строки удалены, то становится возможен переход в следующее состояние на верхнем уровне. Не вставляй модель в код и не сохраняй её в файл, вместо этого реализуй её в коде. Используй все состояния и переходы какие есть в модели с теми же названиями, ничего не удаляй и не переименовывай. Не добавляй дополнительную логику для состояний кроме того что есть в модели. При переходе в конечное состояние на верхнем уровне в столбце «Состояние» должно отображаться название этого состояния. Принятые кандидаты отображаются зелёным цветом, а отклоненные — красным, цвет должен меняться с анимацией. Отклоненные кандидаты в течение 5 секунд с анимацией становятся прозрачными и удаляются из таблицы.

В итоге ещё после порции промптов получаем такое приложение:

Отлично, я доволен! В приложении по сути эмулируется процесс найма, в таблицу добавляются кандидаты, можно двигать их по секциям собеседований. На проведение каждого собеседования тратится время сотрудников, поэтому доход компании падает. Как только наняли удачного кандидата, доход начинает расти. А если кандидат неудачный, то компания продолжает терять деньги.

Конечно в этом HTML файле тонны лапшакода и чтобы довести его до ума мне понадобилась ещё такая серия промптов:

В модели появился ещё один переход «У кандидата недостаточные софт скилы». Добавь его. Сделай, чтобы при переходе в составное состояние у родительской строки не отображались действия для вложенных строк

Сделай, чтобы вложенные строки отображались по порядку. Сейчас обратный порядок

Добавь логическое поле для каждого кандидата. Если в ходе процесса кандидат пошёл по пути, который соответствует его специализации, то поле = true, а иначе false

Добавь столбец «Доход». Для принятых кандидатов каждые 5 секунд доход должен увеличиваться на 100, если matchSpecialization = true. И должен уменьшаться на 70 иначе

Сделай, чтобы доход был последним столбцом. Почему‑то ничего не обновляется

Сделай доход последним столбцом. Убери раскраску строк в зависимости от исхода. И сделай в зависимости от дохода. Если доход положительный, то зеленый. Если отрицательный — красный

Доход должен выравниваться по правому краю. Через случайный промежуток времени от 20 до 60 секунд принятые сотрудники удаляются. Добавь сверху справа вывод суммарного дохода, он должен изменяться на такое же число при изменении дохода в кажой из строк

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

Суммарный доход должен быть красным, если отрицательный. И зеленым, если положительный. При каждом переходе из одного состояния в другое доход кандидата уменьшается на 10

Для каждого ещё не принятого кандидата через случайный промежуток времени от 1 до 3 секунд доход должен уменьшаться на 1

Сделай, чтобы над таблицей выводился график доходов в динамике по времени

Сделай график по ширине страницы. Убери вывод числа, убери вывод осей. Раскрашивай область под графиком относительно оси X. Т.е. если значение выше нуля, то раскраска под графиком и зеленого цвета. А если значение ниже нуля то под графиком и красного цвета

Меняй и цвет линии тоже на зеленый или красный. Если меняется знак дохода, то раскраска под или над графиком сейчас неправильная

Отрезки линии ниже нуля должны быть красными, а выше нуля — зелеными. Сейчас меняется цвет всей линии целиком. Сделай чтобы сотрудники в состоянии «оценка резюме» удалялись через случайное время от 20 до 40 секунд. Но если для них уже был один переход, то их не нужно удалять

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

Другие промпты содержат уже относительно важные дополнительные требования, например, «Добавь логическое поле для каждого кандидата. Если в ходе процесса кандидат пошёл по пути, который соответствует его специализации, то поле = true, а иначе false». И хорошо бы, чтобы эти требования не были похоронены в тоннах лапшакода или в чате, а были нормально сформулированы, структурированы и сохранены в отдельном документе или в модели. Чтобы требования не потерялись в будущем, чтобы при следующих правках, сделанных в коде ИИ, приложение не начало делать что‑то совершенно другое.

Например, чтобы в приложении внезапно не появился такой код:

// subtract remaining income from total only for non-accepted candidates
// (we treat accepted employees as external payroll)
if(!stateMachine.isAcceptanceFinal(candidate.state)){
  if(typeof candidate.income === 'number' && candidate.income !== 0){
    updateTotalBy(-candidate.income);
  }
}

Когда тестировал приложение, то почему‑то при каждом отклоненном кандидате увеличивался доход компании на сумму денег затраченных на проведение собеседований. Т.е. чтобы увеличивать доход нужно проводить очень много собеседований, а потом отказывать кандидатам. Я очень удивился когда нашёл этот кусок кода. Интересно почему ИИ решил его добавить? Может взял из реального приложения какой‑нибудь BigTech компании :)

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

А можно наоборот поменьше моделей и шагов и быстрее получать результат? Да, конечно ничего не мешает пропустить некоторые шаги, потом вернуться назад и, например, добавить эту промежуточную модель с требованиями уже после генерации кода. Собственно я так и делал, изначально я попробовал с нуля сгенерировать приложение. Ничего хорошего не получилось, поэтому я вернулся на шаг назад и сначала описал процесс. По процессу тоже не получилось сгенерировать нормальный код, поэтому добавил ещё один шаг с моделью состояний.

Главное, что у вас в голове есть эта общая многошаговая схема, что сначала мы нарезаем морковку, затем бросаем её в кипящую воду, делаем ещё несколько шагов и едим суп. А если на выходе по какой‑то причине вместо супа у вас получился картофельный отвар для лечения насморка, то вы всегда можете откатиться на несколько шагов назад и понять на каком этапе что‑то пошло не так.

Таким образом, я попробовал показать как может использоваться многошаговый подход для решения сложных или критичных (для HR с точки зрения получения премии) задач:

Такой подход, на мой взгляд, должен работать для большинства задач. Конечно за исключением творческих, например, доказательство математических гипотез просто непонятно на какие шаги раскладывать.

Заключение

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

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

Чем может быть полезно для вас моделирование, если вы используете ИИ:

• Вы можете с помощью моделей разбивать сложные задачи на шаги

• Модели в отличие от текста формальные, структурированные, их можно провалидировать

• Можно существенно экономить ресурсы. Как было описано выше, гораздо дешевле и быстрее сгенерировать Python скрипт, который локально и бесплатно преобразует модель процесса в модель состояний, чем выполнять это преобразование с помощью ИИ на кластере GPU в облаке

• Модели можно показать человеку, чтобы он быстро оценил их корректность, что‑то поправил. Модель процесса или модель состояний на порядок более наглядные для людей, чем текстовые описания

• Можно сохранить свои знания о предметной области в виде метамоделей, чтобы ИИ руководствовался ими. Так вы можете наложить на ИИ очень строгие ограничения. Например, что в модели требований должны быть только требования, у каждого требования есть название, трудозатраты и приоритет и ничего другого в эту модель ИИ не может добавить в принципе

• Можно использовать модели как графы знаний для RAG или других методов и существенно улучшать качество ответов ИИ

• При использовании моделей у вас практически неограниченный контекст. Вы можете описать 100'000 процессов для вашего предприятия и очень легко получать к ним доступ с помощью промпта «Найди такую‑то модель и сделай с ней следующее». Не нужно постоянно держать в контексте огромные портянки текста

• Для моделей на много проще настраивать правила доступа, чем для текста, вплоть до отдельных объектов, атрибутов и связей. Если у вас повышенные требования к обеспечению безопасности, то наверняка такой подход упростит вашу работу

Чем может быть полезен для вас ИИ, если вы занимаетесь моделированием:

• Как было показано в статье, вы можете относительно легко создавать вполне неплохие модели

• Можно выравнивать фигуры на диаграммах

• Можно валидировать модели. Причём, это могут быть как относительно простые проверки типа «В EPC моделях перед ветвлениями вида ИЛИ должна быть функция», так и более сложные типа «В названиях функций должны использоваться отглагольные существительные». Более того, вы можете попросить ИИ заменить в названиях функций глаголы в неопределенной форме (провести собеседование) на отглагольные существительные (проведение собеседования)

• Можно делать массовые правки в моделях. Например, перевести все модели на английский язык, добавить для каждой функции исполнителя и так далее

• Можно преобразовывать одни модели в другие как мы в статье преобразовали модель процесса в модель состояний

• Можно генерировать документы и код из моделей

• Можно анализировать модели