Прямой ответ: постановка задачи связала руки сильнее, чем любое архитектурное решение
Автор кейса формулирует вывод без оговорок: сильнее всего на архитектуру повлияла постановка задачи, а не последующие технические решения. Проект создания системы управления корпоративной архитектурой начинался с формулировок, из которых следовало, что система обязана хранить и чего в ней не будет.
Контекст короткий. Объекты и связи живут с полной историей изменений, как код в git: ветки, коммиты, сравнение состояний, слияние. Работают вдвоём: человек ставит задачи, принимает решения и отвечает за результат, ИИ-агент пишет документы и код. Агент при этом выступил соавтором архитектуры, которую автор собрал в диалоге с ним ещё до того, как завёл репозиторий. Публичный разбор кейса опубликован на Хабре.
Главный инструмент оказался неочевидным. Перечень того, чего в системе не будет, с обоснованием по каждой позиции превращает границы проекта в проверяемые утверждения с известной ценой пересмотра: пункт можно проверить (выполняется или нет), и заранее понятно, что придётся изменить, если от него отказаться. Измеримые требования вместо прилагательных вроде «быстро» и «удобно» предопределили технические решения, включая отказ от графовой СУБД в пользу одной PostgreSQL с реализацией коммит-графа в доменном слое.
Что за система: онтологическая модель ландшафта с историей как в git
Целевое состояние описано одной фразой: репозиторий, где ландшафт хранится как онтологическая модель, с типами объектов, правилами соединения и атрибутами, и у этой модели есть история.
Версионирование «как в git»: требование к модели данных, а не к интерфейсу
Ветки, коммиты, сравнение состояний и слияние обычно воспринимают как набор функций интерфейса. Здесь это требование к структуре хранения и к доменному слою. Текущее состояние ландшафта, проектные изменения и целевое состояние на несколько лет вперёд существуют одновременно, в разных ветках одной модели, и их можно сравнить, слить, откатить.
Следствие для модели данных простое: хранить нужно не только актуальное состояние объектов и связей, но и историю переходов между состояниями. Разница между двумя ветками должна вычисляться по модели, а не восстанавливаться по журналу правок задним числом. Это требование позже напрямую повлияло на выбор хранилища.
Типы объектов определяет архитектор: развитие модели вне цикла разработки
Второе требование касается ролей. Типы объектов определяет архитектор, а не разработчик. Формулировка из кейса противопоставляет два подхода: не «мы добавили в схему таблицу для микросервисов», а «архитектор зашёл в интерфейс и описал новый тип объекта с атрибутами и правилами соединения». Развитие модели не должно зависеть от цикла разработки.
Это требование к метамодели и интерфейсу, а не только к процессу. Если новый тип объекта требует миграции схемы, релиза и выката, архитектор встаёт в очередь к разработчикам. Если тип описывается данными внутри уже существующей модели, ландшафт меняется без выпуска новой версии кода, и стоимость поддержки снижается. Обратная сторона тоже есть: метамодель усложняется, а правила соединения и валидация атрибутов переезжают в доменную логику и требуют тестов.
Третий принцип: автоматика ничего не меняет сама. Данные из внешних систем превращаются в предложения с обоснованием, а решение принимает архитектор. Тот же контур «ИИ предлагает, человек утверждает, исполнитель применяет» разобран в материале про методологию Agent-Ops 0.4.0, где детерминированный исполнитель применяет только допущенные действия.
Постановка задачи для ИИ-агента: что обязательно включить, чтобы не ходить по кругу
На вход агенту автор дал предмет, источники данных, перечень функций и требование пройти тестирование на уязвимости. Отдельным пунктом попросил задавать уточняющие вопросы. Запрос вопросов здесь не вежливость, а рабочий инструмент: он вытаскивает развилки, которые иначе останутся неявными и всплывут позже, когда правки дороже.
Общая рамка такой постановки задачи для ИИ-агента описывается как четыре обязательных элемента: контекст, задача, ограничения и критерий готовности. Агент при этом работает как быстрый, но буквальный исполнитель: он сделает ровно то, что попросили, включая неточности формулировки. Поэтому безопасная схема работы выглядит так: контекст, анализ, вопросы, план, черновик, проверка, и только затем человек принимает решение; код пишется после подтверждения плана, а не вместо него.
Три развилки, которые агент вытащил сам: где разворачивается продуктивная среда, какой стек ближе команде, есть ли требования регуляторов
Первая редакция архитектуры выглядела законченной: варианты сравнены, стек выбран, железо посчитано. Но заканчивалась она отдельным разделом с тремя развилками, где ответ автора изменит рекомендацию: где разворачивается продуктивная среда, какой стек ближе команде, есть ли требования регуляторов.
Ответы переписали топологию развёртывания и половину стека: продуктивная среда похудела почти вдвое, оркестратор уступил место связке виртуальных машин под управлением Ansible. Это наглядная цена одного пропущенного уточнения: три вопроса на этапе проектирования против пересборки развёртывания на этапе внедрения.
Почему код без функциональных требований нечем принимать
Если функциональных требований в постановке задачи нет, сравнивать результат агента не с чем. Приёмка превращается в субъективную оценку «похоже на то, что я имел в виду», и разговор каждый раз начинается заново. Измеримое требование даёт объективный критерий: поведение либо соответствует ему, либо нет.
Для агента, который пишет код, это критично. Без критериев приёмки цикл «сделал, не то, переделай» повторяется, и работа идёт по кругу. Перечень функций и требование безопасности из постановки задачи работают как список проверок: по ним можно принять результат или отправить на доработку, не пересматривая договорённости. Практическая рекомендация здесь такая: изолировать контекст задачи, зафиксировать требования и ограничения в спецификации, до реализации определить исполнимые критерии готовности и поручать агенту реализацию с обязательным запуском проверок. Принимать код без исполнимой проверки нельзя: фразы «всё готово» недостаточно, нужны результаты сборки, тестов, линтера, анализа покрытия или проверки интерфейса. Как растёт время до поддерживаемого результата при таком цикле, разобрано в статье про то, почему разработка с ИИ-агентами стала тяжелее.
Список исключений: как «чего не будет» превращается в проверяемые утверждения с ценой пересмотра
Ключевой элемент постановки задачи в кейсе это перечень того, чего в системе не будет, с обоснованием по каждой позиции. Такой список превращает границы проекта в проверяемые утверждения с известной ценой пересмотра. Пункт с обоснованием можно проверить, и у него есть цена: что именно придётся изменить в архитектуре, если передумать.
Без обоснования исключение превращается в произвольный запрет. Произвольный запрет либо нарушают, когда он мешает, либо он тормозит работу без понятной причины. Со списком исключений архитектура получает набор явных оснований, на которые можно опираться при будущих изменениях, вместо попыток вспомнить мотивацию решений по переписке.
Пример: отказ от графовой СУБД в пользу одной PostgreSQL с коммит-графом в доменном слое
Цепочка выглядит так: требование версионирования как в git (ветки, коммиты, сравнение состояний, слияние), требование развивать модель без цикла разработки и измеримые требования вместо прилагательных. Первой идеей хранилища была графовая СУБД TerminusDB, которая хранит графы и объекты в модели, похожей на git: с ветками, слияниями и историей. Разговор закончился решением оставить одну PostgreSQL, а коммит-граф, ветки и слияние реализовать в доменном слое приложения.
Смысл решения не в том, что PostgreSQL лучше графовой СУБД как класс. Обоснование в кейсе сформулировано прямо: не потому, что так быстрее, а потому, что вторая СУБД это второй контур эксплуатации, второй способ резервного копирования и второй источник расхождений. Цена решения записана рядом с самим решением: рекурсивные запросы вместо готовых обходов и обязательные лимиты глубины, иначе собственный показатель производительности превращается в способ уронить систему.
Отдельно стоит отметить, что требование к обходу графа названо в кейсе той границей, за которой обычно начинается разговор про графовую СУБД. То есть отказ от второй СУБД это не отказ от графовых запросов как таковых, а выбор способа их выполнения внутри одной PostgreSQL с явно обозначенными ограничениями.
Почему обоснование по каждому пункту важнее самого запрета
Обоснование делает исключение проверяемым утверждением. Формулировка «нельзя, потому что X, и если X перестанет быть верным, решение пересматривается» задаёт условие пересмотра и объём работ. Формулировка «нельзя» не задаёт ничего.
Эффект заметен в поддержке. Когда через год возникает вопрос, почему здесь нет графовой СУБД, ответ не ищут в переписке: он есть в обосновании вместе с условием, при котором отказ теряет силу. Изменения опираются на явные основания, и стоимость поддержки снижается. Общая логика такого подхода к проектированию, когда модель системы становится исполняемым планом для агента, разобрана в материале про проектирование вместо кода.
Компромисс финального документа: что теряется, когда убираешь альтернативы
При подготовке окончательной версии документа автор намеренно убрал сравнение вариантов хранилища, отклонённые СУБД, ветвления по целевой ОС и все вопросы с ответами. Архитектурные решения переформулировали. Как документ на согласование финальная версия от этого выиграла: читать проще, спорных мест меньше, согласующим не нужно разбираться в отклонённых вариантах.
Вместе с альтернативами исчезло основание для их пересмотра. Вниз от финальной версии цепочка прослеживается полностью: требование ссылается на раздел. Вверх, к отклонённым вариантам и причинам отказа, цепочки уже нет. Возникает асимметрия: понятно, что делать, и непонятно, почему не сделали иначе и при каких условиях стоило бы вернуться к вопросу.
Практический вывод: если возможность пересмотра важна, основания нужно хранить отдельно от документа на согласование. У этих документов разные задачи. Документ на согласование фиксирует, что принято. Журнал решений сохраняет, почему принято и в каких границах решение действует.
Практические выводы: как применять подход в своём проекте AI-системы
- Соберите постановку задачи для агента из обязательных элементов: контекст, задача, ограничения и критерий готовности. Развилки, которые агент вытащит вопросами, дешевле правок на этапе внедрения.
- Составьте список исключений с обоснованием по каждому пункту. Это превращает границы проекта в проверяемые утверждения с известной ценой пересмотра, а не в набор произвольных запретов.
- Замените прилагательные на измеримые требования. «Быстро» и «удобно» не проверяются, а измеримое требование напрямую определяет технические решения, вплоть до выбора хранилища и места реализации истории изменений.
- Проверьте, чем вы будете принимать код. Без функциональных требований и исполнимых критериев готовности критерия приёмки нет, и цикл «сделал, не то, переделай» будет повторяться.
- Храните основания для пересмотра решений отдельно от документа на согласование. Иначе вместе с убранными альтернативами исчезнет и возможность вернуться к ним осознанно.
- Давайте агенту конкретные задачи и жёсткие рамки. Размытая формулировка приводит к ходьбе по кругу, а результат нечем принять.
Ограничения подхода стоит учитывать заранее. Он требует дисциплины и времени на формулировки до начала работы, а список исключений нужно поддерживать актуальным: устаревшее обоснование вредит сильнее, чем его отсутствие, потому что создаёт ложную определённость. Если требования меняются часто, цена пересмотра окажется высокой, и подход даст меньше выгоды, чем в проекте с устойчивыми границами. Оценивать его стоит по времени до рабочего, поддерживаемого результата, а не по скорости генерации кода.