Чем проще становится получить готовую реализацию с помощью ИИ, тем важнее вопрос, который возникает еще до создания первой строки кода: нужно ли системе именно такое решение и где ему место.
Генеративные инструменты уже умеют писать функции, предлагать исправления, готовить тесты и разбирать существующий код. Но разработка сложной системы не сводится к последовательности задач на генерацию. Перед тем как реализовать изменение, нужно определить его границы, учесть уже существующие связи и выбрать компромисс между скоростью, стоимостью, надежностью, безопасностью и дальнейшим развитием продукта.
Константин Попандопуло, технический директор Umbrella IT, рассказал, почему способность быстро генерировать код пока не заменяет архитектурную работу и как руководителю управлять разработкой, когда объем потенциальных изменений растет.
Архитектурное решение начинается до создания кода
Предположим, продукту требуется новая функция. ИИ может быстро предложить структуру отдельного сервиса, подготовить API, обработку ошибок и тесты. Но до начала реализации нужно принять другое решение: действительно ли системе нужен еще один сервис?
Возможно, новая функциональность использует те же данные и бизнес-правила, что уже существующий компонент. Тогда отдельный сервис формально решит задачу, но создаст новую границу, которую придется поддерживать: отдельные контракты, интеграции, права доступа, мониторинг и сценарии отказа. В другой ситуации изоляция будет оправдана, например если у новой функциональности другой жизненный цикл, требования к масштабированию или безопасности.
Код для обоих вариантов можно сгенерировать. Архитектурная задача состоит в том, чтобы понять, какой вариант соответствует устройству конкретной системы.
В этом и проходит важная граница между генерацией и архитектурой. Генерация отвечает на вопрос, как реализовать поставленную задачу. Архитектура начинается раньше: что именно нужно реализовать, где в системе должно появиться изменение и какие новые связи оно создаст.
ИИ уже может участвовать в такой работе: анализировать репозиторий, находить зависимости, предлагать варианты декомпозиции. Однако его выводы зависят от доступного контекста и критериев, по которым оценивается результат.
Исследователи MIT CSAIL в работе 2025 года о препятствиях на пути к автономной разработке отдельно рассматривают задачи, которые выходят далеко за пределы генерации кода. Среди проблем они выделяют работу с крупными кодовыми базами, взаимодействие с инженерными инструментами и необходимость учитывать реальные условия разработки, которые не попадают в стандартные бенчмарки. В MIT отмечают, что современные оценки ИИ часто строятся на относительно локальных задачах, тогда как реальные изменения могут затрагивать системы с миллионами строк кода.
Для архитектурной работы это принципиально. Решение нельзя оценить только по тому, компилируется ли код и проходят ли локальные тесты. Нужно понимать, что изменится за пределами конкретного модуля.
У архитектурного решения нет универсально правильного ответа
Даже когда команда определила место нового изменения в системе, остается вопрос о способе реализации. Здесь ИИ также способен существенно ускорить работу: сравнить варианты, предложить технологии, перечислить преимущества и риски.
Проблема в том, что архитектурное решение редко выбирают только по техническим характеристикам.
Допустим, компания может доработать существующую систему и быстрее выпустить новую функцию. Другой вариант потребует создания отдельного компонента и дополнительной инфраструктуры, зато упростит дальнейшее развитие продукта. Третий позволит снизить операционные риски, но увеличит стоимость ближайшего этапа.
У каждого решения будут основания. Выбор зависит от того, какие ограничения для компании важнее сейчас: время выхода на рынок, бюджет, надежность, требования ИБ, ожидаемая нагрузка или планы развития продукта.
ИИ может сравнить варианты по заданным критериям. Но сами критерии и их приоритет определяются не моделью. Если для одного бизнеса важнее сократить время запуска, а для другого подготовить систему к росту нагрузки, одинаковое с технической точки зрения решение будет иметь разную ценность.
На практике архитектор постоянно работает с такими компромиссами. Его задача не найти абстрактно лучшее решение, а определить, какое решение оправдано в конкретных условиях и какие последствия компания готова принять.
Это особенно важно учитывать при использовании ИИ. Быстро получить несколько технически убедительных вариантов еще не означает выбрать подходящий. Чем проще становится подготовить реализацию, тем больше внимания требуется к предпосылкам, на которых она строится.
Контекст системы нельзя свести к репозиторию
Архитектура крупной системы существует не только в исходном коде и документации.
Часть решений могла быть принята несколько лет назад. Какие-то ограничения зафиксированы в технических документах, другие известны командам, которые поддерживают отдельные компоненты. Временное решение иногда постепенно становится постоянной частью системы, хотя первоначальные причины его появления уже никто не помнит.
Есть особенности инфраструктуры, требования ИБ, ограничения внешних интеграций, планы развития продукта. Полный контекст, необходимый для архитектурного решения, редко находится в одном месте.
ИИ способен помочь собрать и обработать большой объем информации. Но если существенное ограничение не попало в доступный модели контекст, она может предложить технически логичное решение, которое окажется неприемлемым для конкретной системы.
Исследование MIT CSAIL 2025 года показывает эту проблему и с другой стороны. Авторы отмечают сложности работы современных моделей с крупными кодовыми базами, где важны не только объем информации, но и специфика конкретного проекта: внутренние соглашения, требования и особенности системы. Модель может сгенерировать правдоподобный код, который обращается к несуществующим функциям, нарушает внутренние правила или не проходит существующие процессы проверки.
Разработчик или архитектор тоже не хранит весь контекст системы в памяти. Но существенная часть его работы заключается в том, чтобы понять, какой информации не хватает для решения. Посмотреть историю изменений, выяснить причины прежнего технического выбора, поговорить с владельцами смежных систем, проверить инфраструктурные ограничения.
Архитектурная работа часто начинается не с готового ответа, а с уточнения вопроса. В некоторых случаях способность сказать, что для решения недостаточно информации, важнее способности быстро предложить очередной вариант кода.
Когда кода становится больше, архитектура становится вопросом управления
Ускорение генерации меняет не только работу разработчика. Оно меняет и задачу технического руководителя.
Если команда быстрее получает варианты реализации, растет поток потенциальных изменений. Их нужно проверить, встроить в существующую систему и оценить не только по качеству отдельного кода, но и по последствиям для архитектуры.
Здесь возникает управленческий вопрос: как организовать разработку, если создавать изменения становится быстрее, чем раньше, а способность оценивать их влияние на систему автоматически не растет?
Один из рисков связан с локальной оптимизацией. Несколько разработчиков могут одновременно использовать ИИ для решения своих задач. Каждое изменение отдельно выглядит обоснованным и проходит необходимые проверки. Однако на уровне продукта постепенно появляются дублирующие механизмы, дополнительные зависимости и исключения из общих правил.
Сам по себе рост объема изменений не означает, что система развивается быстрее или лучше.
Именно на эту зависимость между ИИ и качеством организационной среды обращает внимание DORA в исследовании State of AI-assisted Software Development 2025. Исследователи называют ИИ усилителем: он способен усиливать как сильные стороны организации, так и уже существующие проблемы. На основе более чем ста часов качественных исследований и ответов почти пяти тысяч специалистов DORA делает вывод, что эффект от ИИ зависит не только от самого инструмента, но и от процессов, внутренних платформ и организации работы.
Для руководителя разработки это означает, что оценивать эффект ИИ только по скорости написания кода недостаточно. Важно, успевает ли архитектурный контроль за новым темпом изменений и понятно ли команде, где проходит граница между локальной задачей и изменением, которое затрагивает систему в целом.
Это не требует согласовывать каждую техническую деталь на архитектурном комитете. Такой подход быстро превратит архитектурную функцию в новое узкое место. Гораздо важнее заранее определить границы ответственности: какие решения команда принимает самостоятельно, а какие требуют дополнительной оценки.
Например, отдельного архитектурного обсуждения могут требовать изменения, которые затрагивают взаимодействие нескольких систем, создают новую зависимость, меняют модель работы с данными, влияют на требования ИБ или предполагают появление нового инфраструктурного компонента.
ИИ способен помочь подготовить варианты и ускорить анализ. Но решение о том, какие последствия такого изменения приемлемы для системы, остается частью инженерного и управленческого процесса.
По мере распространения генеративных инструментов архитектура становится не менее важной, а более заметной управленческой функцией. Если раньше одним из естественных ограничений была скорость создания кода, то теперь руководителю все чаще приходится следить за другим балансом: не начинает ли производство изменений опережать способность команды удерживать целостность системы.
Архитектура остается там, где заканчивается готовый ответ
ИИ будет брать на себя все больше задач в разработке. Он уже сокращает время на поиск вариантов, подготовку реализации и часть рутинной инженерной работы. Но архитектура не сводится к написанию кода.
Она начинается там, где готового ответа еще нет: нужно определить границы изменения, восстановить недостающий контекст, выбрать между несколькими допустимыми вариантами и принять последствия этого выбора.
Поэтому главный вопрос при внедрении ИИ в разработку постепенно смещается. Недостаточно понять, насколько быстрее команда стала создавать код. Важно, способна ли организация управлять растущим числом технических решений и сохранять целостность системы по мере того, как создавать новые изменения становится проще.
ИИ все лучше отвечает на вопрос, как реализовать решение. Вопрос, какое решение действительно нужно системе и почему, пока остается за разработчиками и техническими руководителями.
Источник: Константин Попандопуло, технический директор Umbrella IT
