Codex CLI — агент OpenAI в командной строке: он читает файлы проекта, предлагает правки и может запускать доступные инструменты в пределах настроенных разрешений. Разработчик проверяет изменения через diff, тесты и ревью перед слиянием. В отличие от расширения редактора, вход в работу здесь — терминал; оба интерфейса могут работать с репозиторием. Для первого пилота выберите задачу с понятным критерием готовности.
Командная строка
Первый прогон: рабочая ветка, узкая задача, просмотр diff, тесты и решение разработчика о слиянии. Разрешения Codex и права в репозитории настраиваются отдельно; заранее проверьте, какие команды агент сможет запускать.
Codex CLI запускают из папки проекта после установки и входа в учётную запись. Он может исследовать файлы, предлагать правки и запускать локальные инструменты; фактический доступ зависит от настроенных разрешений и изоляции среды. Команда заранее выбирает область работы и команды проверки. Инструкции проекта можно хранить в AGENTS.md, но перед пилотом проверьте, какие именно инструкции видит агент в выбранной папке. Терминальный интерфейс удобен разработчику, который уже работает с git и тестами в командной строке. Общий поток в редакторе с расширением — соседний сценарий; оба способа способны работать с контекстом репозитория. Смежный контур агентов в разработке — разбор агентов для репозитория с PR и контролем.
CLI подходит для локального репозитория и окружения, где установлены нужные инструменты. При работе на удалённой машине условия доступа к файлам и секретам проверяют отдельно: агент получает возможности окружения, в котором запущен. Для первого пилота лучше узкая задача с воспроизводимой командой тестов и небольшим diff. Разработчик читает каждое изменение, проверяет поведение и решает, готова ли ветка к слиянию.
Первая задача
Первая задача для агента выбирается маленькая: функция с тестами, исправление бага с воспроизведением, механическая замена по шаблону. Задача формулируется как для нового разработчика: контекст, цель, ограничения, ссылки на тесты. Критерий готовности пишется до запуска: какие тесты должны стать зелёными, какое поведение считается исправленным. Агент получает критерий как часть задания. Первая задача — разведка: команда учится формулировать задания и читать diff на безопасном материале. Удачная разведка закрывает один реальный дефект или механическую правку вместо демонстрации возможностей.
- Создайте ветку для агента и зафиксируйте чистое состояние репозитория.
- Сформулируйте задачу: файл, цель, ограничения, как запускать тесты, ссылки на документацию.
- Запустите агента и наблюдайте за списком изменяемых файлов.
- Остановите при отклонении от задачи: новые файлы вне плана, правки вне области.
- Получите diff и пройдите его построчно перед тестами.
Рабочая ветка упрощает контроль правок и возврат к исходному состоянию. Название ветки и правила слияния задаёт команда. До merge разработчик читает diff, запускает проверки и оценивает изменения с учётом кода вне тестов. Если Codex изменил неожиданные файлы, остановите работу, выясните причину и уточните задание. Такой разбор помогает держать объём изменений понятным.
Проверочный пример для первого запуска — ошибка сортировки списка заказов. Сначала разработчик воспроизводит дефект на тестовых данных и сохраняет ожидаемый порядок элементов. В задании Codex укажите конкретную команду теста, правило сортировки и запрет на изменение формата ответа API. После работы агента сравните новый тест с исходным дефектом: он должен падать на старой реализации и проходить на исправленной. Затем откройте diff реализации и проверьте соседние случаи — пустой список, одинаковые даты и отсутствующее поле. Если агент поменял контракт API, попросите исправить решение в пределах согласованной области. Команда сохраняет команду проверки и вывод CI рядом с изменением; это позволяет повторить проверку при следующем обновлении проекта.
Чтение diff
Diff читайте как обычный код на ревью: какие файлы изменены, зачем и какое поведение затронуто. Сначала проверьте контракты и тесты, затем реализацию и соседние вызовы. Если diff велик, разделите его по файлам с помощью git; Codex может пояснить спорные места, но его объяснение сверяют с кодом. Замечания формулируйте конкретно: какая строка неверна, какой тест или случай пропущен, что нужно исправить. После повторной правки весь затронутый diff смотрят снова. Держите список принятых и отклонённых решений в комментарии к задаче или PR, чтобы следующий проверяющий понял историю изменения.
Стиль проверяет линтер, а разработчик оценивает смысл: сохранность контракта, обработку ошибок, влияние на данные и доступы. Зелёный линтер подтверждает стиль; правильность поведения оценивают тесты и ревью. Повторяющиеся замечания можно включить в инструкции проекта или шаблон задачи. Перед отправкой следующего запроса соберите их в один список и укажите проверочный пример для каждого исправления.
Тесты и merge
Запускайте релевантные тесты в рабочей ветке до слияния и читайте результат. Успешный прогон подтверждает только проверенные тестами сценарии; непокрытые ветви и интеграции остаются предметом ревью. При падении теста сохраните команду и вывод, разберите связь ошибки с изменением, затем передайте агенту конкретное замечание. Для задачи без существующего теста заранее согласуйте другой критерий приёмки или добавьте проверку в рамках самой задачи. Финальный набор проверок зависит от репозитория: могут потребоваться сборка, типы, интеграционный тест и ревью владельца кода.
| Проверка | Кто выполняет | Критерий приёмки |
|---|---|---|
| Юнит-тесты ветки | Скрипт в CI | Прогон зелёный до merge |
| Линтер и формат | Скрипт в CI | Стиль соответствует проекту |
| Diff построчно | Разработчик | Каждый блок понятен и оправдан |
| Сборка проекта | CI после merge | Основная ветка собирается |
После чтения diff и прохождения проверок разработчик принимает решение о слиянии по правилам репозитория. Автоматическое слияние можно отключить настройками ветки и CI. Если в основной ветке есть дополнительные проверки, их статус тоже нужно посмотреть; сбой требует отдельного исправления или отката по правилам команды. Коммит, тестовый лог и решение ревью сохраняют связь между изменением и его проверкой.
Кто читает diff в вашей команде перед слиянием?
Ритм команды
Для командного пилота ведите короткий цикл: задача, правки, просмотр diff, тесты и решение. Разбирайте те случаи, где агент вышел за рамки задания, пропустил тест или предложил сложную для ревью правку. История таких замечаний помогает уточнять инструкции и выбирать подходящие задачи. Начните с подсистемы, где есть владелец кода и воспроизводимые проверки. Критерии пилота определите до старта: размер и понятность diff, число возвратов на доработку, качество тестов и время человека на ревью. После нескольких задач сравните результаты с обычным процессом разработки на сходных изменениях. Сохраните шаблон задания, список проверок и правило остановки как документы команды. Расширяйте применение там, где качество правок и скорость ревью подтверждены результатами, по нескольким проверенным задачам.
Откройте проект в терминале, создайте рабочую ветку и сформулируйте задачу с командой проверки. Перед запуском проверьте разрешения Codex и доступность секретов в окружении. По окончании прочитайте diff, выполните тесты и попросите владельца репозитория оценить влияние на архитектуру. Команда решает, сливать ли изменение, по своим правилам. Сохраните удачное задание и замечания для следующей попытки. Для внедрения агента в процесс команды полезна команда внедрения.