AI для программной архитектуры: почему copilot архитектора всё ещё не получился

Самый важный вывод обзора для меня можно сформулировать без терминов из статьи: сегодняшний AI работает со снимком, а архитектура живёт как история. Модель получает требования, кусок кода или набор ADR в момент времени и предлагает следующий артефакт. Архитектору же приходится помнить, почему решение появилось, какой компромисс тогда был допустим, что изменилось в организации и как система повела себя после внедрения.

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

Поэтому вопрос «может ли LLM нарисовать архитектуру?» слишком узкий. Практический вопрос звучит иначе: может ли система поддерживать проверяемую архитектурную память и обновлять рекомендации по мере того, как меняются требования, код, ограничения и данные эксплуатации? В собранной литературе такой сквозной способности пока нет.

Авторы не проводили один эксперимент с одной моделью. Они сделали систематический обзор литературы по методике Kitchenham: искали работы в IEEE Xplore, ACM Digital Library, Scopus и Web of Science, вручную проверили материалы ICSA и ECSA и дополнили поиск просмотром ссылок. В корпус вошли рецензируемые публикации с января 2019-го по август 2025 года.

Воронка началась с 874 кандидатов. После удаления служебных материалов и дублей осталось 597 работ, после отбора и ручного поиска — 76, а после извлечения данных — 51 первичное исследование. Все пять авторов участвовали в кодировании и согласовании тем; поиск, решения об отборе и таблицы кодирования опубликованы в replication package (Bucaioni et al., 2026).

Затем исследователи сопоставили академические результаты с проблемами из своей предыдущей работы — интервью с 32 практиками программной архитектуры (Wan et al., 2023). Это сильная сторона обзора: он не просто перечисляет техники, а спрашивает, закрывают ли они реальные трудности проектирования, сопровождения и эволюции систем.

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

Наиболее убедительные результаты появляются там, где задача узкая, вход ограничен, а выход можно проверить. Модель Llama 2 7B, дообученная для выбора архитектурного паттерна по требованиям, показала 70% точности — но только среди MVC, microservices и client–server. Она часто объясняла выбор разумно, одновременно демонстрируя смещение к отдельным паттернам и нестабильность формата ответа (Gustrowsky et al., 2024).

В другом исследовании обработка естественного языка помогала извлекать зоны ответственности и строить Use Case Maps по требованиям. На четырёх проектах авторы сообщили F-меру около 75% (Rodríguez et al., 2021). Это полезный первый проход, который сокращает ручную работу, но результат говорит именно о нахождении элементов, а не о качестве всей получившейся архитектуры.

Для анализа архитектурных решений исследователи использовали корпус из 95 ADR. GPT-4 в режиме zero-shot генерировал связные и соответствующие контексту решения, но уступал человеку по полноте. GPT-3.5 с примерами приближался по качеству, а дообученный Flan-T5 выглядел конкурентоспособно и допускал локальное развёртывание. Вывод здесь не «ADR можно отдать модели», а «модель способна ускорить подготовку варианта, если человек проверяет полноту, обоснование и трассируемость» (Dhar et al., 2024).

Ещё сильнее выглядят задачи с измеримым эксплуатационным контуром. Фреймворк для Kubernetes на Azure Kubernetes Service объединял прогноз нагрузки, упреждающее масштабирование и chaos experiments; на небольшом стенде время развёртывания контейнеров снизилось на величину до 34% (Hettiarachchi et al., 2022). А агенты обучения с подкреплением лучше случайного chaos monkey находили критические отказы в моделях client–server и peer-to-peer — правда, только в симуляции (Canonico et al., 2020).

Архитектурная работа не делится на независимые кнопки «выбрать паттерн», «написать ADR» и «найти smell». Решение меняет границы, стоимость, безопасность, способы развертывания и будущие варианты развития. Чтобы поддержать его по-настоящему, AI должен удерживать взаимосвязи и последствия, а не только сгенерировать локально правдоподобный ответ.

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

Авторы отдельно посмотрели на 21 массовый инструмент по состоянию на март 2026 года — от GitHub Copilot и GitLab Duo до Datadog, Dynatrace, облачных advisors и средств ведения ADR. Это не независимый сравнительный benchmark, а диагностический срез по публичной документации поставщиков (Bucaioni et al., 2026). Тем не менее рисунок совпал с литературой: больше поддержки в наблюдаемости, контроле соответствия, локальном исправлении и генерации; меньше — в сквозном рассуждении, накоплении признаков архитектурной эрозии и связи намерения с эксплуатацией.

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

Из сопоставления исследований с практическими проблемами авторы выводят шесть направлений, где текущая поддержка остаётся недостаточной. Это полезнее читать не как список функций будущего продукта, а как шесть свойств архитектурной системы знаний (Bucaioni et al., 2026).

1. Адаптация. Рекомендация должна меняться вместе с требованиями и поведением системы, а не оставаться правильной только для исходного запроса.
2. Непрерывная трассируемость. Требования, ADR, модели, код и эксплуатационные данные должны оставаться согласованными в обе стороны.
3. Контекстное рассуждение. Границы системы зависят от домена, структуры команд, данных, ограничений и накопленной истории, а не только от текста задачи.
4. Экспертная проверка. Архитектурный review должен учитывать отраслевые стандарты, безопасность, регуляторику и знание предметной области.
5. Доказательные метрики. Качество нельзя уверенно свести к одному универсальному score; метрики должны быть связаны с атрибутами качества и наблюдаемым поведением конкретной системы.
6. Длинный горизонт. AI должен видеть накопление долга, smells, эрозии и последствия решений между версиями, а не только состояние текущей ветки.

Корпус систематического обзора заканчивается августом 2025 года, поэтому важно проверить, не устарел ли диагноз. За следующий год появилось сразу несколько работ, которые пытаются измерять именно архитектурные способности моделей. Они не отменяют вывод обзора; скорее, превращают часть его дорожной карты в конкретные измерительные инструменты.

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

R2ABench проверяет переход от требований к архитектурной диаграмме на 68 проектах. Современные системы часто строят синтаксически корректные и читаемые представления, но заметно хуже восстанавливают связи между компонентами, чем сами компоненты. Галлюцинация рёбер оказывается главным структурным сбоем, а покрытие требований и трассируемость — основными содержательными разрывами. Хорошая форма снова не гарантирует архитектурной связности.

CAKE измеряет знание облачной архитектуры на 188 экспертно проверенных вопросах и 22 конфигурациях моделей. В multiple-choice точность быстро упирается в потолок, тогда как свободные ответы продолжают различать модели; сам формат оценки существенно влияет на вывод о компетентности. SAKE расширяет проверку до 2154 вопросов по восьми архитектурным категориям и показывает: высокая средняя точность скрывает заметные провалы по отдельным областям.

Эти работы важно называть свежими benchmark’ами, а не зрелым промышленным доказательством. R2ABench, CAKE и SAKE на момент этого текста опубликованы как preprint’ы. Кроме того, знание терминов и правильный ответ на вопрос — необходимая, но недостаточная проверка способности принять решение в конкретной системе с реальными компромиссами.

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

Сначала нужна живая архитектурная база знаний: версионируемые ADR, явные связи с требованиями и компонентами, машинно читаемые ограничения, атрибуты качества и runtime evidence. Затем — адаптивная поддержка решений, которая пересматривает рекомендации при изменении фактов. После этого — проверяемые метрики и benchmark’и на полной траектории архитектурной работы.

Роль человека при этом не сводится к нажатию кнопки approve. Авторы предлагают разделение: AI действует как аналитик — собирает данные, ищет связи, предлагает варианты и объясняет основание; архитектор остаётся стратегом, который отвечает за «почему», приоритеты и допустимость компромисса. Такое разделение работает только тогда, когда рекомендацию можно оспорить и проследить до источников.

Я бы не начинал внедрение с выбора модели или покупки «архитектурного copilot». Сначала стоит взять одно реальное изменение и попробовать восстановить его причинно-следственную цепочку.

1. 01Какое требование или эксплуатационный сигнал запустил изменение?
2. 02Какие ADR и архитектурные границы оно затрагивает?
3. 03Где эти решения проявляются в коде, конфигурации и инфраструктуре?
4. 04Какие атрибуты качества и ограничения должны измениться или остаться неизменными?
5. 05Какие метрики, инциденты или пользовательские сигналы подтвердят последствия решения?

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

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

Этот обзор силён прозрачной методологией и открытым replication package, но не доказывает причинный эффект AI на качество архитектуры. Большинство исследований проверяет отдельную технику на ограниченном наборе данных; длительной промышленной валидации у задач раннего дизайна мало.

Поисковая строка ("Artificial Intelligence" OR AI) AND "software architecture*" намеренно проста. Она могла пропустить работы, которые используют LLM, но не называют подход AI. Исключение нерецензируемых материалов повышает однородность корпуса, одновременно отрезая самые свежие результаты. А срез массовых инструментов основан главным образом на документации поставщиков и не является рейтингом продуктов.

В arXiv v2 есть и редакционные несогласованности: аннотация, основные таблицы и раздел дорожной карты расходятся в количестве тематических областей, проблем практиков и стратегических направлений. Поэтому я не строю выводы на этих суммарных числах. Надёжные опорные точки — сам корпус из 51 исследования, описанные результаты первичных работ и шесть явно сформулированных разрывов.

Итог от этого не становится слабее. AI не отменяет архитектуру — он повышает цену архитектурной дисциплины. Чем дешевле сгенерировать локально правдоподобное решение, тем важнее удерживать намерение, границы, компромиссы и последствия во времени.