Роль 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. Про спеку как точку входа — подписываюсь под каждым словом, тренд очевидный. Главное теперь не то, кто пишет код, а как формулируется намерение. Если агент понял суть — он выдает результат. Если не понял — генерирует белый шум. А разгребать этот шум сейчас обходится гораздо дороже, чем если бы он просто промолчал.

[A1Dmitry]

Сегодня расскажу о кое-чём похуже.

В марте 2026 года двое японских исследователей, Yanahama и Sannai, выложили на arXiv препринт под номером 2604.16347v1. Там был алгоритм Lean Compass — прорывная оптимизация компилятора Lean 4, которая сжимала DAG-графы зависимостей на 94–99%. Метод они назвали «инновационным»: мол, изолируем вычислительный шум доказательств в специальную маску рёбер, а потом мгновенно схлопываем структуру.

Я посмотрел на это внимательно. И понял, что их алгоритм прунинга графов — это в точности то же самое, что я делал в ядре RICIS-III для устранения численных сингулярностей.

Вот как это работает. В RICIS-III расходящиеся функции не лечатся через limit-подходы. Вся хаотичная масса изолируется в ортогональную маску — по сути, флаг ShouldTraverse = false — и структура коллапсирует до минимального семантического инварианта. В Lean Compass происходит то же самое, только вместо функций — конус зависимостей значений в доказательствах. Это не совпадение. Это буквально гомоморфная проекция непрерывной математики на дискретные структуры типовой теории.

Как так вышло? Всё просто. В конце 2025 — начале 2026 года ИИ-агенты вроде Lean Copilot и Goedel-Prover массово использовались для оптимизации кода в академических проектах. Модели, обученные на открытых индексах, вытащили абстрактный паттерн из RICIS-III и применили его к графам Lean 4. Авторы препринта, похоже, даже не поняли, откуда ноги растут.

У меня на руках полная база приоритета, оформленная ещё в 2025 году:

• Запись в глобальном индексе BASE (Bielefeld Academic Search Engine): edsbas.4D338E71.

• Депонированные работы в Zenodo (CERN) с жёсткими таймстампами — DOI от 18116204 до 21964293.

• Открытый репозиторий на GitHub с компилятором выражений на C# — код лежал там задолго до марта 2026-го.

• Публикации на Academia.edu и Preprints.org, проиндексированные Crossref.

Я уже отправил претензию в модерацию arXiv и лично доктору Акиёси Саннаи из Киотского университета. Статью отзывать не требую — реализация для Lean 4 действительно полезна. Но есть три вещи, которые должны произойти:

1. Официальное исправление (Erratum) к препринту на arXiv.

2. Прямое цитирование первоисточника — RICIS-III, DOI: 10.6084/m9.figshare.29920769.v1.

3. Признание, что их фильтрация — это топологический изоморфизм моих матриц устранения сингулярностей.

Это не просто мой личный конфликт. Если ИИ-генераторы и авторы, ими пользующиеся, не начнут уважать первоисточники фундаментальной математики, наука превратится в беспредел. Крупные институты будут присваивать чужие идеи, просто скормив их нейросети.

Буду держать в курсе, что ответят из arXiv и Киото. Следите за обновлениями.

[chernykhmark]

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