Карта исследований не равна архитектурному процессу
Основная публикация обобщает работы 2019–2025 годов и сопоставляет их с проблемами, найденными ранее в интервью с практиками. В поле попали дизайн и принятие решений, эволюция и адаптация, извлечение архитектурных элементов, ADR, паттерны, восстановление после отказов и оптимизация характеристик. Это полезная карта активности, но не эксперимент над единым copilot: авторы не измеряли долгосрочное качество архитектуры, окупаемость инструмента или production-эффект.
Баранов обращает внимание на разрыв между индуктивным каталогом частных работ и целостным архитектурным процессом: территория описана, но маршрут по ней не восстановлен. Свежие бенчмарки подтверждают ограничение. В ArchBench всего несколько задач, а ADR оценивается близостью текста к эталону; в R2A-Bench модели приемлемо находят компоненты по требованиям, но заметно хуже восстанавливают связи. Чем шире задача, тем труднее получить проверяемый эталон.
Артефакт генерируется легче, чем решение
ADR, диаграмма или список паттернов — форма результата, а не само решение. До записи ADR нужно исследовать варианты, определить приоритеты качеств, проверить ограничения и принять остаточный риск. Поэтому AI особенно полезен как первый проход: собрать факты, восстановить элементы из кода и трейсов, проверить правила, предложить альтернативы, оформить уже принятое решение. В типовых системах с известными границами такая автоматизация действительно снимает много рутины.
Проблема начинается между инструментами. Планирование и код, облачная эксплуатация и инциденты уже получают сильную AI-поддержку, а моделирование, архитектурное управление и связь артефактов остаются фрагментированными. Нет общей памяти, которая соединяла бы требование, ADR, модель, изменение кода и сигнал из production. Поставщик, способный собрать этот контекст, сможет продавать не токены, а готовое архитектурное решение — вместе с высокой стоимостью обработки данных и новым vendor lock-in.
Чего не хватает настоящему помощнику
Выпуск сводит пробелы к шести способностям: адаптировать решение при изменении фактов, поддерживать трассируемость, учитывать локальный контекст и неявное знание, проверять экспертные ограничения, доказывать выполнение атрибутов качества и наблюдать последствия на длинном горизонте. Каждое изменение должно распространяться по связанным представлениям, не создавая противоречий и гонок. Даже на уровне кода постепенное раскрытие требований резко снижает результат агентов; на уровне архитектуры цена такого разрыва выше.
Архитектор работает с неполными и слабоструктурированными данными, выбирает, какую неопределённость исследовать первой, и отвечает за последствия. Практический эксперимент Баранова показал ещё одну границу: модель начала давать конкретный инженерный ответ только после перехода на точный профессиональный язык. Экспертиза позволяет поставить задачу, заметить сбой и продолжить проверку. Поэтому ближайшая роль AI — быстро выполнять типовые операции, освобождая человеку время для нетиповых решений, системных компромиссов и ответственности.
Что стоит унести с собой
- 01Широкий обзор исследований показывает множество полезных локальных методов, но не доказывает существование сквозного AI-copilot для архитектуры.
- 02Сгенерированный ADR или диаграмма ценны только тогда, когда можно проверить исходные факты, альтернативы, компромиссы и последствия решения.
- 03Главный технический барьер — живая связь требований, моделей, кода и runtime-сигналов при постоянном изменении системы.
- 04Экспертиза архитектора не исчезает: она нужна для постановки задачи, выбора языка, проверки неопределённостей и принятия остаточного риска.