Роль Solution Architect с приходом AI-агентов: что изменилось в 2026 году

[ToxaBes]

Поделитесь в комментариях, как у вас устроено ревью агентного выхода?

Другой (это принципиально важно) сетью, пусть небольшой, с хорошим контекстном окном, возможностью рассуждений и доступом к поиску через MCP. Ревью либо говорит что не так и отправляет обратно, либо говорит что можно приступать к human-in-the-loop оценке методом прищуренного глаза.

Для примера, в локальных решениях Gemma 4 31В проверяет выход от Qwen Coder Next 80B, а в облачных сети от Google проверяют выход от сетей Antropic.

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

[AlexeyChijov]

Полезная информация по выстраиванию архитектурного блока в агентной разработки.

[Lightxaoc]

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

[alekseysobolekov]

"Вырастить" - звучит как про конечный процесс, но это не верно. Процесс обучения - это константа, как для джуна, так и для синьора.
Мой рецепт - Нужно учиться у ИИ. Он отличный учитель.

[Lightxaoc]

Но джун не сможет проверить код уровня сеньора, нужно дорасти. А как, если весь код пишут ИИ, а проверяют специалисты уровнем выше. Всем расти на пет проектах до мидлов, чтобы взяли хотя бы проверяющим код за ИИ? Чувствуется здесь какой-то эволюционный недочет в системе.

[alekseysobolekov]

Раньше джун рос, получая замечания по своему коду на код-ревью. Теперь он растет, проверяя более частый и плотный вывод агента. Джун не проверяет код уровня синьора в одиночку - он проверяет вслед за настроенными проверками в агенте и учится на их вердиктах. Это быстрее.

Еще добавляется агентная разработка как новый скилл. Agent = Model + Harness: надо понимать принципы работы модели и строить обвязку - инструкции, скиллы, проверки. Это описывается текстом, но требует инженерного мышления, и учиться этому можно с первого дня. Это актуальнее чем код.

Ручное кодирование уходит в узкие ниши. Растить джунов теперь дешевле: цикл обратной связи сократился с дней до минут.

[BelerafonL]

Отличная статья! Все практики очень похожи на авиационную разработку по DO-178C. Все эти спецификации идентифицируемых атомарных требований, трассируемость, тесты по требованиям, разбивка разработки по процессам, управление конфигураций и т.п.

Вопрос - а в каком виде у вас живут данные в репозитории для агентов? Те же спецификации требований, например. Надо же следить за уникальностью идентификаторов, строить матрицы трассируемости - из идентификатора требования к коду, к тестам, к результатам тестов. Проверять полноту и проверять что не реализовано ничего лишнего. Просто в маркдауне это не работает, нужно изобретать какой-то инструмент для агентов, который даст агенту работу с требованиями на уровне CLI. Но так как ревью делает человек, то и человеку нужен GUI чтобы работать с требованиями - группировать, сортировать, трассировать и т.п… В чём вы это делаете?

[alekseysobolekov]

Где живут данные. Единый источник правды - git. Спецификация - это структурированный .md, YAML с ИД и метаданными, ER в Mermaid, контракты в OpenAPI. Требования трассируются по ИД через спеку, код и тест при помощи CI скрипта. Полноту смотрит ревью-агент, владеющий полным контекстом проекта.

Вы правы про интерфейс для человека. Сейчас выделенного GUI для требований у нас нет: люди работают через Obsidian, VS Code, Git. Пока этого хватает. Про CLI для агента- да, агенту нужны команды. Все это отдельная большая тема - агенто-читаемый формат продуктовой документации, я планирую написать об этом статью.

[A1Dmitry]

Материал огонь, спасибо! Рад, что обошлось без дежурного хайпа в духе «ИИ всех убьет» или «ИИ ничего не умеет». Вы отлично подсветили главный сдвиг: проблема теперь не в том, как быстро написать код, а в том, как быстро вкурить в то, что нейронка нагенерила.

Про cognitive debt — прямо в точку, это наша новая реальность. Раньше мы плевались от человеческого легаси, а теперь будем разгребать легаси-контекст, который наворотили агенты. И если кривой код еще можно переписать, то с контекстом сложнее — это уже онтология проекта, его ДНК, так просто не переделаешь.

Отдельная ирония: агенты сразу фигачат систему «на вырост», а архитектору приходится бить их по рукам и урезать все до состояния «надо на вчера». Но это даже круто. Как раз здесь и включается человеческое суждение — не всё, что технически возможно, нужно тащить в MVP.

Ваш кейс с политиками и версионностью — стопроцентное попадание. Агент выдал идеальную сферическую архитектуру в вакууме, где бюджет бесконечен. Архитектор же выбрал решение для реального мира с жесткими костами. В этом и есть суть инженерного мышления, а не просто в унылом код-ревью.

P.S. Про спеку как точку входа — подписываюсь под каждым словом, тренд очевидный. Главное теперь не то, кто пишет код, а как формулируется намерение. Если агент понял суть — он выдает результат. Если не понял — генерирует белый шум. А разгребать этот шум сейчас обходится гораздо дороже, чем если бы он просто промолчал.

[chernykhmark]

Огонь! все четко и доступно, для меня, как для новичка)