Парное программирование с ИИ: как работать с агентом

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

В этом руководстве разберём, как распределить роли с агентом, когда позволить ему вести самостоятельно, а когда проверять каждый шаг, как с этим выбором сочетаются режимы одобрения в Claude Code, Codex и Gemini CLI, как держать шаги мелкими, а диффы читаемыми, как работать в паре, чтобы учиться, а не просто делегировать, и как позволить двум агентам работать в паре, пока вы прокладываете курс. Названия команд и режимов приведены по официальной документации на октябрь 2026 года.

Ведущий и штурман, когда на одном месте агент

В классической паре роли часто меняются. С агентом полезны две схемы.

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

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

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

Когда позволить вести, а когда проверять каждый шаг

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

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

Хорошая золотая середина для больших задач — сначала план. В Claude Code режим плана позволяет агенту читать и предлагать план, ничего не редактируя; вы проверяете план, исправляете его, затем переключаете режим и даёте выполнить. Подробно это разобрано в статье режим плана в Claude Code. Проверить план — минута; проверить неверную реализацию — гораздо дольше.

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

У каждого крупного CLI кодинг-агента есть настройка того, как часто он останавливается и спрашивает вас. Эта настройка — ваш стиль работы в паре, записанный в виде конфигурации.

Claude Code имеет режимы разрешений, на октябрь 2026 года:

• default: спрашивает перед правками файлов и перед командами, которые ещё не разрешены. Это проверка каждого шага.
• acceptEdits: правки файлов в рабочей папке, а также простые файловые команды вроде mkdir и mv принимаются без вопросов; для остальных команд он по-прежнему спрашивает.
• plan: читает и предлагает, но не редактирует.
• auto: фоновый классификатор проверяет каждое действие и блокирует рискованные, поэтому агент спрашивает реже. Доступность зависит от вашего плана и модели, а администраторы могут его отключить.
• bypassPermissions: никаких проверок. Документация рекомендует его только в изолированных средах, например в контейнерах или виртуальных машинах.

Нажимайте Shift+Tab, чтобы переключать режимы во время сессии, запускайте claude --permission-mode acceptEdits или задайте permissions.defaultMode в настройках. Когда вы отвечаете на запрос «Yes, and don’t ask again», правило сохраняется, и та же команда больше не спрашивает. Про рискованный конец шкалы рассказывает статья разрешения Claude Code.

Codex CLI сочетает песочницу с политикой одобрений. Его пресет по умолчанию Auto позволяет править файлы и запускать команды внутри рабочей папки и спрашивает, прежде чем выйти за её пределы (--sandbox workspace-write --ask-for-approval on-request). Используйте /permissions во время сессии, чтобы переключиться, например на Read Only, или запускайте с --sandbox read-only, когда нужно, чтобы он только смотрел.

Gemini CLI имеет --approval-mode со значениями default (спрашивать), auto_edit (принимать правки, спрашивать для остальных инструментов), plan (только чтение) и yolo (принимать всё).

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

Мелкие шаги

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

• Просите по одному шагу. «Добавь функцию валидации и её тесты, потом остановись» лучше, чем «сделай процесс регистрации».
• Говорите, когда остановиться. Агенты склонны переходить к следующему очевидному делу. «Остановись после этого и кратко опиши, что изменил» оставляет темп за вами.
• Коммитьте после каждого зелёного шага. Коммит на каждый шаг даёт чистую точку отмены и читаемую историю. git add -p позволяет проверить каждый фрагмент при добавлении.
• Используйте чекпоинты для промежуточного. В Claude Code /rewind (или двойное нажатие Esc) возвращает код и разговор к более раннему промпту. Изменения, сделанные shell-командами, он не отслеживает, поэтому настоящей страховкой остаётся git. Оба способа описаны в статье как отменить изменения Claude Code.

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

Проверка диффов

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

git status
git diff --stat
git diff

В Codex /diff показывает текущие изменения прямо в сессии. Любого агента можно попросить: «Покажи дифф того, что ты изменил, и объясни каждый фрагмент одной строкой».

На что смотреть, кроме того, работает ли код:

• Охват. Изменённые файлы, не имеющие отношения к задаче. Переименования, переформатирование и «небольшие чистки» прячут настоящие изменения.
• Удалённые или ослабленные тесты. Утверждение, подогнанное под новый вывод, или тест, помеченный как пропущенный, — тревожный сигнал.
• Заглушённые ошибки. Пустые блоки catch, приведения к any, отключённые правила линтера, флаги --force.
• Новые зависимости. Каждая — это код, который теперь поддерживаете вы.
• То, что вы не можете объяснить. Если не можете сказать, зачем здесь строка, спросите, прежде чем её принять.

Подробнее о проверке результатов агента на этапе pull request — в руководстве ИИ-ревью кода.

Учиться или делегировать

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

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

Когда вы хотите научиться, намеренно замедляйтесь:

• Просите план и объяснение до любого кода: «Объясни, как бы ты к этому подошёл и почему, код пока не пиши».
• Набирайте основную логику сами и просите агента её проверить.
• Спрашивайте «почему это, а не то?» о его решениях и просите показать альтернативу.
• Просите сначала написать падающий тест, а затем сделайте так, чтобы он прошёл, сами.

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

Пара из двух агентов: один пишет, другой проверяет

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

Простой вариант с двумя CLI в одном репозитории:

# Terminal 1: Claude Code implements the step
claude "Add rate limiting to the /login route. Stop when tests pass."

# Terminal 2: Codex reviews the uncommitted changes
codex review --uncommitted

codex review может также проверять относительно базовой ветки (--base main) или отдельного коммита (--commit <sha>), а внутри сессии то же делает /review. Передайте пишущему агенту замечания, с которыми согласны, и игнорируйте остальные: вывод ревьюера — совет для вас, а не приказ для другого агента.

Несколько правил помогают паре агентов работать:

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

Для больших задач та же схема масштабируется до нескольких авторов в отдельных worktree с одним ревьюером; об этом статья команды ИИ-агентов.

Как это сделать в AgentVera

AgentVera запускает Claude Code, Codex, Gemini CLI и других CLI-агентов бок о бок в одном окне, так что обе схемы работы в паре помещаются в один вид.

• Workspace. Поставьте пишущего и проверяющего агентов в соседние панели на одном проекте. У каждого агента своя настройка разрешений (Ask, Auto или Full access), так что автор может принимать правки, а ревьюер — только читать.
• Автоодобрение (Pro и Team, Claude Code). Чтение, git-команды только на чтение и команды тестов, линтера и сборки одобряются за вас, а рискованные команды вроде git push, rm или git reset --hard всегда приходят к вам. Это схема «пусть ведёт, но опасные части за мной» без нажатия на каждый запрос.
• Уведомления и одобрения. Когда агент ждёт вас, сочетание клавиш переносит прямо к тому, кто ждёт дольше всех.
• Чекпоинты. Каждый ход сохраняется, так что можно отменить один шаг сессии, не трогая историю git.
• Ревью кода. В конце хода выбранная вами модель Claude проверяет изменения и перечисляет замечания с уровнем серьёзности и file:line, а вы можете отправить их обратно агенту. Это встроенный второй агент на месте штурмана.
• Инбокс ревью. Готовая работа ждёт в виде карточек с изменёнными файлами, заметками о рисках и диффами, где вы одобряете её или отправляете обратно с комментарием.
• Обмен сообщениями между агентами. Агенты в одном проекте могут писать друг другу и делить общий список задач даже между разными CLI, так что автор может спросить ревьюера напрямую.

Подводим итоги

Парное программирование с ИИ работает, когда роли ясны. Решайте, кто ведёт, до каждой задачи. Выбирайте режим одобрения по риску, а не по настроению. Держите шаги мелкими и коммитьте после каждого зелёного. Читайте каждый дифф, прежде чем его принять. Осознанно выбирайте между делегированием и обучением. Когда нужно второе мнение, пусть второй агент проверит работу, а штурманом останетесь вы.

Если хотите потренироваться на длинной пошаговой задаче, хороший вариант — миграция с JavaScript на TypeScript с ИИ: каждый шаг мал, а компилятор сам скажет, когда работа готова.