Supergoal для Codex и Claude Code: зачем агенту видимая цель

Андрей Отинов -

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

Если убрать рекламную подачу, в сухом остатке остаётся полезная рабочая идея: AI-агент должен не просто писать код, а вести задачу как мини-проект с дорожной картой, контекстом, статусом и проверками. Это уже можно оценивать как метод внедрения, а не как очередной «суперскилл».

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

Что на самом деле обещает такой workflow

Публичное сообщение описывает инструмент вроде Supergoal, который якобы:

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

Если перевести это на язык разработки, речь идёт о structured agent loop: агент не действует в одном проходе, а строит управляемую траекторию работы. Для Claude Code и Codex это особенно важно, потому что сами по себе такие инструменты ценны не «автопилотом», а именно дисциплиной выполнения.

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

Почему это полезно именно в реальной разработке

Автономная генерация кода часто ломается на одном и том же:

  1. агент берёт слишком большой кусок работы;
  2. контекст расползается;
  3. меняются решения по ходу выполнения;
  4. тесты падают;
  5. исправления вносятся точечно, но причина ошибки не фиксируется;
  6. через пару шагов система снова повторяет тот же сбой.

Промежуточные артефакты — roadmap, current status, context — нужны не ради красоты. Они решают три операционные задачи:

  • делают работу проверяемой: видно, что именно агент собирался сделать;
  • снижают потерю контекста: следующий шаг опирается не на «память» модели, а на файл состояния;
  • позволяют управлять риском: человек может остановить задачу, если план ушёл не туда.

Для командной работы это особенно важно: если агент создаёт понятный след, его можно встроить в code review, CI и обычный release-процесс. Без такого следа автономный AI часто остаётся игрушкой для локального прототипирования.

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

Самую ценную часть сигнала можно описать как метод постановки задачи агенту:

  1. Сначала анализ проекта, потом действия. Агент должен понять стек, структуру и ограничения репозитория до правок.
  2. Сначала план, потом исполнение. Задача должна быть разложена на фазы, а не атакована целиком.
  3. Состояние фиксируется отдельно от кода. Полезно иметь документ или файл, где записаны:
  4. цель;
  5. текущий прогресс;
  6. принятые решения;
  7. ошибки и причины отката.
  8. Тесты и аудит встроены в цикл. Не как отдельный финальный ритуал, а как обязательная часть каждого этапа.
  9. Человек утверждает маршрут, но не микроменеджит шаги. Это компромисс между автономией и контролем.

Ниже — компактная таблица, чтобы понять, что даёт такой подход и когда он уместен.

Элемент workflow Что даёт Когда полезно Риск
Roadmap Видимая декомпозиция задачи Большие фичи, миграции, refactor Слишком детальный план может тормозить старт
Status file Понимание, где именно остановились Долгие сессии, асинхронная работа Если не обновляется, теряет смысл
Context file Стабильная память о решениях Многошаговые исправления, сложный стек Может устареть и ввести в заблуждение
Автотесты в цикле Быстрое обнаружение поломок Любые CI-процессы, критичный код Ложное чувство безопасности без хороших тестов
Финальный аудит Проверка на побочные эффекты Перед merge/release Если формален, пользы мало

Как внедрять такой подход без лишнего шума

Если смотреть прагматично, подобный workflow стоит внедрять не «во всей разработке сразу», а там, где он реально окупается:

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

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

  • плохие или отсутствующие тесты;
  • неявные архитектурные решения;
  • слишком большой контекст;
  • небезопасные права на запись в репозиторий;
  • отсутствие человеческой точки принятия решений.

Поэтому рабочая схема обычно такая:

  1. агент формирует план;
  2. человек быстро проверяет план на соответствие задаче;
  3. агент выполняет этап;
  4. после каждого этапа запускаются тесты;
  5. ошибки и откаты фиксируются в отдельном состоянии;
  6. только потом идёт следующий шаг.

Это не «автономный разработчик», а контролируемый исполнитель с хорошей памятью. И в этом качестве он уже может быть полезен.

Что проверить перед тем, как принимать решение об использовании

Перед внедрением такого workflow важно ответить на несколько практических вопросов.

  • Есть ли у проекта тесты, которые агент может запускать сам?
  • Понятно ли, где хранить roadmap, status и context?
  • Может ли команда быстро ревьюить план до выполнения?
  • Есть ли ограничения по безопасности и правам доступа?
  • Как фиксируются ошибки, которые агент уже «поймал»?
  • Кто отвечает за финальное решение: человек или автомат?

Если на эти вопросы нет ответов, то сам по себе «goal»-подход не даст дисциплины. Он просто ускорит хаотичную работу.

Короткий рабочий запрос для команды

Если вы хотите протестировать этот метод без большой перестройки процесса, дайте агенту такой формат задачи:

  • сначала: прочитать структуру репозитория и описать ограничения;
  • затем: предложить roadmap из 3–7 шагов;
  • после утверждения: выполнить только первый шаг;
  • после каждого шага: прогнать тесты и обновить status/context;
  • любые ошибки: записать с причиной и способом исправления;
  • перед merge: сделать краткий audit с перечислением изменённых файлов и рисков.

Этот формат лучше, чем просьба «сделай всё сам», потому что он оставляет место для контроля и снижает вероятность, что агент уйдёт в неверную архитектуру.

Источники

  • Публичный сигнал Telegram: https://t.me/forjournalonffru/2106
  • Claude Code — официальная страница продукта: https://www.anthropic.com/claude-code
  • OpenAI Codex — официальная информация: https://openai.com/codex/