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

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

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

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

Авторы не проводили один эксперимент с одной моделью. Они сделали систематический обзор литературы по методике 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).020202Про ADR как машиночитаемый интерфейс между людьми, агентами и CI-проверками был отличный доклад «BDD, ADR, PRD, WTF» с AI Engineer Europe — пересказывал его в канале.Книжный куб · BDD, ADR, PRD, WTF02Про ADR как машиночитаемый интерфейс между людьми, агентами и CI-проверками был отличный доклад «BDD, ADR, PRD, WTF» с AI Engineer Europe — пересказывал его в канале.Книжный куб · BDD, ADR, PRD, WTF

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

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

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

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

Иными словами, индустрия уже научилась встраивать интеллект в отдельные этапы, но ещё не собрала архитектурный контур. Изолированная помощь может быть ценной. Ошибка начинается, когда её принимают за системное понимание.030303Похожий сдвиг я разбирал в посте «IDP is Dead? Нет, умирает монополия GUI»: платформы перестраиваются под агентов по кускам, и цельного контура там тоже пока нет.Книжный куб · IDP is Dead?03Похожий сдвиг я разбирал в посте «IDP is Dead? Нет, умирает монополия GUI»: платформы перестраиваются под агентов по кускам, и цельного контура там тоже пока нет.Книжный куб · IDP is Dead?

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

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

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

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

R2ABench проверяет переход от требований к архитектурной диаграмме на 68 проектах. Современные системы часто строят синтаксически корректные и читаемые представления, но заметно хуже восстанавливают связи между компонентами, чем сами компоненты. Галлюцинация рёбер оказывается главным структурным сбоем, а покрытие требований и трассируемость — основными содержательными проблемами. Хорошая форма снова не гарантирует архитектурной связности.050505Ещё в начале 2025-го я разбирал whitepaper «From Requirements to Architecture»: кандидатов генерировал LLM, оценивали по ATAM — и отставание связности от формы было видно уже там.Книжный куб · From Requirements to Architecture05Ещё в начале 2025-го я разбирал whitepaper «From Requirements to Architecture»: кандидатов генерировал LLM, оценивали по ATAM — и отставание связности от формы было видно уже там.Книжный куб · From Requirements to Architecture

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

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

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

Сначала нужна живая архитектурная база знаний: версионируемые ADR, явные связи с требованиями и компонентами, машинно читаемые ограничения, атрибуты качества и свидетельства из рабочей среды. Затем — адаптивная поддержка решений, которая пересматривает рекомендации при изменении фактов. После этого — проверяемые метрики и бенчмарки на полной траектории архитектурной работы.060606Живой пример — RepoSwarm Роя Ошерова: архитектурная дока по 400+ репозиториям, которую агенты регулярно перегенерируют через Claude Code SDK. Разбирал в канале.Книжный куб · RepoSwarm06Живой пример — RepoSwarm Роя Ошерова: архитектурная дока по 400+ репозиториям, которую агенты регулярно перегенерируют через Claude Code SDK. Разбирал в канале.Книжный куб · RepoSwarm

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

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

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

Затем путь надо пройти назад: от инцидента или архитектурного запаха к компоненту, изменению, ADR и исходному намерению. Если хотя бы в одном направлении цепочка держится только в памяти конкретного человека, AI не сможет сделать её надёжной. Он лишь быстрее произведёт ещё один несвязанный документ.070707Дисциплина таких цепочек старше LLM: в Amazon её держали через RFC и ADR ещё в нулевые. Мы разбирали их Distributed Computing Manifesto в новогоднем выпуске Code of Architecture.Книжный куб · Distributed Computing Manifesto07Дисциплина таких цепочек старше LLM: в Amazon её держали через RFC и ADR ещё в нулевые. Мы разбирали их Distributed Computing Manifesto в новогоднем выпуске Code of Architecture.Книжный куб · Distributed Computing Manifesto

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

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

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

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

Итог от этого не становится слабее. AI не отменяет архитектуру — он повышает цену архитектурной дисциплины. Чем дешевле сгенерировать локально правдоподобное решение, тем важнее удерживать намерение, границы, компромиссы и последствия во времени.080808Про удержание компромиссов во времени мы полгода читали «Software Architecture: The Hard Parts» в книжном клубе — конспект всех шести сессий есть в канале.Книжный куб · The Hard Parts08Про удержание компромиссов во времени мы полгода читали «Software Architecture: The Hard Parts» в книжном клубе — конспект всех шести сессий есть в канале.Книжный куб · The Hard Parts