Как работать с Codex в репозитории: контекст, ограничения и проверки

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

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

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

Задача для Codex должна задавать не только результат, но и границы работы. Удобно проверять ее по четырем этапам.

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

Лучше начинать с задач с понятным scope. Например: один баг, один компонент, один parser, один набор тестов, одна страница документации. Так проще проверить, что агент действительно понял проект и не ушел в лишние изменения.

Не стоит просить Codex «улучшить архитектуру», «переписать модуль» или «разобраться во всем проекте» без границ. Такие задачи сначала нужно разложить на цель, область изменений, ограничения, критерии приемки и проверки. Для опасных действий, миграций, удаления данных, смены зависимостей и security-sensitive кода нужен план до правок и отдельное подтверждение.

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

• Ветка или рабочее состояние. Убедитесь, что понятно, где можно менять файлы и какие текущие изменения нельзя трогать.
• Инструкции проекта. Укажите, где лежат правила: AGENTS.md, README, CONTRIBUTING, архитектурные заметки, соглашения по тестам и стилю.
• Область изменений. Назовите файлы, директории, модуль, feature area или issue, с которым нужно работать.
• Ограничения. Прямо напишите, что нельзя менять: публичный API, миграции, зависимости, формат данных, чужие незакоммиченные изменения, конкретные директории.
• Проверки. Дайте команды или ожидаемый минимальный набор: tests, typecheck, lint, build, visual check, security/privacy review.

Если проект большой, сначала попросите Codex прочитать relevant files и вернуть короткий план. Это снижает риск, что агент начнет писать код до понимания локальных соглашений.

Хороший запрос к Codex обычно состоит из пяти частей:

1. Цель. Что должно измениться для пользователя, системы или команды.
2. Контекст. Где в репозитории искать код и какие документы считать источником правды.
3. Границы. Что можно менять, что нельзя менять и когда нужно остановиться.
4. Ожидаемый diff. Какие типы файлов могут измениться: код, тесты, fixture, документация, конфиг.
5. Критерий готовности. Какие проверки должны пройти и что нужно написать в финальном ответе.

Пример короткой формулировки:

Найди, где разбирается HTML письма в модуле импорта. Сначала проверь существующие зависимости и helpers для MIME/HTML parsing. Не пиши ручной parser без обоснования. Добавь тест на реальный пример письма, запусти релевантную проверку и в конце перечисли измененные файлы, проверки и оставшиеся риски.

Такой prompt задает Codex маршрут: сначала понять код и доступные инструменты, потом менять минимальный участок, затем проверить результат.

Если задача ставится не AI-агенту, а разработчику или подрядчику, действуют те же базовые принципы. Смотрите общие правила постановки задач разработчикам: результат, границы, out of scope, проверяемые критерии приемки задачи и проверка.

Проверки зависят от проекта, но для задач в репозитории полезно явно просить один или несколько видов контроля:

• Tests. Unit, integration, regression или nearest relevant test, который подтверждает изменение.
• Typecheck. Проверка типов для TypeScript, Python typing или другого typed-контура.
• Lint. Проверка стиля, import order, форматирования и локальных правил.
• Build. Сборка приложения, пакета, документации или отдельного affected module.
• Visual check. Скриншоты или браузерная проверка для UI-изменений.
• Security/privacy review. Отдельный проход по доступам, секретам, персональным данным, сетевым вызовам и логированию.

Если проверку нельзя выполнить в текущей среде, Codex должен сказать это прямо: какая команда недоступна, почему и чем он заменил проверку. Молчаливое «готово» без проверки для кодовой задачи лучше не принимать.

Самая частая ошибка — слишком общий prompt. Фраза «сделай нормально» не задает Codex ни scope, ни критерий качества, ни способ проверки. В результате агент может сделать большую правку, которую трудно принять.

Вторая ошибка — просить ручную реализацию для сложного известного формата. HTML, MIME/email, XML, YAML, CSV, PDF, DOCX, OpenAPI и SQL не стоит разбирать строковыми эвристиками, если в проекте или экосистеме есть parser. Ручной parser допустим только для узкого и доказуемо стабильного подмножества формата, с тестами на реальные примеры.

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

Плохая постановка:

Почини parser писем.

Рабочая постановка:

В модуле импорта писем падает извлечение номера заказа из HTML body. Найди текущую точку разбора, проверь существующие зависимости для email/MIME и HTML parsing, не добавляй ручной parser сложной разметки без обоснования. Scope: только импорт писем и ближайшие тесты. Добавь regression test на fixture из issue, запусти релевантный test command. В финале покажи changed files, checks run и риски.

Вторая формулировка лучше не потому, что длиннее. Она задает инженерную политику: сначала known-format и tool-selection, потом минимальная правка, затем verification.

Финальный ответ Codex должен помогать принять работу. В нем стоит ожидать:

• Summary. Что было сделано и почему.
• Files changed. Какие файлы изменены и какую роль играет каждый файл.
• Checks run. Какие команды запускались и чем закончились.
• Unresolved risks. Что не проверено, какие предположения остались и где нужна ручная ревизия.
• Next step. Что должен сделать разработчик: review, manual QA, deploy check, security review или уточнение задачи.

Если Codex менял код, но не может объяснить, чем проверил результат, задачу лучше вернуть на доработку. Для командной разработки это нормальная дисциплина: агент ускоряет работу, но критерий готовности остается инженерным. Общую рамку можно сверить с различием Definition of Ready, Acceptance Criteria и Definition of Done: задача должна быть готова к старту, иметь проверяемые критерии и закрываться по понятному стандарту качества.