Claude Code /goal зациклился: 7 типов задач где автономный режим сжигает токены

Команда /goal обещает закрыть задачу без участия. На 7 типах задач она уходит в петлю и сжигает токены, не двигаясь к финалу. Разбираю где и что делать.

Это было ночью на прошлой неделе. Я задал Claude Code одну цель и пошёл спать. Уверенно. Условие звучало нормально: «сделай интерфейс настроек удобнее». Утром открыл терминал и увидел 217 ходов, нулевой коммит и счётчик токенов, который съел больше двух третей моего недельного лимита на Max-плане. Агент всю ночь крутил один и тот же компонент: менял отступы и откатывал, потом шрифт и снова откатывал. Оценщик на каждом ходу говорил «ещё не удобно».

В тот момент я понял три вещи. Первое: /goal работает не везде где работает обычный Claude Code. Второе: список «где не работает» Anthropic в документации описывает на одной строке: «расплывчатые цели не подходят». Третье: за месяц использования у меня собралось 7 конкретных типов задач, на которых режим стабильно зацикливается. Не один-два, а семь.

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

Команда /goal появилась в Claude Code 2.1.139 одиннадцатого мая 2026 и в Codex CLI стабильно с 21 мая. Идея простая: ты задаёшь критерий «готово», агент сам циклит план-действие-проверка, пока критерий не закрыт. После каждого хода маленькая модель (по умолчанию Haiku в Claude и тот же агент в Codex) проверяет условие. Если «нет» - следующий ход без твоего «продолжай». Полный разбор настройки и сравнения двух инструментов есть в гайде про автономный режим Claude Code и Codex.

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

Это нормально работает, когда «готово» - это запускаемая команда. pytest tests/ либо отдаёт exit 0, либо красные тесты в выводе. У mypy strict ровно две концовки: ноль ошибок или конкретный список. npm run build собирает бандл за известное время или падает на конкретной строке. Тут текст переписки и реальный мир сходятся, потому что в переписке агент пишет вывод реальной команды.

Это разваливается, когда «готово» - это субъективная оценка. «Удобно», «чисто», «безопасно», «надёжно». Оценщик не может сверить такие критерии ни с чем, кроме собственного мнения. У основной модели тоже нет якоря. Обе пишут текст, читают текст, не двигаются.

Шаблон правильного критерия выглядит так:

Шаблон, который сжигает токены вхолостую:

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

Это самая частая ловушка и самая дорогая. Я ловлю себя на ней раз в неделю.

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

Почему это убивает /goal. Оценщик прочитает текст переписки и спросит себя: «удобнее ли стало?» Если основная модель написала «я поменял отступы и теперь интерфейс выглядит лучше», судья пожмёт плечами и скажет «не вижу скриншота, не могу подтвердить». Если написала «теперь однозначно удобнее», судья ответит «по чьему мнению?». Цикл уходит в бесконечность, потому что в текстовой переписке нельзя проверить, удобно ли что-то конкретному пользователю.

В моём ночном прогоне на 217 ходов основная модель меняла одни и те же отступы туда-обратно, и каждый раз писала «теперь точно удобнее». Оценщик каждый раз сомневался. Ходы шли, токены утекали, скриншот никто не делал, потому что Claude в режиме без MCP не умеет смотреть на собственный интерфейс глазами.

Как переформулировать. Вместо «сделай удобнее» - конкретная команда с измеримым выходом:

Это уже три проверяемые команды. Оценщик читает вывод axe-core в переписке, видит «0 violations», подтверждает. Lighthouse показывает 95, подтверждает. Цель закрывается за известное число ходов с известным расходом.

Если хочется субъективной части - оставь её на финальный ручной проход. Агент закрывает измеримое, ты дочищаешь эстетику глазами 15 минут. Это разделение даёт самый высокий КПД.

Связана с предыдущей, но отдельный класс с другой механикой провала.

Сценарий: всё то же самое, только теперь у тебя есть юнит-тесты компонента, но нет e2e. Ты пишешь /goal с условием «vitest проходит и UI выглядит чисто».

Что происходит. Vitest действительно может пройти. Юнит-тесты проверяют render и события. Они не проверяют, что компонент влезает в экран на 360 пикселях, не накладывается на меню, не выходит за safe-area на iPhone. Эта часть «выглядит чисто» опять висит в воздухе.

В одном из прогонов на моей машине агент дотягивал vitest до зелёного, потом ходил по styles.scss и писал случайные значения. Оценщик соглашался «vitest проходит», но цеплялся за вторую часть условия, и Claude крутил css ещё час, пока я не вернулся.

Как переформулировать. Если e2e нет - вынеси визуальную часть из /goal в отдельный шаг. Если e2e есть - условие должно опираться на Playwright или Cypress, а не на vitest плюс прилагательное:

Третья строка - ловушка против самой частой деградации /goal: агент по дороге трогает чужие файлы и портит соседние компоненты. Якорь на git diff не даёт ему уехать.

Тут /goal сломан не на уровне петли, а на уровне риска. Зацикливания может не быть, и в этом весь обман.

Сценарий: ты делаешь миграцию таблицы users. Хочешь добавить колонку plan_tier, залить значения из subscriptions, удалить старое поле legacy_plan. Условие «миграция применена, тесты зелёные, на проде нет ошибок».

Что бывает. Codex с /goal действительно может это сделать. И это самый страшный режим из всех, потому что он сделает быстро, рапортует «зелёные», и ты только спустя сутки увидишь, что у 0.3% пользователей теперь plan_tier равен NULL, потому что в subscriptions у них хранился старый формат.

История из публичного разбора Pydantic v1 → v2: Codex закрыл миграцию за 31 час, потратил $44 на токены, оставил одну регрессию в проде, которую поймали через сутки. Это 95% работы, что прекрасно. Но финальные 5% всегда ждут глаз человека. На продовой БД эти 5% - это потеря данных или денег пользователей.

Что делать вместо /goal на проде. Я разделяю на два шага:

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

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

Сценарий: ты переписываешь обработку JWT, добавляешь refresh-токены, чистишь хранение секретов. Условие звучит логично: «все тесты auth-сервиса проходят, eslint без ошибок, security-audit чистый».

Что не сработает. Тесты могут быть зелёными, и при этом ты получил рабочий вход через старый ключ, который агент забыл удалить из переменных окружения. Eslint не ловит логические дыры в авторизации. Security-audit (npm audit или аналог) проверяет зависимости, а не твою архитектуру. Все три критерия проходят - дыра остаётся.

Платежи - частный случай. Если /goal трогает функцию confirmPayment, и у тебя нет мокированного Stripe-окружения, агент будет вызывать тестовый Stripe-аккаунт реально. Каждый retry стоит токенов плюс может оставить грязные тестовые транзакции, которые потом разгребать руками.

Что делать. Безопасность и платежи остаются ручным режимом. Claude Code без /goal помогает писать, человек ревьюит каждый коммит, в проде ничего не катится без второго ревьюера. Anthropic это формулирует прямо в документации Codex: «пути по безопасности требуют ручного одобрения».

Это скучно, но альтернатива - история, которую потом разбирают на конференциях.

Здесь ломается не критерий, а экономика.

Сценарий: твой код стучится в публичный API - Notion, Linear, Google Calendar, любую внешку. Ты просишь Claude /goal довести интеграцию до зелёных интеграционных тестов.

Что происходит. Каждый прогон тестов делает реальные запросы. Если внешний API ответил 503 (а это случается чаще, чем хочется), Claude видит ошибку, не понимает, что она снаружи, начинает чинить свой код. Меняет один параметр запроса, повторяет, снова 503. Ходит десять раз. Токены утекают. В переписке нарастает мусор. Контекст пухнет, у Claude после 6.7M токенов срабатывает компрессия, часть памяти теряется.

В одном из тред-разборов Codex /goal на форуме разработчик описал ночной прогон, который сжёг $187 токенов, потому что Stripe-sandbox два часа отдавал 502. Агент два часа исправно крутил собственный код.

Как делать правильно. Перед /goal обязательны заглушки. Я держу vitest --mocks или nock для node-сервисов, msw для фронтенда. Условие тогда звучит честно:

Заглушки делают петлю детерминированной. Без них /goal - это азартная игра с чужим uptime.

Я долго не хотел добавлять этот класс в список. Кажется, что «зарефакторь хук под одну единственную ответственность» - проверяемое условие. На практике нет.

Сценарий: у тебя жирный хук useDashboard на 400 строк. Он делает фетч данных, фильтрацию, агрегацию, форматирование, обработку кликов. Ты просишь /goal «разбить на 4-5 хуков с одной ответственностью каждый».

Почему /goal не справится. Слово «одна ответственность» - это снова субъективная оценка. Что считать одной ответственностью? Это и есть инженерное решение, которое делает человек. Агент в режиме оценщика будет крутить разбиения: то 4 хука, то 6, то 3 с подсосом друг друга. Каждое разбиение «выглядит логично» в переписке, но в кодовой базе превращается в новую кашу.

В моём прогоне это занимало 40-50 ходов и заканчивалось декомпозицией, которую я потом возвращал к одному хуку обратно. Чистая трата токенов.

Что работает. Рефакторинг под измеримый показатель: «функция X разбита так, чтобы цикломатическая сложность каждой ветки была меньше 10 (по complexity из ESLint)». Это команда, она запускается, выводит цифру, оценщик видит ответ.

Если же ты хочешь «по уму», без числа - делай руками. Декомпозицию архитектуры /goal делать не умеет, и это нормально.

Самая обманчивая категория. Кажется, что «найди баги в этом PR» - идеальная задача для автономного режима.

Сценарий: ты получил большой пул-реквест от коллеги. Хочешь, чтобы Claude /goal прочитал, прогнал тесты, проверил безопасность, описал риски, дал вердикт «можно мержить» или «нет».

Что ломается. Условие «найди все потенциальные проблемы» не имеет finish-state. Оценщик не может сказать «все нашли», потому что не знает, сколько проблем заложено. Агент пишет 5 замечаний, оценщик соглашается «возможно есть ещё», агент пишет 10, потом 20, потом начинает выдумывать сомнительные «code smells». Качество вердиктов падает с каждым ходом, токены тратятся.

В тред-разборе на форуме Anthropic один из инженеров описал прогон, где Claude за час сгенерировал 84 ремарки к ПР из 200 строк. Сорок из них были ложными тревогами. Это меньше пользы, чем 5 точных, которые человек нашёл бы за 20 минут.

Что делать. Код-ревью лучше делать в интерактивном режиме без /goal. Один проход агента, один проход твоих глаз. Если хочется автоматизации - вынеси проверки в pre-commit hooks с конкретными чек-листами (eslint, типы, размер диффа). Это даст 70% пользы от ревью без бесконечного цикла оценщика.

Прогон по этому списку занимает 90 секунд и экономит часы.

Когда все семь зелёные, /goal даёт огромный выигрыш. Когда хоть один красный, обычный режим Claude Code часто дешевле.

Признак петли: 3-4 хода подряд агент трогает одни и те же файлы и возвращается к предыдущему состоянию. Расход токенов на ход растёт, прогресса в коде нет. Условие выглядит выполненным глазами, оценщик пишет «не выполнено».

Что делать сразу:

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

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

До тех пор /goal остаётся инструментом, который удваивает скорость в верхнем квартиле задач и потенциально съедает твой недельный лимит в нижнем. Граница между квартилями - не в сложности кода, а в формулировке критерия. Если ты её научился чувствовать, /goal работает. Если нет - один сэкономленный час оборачивается ночью без коммитов.

На каком из 7 типов задач ты уже наступил? У меня - на первом и пятом, по разу каждый. Поделитесь в комментариях, на чём ловил /goal вас, и какое условие в итоге сработало вместо размытого.