
Новости про очередной этап «развития ИИ» выходят чуть ли не каждый день. И со временем меняются не только ИИ-инструменты, но и отношение к ним у ИТ-специалистов, их представление о назначении таких инструментов. Эта статья — о сдвиге понимания роли искусственного интеллекта в работе архитектора ПО.
Привет, Хабр! Меня зовут Александр Брейман, я доцент департамента программной инженерии факультета компьютерных наук НИУ ВШЭ и старший преподаватель Учебного центра IBS.
Недавно я пересматривал вебинар «Генеративные нейронные сети в работе архитектора ПО», который сам же и проводил год назад. Слушать собственные мысли из прошлого — опыт специфический. С одной стороны, идеи кажутся логичными, с другой — сейчас я остро вижу, насколько за этот год изменилось понимание того, как ИИ на самом деле встраивается в инженерные процессы.
Если попытаться упаковать весь мой опыт работы с агентными системами за этот год в одну фразу, она будет такой:
ИИ не заменяет архитектора. Он заставляет нас пересобрать саму архитектуру систем, чтобы в них можно было безопасно использовать нейросети.
Год назад подход казался прямолинейным: берем мощную модель, даем ей контекст, прописываем цепочку действий (Chain of Thought) и подключаем инструменты (Tools). Мы верили, что агент — это такой «мини-сотрудник», который может автономно анализировать задачи, проектировать решения, составлять спецификации и генерировать код.
На коротких демопримерах это работало магически. Но как только мы выходим в реальный продакшен с длинными цепочками задач, начинаются проблемы, которые не лечатся простым «докручиванием промпта». Например, можно попросить:
Спроектируй сервис управления заявками на обучение сотрудников. Нужны роли, жизненный цикл заявки, API, схема БД и интеграция с кадровой системой.
Через несколько минут модель выдаст сущности Employee, Course, Application, Approval, несколько эндпойнтов, таблицы, статусы заявки, диаграмму последовательности. Как демонстрация выглядит впечатляюще.
Но этот результат должен выдержать столкновение с ограничениями бизнеса, существующим ИТ-ландшафтом, регуляторкой, эксплуатацией, безопасностью, интеграциями, данными и людьми, которые будут все это поддерживать.
И вот тут агент начинает вести себя не как «младший архитектор», а как очень убедительный, быстрый и опасный генератор правдоподобных артефактов.
В реальности мы столкнулись с набором эффектов, которые делают автономных агентов непредсказуемыми.
Представим задачу: проектируем внутренний сервис согласования заявок на обучение сотрудников. На входе есть описание бизнес-процесса: сотрудник выбирает курс, руководитель согласует, HR видит статус, данные уходят в кадровую систему и в систему бюджетирования.
На первом шаге ИИ может выдать приличный результат. Но если дать агенту идти дальше автономно — уточнять требования, проектировать интеграции, писать спецификацию API, генерировать миграции и тесты, — начинают проявляться системные проблемы.
Дрейф цели. Изначально задача была простой: автоматизировать согласование заявок на обучение. Но на десятом шаге агент вдруг начинает проектировать рекомендательную систему курсов, рейтинг сотрудников, персональные образовательные траектории и модель подбора программ. Каждая отдельная идея может выглядеть разумной, но вместе они уводят решение от исходной бизнес-задачи.
У человека-архитектора обычно есть стоп-сигнал: «нам это сейчас не нужно», «это не входит в контур проекта», «у заказчика нет ресурсов это сопровождать». У автономного агента такого стоп-сигнала нет, если он специально не встроен в процесс.
Галлюцинации в инструментах. Пока модель просто пишет текст, ошибка остается текстовой. Но когда агент получает доступ к инструментам — Jira, GitLab, Confluence, базе знаний, генератору кода, API внешней системы, — галлюцинация превращается в действие.
Например, агент может создать задачу в трекере с несуществующим типом ArchitectureDecision, вызвать API с параметром approval_required, которого нет в контракте, сослаться на компонент, который был переименован полгода назад, или сгенерировать SQL-миграцию под поле, отсутствующее в доменной модели.
Накопление энтропии. Самые неприятные ошибки — те, которые не ломают процесс сразу.
Например, агент на раннем шаге решил, что одна заявка всегда относится к одному сотруднику и одному курсу. На демоданных это выглядит нормально. Но в реальности бывают групповые заявки, переносы дат, замены участников, частичные согласования, разные бюджеты и разные правила для внутренних и внешних программ.
Если эту ошибку не поймать сразу, она расползается дальше: OpenAPI строится вокруг неверной сущности, схема БД фиксирует неправильную кардинальность, UI становится слишком простым, тесты проверяют не ту бизнес-логику, а документация убедительно объясняет ошибочную модель.
На выходе получается аккуратный, согласованный и внешне профессиональный комплект артефактов. Проблема в том, что он согласован вокруг неверного предположения.
Правдоподобность вместо корректности. ИИ хорошо пишет убедительные архитектурные тексты: отказоустойчивость, масштабируемость, идемпотентность, наблюдаемость, событийная архитектура, разграничение ответственности, аудит изменений.
Можно получить красивое описание интеграции через очередь сообщений, но не получить ответа на ключевые вопросы: кто владелец данных, что делать при повторной доставке события, где граница транзакции, как обрабатываются ошибки, можно ли хранить эти данные в данном контуре, кто будет сопровождать решение через два года.
Именно здесь становится видно, что ИИ не заменяет архитектурное мышление. Он ускоряет производство вариантов, но не гарантирует инженерную корректность.
Главный инсайт года: проблема не в том, что модели «глупые». Проблема в том, что мы пытались строить системы вокруг поведения агента, а нужно строить их вокруг контроля состояния.
Что значит «строить вокруг поведения агента»? Это когда мы описываем агенту последовательность действий почти как человеку:
Изучи требования, задай уточняющие вопросы, предложи архитектуру, опиши API, подготовь схему БД, проверь риски и оформи результат.
Такой сценарий выглядит естественно, потому что именно так мы часто ставим задачу коллеге или стажеру. Но у человека есть профессиональная память, ответственность, опыт, понимание организационного контекста и способность остановиться, когда исходные данные противоречивы. У агента все это нужно специально проектировать.
Поэтому вместо «пусть агент сам пройдет путь от задачи к решению» более надежным становится другой подход: проектировать не траекторию рассуждений, а граф артефактов и состояний.
Граф артефактов — это набор промежуточных результатов, каждый из которых имеет понятные формат, статус и правила перехода к следующему шагу.
Например, не так:
Агент, спроектируй сервис согласования обучения.
А так:
Из исходного описания выделить акторов, сценарии и открытые вопросы.
После уточнения вопросов построить глоссарий и бизнес-правила.
Из утвержденных бизнес-правил получить модель сущностей.
Из модели сущностей предложить схему данных и API.
Проверить артефакты на противоречия, ограничения и риски.
После проверки архитектором оформить ADR.
В этом подходе агент перестает быть «центром принятия решений» и становится исполнителем внутри жесткого контура управления. Он не сам решает, что делать дальше, а выполняет конкретное преобразование: из одного проверенного состояния получить следующее проверяемое состояние.
Раньше мы пытались управлять ходом рассуждений модели. Сейчас важнее управлять состояниями системы: какие артефакты уже утверждены, какие находятся в черновике, какие противоречат друг другу, какие можно передавать на следующий шаг, а какие должны остановить процесс.
В этом подходе агент перестает быть «центром принятия решений» и становится исполнителем (stateless-функцией) внутри жесткого контура управления.
Если коротко:
Как мы думали раньше | Как стоит делать сейчас |
Агент — это мозг системы | Система — это скелет, агент — это мышцы |
Промпт-инжиниринг как магия | Проектирование состояний и переходов |
Верим итоговому результату | Проверяем каждый значимый шаг |
Один большой контекст | Минимальный контекст под конкретную операцию |
Агент сам решает, что делать дальше | Система явно разрешает следующий переход |
В работе с искусственным интеллектом особенно важно настроить программируемый рабочий процесс, воркфлоу. Здесь важно уточнить термин.
Слово workflow обычно переводят как «рабочий процесс», но я бы уточнил — именно программируемый рабочий процесс.
Обычный рабочий процесс — это то, как люди выполняют работу: обсуждают требования, пишут документы, создают задачи, проверяют код, принимают архитектурные решения.
Программируемый рабочий процесс — это когда эта последовательность становится явной и управляемой: у нее есть входы, выходы, состояния, проверки, правила перехода, точки участия человека и автоматические действия.
В контексте ИИ это особенно важно.
Пока мы просто общаемся с чат-ботом, рабочий процесс находится у нас в голове. Мы сами решаем, какой вопрос задать, какой ответ принять, что скопировать в документ, что проверить, что переделать.
Когда мы запускаем автономного агента, мы, наоборот, отдаем слишком много управления модели: «разберись, что надо сделать, выбери шаги, вызови инструменты, собери результат».
Программируемый рабочий процесс находится между этими крайностями. Мы заранее описываем, как задача должна проходить через систему, а ИИ используем на отдельных шагах — там, где он действительно полезен.
Для многих разработчиков этот сдвиг стал особенно заметен в инструментах вроде Claude Code и Codex. В них работа с ИИ уже не сводится к одному промпту в чате. Появляется другой стиль: изучить кодовую базу, найти место ошибки, предложить исправление, изменить файлы, запустить тесты, объяснить изменения, подготовить коммит или pull request.
Сначала это выглядит как набор типовых рабочих сценариев: «исследуй проект», «исправь баг», «напиши тест», «сделай рефакторинг». Но постепенно вокруг этого появляются механизмы, которые делают процесс более инженерным: проектные инструкции, пользовательские команды, хуки, навыки, субагенты, локальное и облачное выполнение задач.
Здесь может возникнуть справедливое возражение. Но ведь современные агентные системы снова двигаются в сторону автономности. OpenClaw, Hermes, методологии типа BMAD и похожие подходы позволяют поставить агенту цель, дать доступ к инструментам, памяти, проектным файлам, задачам, репозиторию — и дальше он начинает долго идти к результату. Не просто отвечает на один запрос, а делает шаги, проверяет себя, возвращается к цели, исправляет ошибки и продолжает.
В сообществе вокруг coding agents для этого часто используют идею Ralph loop — я бы перевел это как целевая петля или цель-цикл. Смысл простой: не пытаться получить идеальный результат за один проход, а запускать агента в цикле.
Условно:
цель → действие → проверка → фиксация состояния → повтор
На практике это может выглядеть так: есть файл с целью или PRD, список критериев готовности, проектные инструкции и репозиторий. Агент берет следующий незавершенный пункт, меняет код или документы, запускает тесты, фиксирует прогресс, смотрит, что осталось, и продолжает цикл до завершения.
На первый взгляд это выглядит как возвращение к идее автономного агента: поставил задачу — и он «следует за целью».
Но важная деталь в другом. Такой агент живет уже не только внутри собственного рассуждения. Он опирается на внешний контур управления: файлы состояния, историю изменений, критерии готовности, тесты, чек-пойнты, список задач, роли, skills, ограничения и проверки. То есть автономность появляется не вместо архитектуры процесса, а поверх нее.
Именно поэтому я бы не противопоставлял Ralph loop и программируемые рабочие процессы. Наоборот, целевая петля — это один из вариантов программируемого рабочего процесса, где основной паттерн выглядит так:
поставили цель → сделали шаг → проверили результат → обновили состояние → повторили
Для coding-задач такой подход действительно может быть очень эффективен. Если есть хорошо описанный PRD, тесты, понятный репозиторий и критерии готовности, агент может долго и продуктивно идти по задаче: писать код, запускать проверки, исправлять ошибки, обновлять документацию.
Но в архитектурной работе не все так просто.
Архитектурная цель часто не сводится к «все тесты прошли». Система может собраться, тесты могут быть зелеными, документация может выглядеть убедительно — и при этом решение может быть архитектурно неверным: нарушать границы ответственности, неправильно определять владельца данных, создавать лишнюю синхронную зависимость, не учитывать регуляторные ограничения или незаметно менять исходную бизнес-цель.
Поэтому для архитектора Ralph loop — полезный механизм, но недостаточный.
Нужен более богатый контур: какие артефакты должны появиться, какие критерии готовности применимы, какие проверки автоматические, какие проверки архитектурные, где нужен человек и какие решения агент не имеет права принимать сам.
В этом смысле в OpenClaw и Hermes мы видим следующий этап зрелости.
Мы действительно возвращаем агенту способность долго идти к цели. Но делаем это уже не наивно, не в режиме «умный агент сам разберется», а через внешний контур состояния, памяти, проверок и повторяемых рабочих сценариев.
Поэтому более точная формулировка такая:
автономный агент опасен, если он сам управляет целью, состоянием и критериями готовности; но агент в целевой петле, встроенной в программируемый рабочий процесс, становится мощным инженерным инструментом.
Для архитектора задача не в том, чтобы запретить автономность. Задача в том, чтобы спроектировать ее границы: где агент может «фигачить за целью», а где обязан остановиться и вернуть управление человеку.
Чтобы система с ИИ была надежной, у нее должны быть три свойства.
Атомарность шагов. Вместо «спроектировать сервис» мы просим выполнить маленькое преобразование: выделить бизнес-правила, найти противоречия, сопоставить сущности с таблицами, проверить API на покрытие сценариев, сформировать список открытых вопросов.
Например, вместо большого запроса:
Спроектируй архитектуру системы обучения.
лучше дать узкий запрос:
На основе этих пользовательских сценариев выдели бизнес-правила. Каждое правило оформи в виде: идентификатор, формулировка, источник, связанные сценарии, открытые вопросы.
Тогда результат становится инженерным артефактом. Его можно сохранить, проверить, обсудить, версионировать и использовать дальше.
Валидация. Каждый выход нейросети должен проходить через «сито».
Проверка может быть структурной, например, результат соответствует нужной JSON-схеме. Технической — код проходит тесты, SQL-миграция применяется к тестовой базе, OpenAPI проходит валидатор, диаграмма рендерится. Семантической—результат не противоречит исходной задаче. Архитектурной — не нарушены границы ответственности, владельцы данных, ограничения безопасности и эксплуатации.
Если проверка не прошла, система должна остановиться. Не «попросить модель попробовать еще раз в том же диалоге», а именно заблокировать переход состояния: этот артефакт нельзя использовать как утвержденный.
Управление контекстом. Еще одна типичная ошибка — скармливать модели всю историю обсуждения.
На первый взгляд кажется: чем больше контекста, тем лучше. Но в реальном проекте большой контекст почти всегда содержит шум: старые гипотезы, отмененные решения, промежуточные идеи, противоречивые комментарии, черновики и куски документации, которые уже устарели.
Поэтому на каждый шаг нужно подавать только тот контекст, который нужен для конкретного преобразования. Здесь хорошо себя показали субагенты, запускаемые именно с таким контекстом.
Если модель генерирует схему данных, ей нужны утвержденные сущности, бизнес-правила, ограничения по хранению данных, соглашения по именованию и требования к аудиту. Если модель проверяет ADR, ей нужны само решение, альтернативы, ограничения, критерии выбора и связанные риски.
Такой подход снижает шум и уменьшает вероятность того, что модель начнет опираться на то, что уже не является актуальным решением.
Возьмем задачу: нужно спроектировать интеграцию между внутренней системой обучения и кадровой системой.
Наивный запрос выглядит так:
Спроектируй интеграцию между LMS и HRM. Нужна надежная архитектура.
Скорее всего, модель предложит что-то разумное: REST API, очередь сообщений, периодическую синхронизацию, ретраи, логирование, мониторинг. Текст будет выглядеть профессионально.
Но в реальности нам сначала нужно ответить на другие вопросы: какая система является источником мастер-данных по сотрудникам, можно ли хранить персональные данные в LMS, что делать с уволенными сотрудниками, что считается фактом прохождения обучения, должны ли данные уходить в HRM сразу или после подтверждения HR, что делать при недоступности HRM, нужен ли аудит изменений, есть ли требования по закрытому контуру.
Если эти вопросы не заданы, архитектура может быть красивой, но неверной.
Более надежный подход—система сначала просит модель извлечь открытые вопросы. Затем классифицирует их: данные, безопасность, бизнес-процесс, эксплуатация, интеграции. Затем архитектор или аналитик закрывает вопросы. Только после этого модель получает утвержденные ответы и генерирует варианты архитектурных решений.
После генерации варианты проходят проверку: не нарушают ли они ограничение по персональным данным, есть ли стратегия обработки ошибок, описан ли владелец данных, учтен ли аудит, не появились ли внешние сервисы там, где разрешен только внутренний контур.
В таком сценарии ИИ полезен не потому, что «сам стал архитектором», а потому, что ускоряет работу внутри архитектурной рамки.
Сейчас многие специалисты застревают на первом уровне: научились писать промпты, генерировать диаграммы, получать куски кода, просить модель объяснить технологию или подготовить черновик документа. Это полезно. Но это еще не инженерное использование ИИ.
Как только дело доходит до сложного процесса, где задействованы десятки или сотни шагов, несколько моделей, внешние инструменты, репозитории, базы знаний, тесты и реальные ограничения, качество резко падает.
Выяснилось, что навыки общения с чат-ботом и навыки построения систем с участием ИИ — это разные компетенции.
Здесь полезно разделить два типа умственной работы.
Первый тип — работа по заданной рамке. Есть понятная инструкция, критерии готовности, примеры, тесты, ограничения. В такой ситуации ИИ может быть очень эффективен: дописать код по подробному описанию, сгенерировать тесты, привести документ к шаблону, найти несоответствие в спецификации.
Второй тип — экспертное суждение. Это задачи, где недостаточно следовать инструкции: нужно понять, какие ограничения существенны, где риск, что можно упростить, где нельзя экономить, какой компромисс допустим, а какой разрушит систему через полгода.
Архитектура почти всегда находится во второй зоне.
Можно попросить модель «придумать архитектуру высоконагруженного сервиса», и она действительно напишет убедительный текст. Но выбор границ сервисов, владельцев данных, модели отказа, интеграционного стиля и эксплуатационных компромиссов — это не просто генерация вариантов. Это экспертное суждение.
Хорошая новость в том, что часть экспертного суждения можно постепенно выносить наружу: в архитектурные принципы, чек-листы, ADR, критерии качества, примеры хороших и плохих решений, тесты, ограничения платформы, правила безопасности. Тогда ИИ уже не пытается «быть архитектором из головы», а действует внутри явно заданной профессиональной рамки.
Плохая новость в том, что, если этой рамки нет, модель ее не придумает надежно. Она заполнит пустоту правдоподобным текстом.
Архитектору сегодня нужно понимать не только классические паттерны, интеграции, данные, инфраструктуру и безопасность. К этому добавляется новый слой: как проектировать системы, устойчивые к вероятностным компонентам; как задавать границы автономности ИИ; как превращать рассуждения модели в проверяемые артефакты; как управлять контекстом; как не позволить правдоподобному тексту заменить инженерную проверку.
Фактически архитектор становится не менее, а более важным. Раньше он проектировал систему из сервисов, данных, интеграций и инфраструктуры. Теперь ему приходится проектировать еще и контур доверия: где ИИ может предлагать, где может исполнять, где обязан остановиться, где нужен человек, а где результат должен быть проверен автоматически.
Есть соблазн свести все к промпт-инжинирингу. Мол, если агент ошибается, значит, плохо написали инструкцию. Но это похоже на попытку заменить архитектуру приложения очень подробным README.
Хороший промпт важен, но он не решает системные проблемы: не гарантирует корректность состояния, не валидирует выходные данные, не управляет правами доступа, не версионирует артефакты, не отличает утвержденное решение от черновика, не блокирует опасный переход.
Промпт — это только один элемент. Вокруг него нужны обычные инженерные механизмы: схемы, контракты, тесты, рабочие процессы, журналирование, контроль версий, права, наблюдаемость, ручные точки подтверждения.
Именно поэтому, когда мы говорим об ИИ в архитектурной работе, речь должна идти не о «секретных промптах», а о проектировании процесса.
И еще один практический вывод: не стоит надеяться, что мы просто «зашьем экспертизу» в модель и она начнет принимать архитектурные решения как сильный специалист. Надежнее другой путь: вынести экспертное суждение во внешний контур — в документы, правила, примеры, ограничения, проверки и программируемые рабочие процессы.
Тогда задача модели становится проще и безопаснее. Она не должна заново изобретать профессиональную интуицию архитектора. Она должна пользоваться явно описанной рамкой и производить проверяемые артефакты внутри нее.
Именно из этой практической проблемы у нас в Учебном центре IBS вырос новый курс «ИИ для архитектора ПО: эффективное использование AI». Мы сознательно не делали курс про «набор сильных промптов для архитектора». Промпты важны, но они не решают главную инженерную задачу: как встроить ИИ в архитектурный процесс так, чтобы результат можно было проверять, воспроизводить и безопасно использовать дальше.
Поэтому фокус курса — на программируемых архитектурных рабочих процессах: как разложить работу архитектора на проверяемые шаги, как описать граф артефактов и переходов между ними, как встроить ИИ в отдельные операции, не отдавая ему управление всем процессом, как валидировать результаты модели и как проектировать точки участия человека.
Для меня это важный сдвиг: тема ИИ для архитектора перестала быть темой про то, «как правильно спросить у модели». Она стала темой про то, как проектировать программируемые процессы с вероятностным исполнителем внутри.
Тот вебинар годичной давности был хорошим отражением времени — эпохи агентского романтизма. Мы верили в автономность. Казалось, что еще немного — и появится достаточно сильный агент, который сможет взять на себя значительную часть архитектурной работы.
Сейчас я смотрю на это иначе.
ИИ действительно меняет работу архитектора, но не потому, что заменяет архитектора. Он меняет сам объект архитектурного проектирования.
Раньше архитектор проектировал систему из сервисов, данных, интеграций, инфраструктуры, интерфейсов, ограничений и командных соглашений. Теперь к этому добавляется еще один слой: система должна уметь работать с вероятностным исполнителем, который может быть полезным, быстрым и убедительным, но не является надежным по умолчанию.
Поэтому главный вывод не в том, что «ИИ нужно использовать аккуратно». Это слишком общее утверждение.
Более точный вывод такой: ценность архитектора смещается от ручного производства всех артефактов к проектированию процесса, в котором эти артефакты могут быстро создаваться с помощью ИИ, но не теряют инженерной проверяемости.
ИИ ускоряет производство вариантов. Целевая петля позволяет агенту долго идти к результату. Программируемый рабочий процесс удерживает систему в границах. Архитектор отвечает за состояние, проверки, последствия и целостность решения.
И возможно, главный профессиональный навык архитектора в ближайшие годы — не умение получить от ИИ красивый ответ, а умение построить такую систему, в которой красивый, но неверный ответ не сможет пройти дальше.