Как дать вашему ИИ-агенту для программирования цикл обратной связи, который ловит его собственные ошибки

Когда ИИ-агент для программирования пишет код, который выглядит правильным, но тихо что-то ломает, проблема обычно не в модели — а в том, что агент так и не увидел сбой. Он внёс изменение, объявил победу и пошёл дальше, потому что ничто не сообщило ему, что набор тестов теперь стал красным. Решение — замкнуть цикл: сделать так, чтобы собственные инструменты агента автоматически отчитывались ему обратно.

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

Главная идея: ошибки должны возвращаться в контекст

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

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

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

Вариант 1: Просто попросите в конфигурации проекта

Самая малозатратная версия — это строка в вашем CLAUDE.md или AGENTS.md (текстовом файле инструкций, который большинство агентов читают при запуске):

## Verification
After any code change, run `npm run typecheck && npm test`.
If either fails, fix the cause and re-run before reporting done.

Это работает на удивление хорошо — но носит рекомендательный характер. Занятый агент может забыть или решить, что изменение «слишком мелкое» для проверки. Для всего, что вам важно, сделайте проверку детерминированной.

Вариант 2: Автоматизируйте с помощью хука

Хуки Claude Code позволяют запускать shell-команду в ответ на события жизненного цикла, независимо от того, вспомнит ли об этом модель. Здесь нас интересует PostToolUse, который срабатывает после того, как агент редактирует файл. Как формулирует одно практическое руководство по хукам, PostToolUse создан для реакций — форматирования, логирования, запуска тестов — и его вывод внедряется обратно в контекст агента, чтобы повлиять на его следующий шаг.

Вот минимальный хук, который запускает вашу проверку типов после любого редактирования файла и передаёт сбои обратно агенту. В .claude/settings.json:

{
  "hooks": {
    "PostToolUse": [
      {
        "matcher": "Edit|Write",
        "hooks": [
          {
            "type": "command",
            "command": "npm run typecheck"
          }
        ]
      }
    ]
  }
}

Теперь цикл становится автоматическим: агент пишет код → хук запускает tsc → если есть ошибка типа, сообщение возвращается в виде контекста → агент исправляет её → хук запускается снова. Справочник по хукам описывает, как ненулевой код выхода и вывод доводятся до модели. Этот цикл выполняется при каждой записи, без всяких подсказок.

Держите цикл быстрым и узконаправленным

Цикл обратной связи помогает только если он быстрый. Несколько практических правил:

• Запускайте дешёвые проверки при каждом редактировании, дорогие — реже. Проверка типов или линтер на изменённом файле выполняются быстро. Полный набор интеграционных тестов — нет; вынесите его за хук Stop (когда агент завершает ход) или ручную команду, а не за каждое нажатие клавиши.
• Ограничивайтесь тем, что изменилось. Запуск всего набора тестов после однострочной правки CSS тратит время и затопляет контекст. Где позволяет ваш инструментарий, нацеливайтесь на затронутые файлы.
• Делайте сбои читаемыми. Агент исправляет только то, что может прочитать. Линтеры и проверки типов с ясными, локализованными сообщениями об ошибках (file:line: message) дают модели ровно то, что ей нужно; обобщённое «build failed» — нет.

Конкретное «до и после»

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

С циклом: то же переименование запускает typecheck при сохранении. tsc сообщает Cannot find name 'oldFn' в пропущенном месте вызова. Эта ошибка попадает в контекст, агент открывает четвёртый файл, исправляет ссылку, и следующая проверка проходит — всё это до того, как он сообщит вам, что закончил.

Главный вывод

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