AI-агенты в разработке: от тикета до пул-реквеста

Что произошло

За полтора года агентные инструменты для кодинга перестали быть демо на конференции. В 2024-м стартап Cognition показал Devin, которого назвали «первым AI-инженером»; Anthropic выпустила Claude Code как терминальный агент; Cursor добавил режим Agent, а GitHub — Copilot Workspace и позже agentic-режим прямо в задачах репозитория. Все они претендуют на одно: взять тикет, разобраться в чужом коде, написать патч, прогнать тесты и открыть пул-реквест — без того, чтобы разработчик держал руку на клавиатуре весь цикл.

Разница между «автодополнением строки» и «агентом» принципиальная. Автодополнение подсказывает следующую строку. Агент^* сам решает, какие файлы открыть, какие команды запустить в терминале, как отреагировать на упавший тест и когда остановиться. Ниже — как выглядит полный цикл и где на этом пути инструменты спотыкаются.

^* AI-агент — программа на основе языковой модели, которая не просто выдаёт текст, а планирует шаги, вызывает инструменты (терминал, файловую систему, поиск) и корректирует действия по результату, пока не выполнит задачу или не упрётся в лимит.

Цикл фичи глазами агента

Возьмём типовую задачу: «Добавить фильтр по дате в список заказов и покрыть тестами». Хорошо настроенный агент проходит её примерно так.

1. Разбор задачи. Читает текст тикета, задаёт уточняющие вопросы или делает допущения и фиксирует их.
2. Ориентация в коде. Ищет, где лежит список заказов, какой стек, как устроены существующие фильтры. Здесь агенту помогает индексация репозитория и поиск по коду.
3. План. Разбивает работу на шаги: модель запроса, обработчик, UI, тесты.
4. Правки. Вносит изменения в несколько файлов, а не в один — это ключевое отличие от подсказок в редакторе.
5. Проверка. Запускает линтер и тесты в терминале, читает вывод, чинит то, что упало, повторяет.
6. Пул-реквест. Оформляет ветку, коммит и PR с описанием того, что и зачем сделано.

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

Агент не устаёт и не ленится читать чужой код целиком. Но он с той же уверенностью пишет правильный патч и правдоподобно выглядящую чушь — и отличить одно от другого по-прежнему обязан человек.

Где ломается

Три частые точки отказа, о которых говорят команды, уже гонявшие агентов на реальных задачах:

• Большие и незнакомые кодовые базы. Чем больше проект, тем выше шанс, что агент упрётся в контекстное окно^** и потеряет из виду половину зависимостей. Он чинит один тест и ломает соседний модуль, которого не видел.
• «Зелёные» тесты любой ценой. Агент, которому поручено добиться прохождения тестов, иногда правит сам тест, а не код. Формально задача выполнена, по сути — нет.
• Тихие допущения. Если тикет сформулирован размыто, агент домысливает поведение и не всегда об этом сообщает. Ревью PR становится обязательным, а не опциональным.

^** Контекстное окно — объём текста (кода, инструкций, вывода команд), который модель удерживает «в голове» за один проход. Всё, что не влезло, модель не учитывает, даже если файл лежит в том же репозитории.

Чем инструменты отличаются

Четыре подхода к одной идее. Характеристики и доступность актуальны на начало 2025 года; тарифы у всех менялись и продолжают меняться — точные цифры сверяйте на официальных страницах.

Общая логика у всех похожа, а различается точка входа. Devin ближе к «поручил и ушёл»: он крутит задачу в своём окружении и приходит с готовым PR. Claude Code и Cursor держат разработчика рядом — вы видите каждый шаг и вмешиваетесь. Copilot выигрывает за счёт того, что и так стоит в вашем GitHub.

Насчёт бенчмарков стоит быть осторожным. Компании часто ссылаются на SWE-bench — набор реальных задач из открытых репозиториев на GitHub, где измеряют долю корректно закрытых issue. Цифры в пресс-релизах растут от версии к версии, но методики прогонов различаются, и сравнивать проценты «в лоб» между вендорами некорректно. Ориентируйтесь на прогон в вашем собственном проекте, а не на слайд с конференции.

Кому это пригодится, а кому нет

Пригодится, если:

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

Не стоит рассчитывать, если:

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

Что это меняет в работе команды

Главный сдвиг не в том, что код пишется быстрее. Он в том, что смещается узкое место. Раньше дефицитным ресурсом было написание кода, теперь — его ревью. Агент выдаёт больше PR, чем команда успевает вдумчиво проверять, и соблазн пропускать патчи бегло — прямой путь к техническому долгу и багам, которые всплывут позже.

Практический вывод простой: агент экономит время на наборе и на разборе незнакомого кода, но перекладывает нагрузку на постановку задач и на ревью. Команда, у которой хромает то и другое, от агента получит не ускорение, а рост беспорядка.