Почему AI-copilot архитектора всё ещё не получился

В основе разговора — систематический обзор 51 исследования об AI в архитектуре за 2019–2025 годы. Авторы разложили работы по темам: проектирование и принятие решений, эволюция и адаптация, ADR, паттерны, нефункциональные требования. В разделе 2.2 препринта arXiv v2 начальная выборка составляет 874 кандидата, после очистки остаётся 597. В субтитрах на этом месте указано 8074: это расхождение с первоисточником, а не размер итогового корпуса.

Баранов объясняет, почему такая индукция буксует: чтобы из частного собралось общее, нужна большая выборка, а здесь представления о том, из чего состоит архитектура, выведены из найденных работ. Он предпочёл бы взять архитектурный процесс из учебников и показать, какая его часть чем покрыта. Первое впечатление от статьи — точечные выводы, которым недостаёт концептуальной целостности по Бруксу. Его метафора: «нафотографировали Африку» — территория есть, карты нет.

Дальше Александр показывает бенчмарки. В ArchBench, по его словам, за всё время появилось пять задач, модели взяты старые, а сгенерированный ADR оценивается совпадением текста с эталонным; репозиторий есть, коммитов нет, участвовать никто не идёт. Свежий бенчмарк «из требований в архитектуру» сделан аккуратнее: на учебных и GitHub-проектах, 68 в сумме, модель строит план UML-диаграммы, и выясняется, что компоненты угадываются неплохо, а стрелки идут не туда — F1 по связям грустный. Баранову отдельно смешна задача распознавания паттернов: работа звучит как индустриальное подтверждение опыта, а внутри — поиск синглтона в двух-трёх проектах. Он честно говорит, что не нашёл ответа, зачем жечь токены на поиск Singleton или Factory: сам он когда-то устраивал ежемесячные хакатоны по паттернам, но ради того, чтобы команда научилась локализовать изменения. И замечает, что уровни в обзоре перемешаны: работа с кодом лежит там рядом с нефункциональными требованиями и инфраструктурными сюжетами.

Генерация ADR — самый распиаренный сценарий, и обоим он кажется мелким. Баранов напоминает, что шаблоны текста он раскладывал ещё в те времена, когда контрибьютил в httpd: ADR — это architecture decision record, а не decision, то есть read model уже принятого решения, полпроцента процесса, в котором остаются исследование, проектирование, сравнение вариантов и сбор данных по ним. Александр вспоминает, как в Т-Банке в прошлом году делали помощника, которому можно задавать вопросы по твоему ADR, — а сегодня Codex или Claude на порядок лучше прочелленджат черновик и помогут его дописать, если ответить на ключевые вопросы. Смешное он видел там же: из ADR генерируют план UML, который в процессе всё равно никто не читает, потому что UML читать умеют немногие, а шага ревью того, что сгенерировали инструменты, в таких конвейерах не предусмотрено.

Вторая часть обзора — карта инструментов по четырём уровням автономности, от правил до агентов. Наверху оказались Jira и Confluence с агентскими сценариями и поддержкой ADR, GitHub, GitLab, Sonar, а Postman попал туда за валидацию API-дизайна, рядом со средствами моделирования, что участников веселит; Cursor и Codex, самые массовые инструменты, в список не попали вовсе. Планирование, код и облачная эксплуатация закрашены хорошо, проектирование и моделирование — почти нет, и авторы признают, что не хватает общей памяти об истории и эволюции системы: цепочка «требования — ADR — модель — код — рантайм» разорвана. Александр ставит на то, что соберут её провайдеры моделей, поднимаясь снизу от кода, и тогда ADR со всем анализом вашей системы будет стоить не пятнадцать-двадцать долларов, как ревью изменения, а полторы сотни. Баранов отвечает, что это вендор-лок уже не на инструмент, а на мозги.

Финальный слайд перечисляет, чего помощнику не хватает: адаптации при смене фактов, трассируемости от намерения до реализации, локального контекста, проверки экспертных ограничений, доказательств по атрибутам качества и длинного горизонта. Первый пункт Александр подкрепляет свежими бенчмарками: когда требования выдают агенту не одним пакетом, а порциями, проходимость топовых моделей падает примерно с половины задач до четверти — и это на уровне кода, а на уровне архитектуры провал должен быть драматичнее. Баранов разбирает трассируемость: в нотациях вроде ArchiMate связь слоёв заложена в сердце, но правка одного блока меняет и элементы, и связи, и rationale, так что на выходе чаще новая модель, а не поправленная, а при высокой скорости изменений добавляются race condition и невозможность заранее проверить непротиворечивость без пессимистичной блокировки. Александр возражает: сквозная трассируемость и не нужна, достаточно видеть, учтено ли требование в ADR и доехало ли изменение до прода. Тут же в эфире у Баранова рождается мысль, что замкнутому циклу, способному прокрутить, по его прикидке, сто триллионов итераций почти мгновенно, нужны тормоза.

Контекст — отдельная боль: Александр давно хочет, чтобы правила компании, её компоненты и домен команды перетекали в агента, а не жили в голове архитектора. Баранов сводит ограничения к трём: данные всегда неполные, слабоструктурированные и огромные по объёму, а тревоги, которая помогает человеку ранжировать неопределённости по критичности, у модели нет. Его эксперимент: он залил в модель данные уже завершённого проекта и повторил запрос заказчика — ответ вышел усреднённым и почти нетехническим, а конкретика появилась, только когда он перешёл на строгий инженерный язык и стал обсуждать абстрактные фабрики и шаблон состояния. Вывод: чтобы получить профессиональный ответ, нужно самому быть сильным инженером, это тот же bounded context. Александр добавляет разбор из выпуска с Евгением Сергеевым: экспертиза сильнее всего видна на сбоях, новички бросают разбираться почти вчетверо чаще экспертов. В финале Баранов формулирует рубеж: людям остаются нетиповые задачи, и первая из них — сделать то, что закроет за нас типовые.