AI-агент не должен слишком быстро принимать цель

Сегодня я проверял в Codex запуск задачи через /goal.

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

У меня такой запуск занял примерно полчаса.

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

Это не тот случай, где агент сделал явную ерунду.

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

Вот этот класс ошибок меня сейчас интересует больше всего.

Не когда AI галлюцинирует на ровном месте. Не когда ломает obvious test. Не когда пишет странный код, который сразу видно.

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

Где на самом деле появляется цена

В AI-assisted работе часто обсуждают исполнение.

Какая модель лучше пишет код. Какой агент лучше ходит по repo. Кто быстрее запускает команды. Кто аккуратнее редактирует файлы.

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

Цена появилась до первого действия.

Не в моменте, где агент писал текст или код. А в моменте, где он принял цель без короткой сверки.

Для человека это выглядит мелко:

Формально все выглядит нормально. Был input, был output, была работа.

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

Почему это особенно неприятно

Обычная ошибка в результате часто видна быстро.

Не тот файл изменен. Тест упал. Формат сломан. Ссылка неправильная. Команда не запускается.

Ошибка в понимании цели опаснее.

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

Но человек потом понимает: работа была не про то.

Это создает неприятный тип review.

Ревьюер проверяет не только результат, а пытается восстановить, какую цель вообще выполняли. Если цель была понята не так, diff, краткий отчет и даже часть проверок становятся вторичными.

У команды возникает не review, а разбор смещения смысла.

Почему агентам легко туда попасть

У AI-агента есть сильный операционный перекос: он хочет превратить запрос в действие.

Для простых задач это хорошо. Если я прошу поправить опечатку, не нужно устраивать интервью.

Но для задач с бизнесовым или продуктовым смыслом быстрое согласие становится риском.

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

Агент в этот момент может выбрать один из возможных смыслов и не остановиться.

Не потому что он плохой.

Потому что у него нет обязательной точки сверки перед дорогим действием.

Маленькая сверка смысла

Я бы не превращал это в тяжелую бюрократию.

Если агент перед каждой мелкой правкой будет задавать десять вопросов, workflow умрет.

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

Минимальная версия:

Это не должен быть документ на страницу.

Иногда достаточно пяти строк.

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

Где я бы включал такую проверку

Не везде.

Я бы включал сверку смысла там, где ошибка понимания дороже самой операции:

1. Длинный запуск

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

2. Публичный текст

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

3. Изменение в продукте

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

4. Много контекста

Если цель опирается на прошлые обсуждения, голосовую расшифровку, несколько файлов или неявные договоренности, риск смещения выше.

5. Работа с внешними поверхностями

Публикация, профиль, README, лендинг, публичная документация, интеграция. Ошибка выходит наружу.

Где сверка смысла не нужна

Есть и обратная сторона.

Если задача маленькая, локальная и обратимая, лишняя сверка только тормозит.

Например:

В таких случаях лучше делать, а не спрашивать.

Проблема не в том, что агент редко задает вопросы.

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

Практическое правило для команды

Я бы формулировал так:

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

В пересказе важно не только что сделать, но и что не делать.

Плохая сверка смысла:

Я понял, надо улучшить статью.

Хорошая сверка смысла:

Я понял, что нужно написать vc.ru статью из личного кейса с /goal: не обзор Codex, не реклама инструмента, не теория про AI-агентов, а разбор ошибки, где цель была принята слишком быстро. Главный вывод: перед дорогим запуском нужна короткая сверка смысла. Не трогаю исходный пост и не утверждаю, что /goal новая команда, если это не подтверждено источником.

Вот это уже можно остановить до работы.

Или подтвердить.

Что не решает подход

Сверка смысла не делает AI-агента безопасным.

Он не заменяет ревью, тесты, доказательство, security review, нормальные права доступа и человеческую ответственность.

Он не гарантирует, что модель потом не ошибется.

Он решает более узкую задачу: снижает шанс, что агент быстро и аккуратно выполнит почти ту задачу.

Для меня это важная разница.

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

Итог

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

Что он сделал перед тем, как начать?

Пересказал цель?
Назвал границы?
Назвал то, что не входит в задачу?
Показал критерий готовности?
Остановился, если запрос был мутным?

Если нет, то агент может быть быстрым, аккуратным и все равно дорогим.

Потому что самая неприятная потеря времени возникает не там, где AI работает медленно.

А там, где он быстро принял не ту цель.

Где у вас такое уже было: человек или агент быстро взял задачу в работу, а потом оказалось, что смысл был другим?