Купили кодинг-агента, половину задач всё равно писали сами: где ИИ-агент в разработке нужен, а где хватает ассистента
К осени 2026 у нас в команде накопилось четыре подписки на разные ИИ-агенты для программирования. Кодинг-агенты для команды осенью посыпались один за другим: Cognition выкатила SWE-2 с ценником заметно ниже фронтир-моделей, Anthropic научила Claude Code Projects разбирать задачу по параллельным веткам с общей памятью, Google собрала свой antigravity-preview для агентных пайплайнов, GitLab в 19.4 приделал governance над агентами прямо в Duo. Мы честно попробовали всё, что достали. И к декабрю выяснилось, что половину задач в наших проектах покупные агенты просто не тянут — не потому что тупые, а потому что стоят не там, где нужно. Пришлось разбираться, где ИИ-агент в цикле разработки действительно нужен, а где мы годами путали его с ИИ-ассистентом и переплачивали за возможности, которыми не пользовались.
Как мы сначала попались на маркетинге
Первый заход был простой: раз выходят кодинг-агенты для программирования, давайте раздадим команде и посмотрим. Разработчикам понравилось: автодополнение стало умнее, объяснения кода — толковее, простые рефакторинги делаются быстрее. Через пару недель я спросил у ребят, что изменилось в скорости больших задач. Ответ был честный: почти ничего. Рутина ускорилась, а сроки по крупным фичам плюс-минус те же.
Мы стали копать, куда уходит время. И тут оказалась любопытная вещь. То, что мы купили и раздали, работало как ассистент — сидел рядом с разработчиком, отвечал на вопросы, писал куски по запросу. А узкие места в команде были совсем в других местах: сборка тестового окружения, разбор ошибок в CI, миграции схемы под сотню таблиц, замена библиотеки, которая тянула хвост зависимостей через весь монорепо. Там разработчик тратил не минуты на кусок кода, а часы на переключение контекста между окнами.
Где заканчивается ассистент и начинается агент
Разница между ИИ-агентом и ИИ-ассистентом стала для нас не философской, а вполне рабочей. Ассистент отвечает на запрос: спросил — получил. Живёт в редакторе, не выходит наружу, не помнит контекста между сеансами. Агент действует сам: получает цель, разбивает её на шаги, лазит по системам, оставляет за собой следы, может вернуться и доделать. Ассистент экономит секунды и минуты, агент — часы и дни.
И вот здесь стало понятно, где ИИ-агенты действительно нужны, а где они избыточны. Написать функцию, объяснить чужой класс, подсказать регулярку — это работа для ассистента. Разобрать красный CI на пятидесяти джобах, понять, где сломалось, поправить, прогнать заново — это уже агент. Написание ИИ-агентов имеет смысл именно там, где длинная цепочка действий, доступ к нашей инфраструктуре и обязательство довести задачу до конца.
Что мы попробовали купить и почему не всё зашло
Cognition SWE-2 мы гоняли на реальных задачах из бэклога. По качеству — близко к фронтир-моделям, по цене — заметно приятнее, для автономных кодеров действительно рабочий вариант. Но SWE-2 хорошо себя показал там, где задача формулируется коротко: почини баг в этом файле, перепиши эндпоинт под новую схему. На длинных задачах, где нужно ходить по нашему монорепо, дёргать наши внутренние сервисы, читать нашу базу знаний, покупной агент упирался в то, что ничего про нас не знает.
Обновление Claude Code Projects с координатором и параллельными потоками выглядело красиво в демо. На нашем коде тоже работало, но с оговоркой: чем дальше от типового веб-приложения, тем чаще потоки начинали дублировать друг друга, потому что общая память не понимала специфики нашего домена. Antigravity-preview у Google и Duo agentic от GitLab тем временем очень сильно давят на governance и аудит — для команд, которым нужно объяснять безопаснику каждый вызов, это плюс. Нам этот плюс тоже был важен, но не спасал от главного: чужой агент не знает нашего заказчика, наших правил приёмки, наших легаси-подсистем.
Где мы сели писать своего
К декабрю мы очертили три места, где написание ИИ-агентов под себя окупилось быстрее всего.
Первое — агент-разбиратель CI. Собирает падение, читает логи, смотрит последние коммиты, лезет в pgvector с историей похожих поломок, предлагает три версии причины и одну — с патчем. Не заменяет разработчика, а приходит к нему с готовой гипотезой вместо голой красной галки.
Второе — агент миграций. Мы часто переезжаем с одной библиотеки на другую или чиним схему БД, растёкшуюся по десяткам сервисов. Такой агент проходит по всем местам, где всплывает старый вызов, готовит патчи с одинаковой логикой, оставляет ссылки на файлы, где не смог решить сам. Раньше на такую задачу уходила неделя разработчика, теперь мы закрываем её за пару дней вдвоём с агентом.
Третье — агент-приёмщик задачи. Читает тикет, идёт в наш монорепо, проверяет, где, скорее всего, придётся править, дёргает MCP-сервер над нашей документацией, возвращает разработчику готовый черновик плана: что менять, что проверить, где риски. Не пишет код, но снимает половину подготовительной работы.
Как мы это собрали
Ядро пишем на Python поверх FastAPI, оркестрацию строим вокруг MCP: у нас есть MCP-серверы над PostgreSQL, над нашей вики, над CI, над трекером. Модель для рассуждения выбираем под задачу — не привязываемся к одному вендору. На чувствительных к 152-ФЗ проектах у нас на приёме GigaChat Pro и свежий GigaChat 3.5 Reasoning, который в сентябре прибавил на IFBench и LiveCodeBench и стал реально пригоден для многошагового планирования. Там, где заказчик не против облака и хочет открытые веса, смотрим на Qwen и DeepSeek, на самых длинных задачах трогали preview от Shanghai AI Lab. Свежий T-Lite ставим локально, когда клиент вообще не хочет выпускать код за периметр.
Дисциплину написания ИИ-агентов мы у себя вывели в правила. У каждого агента есть бюджет шагов и дедлайн на всю задачу. Каждый вызов инструмента пишется в лог, каждый пройденный шаг — в память с TTL, чтобы через неделю не разбираться в чужом следе. И самое неочевидное: у нас в команде агент не имеет права коммитить в основную ветку. Он готовит патч, открывает MR, вешает свой бейдж — и дальше решает человек. Governance в GitLab 19.4 здесь неплохо ложится сверху, но своя дисциплина всё равно важнее любого инструмента.
Что мы поняли про границу
Если совсем коротко — ИИ-агенты для программирования сейчас есть везде, но полезны они не везде. Ассистент рядом с разработчиком уже норма и, вероятно, останется. Полноценный агент, который действует сам, оправдан там, где задача длинная, повторяющаяся и требует доступа к вашей внутренней кухне. Всё, что короче часа работы человека, ассистент закроет дешевле. Всё, что длиннее дня и повторяется из месяца в месяц, — кандидат на написание собственного ИИ-агента, потому что покупной агент про ваш монорепо, ваших клиентов и вашу приёмку не знает и не узнает.
Осенние релизы это ощущение только усилили. Кодинг-агенты за квартал подешевели, стали умнее и научились работать параллельно, но чужого домена в них по-прежнему нет. Свой домен — единственное, что заказчик не купит в подписке. Собственно, именно поэтому мы и разрабатываем ИИ-агентов под конкретные процессы, а не пересаживаем клиентов на универсальный кодинг-помощник. Универсальный помощник — это ассистент. Агент — это тот, кто знает вас лично.
Похожие статьи
- Красная папка: как мы учим ИИ-агента после запуска и не чиним всё подряд
- Стенд вместо чужих бенчмарков: как мы проверяем ИИ-агентов для бизнеса перед сдачей
- «Хочу ИИ-агента прямо на ноутбук, как у Perplexity»: разбираемся, какие есть ИИ-агенты для ПК и что реально стоит покупать
- ИИ-агент для 1С после сентябрьских атак: как мы переписали правила доступа, не сломав рабочие сценарии
