Опыт + ИИ: как AI-агенты меняют роль архитектора

Опубликовано 28.08.2026 03:34:00 в категории Искусственный интеллект

Введение

Сейчас разговоры о том же самом ведутся вокруг искусственного интеллекта (artificial intelligence). Но вопрос «заменит ли ИИ архитектора» кажется мне неправильно поставленным. Более практичный вопрос — как меняется сама роль архитектора, когда рядом появляется агент (agent), способный писать код, а иногда — принимать локальные технические решения самостоятельно.

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

От кодера к архитектору: что не меняется с приходом ИИ

Есть соблазн думать, что раз агент умеет писать код, то роль архитектора сводится к написанию промптов. Это не так, и вот почему. Работа архитектора никогда не сводилась к написанию кода — это была лишь видимая часть. Настоящая работа — это:
●    определение границ контекстов (bounded contexts) и того, где заканчивается ответственность одного сервиса и начинается другой;
●    принятие решений в условиях неопределённости — когда нет единственно верного ответа, а есть компромисс между производительностью, стоимостью поддержки и скоростью разработки;
●    понимание бизнес-контекста настолько глубоко, чтобы видеть последствия технического решения на годы вперёд;
●    удержание согласованности архитектуры на уровне всей системы, а не отдельного модуля.
Ни один из этих пунктов ИИ-агент выполнить не может — потому что для этого нужен не доступ к коду, а понимание целей бизнеса, истории проекта и компромиссов, которые были приняты раньше и по каким причинам. Агент видит код. Архитектор видит систему целиком, включая то, чего в коде нет.

Где ИИ реально экономит время

При этом было бы нечестно с моей стороны сказать, что польза от ИИ преувеличена. Есть конкретные сценарии, где агент экономит часы, а не минуты:

1. Типовой код. Реализация интерфейса репозитория (repository), DTO-классов, мапперов (mapper) между слоями — всё это агент делает быстро и почти без ошибок, если у него есть пример существующего кода в проекте для ориентира.
2. Черновые реализации. Когда нужно быстро проверить гипотезу — набросать прототип нового сервиса или endpoint, чтобы посмотреть, как он впишется в существующую архитектуру, — агент даёт стартовую точку за минуты вместо часа-двух.
3. Рутинный рефакторинг. Переименования, вынесение общей логики в отдельный метод, приведение кода к единому стилю по всему проекту — задачи, которые отнимают время, но не требуют творческих решений.
4. Документация. Генерация XML-комментариев, черновиков README, описания API по существующему коду — там, где нужен не творческий, а описательный текст.

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

Какие ошибки совершает ИИ

Есть категории ошибок, которые агент совершает регулярно, и я перестал удивляться, увидев их снова. Вот основные:

• Галлюцинации API (hallucinations). Агент уверенно использует метод или свойство, которого не существует в библиотеке — просто потому, что похожий метод существует в другой, похожей библиотеке или в более старой версии той же самой.
• Неверные допущения о контексте. Агент не видит всей кодовой базы одновременно и часто делает предположения о том, как устроен остальной проект, вместо того чтобы это проверить. Результат — код, который прекрасно работает в изоляции и ломает согласованность с остальной системой.
• Нарушение архитектурных границ. Это то, что задевает архитектора больнее всего: агент может напрямую обратиться к сущности домена (domain entity) из контроллера, обойдя слой приложения (application layer), просто потому что так короче и «работает».
• Игнорирование существующих паттернов проекта. Даже если в проекте уже есть устоявшийся способ работы с транзакциями (transaction) или обработки ошибок, агент нередко предлагает свой — синтаксически корректный, но не согласующийся с остальным кодом.
• Избыточная генерация кода. Там, где опытный разработчик обошёлся бы одним методом, агент иногда создаёт целую иерархию классов с интерфейсами «на будущее», которое никогда не наступит.

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

Ревью кода агента через архитектурную призму

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

• Границы слоёв. Не залезла ли бизнес-логика в контроллер, не появилась ли прямая зависимость домена от инфраструктуры.
• Соответствие существующим паттернам. Использован ли тот же подход к обработке ошибок, транзакциям, логированию, что и в остальном проекте.
• Избыточность. Не решает ли предложенный код задачу, которая шире, чем была поставлена.
• Скрытые допущения. Не полагается ли код на то, что определённое поле никогда не будет null, или что метод всегда вызывается в одном и том же порядке.

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

Как формулировать промпты, опираясь на паттерны

Часть ошибок из раздела «Какие ошибки совершает ИИ» можно предотвратить ещё до того, как агент напишет код — если явно закладывать архитектурные ограничения в постановку задачи, а не только бизнес-требование.

Разница на практике выглядит так. Вместо запроса вида «добавь метод для отмены заказа» я формулирую задачу с явным указанием на архитектуру: «добавь метод для отмены заказа в доменной сущности Order, обработку в соответствующем обработчике команды (command handler) по аналогии с существующим OrderCreatedHandler, без прямого обращения к репозиторию из домена».

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

1. Указывать не только что сделать, но и в каком слое архитектуры это должно находиться.
2. Ссылаться на существующий похожий код в проекте как на образец — агент гораздо точнее следует паттерну, когда видит конкретный пример, а не абстрактное описание.
3. Явно указывать ограничения — какие зависимости недопустимы, какой класс не должен быть затронут.
4. Просить агента задать уточняющие вопросы, если контекста недостаточно, вместо того чтобы он делал предположения молча.

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

Новая роль архитектора

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

Архитектор становится своего рода хранителем границ (guardian of boundaries) — тем, кто удерживает согласованность системы, пока скорость генерации кода растёт. Это не новая функция как таковая — она всегда была частью работы архитектора. Но её значимость выросла, потому что источник кода, который нужно держать в рамках архитектуры, теперь может производить его в разы быстрее, чем любой человек в команде.

Заключение

Спустя 25+ лет в разработке я не вижу в ИИ угрозы профессии архитектора — скорее наоборот, вижу инструмент, который освобождает время для той части работы, которая всегда была главной: принятия решений, а не написания кода. Если Вы хотите попробовать применить это на практике, вот с чего я бы начал: возьмите одну типовую задачу, которую обычно делегируете джуниору, и делегируйте её агенту с явным указанием архитектурных границ, как описано в разделе «Как формулировать промпты, опираясь на паттерны». Проведите ревью так же внимательно, как если бы это был код нового человека в команде. Скорее всего, Вы увидите одну-две ошибки из раздела «Какие ошибки совершает ИИ» — и это нормально. Важно, что Вы их поймаете до того, как они попадут в продакшн (production).