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

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

Поэтому первый навык работы с Codex — не составление длинного промпта, а постановка небольшой задачи с наблюдаемым результатом. В нашем примере форма должна появиться в определённом месте, не отправляться с пустыми полями и показывать заданный текст после корректного ввода. Эти признаки можно увидеть и проверить.

OpenAI предлагает несколько способов работы с Codex. В desktop app удобно вести задачу рядом с локальными файлами и другими материалами. Расширение для IDE подходит, когда вы хотите видеть проект и изменения в редакторе. CLI запускается в терминале из каталога проекта и хорошо ложится на привычную работу с командами, тестами и Git.

Новичку не нужно осваивать все варианты сразу. Выберите поверхность, в которой сможете выполнить три действия: открыть нужную папку, посмотреть изменённые файлы и запустить проект или проверку. Если вы уже работаете в VS Code, естественно начать с IDE extension. Если уверенно пользуетесь терминалом, подойдёт CLI. Desktop app удобен, когда хочется держать проект, переписку и другие рабочие материалы в одном окне.

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

Перед первым запросом откройте проект и убедитесь, что он запускается в исходном виде. Зафиксируйте исходное состояние в Git. Теперь у вас есть точка возврата, а у Codex — конкретная рабочая папка. Только после этого имеет смысл ставить задачу.

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

Не нужно копировать в запрос весь репозиторий. Сначала попросите изучить README, файл с зависимостями и ближайшие к задаче компоненты. Если в проекте есть AGENTS.md, запишите туда постоянные правила: команды запуска и тестов, принятый стиль, архитектурные ограничения, запрет менять определённые каталоги. Codex использует такие файлы как инструкции проекта. Разовые условия конкретной фичи всё равно остаются в самой задаче.

Для учебной формы заявки контекст может выглядеть так:

Изучи проект и найди компонент страницы мероприятия. Перед изменениями сообщи, какие файлы понадобятся. Нужно добавить под описанием форму с полями «Имя» и «Телефон». Оба поля обязательные. При пустом поле покажи сообщение рядом с ним. После корректного ввода не отправляй данные наружу: покажи текст «Заявка сохранена в учебном режиме».

Не меняй шапку, подвал и общие стили сайта.

Используй существующие компоненты и команды проверки.

Готово, если:

- форма видна на странице мероприятия;

- пустые поля не проходят проверку;

- корректный ввод показывает заданный текст;

- существующая проверка проекта проходит.

В этом запросе нет роли «ты старший разработчик» и длинного описания характера агента. Зато есть цель, место изменения, ограничения и признаки готовности. Именно их можно сопоставить с результатом.

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

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

После согласования попросите выполнить один шаг и показать результат. Посмотрите список изменённых файлов и diff. У каждого изменения должна быть понятная связь с задачей. Новый компонент формы объясним. Замена конфигурации сборки — уже повод спросить, зачем она понадобилась.

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

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

Для учебной формы нужны как минимум четыре попытки:

1. отправить оба поля пустыми;

2. заполнить только имя;

3. заполнить только телефон;

4. заполнить оба поля.

В первых трёх случаях форма должна остановить отправку и показать ошибку у нужного поля. В четвёртом — вывести точный текст про учебный режим. Затем обновите страницу и убедитесь, что остальная часть сайта выглядит как раньше.

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

Когда проверка падает, не просите «починить всё». Передайте агенту конкретный симптом: что вы сделали, чего ожидали и что увидели. Добавьте сообщение из консоли или лога. Такой отчёт сужает поиск причины и позволяет после исправления повторить ровно тот же сценарий.

После успешных проверок ещё раз просмотрите diff. Уберите временные логи, случайные файлы и изменения, не относящиеся к форме. Затем сохраните результат отдельным коммитом с понятным сообщением, например Добавить проверку формы заявки.

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

Если хочется пройти тот же цикл не только на форме, а на собственном сайте, боте или приложении, в программе курса «Вайбкодинг на максималках» Codex и VS Code связаны с Git, Docker, чтением логов, базой данных, деплоем и защитой секретов. Это продолжение уже начатой работы: задача становится частью проекта, который нужно запускать, обновлять и поддерживать.

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

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

Секреты не должны попадать ни в запрос, ни в репозиторий. Ключи API и пароли хранят в переменных окружения, а файлы с локальными значениями исключают из Git. Перед коммитом проверьте diff ещё и с этой точки зрения. Агент помогает работать с проектом, но решение о том, какие данные и действия ему доступны, остаётся за вами.

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

Перед работой проверьте исходный запуск и состояние Git. Затем попросите Codex изучить нужные файлы и предложить короткий план. После каждого изменения смотрите diff. В конце повторите проверки, удалите временные следы и сделайте отдельный коммит.

Короткий чек-лист первой самостоятельной задачи:

• я могу показать, в каких файлах появился результат;

• я понимаю, как запустить проект и проверить новую функцию;

• фактическое поведение совпадает с критериями готовности;

• старые части проекта продолжают работать;

• в diff нет случайных файлов, секретов и лишних переделок;

• у меня есть коммит, к которому можно вернуться.

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