Реализация в Codex - это управляемое движение по slice'ам, а не один большой прыжок к финалу. После одобрения плана агенту дают право выполнить только следующий логический срез работы, а не всё сразу. Если задача длинная, milestone полезнее обещания "сделать всё": маленький проверяемый шаг оставляет вам точку контроля и не даёт накопиться большому непонятному изменению. Дисциплина срезов - это то, что отличает управляемую реализацию от потока правок, за которым остаётся только наблюдать.
Право прерывать turn - ключевой инструмент, и им не стоит пренебрегать. Если агент ушёл в несвязанный рефакторинг, запускает слишком широкую команду или повторяет одну и ту же неудачу без новой гипотезы - его останавливают, не дожидаясь конца. Новая короткая инструкция в том же чате почти всегда дешевле, чем поздний откат большого неверного изменения. Ждать, пока агент "сам разберётся", когда он явно буксует, - значит платить токенами и временем за то, что можно прекратить одной фразой.
Прерывание формулируют конкретно, а не эмоционально. Хорошая остановка звучит так: остановись, больше файлы не меняй, покажи текущий git diff и объясни, какие строки нужны для исходной цели, а какие нет. Отдельно просят отделить ваши прежние изменения от изменений агента. Такая формулировка не просто тормозит агента, а возвращает его к цели и делает видимым, что именно уже сделано и насколько это соответствует задаче.
У просмотра diff есть тонкость, которую надо помнить. /diff показывает состояние git, а не гарантированно только изменения последнего turn. Это значит, что в него попадают и ваши прежние правки, и всё, что накопилось в рабочем дереве, а не только то, что агент сделал в последнем шаге. Если нужна именно граница последнего turn, в desktop-приложении для этого есть режим Last turn. Путать состояние git с изменениями одного шага - частый источник неверной оценки того, что произошло.
Полезно один раз увидеть формулировку прерывания как готовый инструмент. Ниже - короткий stop-запрос, который возвращает агента к цели и разделяет источники изменений. К этой форме возвращаются каждый раз, когда turn пошёл не туда: она дешевле, чем дать агенту закончить неверный путь и потом всё откатывать. Управление реализацией - это в первую очередь умение вовремя остановить, а не только умение точно поставить задачу.
Узкие проверки по ходу важнее одного большого прогона в конце. После каждого значимого среза запускают targeted-сигнал - тот самый тест или команду, что доказывает конкретное изменение, - а не весь suite на каждый шаг. Широкий прогон на каждом шаге и медленнее, и размывает сигнал: непонятно, что именно починилось. Узкая проверка по ходу и общий прогон в конце - правильный порядок, тот же, что и в ручной работе над багом.
Steer, interrupt, inspect, verify - это не отдельные приёмы, а один цикл управления. Вы направляете агента к следующему срезу, прерываете, если он ушёл в сторону, инспектируете diff, отделяя своё от чужого, и запускаете узкую проверку, прежде чем расширять. На каждом обороте у вас остаётся контроль над тем, что именно уходит в изменение. Реализация без этого цикла превращается в накопление правок, которое дороже разобрать, чем сделать заново.
Типичные провалы реализации предсказуемы. Дать агенту "сделать всё" вместо следующего среза и получить большое непонятное изменение. Не прерывать явно буксующий turn и платить за это откатом. Спутать состояние git с изменениями последнего turn при просмотре diff. И гонять весь suite на каждый шаг вместо узкого сигнала. Ведите реализацию срезами, прерывайте вовремя, инспектируйте diff осознанно и проверяйте узко по ходу - тогда движение к результату остаётся управляемым.
# Прерывание, возвращающее агента к цели
Остановись. Не меняй больше файлы.
Покажи текущий git diff и объясни, какие строки нужны для исходной цели.
Отдели мои прежние изменения от своих.
# /diff показывает состояние git, а не только изменения последнего turn