
Комментарии 5
Поделитесь в комментариях, как у вас устроено ревью агентного выхода?
Другой (это принципиально важно) сетью, пусть небольшой, с хорошим контекстном окном, возможностью рассуждений и доступом к поиску через MCP. Ревью либо говорит что не так и отправляет обратно, либо говорит что можно приступать к human-in-the-loop оценке методом прищуренного глаза.
Для примера, в локальных решениях Gemma 4 31В проверяет выход от Qwen Coder Next 80B, а в облачных сети от Google проверяют выход от сетей Antropic.
Вообще, позиция архитектора сейчас сильно меняется в том плане, что раньше синьоры/лиды становились архитектами, а теперь архитекты все больше становятся пишушими код синьорами, пусть и с помощью ИИ.
Полезная информация по выстраиванию архитектурного блока в агентной разработки.
Чтобы проводить ревью нужно наработать немалый опыт. Получается для закрытия нарастающего объема финальных проверок нужны специалисты достаточно хорошего уровня. Если код всё в большей степени пишут агенты ИИ, как же вырастить специалистов. На чём им учиться? Есть ли у вас ответ на этот вопрос?
Отличная статья! Все практики очень похожи на авиационную разработку по DO-178C. Все эти спецификации идентифицируемых атомарных требований, трассируемость, тесты по требованиям, разбивка разработки по процессам, управление конфигураций и т.п.
Вопрос - а в каком виде у вас живут данные в репозитории для агентов? Те же спецификации требований, например. Надо же следить за уникальностью идентификаторов, строить матрицы трассируемости - из идентификатора требования к коду, к тестам, к результатам тестов. Проверять полноту и проверять что не реализовано ничего лишнего. Просто в маркдауне это не работает, нужно изобретать какой-то инструмент для агентов, который даст агенту работу с требованиями на уровне CLI. Но так как ревью делает человек, то и человеку нужен GUI чтобы работать с требованиями - группировать, сортировать, трассировать и т.п… В чём вы это делаете?
Роль Solution Architect в эру AI-агентов