Ключ к разумной работе с Codex - понять, что это не автокомплит с длинным ответом, а замкнутый цикл. На каждом шаге агент интерпретирует цель, читает доступный контекст, выбирает инструмент, наблюдает результат и решает, что делать дальше. Модель не знает репозиторий заранее и не получает автоматически каждый файл - она видит только то, что реально прочитано инструментом. Понимание этого цикла важнее любых трюков формулировки: оно объясняет, почему агент иногда уверенно ошибается.
Отсюда первое правило: доверять нужно не уверенности формулировки, а evidence из инструментов. Фраза "похоже, используется Vitest" - это догадка; доказательство - найденный package.json, config и конкретная команда. Модель может звучать одинаково убедительно и когда она права, и когда домысливает, поэтому её вывод оценивают по приложенным фактам, а не по тону. Это различие - основа всего остального в книге.
Полезно один раз свести уровни доказательства в таблицу, чтобы отличать слабое утверждение от проверяемого. Ниже - четыре уровня: обнаружение, изменение, проверка и поведение. Каждому соответствует своё evidence: найденная команда, точный diff, exit code с выводом теста, воспроизведение в браузере. К этой карте возвращаются, оценивая любой итог агента: она показывает, на каком уровне доказательства он остановился и где вам ещё нужно перепроверить.
Уровни выстраиваются от дешёвого к дорогому, и это не случайно. Обнаружение подтверждается прочитанным файлом, изменение - точным diff и списком затронутых файлов, проверка - exit code и релевантным выводом теста, typecheck или lint. Самый сильный уровень - поведение: приложение собрано, запущено, и результат виден через browser- или E2E-воспроизведение либо явно описан как непроверенная граница. Пропускать уровни - значит принимать объяснение за доказательство.
| Уровень | Слабое утверждение | Нужное evidence |
|---|---|---|
| 1. Обнаружение | "Похоже, используется Vitest" | package.json, config и найденная команда |
| 2. Изменение | "Файл исправлен" | Точный diff и список затронутых файлов |
| 3. Проверка | "Должно работать" | Exit code и вывод test/typecheck/lint |
| 4. Поведение | "UI исправлен" | Browser/E2E-воспроизведение или явно непроверенная граница |
|---|
Второе фундаментальное различие - права инструментов не равны правам shell. Sandbox ограничивает именно порождённые команды: что shell может прочитать, записать или отправить в сеть. Но apps, MCP, browser, computer use и cloud имеют собственные дополнительные контроли поверх этого. Это разные плоскости доступа, и держать их отдельно необходимо, чтобы не объяснять поведение не той причиной.
Из этого следует неочевидное, но важное правило. Одобрение одного side-effecting вызова коннектора не расширяет filesystem sandbox: разрешив агенту сделать действие через MCP или app, вы не выдали ему заодно доступ к файлам за пределами writable roots. Границы складываются, а не переносятся с одного механизма на другой. Путаница здесь опасна: человек думает, что "уже всё разрешил", хотя на самом деле открыл только один узкий канал.
Практический вывод для запросов прямой: утверждение "Codex понял проект" подтверждают доказательствами, а не принимают на веру. Хороший итог называет причину, изменённые файлы, команды с кодами возврата, что проверено наблюдением и что осталось непроверенным. Такой отчёт превращает расплывчатое "готово" в проверяемое утверждение и сразу показывает, на каком уровне доказательства агент остановился - а значит, где именно ваше внимание нужнее всего.
Типичные провалы вокруг цикла предсказуемы. Принять уверенную формулировку за факт, не спросив evidence. Остановиться на статической проверке там, где нужно было наблюдение поведения. И спутать плоскости доступа, решив, что одобренный вызов коннектора расширил файловый sandbox. Требуйте доказательство под уровень риска, различайте права инструментов и права shell - и цикл станет управляемым, а не потоком уверенных, но непроверенных утверждений.