Codex — агент, а не просто автодополнение
Автодополнение отвечает на локальный вопрос: что, вероятно, идёт следующей строкой. Агент работает на другом масштабе. Он может прочитать связанные файлы, найти принятую в проекте схему, изменить несколько мест и запустить уже установленные команды — в пределах разрешений и доступного окружения.
По официальной документации Codex доступен через CLI, IDE-интеграцию и облачные задачи. Эти поверхности отличаются, но полезная единица работы одна: ограниченная задача в репозитории с понятным результатом. Поэтому evergreen-процесс не стоит привязывать к названию конкретной модели или кнопке интерфейса.
Совместная работа и делегированная задача — не одно и то же
В CLI или IDE удобно оставаться рядом с процессом: попросить найти поток данных, задать уточнение, принять маленький diff и сразу открыть приложение. Этот режим хорош, когда решение зависит от обратной связи человека — например, от визуального ощущения или продуктовой трактовки требования.
Отдельная агентная задача требует более самостоятельного описания. Агенту нужны доступный репозиторий, воспроизводимое окружение и критерии, по которым можно закончить работу без постоянных вопросов. Такой формат подходит не каждой идее: «разберись, что здесь хочется» — слабое делегирование, а «исправь воспроизводимую ошибку и добавь регрессионный тест» — уже рабочее.
Работать рядом
Вы часто меняете направление, смотрите открытые файлы и проверяете промежуточный результат после каждого смыслового шага.
Делегировать отдельно
Задача имеет чёткие границы, окружение собирается, а правильность можно подтвердить командами и итоговым diff.
Какая первая задача подходит Codex
Начинать лучше не с нового продукта целиком, а с изменения, которое помещается в одну проверяемую историю. В существующем проекте это может быть дополнительное состояние формы, небольшой API-адаптер, исправление мобильной вёрстки или тест для уже понятного поведения.
- вы можете показать место, где начинается текущая реализация;
- ожидаемый результат виден в интерфейсе, ответе API или тесте;
- есть ограничения: какие публичные контракты и архитектурные решения нельзя менять;
- известны команды lint, typecheck, test или build;
- diff можно просмотреть за один подход, не доверяя краткому пересказу агента.
Если два пункта из этого списка пока неизвестны, первым поручением может быть именно исследование: «прочитай реализацию, ничего не меняй и объясни, где лучше добавить правило». Такой шаг не производит эффектного экрана, зато резко снижает количество случайного кода.
Пример: небольшое изменение в существующем Next.js-проекте
1. Начните с чистой рабочей точки
Посмотрите состояние git и отделите незавершённые пользовательские изменения. Агент должен понимать, что принадлежит текущей задаче, а что нужно сохранить нетронутым.
2. Попросите исследовать, прежде чем редактировать
«Найди текущую валидацию этой формы, связанные типы и тесты. Перечисли затронутые файлы и предложи минимальный план без параллельной архитектуры».
3. Уточните критерии готовности
Опишите допустимое и ошибочное значение, текст состояния и мобильный сценарий. Явно назовите команды, которые должны пройти после изменения.
4. Проверьте работу, а не отчёт
Запустите проверки, откройте diff, найдите неожиданные зависимости и вручную пройдите основной сценарий. Если агент сообщил «готово», это начало приёмки, а не её замена.
Где такой цикл особенно полезен
Codex удобен там, где значительная часть труда — не придумать алгоритм с нуля, а аккуратно пройти по существующему проекту: найти несколько связей, повторить принятую схему, обновить тест и не забыть проверку. Агент может удерживать задачу на уровне репозитория, пока человек оценивает смысл изменения.
Ещё один полезный сценарий — первое чтение незнакомой кодовой базы. Вопросы «откуда приходит это состояние», «какие компоненты используют этот тип» и «что проверяет сборка» дают карту, которую затем можно подтвердить поиском и кодом. Но формулировку «понимает весь проект» лучше не использовать: агент исследует тот контекст, который нашёл и смог удержать для текущей задачи.
Что остаётся ответственностью человека
- выбрать правильную проблему и не подменить её тем, что проще автоматически реализовать;
- решить, какие данные и разрешения безопасно отдавать инструменту;
- оценить совместимость изменения с продуктом, архитектурой и соседними сценариями;
- проверить поведение на реальных данных и крайних состояниях;
- принять diff и решить, готов ли код к публикации.
Sandbox и подтверждения команд полезны: они ограничивают последствия действий. Но режимы различаются между поверхностями и настройками, поэтому нельзя считать их абсолютной защитой. Права должны соответствовать задаче, а опасные операции — оставаться явными.
Как подготовить репозиторий
Агенту помогают не длинные универсальные промпты, а короткие инструкции самого проекта: где лежат основные слои, какие команды запускать, какие соглашения обязательны и чего не следует менять. Для Codex такие правила можно хранить в AGENTS.md, чтобы они сопровождали код, а не терялись в истории чата.
Перед первой задачей проверьте, что проект устанавливается и запускается без тайных ручных шагов. Чем воспроизводимее окружение, тем меньше агент будет угадывать. Актуальные способы установки, поверхности работы и правила разрешений лучше сверять с официальной документацией Codex.