Агентное программирование: что поручать ИИ и как проверять код

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

Описанное ниже поведение инструментов сверено с актуальной документацией разработчиков 24 октября 2026 года. Правила делегирования и пример с экспортом счетов — авторский разбор, а не результаты испытания продуктов.

Что такое агентное программирование?

При агентном программировании ИИ отвечает за последовательность действий по разработке и учитывает результат каждого шага при выборе следующего. Он изучает кодовую базу, планирует изменение, редактирует файлы, запускает команды и тесты, разбирает результаты и корректирует дальнейшие действия. Сеанс может завершиться, когда работа готова, агент достиг границы разрешений или ему понадобилось решение человека.

Anthropic описывает этот цикл как сбор контекста, действие и проверку. Ключевой момент — результат работы инструмента влияет на следующее решение: упавший тест даёт основание для новой правки. Сам по себе предложенный блок кода такого цикла не создаёт. Агентный цикл Claude Code.

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

Агенту нужна и программная обвязка, или harness: она окружает модель, предоставляет инструменты и управляет рабочим контекстом. Модель предлагает действия; обвязка выполняет разрешённые вызовы инструментов и возвращает результаты. Замена модели сама по себе не меняет правила доступа в среде.

Чем агент отличается от автодополнения и чата?

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

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

Агентное программирование и вайб-кодинг: в чём разница?

Агентное программирование описывает то, как действует инструмент. Вайб-кодингом обычно называют подход, при котором человек направляет создание программы главным образом через промпты и наблюдение за её поведением, иногда почти не изучая реализацию. На практике эти понятия пересекаются, но отвечают на разные вопросы.

Можно работать с агентом, проверяя каждое изменение и поддерживая строгие тесты. Можно принимать сгенерированный код почти без проверки. Для одноразового прототипа второй подход бывает осознанным компромиссом. Но если речь о данных клиентов или платежах, ответственность за продукт по-прежнему требует понимания реализации. Более широкий обзор конструкторов и инструментов разработки — в руководстве по инструментам для вайб-кодинга.

Что умеют ИИ-агенты для программирования?

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

Claude Code

Claude Code — агент для программирования от Anthropic — умеет искать по проекту, читать и редактировать файлы, запускать команды и тесты. В документации описан цикл, направление которого меняется по мере получения результатов от инструментов. Поэтому точечное исправление ошибки — естественная задача для такого агента: изучить сбой, изменить нужный код и проверить поведение. Документация Claude Code.

На практике работу ограничивает недостающий или забытый контекст. Anthropic указывает, что контекстное окно конечно, а в долгих сеансах контекст сжимается. Храните постоянные ограничения в инструкциях проекта и ограничивайте объём каждого изменения: длинный разговор плохо заменяет критерий приёмки. Подробнее об этом процессе — в наших рекомендациях по работе с Claude Code.

OpenAI Codex

OpenAI Codex — агент для программирования от OpenAI — предлагает интерфейс командной строки (CLI), через который можно изучать репозиторий, планировать изменения, редактировать файлы и запускать локальные команды разработки. В нём также есть отдельный режим ревью: для незакоммиченных изменений, коммита или сравнения с базовой веткой. Документация Codex CLI.

Практическое ограничение здесь — среда выполнения. Если проверке нужен недоступный сервис или заблокированное сетевое соединение, получить ожидаемое подтверждение не удастся. Отметьте результат как непроверенный, затем повторите проверку в подходящей среде. Выбору продукта посвящено сравнение Codex и Claude Code; настройки разрешений требуют отдельного решения.

Cursor Agent

Cursor Agent, агент для программирования в редакторе Cursor, умеет искать по кодовой базе, редактировать файлы и запускать команды терминала. Он подходит для интерактивной работы: вы направляете изменения и по ходу изучаете результат. Это документированные действия, а не гарантия того, что функция будет работать правильно. Обзор Cursor Agent.

Важно понимать, где проходят границы: обычные правки в рабочем пространстве сохраняются на диск без подтверждения, а изменения конфигурационных файлов защищены дополнительно. Cursor предупреждает, что приложение с автоматической перезагрузкой может выполнить изменённый код до вашего ревью. Подбирайте учётные данные и данные в среде разработки с учётом этого поведения. Безопасность Cursor Agent.

Агент для программирования GitHub Copilot

Агент для программирования GitHub Copilot, который в актуальной документации называется Copilot cloud agent, может изучать репозиторий, планировать изменения, редактировать файлы, запускать тесты и линтеры во временной облачной среде. Он умеет подготавливать ветки, коммиты и пул-реквесты. Это отдельный сценарий работы, отличный от подсказок в IDE или ревью уже существующего пул-реквеста с помощью Copilot. Copilot на GitHub.com.

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

Подробности о тарифах — в наших материалах о ценах на Claude Code, Codex, Cursor и GitHub Copilot.

Работа с агентом начинается с проверяемой спецификации

Хорошая спецификация объясняет агенту не только то, что нужно изменить, но и то, что должно остаться неизменным. В задаче «добавить экспорт CSV» слишком много важных решений остаётся открытыми. Агент может сделать работающую загрузку файла, но неверно реализовать правила доступа.

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

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

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

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

Разрешения и песочница ограничивают разные вещи

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

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

Проверьте фактические настройки каждого инструмента

Для Claude Code Anthropic описывает изоляцию файловой системы и сети для команд, запускаемых в песочнице, включая их дочерние процессы. В документации также есть механизм повторного запуска вне песочницы. Прежде чем считать эту границу обязательной, изучите такой способ выхода за её пределы, исключения для команд и поведение при невозможности запустить песочницу. Запрет на запись сам по себе не означает запрета на чтение конфиденциальных файлов. Песочница Claude Code.

В Codex CLI режим workspace-write с подтверждениями on-request разрешает работу внутри рабочего пространства; сетевой доступ для команд по умолчанию отключён, если его явно не включили. Политика подтверждений и режим песочницы настраиваются отдельно: отключение запросов на подтверждение само по себе не снимает ограничения песочницы. Политика сетевого доступа команд также сама по себе не регулирует веб-поиск, выполняемый на стороне сервиса, приложения и подключения MCP, через которые агент обращается к внешним инструментам и сервисам. Эти пути доступа нужно проверять отдельно. Подтверждения и безопасность Codex.

В Cursor Agent команды терминала по умолчанию требуют подтверждения, а настраиваемые режимы Run Modes описаны как защитные меры без строгой гарантии, а не как жёсткая граница безопасности. Это существенно, если вы планируете оставлять команды без присмотра. Помимо выполнения в терминале, учитывайте и приведённое выше предупреждение об автоматической перезагрузке приложения. Безопасность Cursor Agent.

Для GitHub Copilot cloud agent GitHub описывает ограниченные права на ветки, которые запрещают прямую отправку изменений в ветку по умолчанию. Также документированы межсетевой экран, включённый по умолчанию, и требование подтверждения от пользователя с правами записи перед запуском процессов Actions, вызванных пул-реквестами агента. Общие секреты Actions на уровне репозитория и организации агенту не передаются; секреты, специально добавленные в окружение copilot, передаются. Проверьте, что вы туда помещаете. Защитные меры, описанные GitHub.

Подбирайте ограничения под задачу

Для экспорта счетов агенту нужны исходный код, зависимости для разработки и синтетические записи счетов. Ему не должны требоваться реальные счета клиентов, учётные данные производственной базы или полномочия на развёртывание. Дайте минимальный доступ к ресурсам, который позволяет воспроизвести и проверить поведение.

Считайте текст в репозитории, загруженные страницы и содержимое задач потенциально недоверенными данными. Промпт-инъекция — это попытка перенаправить действия агента с помощью вредоносного содержимого. Инструкция, спрятанная в документе, не должна получать полномочия вашего задания. Разработчики инструментов отмечают этот риск в рекомендациях по безопасности; ограничение доступных ресурсов уменьшает возможные последствия. Модель безопасности Cursor.

Как проводить ревью: изучайте изменения и результаты проверок

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

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

Далее проверьте, не ослабил ли патч доказательную силу проверок: не удалены ли проверки условий, не стали ли тесты пропускаться, не расширилось ли использование моков, не изменены ли снимки или конфигурация CI. Набор тестов может стать зелёным как благодаря улучшению реализации, так и потому, что проверки стали менее требовательными. Что именно произошло, покажет diff.

Для первичного осмотра рабочей копии репозитория с незакоммиченными изменениями подойдут эти команды Git:

git status --short
git diff --stat
git diff --check
git diff
git diff --cached

git status также показывает неотслеживаемые файлы, содержимое которых нужно изучить отдельно. Эти команды не запускают тесты приложения. Если работа агента уже закоммичена, изучите полный diff пул-реквеста между базовой и конечной ревизиями и выполните предусмотренные в репозитории проверки в чистой среде.

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

Drew Breunig в статье «10 уроков агентного программирования» выступает за тестирование поведения продукта, документирование замысла и развитие спецификаций вместе с реализацией. В нашем примере неизменной должна оставаться проверка того, что клиент не может выгрузить чужие счета. Конкретная вспомогательная функция, обеспечивающая это правило, может меняться.

Автоматическое ревью способно дать дополнительные замечания, но человек, принимающий изменения, должен понимать ключевую цепочку их работы. GitHub прямо предупреждает: ревью с помощью ИИ может пропустить проблему или дать ложное срабатывание. Ответственность за поведение, важное для безопасности, и за сопровождаемость кода должна оставаться у человека-ревьюера. Ограничения ревью, описанные GitHub.

Кому стоит делегировать больше, а кому — подождать?

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

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

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

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

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

Где подход даёт сбой и какие ожидания завышены?

Цикл перестаёт работать, когда обратная связь не позволяет отличить правильное решение от правдоподобного. Зелёная проверка может подтверждать форматирование, ничего не говоря об изоляции данных разных клиентов. Успешный тест с моками может не охватывать интеграцию, которой пользуются клиенты. Убедительный отчёт может умолчать о команде, завершившейся ошибкой.

Ещё одно ограничение — контекст. Агент может видеть нужную функцию, но не знать, зачем в ней существует необычное ограничение. Храните важные решения рядом с соответствующим кодом, указывайте, какая спецификация служит источником истины, и просите явно сообщать о неопределённости. В документации Anthropic описано, как долгие сеансы работают с конечным контекстом; не рассчитывайте, что инструкция из начала разговора будет одинаково заметна на всём протяжении большого изменения. Как работает Claude Code.

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

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

Чего не доказывают бенчмарки агентов для программирования?

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

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

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

Частые вопросы

С чего начать в понедельник?

Выберите из бэклога одну небольшую задачу с воспроизводимым поведением и назначьте ревьюера до запуска агента. Запишите критерии приёмки, предоставьте изолированную рабочую среду и исключите доступ к учётным данным продакшена. Запросите патч вместе с результатами проверок, по которым можно оценить работу.

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

За практическими заметками о разработке с ИИ подписывайтесь на рассылку.