Агентная разработка: как команда работает с AI-агентами

Что такое агентная разработка

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

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

• Agentic coding — работа с агентом, который пишет и правит код сам. Термин появился вместе с Claude Code, Codex и агентным режимом Cursor в 2025 году.
• Agentic engineering — термин, который в феврале 2026 года предложил Андрей Карпаты взамен «вайб-кодинга». Он подчёркивает, что код пишут агенты, а инженерная дисциплина остаётся за человеком. Саймон Уиллисон использует его для разработки с агентами, где результат доводят до production-качества.
• Вайб-кодинг — генерация кода без ревью, на уровне прототипа. Для production этот режим не подходит.

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

Агент, автодополнение и чат: в чём разница

Главное отличие агента — он сам проверяет свою работу. Если тест упал, агент читает ошибку и исправляет код. Поэтому качество результата зависит от того, какие проверки есть в репозитории и какой контекст агент получил.

Инструменты

Агентов для разработки можно разделить по месту работы:

• В терминале: Claude Code, Codex CLI, Gemini CLI, Aider. Работают с локальной копией репозитория, запускают команды в окружении разработчика.
• В IDE: агентный режим Cursor, GitHub Copilot в VS Code и JetBrains, Windsurf, Kiro.
• В облаке: Codex в облаке, GitHub Copilot coding agent, Google Jules, Devin. Получают задачу из тикета или issue, работают в изолированном окружении и открывают pull request.

Для процесса выбор инструмента важен меньше, чем кажется. Правила в AGENTS.md, спеки и тесты читает любой агент. Команды, которые строят процесс вокруг одного инструмента, переделывают его при каждой смене вендора.

Как ставить задачу агенту

Агент делает то, что понял из задачи и контекста. Пробелы он заполняет догадками. Хорошая задача для агента содержит:

• Цель и критерий готовности. Что должно работать после изменения и как это проверить.
• Границы. Какие модули менять, какие нельзя. Что в задачу не входит.
• Ссылки на контекст. Спека, связанный код, похожая реализация, которую стоит взять за образец.
• Способ проверки. Какие тесты запустить, какой сценарий пройти руками.

Пример слабой и рабочей постановки:

Слабо:
  Добавь экспорт отчёта в CSV.

Рабочая постановка:
  Добавь экспорт сводного отчёта в CSV по спеке specs/report-export.md.
  Эндпоинт GET /reports/daily.csv, параметры те же, что у /reports/daily.
  Формат дат и сумм — как в services/billing/export.ts, возьми его за образец.
  Не меняй схему таблиц и существующий JSON-эндпоинт.
  Готово, когда: проходят тесты reports/, добавлен тест на AC-1..AC-3 из спеки,
  pnpm lint и pnpm typecheck без ошибок.

Для задач крупнее пары часов работы постановку оформляют спецификацией. Подробнее — в статье про spec-driven development.

Как принимать результат

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

1. Сверить с задачей. Закрыты ли все критерии готовности. Нет ли изменений за пределами задачи.
2. Посмотреть тесты. Проверяют ли они поведение из спеки. Не ослабил ли агент существующие тесты, чтобы они прошли.
3. Проверить границы. Публичные API, схема данных, конфигурация, зависимости.
4. Прочитать логику. Граничные случаи, часовые пояса, деньги, конкурентный доступ.

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

Где команды застревают

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

Похожий эффект зафиксировало рандомизированное исследование METR 2025 года. Опытные разработчики решали задачи в своих крупных open-source репозиториях. С AI-инструментами они тратили на задачи на 19% больше времени, хотя сами оценивали ускорение в 20%. Авторы предупреждают, что результат относится к конкретным условиям: опытные люди, знакомый код, ранние инструменты. В феврале 2026 года METR опубликовала обновление: по сырым данным нового эксперимента разработчики с AI уже работают быстрее. Сами авторы считают эти данные ненадёжными. Часть разработчиков отказалась участвовать, потому что не хочет работать без AI. Разрыв между ощущением и замером виден и в командах.

Типичные причины:

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

Переход со второго уровня на третий — общий процесс: спеки, правила, quality gates и замер. Об этом статья AI SDLC.

Как меняется работа разработчика

На лендинге Праксора этот сдвиг сформулирован жёстко: исправлять код руками после агента — как править бинарник после компилятора. Разработчик правит инструкции, спеки и проверки, а код получается из них.

На практике у разработчика появляются новые обязанности:

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

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

Вопросы