Как мы выбирали ИИ-агента-помощника для своих разработчиков: MCP, наш монорепо и один тихий дисквалификатор

Мы делаем ИИ-агентов для чужого бизнеса каждый день. Логично было предположить, что и внутри команды у нас порядок: сидят инженеры, каждый со своим помощником, катают код, запросы, автотесты. На деле — как у сапожника. Долго обходились всем подряд: кто-то пробовал одно, кто-то другое, кто-то писал руками. Пока однажды не поймали себя на том, что один и тот же кусок FastAPI-мидлвари переписывался в трёх ветках, потому что три человека одновременно спрашивали разных ИИ-агентов, как это правильно сделать.

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

Первый круг: бенчмарки, которые никого ни в чём не убедили

Начали, как все, с обзоров. Лето 2026-го, релизы валятся один за другим: Claude Fable 5 после снятия экспортных ограничений вернулся в доступ, у GPT-5.6 подтянули семейство Sol/Terra/Luna, Grok 4.5 обещает быть заметно дешевле топовых, DeepSeek V4, GLM-5.2 и Kimi K3 подобрались вплотную к коммерческим на кодинге. Плюс наши российские варианты — GigaChat Pro, YandexGPT, T-Lite для локального запуска. Есть из чего выбирать.

Собрал я ребятам таблицу с бенчмарками. Смотрели недолго. Разошлись без консенсуса.

Проблема бенчмарков в том, что они меряют абстрактного кодера на абстрактных задачах. А у нас — конкретный монорепо: Angular на фронте, FastAPI и SQLAlchemy сзади, pgvector под RAG, десяток внутренних библиотек, свои конвенции по неймингу, свои линтеры. И самое главное — свой MCP-сервер, через который ИИ-агент для кодинга должен ходить к нашему трекеру, вики и индексу кода.

Так что стало ясно: сравнивать надо не «какой ИИ-агент лучше вообще», а «какой из них лучше живёт с нашим MCP и нашим репозиторием».

Что действительно оказалось важно

Мы выписали пять критериев. Не «в чём модель сильна», а «что нам от неё нужно каждый день».

Первое — работа с MCP. Не заявленная поддержка в спецификации, а способность реально пройти через наш сервер, взять контекст из внутреннего трекера, прочитать соседнюю задачу и не выдумать поле, которого в схеме нет.

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

Третье — предсказуемость. Помощник, который сегодня расставляет пробелы по нашему стилю, а завтра неожиданно переходит на camelCase, отнимает больше времени, чем экономит.

Четвёртое — цена в реальных сценариях. Не «сколько за миллион токенов на прайсе», а сколько за задачу, если считать все ретраи, все чтения контекста и всю болтовню.

Пятое — как подключить ИИ-агента к нашей инфраструктуре так, чтобы не пришлось выкладывать полкода наружу. Часть репозитория закрыта соглашениями с клиентами, кое-где — прямо 152-ФЗ. Помощник, который тянет в облако всё подряд, у нас не приживётся.

MCP, на котором один кандидат тихо сложился

Дальше самое интересное. Построили тестовый стенд: наш MCP-сервер, набор из десятка типовых задач («добавить эндпоинт с валидацией», «починить регресс в компоненте формы», «переписать миграцию под новую версию SQLAlchemy»), и прогнали через них нескольких коммерческих и открытых кандидатов.

Один из них — имя оставим за скобками, это обзор, а не разгром — заявлен как топовый на кодовых бенчмарках. Спецификацию MCP поддерживает. По документам всё как надо.

На нашем стенде он валился на второй-третьей задаче. Ходил в MCP, получал ответ и... принимал его за что-то другое. Списки тикетов интерпретировал как код, поля структуры трактовал как список инструкций к выполнению. Однажды попытался «выполнить» описание бага, приняв его за скрипт. Prompt injection в чистом виде, только источником был не злой умысел, а наш собственный трекер.

Разбор занял пару вечеров. Оказалось, что модель просто плохо переваривает смешанный контекст, где через один MCP приходят и данные, и инструкции. Другие кандидаты на тех же вводных вели себя аккуратно: явно отделяли «это факт из системы» от «а вот это я собираюсь сделать».

Так у нас появился тихий дисквалификатор, который ни в одном публичном обзоре не всплывает: устойчивость к «отравлению» через собственные корпоративные источники. На нашем контуре она важнее лишних процентов на HumanEval. И, судя по волне CVE по MCP этим летом, ловим мы этот эффект не одни.

Как мы в итоге подключили помощника

Победил не один агент-помощник, а связка. Тяжёлые задачи, где нужно рассуждать через несколько файлов, — на одну модель. Быстрые правки, шаблонный код, тесты — на другую, попроще и подешевле. Подсказки прямо в редакторе — на третью, заточенную под inline.

Подключили это всё через один MCP-шлюз, который сам решает, какому агенту отдать задачу, ведёт лог того, что именно ушло наружу, и режет доступ к закрытым частям репозитория. Если по флажкам в задаче видно, что она пахнет клиентскими данными, — маршрут идёт только к тем моделям, которые крутятся в нашем контуре, и никуда больше. Для клиентов, где важен 152-ФЗ и российский контур, тот же шлюз замыкает всё на GigaChat Pro и локально развёрнутые открытые модели.

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

Что изменилось в работе

Разговоры «а какой ИИ-агент лучше» в чате команды почти прекратились. Каждый знает: для этой задачи — вот такой маршрут, для той — вот такой. Одинаковый кусок мидлвари в трёх ветках больше не появляется — MCP видит, что задача уже решалась, и подсовывает готовый фрагмент.

Ревью-встречи, на которых раньше уходило заметное время на «объясни, что ты тут написал», стали короче. Помощник заранее подкладывает объяснение прямо к пулл-реквесту, и обсуждение начинается уже с сути. Ощущение — будто в команде появился ещё один инженер, только он не устаёт, ничего не забывает и никогда не спорит.

Какой ИИ-агент лучше — вопрос неправильный

Если по-честному, за это время главный вывод такой: «лучшего» ИИ-агента-помощника не существует в отрыве от конкретной команды, стека и уровня зрелости процессов. Один и тот же кандидат у нас проиграл, а у знакомых на другом проекте выстрелил — потому что у них монорепо меньше, MCP проще и требований по персональным данным нет.

Полезнее спрашивать не «какой», а «как подключить ИИ-агента». Как встроить в пайплайн, как отделить безопасные данные от чувствительных, как измерять полезность на своих задачах, а не на чужих. Модели меняются каждый месяц. Ваш способ работать с ними — гораздо реже.

И если сегодня в вашей команде каждый инженер сидит со своим помощником, а в трёх ветках лежат три версии одного и того же — начните с этого. Не с выбора модели. С правил, по которым модель попадает к коду.