Руководство

Ночной процесс для агентов программирования

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

Пишите задачи как для нового подрядчика

Ночью задаче некого спросить. Она должна нести весь контекст в себе. Каждая задача должна умещаться в абзац и отвечать на три вопроса. Что сломано или чего не хватает. Как выглядит готовый результат. Как это доказать.

## Task: paginate the /orders endpoint
Problem: GET /orders returns every order. Large accounts time out.
Done: accepts ?cursor and ?limit (max 100), returns next_cursor.
Proof: new tests in tests/orders_pagination.test.ts pass; existing tests pass.
Do not: change the response shape of existing fields.

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

Одна задача, одна ветка, один worktree

Задачи не должны делить рабочее дерево. Две задачи, которые правят один checkout, дают diff, который никто не распутает. Git worktree даёт каждой задаче собственную папку в том же репозитории.

git worktree add ../work/orders-pagination -b agent/orders-pagination
git worktree add ../work/retry-webhooks -b agent/retry-webhooks

Для каждой ветки свой запуск агента и свой pull request. Утром вы проверяете их по одному. Если один плохой, вы его закрываете, а остальные остаются нетронутыми.

Решите, что агент делает сам

Задайте режим разрешений и список deny до первого запуска, а не после. Точные настройки есть в руководстве по запуску Claude Code без присмотра. Для ночной работы коротко так. Свободно править файлы. Свободно запускать тесты. Свободно коммитить и пушить ветку задачи. Открыть pull request. Ничего другого без вопроса и ничего за пределами репозитория.

Цикл запуска

Небольшой скрипт запускает по одному запуску без интерфейса на задачу, в её worktree, с лимитом ходов и файлом журнала. Вот он целиком.

#!/bin/sh
# run-overnight.sh: one agent run per task file in tasks/
for task in tasks/*.md; do
  name=$(basename "$task" .md)
  dir="../work/$name"
  git worktree add "$dir" -b "agent/$name" 2>/dev/null
  (
    cd "$dir" || exit 1
    claude -p "Complete the task in $task. Commit on this branch, push it, and open a pull request with gh pr create. Stop when the tests pass or when you are blocked, and say which." \
      --permission-mode acceptEdits \
      --max-turns 80 \
      > "../logs/$name.log" 2>&1
  )
done

Запускайте его внутри tmux, чтобы SSH-соединение не имело значения. Задачи идут одна за другой. Параллельный запуск возможен, но тогда задачи конкурируют за CPU и за ваш лимит запросов. И журналы становится труднее читать. Начните с последовательного.

Пусть судьёй будут тесты

Промпт велит агенту остановиться, когда тесты пройдут. Затем ваш CI прогоняет те же тесты на pull request. Если агент заявил, что всё зелёное, а CI показывает красное, вы узнаете это до того, как прочитаете хоть строку diff. Защитите main, чтобы без этой проверки ничего не сливалось. Это самая ценная защита во всём процессе, и она ничего не стоит.

Утренний разбор за десять минут

  • Откройте список pull request. Сверьте их количество со списком задач. Пропавшие ищите в журналах.
  • Прочитайте журнал каждой задачи, которая остановилась как заблокированная. Обычно не хватает учётных данных или задача сформулирована неоднозначно. Исправляйте текст задачи, а не агента.
  • Проверяйте зелёные pull request, начиная с самых маленьких. Сливайте правильные. Неправильные закрывайте с одной строкой о причине. Скопируйте эту строку в файл задач на завтра.
  • Удалите слитые worktree и ветки, чтобы следующая ночь началась с чистого листа.
git worktree remove ../work/orders-pagination
git branch -d agent/orders-pagination

Что отдать в первую очередь

Некоторая работа подходит для ночи лучше другой. Начните с этого и расширяйте список по мере роста доверия.

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

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

Машина под всем этим

Всё это предполагает машину, которая работает и в 4 утра. Ноутбук, который засыпает, это самая частая причина, по которой ночной запуск ничего не дал. Руководство про сон решает это на вашем собственном Mac. На размещённом Mac для агентов это уже решено.

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

Сколько задач агент успевает сделать за ночь?

+

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

Стоит ли запускать Claude Code и Codex на одном бэклоге?

+

Только не на одних и тех же задачах. Дайте каждому свои задачи и свои worktree. Если запустить обоих на одной задаче, получатся два конкурирующих pull request и вдвое больше проверки.

Что делать, если агент открыл pull request, который меняет гораздо больше, чем задача?

+

Закройте его и добавьте в задачу строку Do not. Расползание объёма это самый частый ночной сбой, и лечится он текстом задачи. Жёсткий лимит ходов тоже помогает.

Может ли агент сам сливать свои pull request?

+

Может, но не должен. Защитите main и требуйте проверки человеком. Весь смысл процесса в том, что утром вы проверяете работу на свежую голову.

Похожие руководства