От чата с агентом к графу изменений: как я перестроил проектирование фич
В какой‑то момент мой процесс разработки начал упираться не в код, а в проектирование изменений.
Код тоже сопротивляется, конечно. Он вообще не подарок: положишь одно поле не туда — и через неделю у тебя уже маленький архитектурный цирк с пони и грустным API. Но главная сложность оказалась раньше — в моменте, когда изменение ещё только формулируется.
Фича звучит просто, пока её не начинают реализовывать.
Пользовательская история кажется очевидной, пока не появляются роли, состояния, исключения, интерфейсы, API, ограничения, тесты и зависимости.
Задача выглядит маленькой, пока не выясняется, что она затрагивает сразу несколько слоёв системы.
Именно для этого я изначально и делал Онто — как инструмент управления сложностью при проектировании изменений.
Не как канбан.
Не как очередную доску.
Не как трекер задач с красивыми связями.
Мне нужна была среда, в которой изменение можно сначала сделать видимым: через объекты, связи, роли, состояния, сценарии и контекст. А уже потом отдавать его в реализацию — человеку, команде или агенту.
Это не канбан и не процессный трекер
Важно сразу развести понятия.
Онто — это среда свободного моделирования. В ней можно описывать предметную область: объекты, связи, роли, состояния, контексты и правила работы с ними. А уже поверх такой модели можно собирать разные сценарии: управление изменениями, цифровой двойник, исследовательскую базу знаний, структуру компании, продуктовую линейку или автоматизацию сбора данных.
В этой статье я показываю только один конкретный кейс: как я использую платформу для проектирования изменений в разработке ПО.
Не потому что она предназначена только для этого.
А потому что проектирование изменений — хороший пример сложной задачи, где быстро становится видно ценность модели.
Канбан показывает движение карточек.
Модель показывает устройство смысла.
И это разные сущности. Одна помогает понять, что едет дальше. Другая — почему оно вообще существует, с чем связано и что сломает по дороге.
От модели данных к модели действий
Идея связывать данные, модель, действия и агентов уже становится заметной архитектурной линией в индустрии.
Например, в документации Palantir Foundry Ontology онтология описывается не как обычный каталог данных или схема, а как операционный слой организации. Она связывает цифровые активы платформы с объектами реального мира — оборудованием, продуктами, заказами, транзакциями и другими сущностями. Внутри этой рамки есть не только семантические элементы — объекты, свойства и связи, — но и «кинетические» элементы: действия, функции и динамическая безопасность. (Palantir)
Это важный сдвиг.
Модель перестаёт быть справочником и становится средой, через которую можно действовать.
В архитектурном описании Palantir эта мысль формулируется ещё шире: онтологическая система объединяет данные, логику, действия и безопасность в представление, пригодное для принятия решений, а язык онтологии моделирует «существительные» и «глаголы» операционных процессов так, чтобы они были понятны людям и агентам. (Palantir)
Мне близка именно эта рамка: инженерная модель должна описывать не только то, что есть, но и то, что с этим можно делать.
В моём случае я двигаюсь к этой логике через свободное моделирование, агентский бутстрап, MCP и собственный техпроцесс разработки.
Что изменилось после появления MCP
Раньше агент был для меня в основном собеседником. Он мог рассуждать, предлагать варианты, помогать формулировать решения, но всё равно оставался где‑то рядом с системой.
После появления полноценного MCP ситуация изменилась.
Агент получил доступ не только к текстовому контексту, но и к самой модели: объектам, связям, шаблонам, полям, состояниям и метауровню. Теперь он может не просто обсуждать изменение, а работать с его структурой: находить связанные элементы, предлагать новые связи, проверять недостающие части модели и фиксировать результат в графе.
Это резко изменило мою продуктивность при проектировании изменений.
Но MCP сам по себе не делает процесс управляемым. Он только открывает доступ к возможностям. Если дать агенту доступ к хаосу, он будет очень бодро автоматизировать хаос. Маленький цифровой енот с гаечным ключом и полной уверенностью в глазах.
Предсказуемость появляется только в связке:
модель удерживает сложность;
MCP даёт агенту доступ к этой структуре;
агентский бутстрап задаёт правила анализа;
техпроцесс определяет, когда результат можно считать готовым.
Именно последнего пункта часто не хватает в разговорах про агентную разработку.
Реальная работа идёт в чате с агентом
В этом кейсе реальная работа с изменением велась не на диаграмме и не в абстрактном списке задач.
Она велась в чате с агентом бизнес‑аналитиком.
Чат здесь — не просто место для разговора. Это рабочая поверхность проектирования изменения.
Я формулирую идею.
Агент уточняет смысл.
Проверяет термины.
Предлагает варианты связей.
Задаёт вопросы про роли, цели, мотивы и зависимости.
Выявляет места, где смысл ещё не разобран.
И только после этого помогает зафиксировать результат в модели.
Но агент делает это не свободно «как получится», а в рамках принципов работы с изменениями, которые заложены в агентский бутстрап.
Бутстрап задаёт ему рамку:
как разбирать изменение;
какие сущности искать;
какие вопросы задавать;
какие связи фиксировать;
когда считать смысл недостаточно прояснённым;
что можно передавать дальше в разработку;
какие артефакты должны быть подготовлены.
Поэтому агент не просто общается. Он ведёт изменение через заданный аналитический сценарий.
Именно здесь появляется предсказуемость. Не потому что LLM стала безошибочной, а потому что её действия ограничены структурой, словарём, правилами и техпроцессом.
Диаграмма — это не место работы, а след работы
Диаграмма в этом процессе важна, но не как место, где происходит основная работа.
Она становится способом увидеть уже собранную структуру: какие сущности появились, как они связаны и где ещё остались смысловые разрывы.
Цепочка выглядит так:
разговор → уточнение смысла → структурирование → создание объектов и связей → визуализация графа.
Это важное отличие.
Если сказать, что мы «работаем на диаграмме», читатель легко решит, что речь про визуальную доску для проектирования фич. Но это не так.
Мы работаем с изменением через агента.
А граф становится памятью, моделью и визуальным представлением результата.
Пример: агентская память
Хороший пример — наша работа с Claude над одной из фич: агентской памятью.
На первый взгляд идея простая: агент должен не терять контекст между сессиями и уметь восстанавливать рабочее состояние.
Но как только начинаешь проектировать это всерьёз, появляются вопросы:
что именно считать памятью;
где хранится контекст;
какая часть памяти относится к объекту;
какая — к сессии;
как отличать актуальное знание от устаревшего;
как агент должен искать по памяти;
как не превратить память в свалку красиво оформленного мусора.
И вот здесь работа с агентом бизнес‑аналитиком оказалась особенно полезной.
Мы начали не с реализации. Мы начали с разговора о смысле.
Что должен помнить агент?
Почему это важно пользователю?
Какая сущность является центром истории?
Что является мотивом?
Что является целью?
Какая роль действует в сценарии?
Какие связи должны появиться в графе?
Агент помог разложить изменение на элементы модели и не потерять смысл в комментариях к задаче.
Мотив нельзя оставлять в комментарии
Один из показательных моментов — обсуждение мотива User Story.
Можно было оставить мотив в текстовом описании. Но если мотив является смысловым центром истории, его нельзя терять в комментарии.
В графе он должен стать отдельной сущностью или явно выраженной связью. Иначе агент, разработчик или тестировщик каждый раз будут заново восстанавливать его из текста.
Это кажется мелочью, но именно из таких мелочей и складывается качество проектирования.
В формуле User Story «я как X хочу Y, чтобы Z» элемент Z часто называют целью, выгодой, потребностью или мотивом. Эти понятия близкие, но не одинаковые.
Цель — к чему стремится персона.
Выгода — что она получает.
Потребность — чего ей не хватает.
Мотив — почему она вообще действует.
Если смешать их в одну сущность, модель быстро станет мутной. А мутная модель — это когда агент вроде бы всё понял, но почему‑то делает не то. Классика жанра: маленький семантический енот уже снова в проводке.
User Story как граф, а не строка текста
В онтологическом подходе User Story перестаёт быть просто строкой вида «я как X хочу Y, чтобы Z».
Она раскладывается на граф:
роль пользователя;
персона;
мотив;
цель;
фича;
сценарий;
шаги;
архитектурные элементы;
API;
задачи разработки;
тестовые ожидания.
Текст остаётся удобным интерфейсом для человека. Но рабочим носителем смысла становится граф.
Это важно, потому что текст сложно проверять автоматически. Граф можно анализировать.
Можно увидеть, у каких историй нет мотива.
Какие фичи не связаны с пользовательской потребностью.
Какие задачи не привязаны к сценарию.
Какие изменения затрагивают один и тот же API.
Какие элементы модели давно не пересматривались.
Где возникла блокирующая зависимость.
Для пользователя это означает меньше хаоса в развитии продукта.
Для команды — меньше ситуаций, когда задача выглядит понятной только тому, кто её придумал.
Почему агентная разработка стала возможной
Я не считаю, что агенты полезны потому, что LLM внезапно научились идеально писать код.
Они не научились.
Люди, кстати, тоже не научились.
Агентная разработка стала для меня рабочей не из‑за безошибочности моделей, а из‑за того, что вокруг разработки уже был выстроен достаточно зрелый техпроцесс.
У нас изменение не уходит в работу сразу после идеи. Сначала оно проходит через разбор смысла: зачем это нужно, кому это нужно, какие сценарии затрагиваются, какие сущности меняются, какие связи появляются, какие ограничения есть, как это будет проверяться.
Агент в этом процессе не заменяет инженера. Он становится участником технологической цепочки.
Он может работать как аналитик.
Может проверять связность модели.
Может готовить документацию.
Может смотреть на изменение с позиции разработки.
Может помогать QA‑агенту понять, что именно нужно проверять.
Может сформировать дайджест изменений.
Но он делает это не из пустоты. Он действует в рамках бутстрапа и модели.
Именно поэтому результат становится воспроизводимым.
Где здесь пользовательская выгода
На поверхности может показаться, что это внутренняя история разработки платформы.
Ну подумаешь, автор научился дружить модель, MCP и агентов. Милый инженерный зоопарк.
Но пользовательская польза здесь прямая.
Если продукт развивается через модель, а не через набор несвязанных фич, пользователь получает более устойчивую систему.
Новые возможности не появляются как случайные кнопки.
Они встраиваются в общую логику.
Интерфейс, API, MCP, OntoAI, OntoGPTs и внутренний ассистент начинают опираться на одни и те же сущности.
Документация меньше расходится с реальностью.
Рефакторинг становится безопаснее, потому что зависимости видны заранее.
Агентная работа становится предсказуемее, потому что агент действует не в пустоте, а в модели.
Для меня это и есть главный эффект: изменение становится понятным до реализации.
Мы не отдаём в работу сырой смысл.
Сначала он проходит через разговор, агентский разбор и модель.
И только потом становится задачей, сценарием, API, интерфейсом или тестом.
Что даёт MCP именно в этой связке
MCP дал агентам доступ к модели. Но предсказуемость появилась не из‑за MCP самого по себе.
MCP — это интерфейс к возможностям.
Техпроцесс — это ограничитель и направляющая.
Граф показывает, где агент находится.
Шаблоны задают типы объектов.
Связи задают грамматику.
Состояния задают допустимые переходы.
Критерии качества задают проверку результата.
В итоге агентная разработка становится не «поговорили с моделью и надеемся», а воспроизводимым инженерным циклом.
И здесь появляется главный сдвиг: агент перестаёт быть отдельным чатиком сбоку от процесса. Он становится участником технологической цепочки.
Разговор → семантика → модель → документация → реализация → проверка.
Каждый шаг становится менее ручным и менее хрупким.
Похожая архитектурная логика видна в Palantir Ontology MCP: ресурсы онтологии — типы объектов, типы действий и query functions — становятся MCP‑инструментами для внешних AI‑агентов. Такие агенты могут читать объекты, выполнять заранее определённые действия и запрашивать данные, при этом доступ ограничивается scopes и permissions. (Palantir)
Для меня здесь важен не конкретный продуктовый подход Palantir, а архитектурный принцип: агенту мало дать промпт. Ему нужен управляемый доступ к модели и допустимым действиям.
Почему это важно именно сейчас
Чем дальше развивается продукт, тем сложнее становится синхронизировать разные способы взаимодействия с ним:
UX;
API;
MCP;
OntoAI;
OntoGPTs;
агент в чате;
метауровень;
пользовательские пространства.
Все эти слои должны работать с одними и теми же сущностями. Если сущности расходятся, система начинает распадаться на набор интерфейсов.
Поэтому соотнесение метамодели с API стало для меня важным шагом. Оно позволило свести разные уровни взаимодействия в единую структуру и дать агентам возможность работать не только с текстом, но и с реальной моделью платформы.
В итоге изменение перестаёт быть локальной правкой. Оно становится частью единой структуры: от пользовательского смысла до интерфейса, API, документации, тестов и агентных сценариев.
Почему это не просто «ИИ помогает писать код»
История про «ИИ пишет код» выглядит слишком узкой.
Код — это уже поздний этап. До него есть более важный слой: понимание изменения.
Что именно мы делаем?
Зачем?
Для кого?
Какие сценарии затрагиваем?
Какие сущности меняются?
Какие связи появляются?
Какие старые допущения ломаются?
Как это проверить?
Как это потом переиспользовать?
Именно здесь агенты становятся особенно полезны.
Они помогают смотреть на модель с разных сторон: как аналитик, как разработчик, как тестировщик, как архитектор, как документатор. Но результат становится надёжным не потому, что агент «всё понял», а потому что его работа проходит через жёсткий контур: модель, связи, состояния, критерии качества и техпроцесс.
Для меня вывод простой: агенту мало дать инструкцию. Ему нужна среда, правила и доступ к структурированному знанию.
Финал
Для меня это не история про то, что «ИИ пишет код».
Гораздо интереснее другой вопрос: может ли инженерное знание работать как код?
То есть быть структурированным, проверяемым, трассируемым, воспроизводимым и пригодным для автоматизации.
С появлением полноразмерного MCP я стал гораздо ближе к этому состоянию. Агенты получили доступ к модели, но результат стал предсказуемым не из‑за магии LLM, а из‑за связки модели, агентского бутстрапа и техпроцесса.
Модель удерживает сложность.
MCP открывает к ней доступ агентам.
Бутстрап задаёт правила мышления и действия.
Техпроцесс делает результат проверяемым.
Именно эта комбинация позволяет проектировать изменения не как поток переписок, догадок и героического удержания контекста в голове, а как инженерный процесс, где смысл становится рабочим артефактом.
Инженерное знание должно работать как код.
Но жить оно будет не в одной плоскости, а на пересечении нескольких графов:
семантики;
контекста;
классификации;
топологии.
И, кажется, именно там начинается самое интересное.
