Пробуем Codex CLI от OpenAI для доработки ХрюХрюКара

Привет Хабр!

Пару дней назад я опубликовал статью про ХрюХрюКар — телегам-бот для борьбы со стоянкой автомобилей на зелёных зонах. Проект с открытым исходным кодом.

За два дня ко мне обратилось несколько сторонников с просьбой добавить их города. Но вот незадача: у меня была возможность через админ-панель Django править данные в базе, но об этом кеш сервера не узнает (основной бекэнд на Go). В результате приходилось добавлять данные и перезагружать контейнеры с go-бекэндом вручную.

Основные серверы ХХК уже имели сторы, которые получают и обрабатывают апдейты, прилетающие через redis.

По сути, оставалось внести правки в часть django-бэкенда, чтобы обрабатывать сигналы pre_save и pre_delete, сериализовать данные и отправлять их в нужный канал редиса.

Решил поручить эту задачу Codex CLI, которую вчера OpenAI представили нам с вами. Хотелось посмотреть насколько этот инструмент будет полезен в среднего размера проектах с развитой структурой, средних размеров кодовой базой и широким стеком технологий.

Если у вас совсем нет времени на просмотр всего процесса, то вот что я получил от Codex CLI примерно за 22 минуты*, пару промптов средней длины, один промпт с трейсбеком из консоли и 1.17$.

*Примечание: работа выполнялась на ПК, имеющем слабый канал связи (скорость 5-10 Мбит/сек.)

Доработка кода на Python/Django

После установки и настройки Codex CLI, я перешел в корневую директорию ХХК и выполнил в консоли команду: codex "<промпт>" и начал ждать.

Вот какой промпт я использовал:

У меня на бекэнде в Go есть сторы в папке go_backend/internal/store/redis_broker которые подписаны через редис на каналы go_backend/internal/store/channels.go. Через эти каналы сторы получают инфу об апдейтах go_backend/internal/store/update_messages.go. Сделай мне в бэкенде Django для моделей, которые в папке django_backend/core/models, набор простых сериализаторов (для преобразования экземпляра модели в простой JSON со всеми полями), при этом название и тип данных полей смотри в моделях в папке go_backend/internal/models. Сериализаторы положи в папку django_backend/core/serializers. Затем в папке django_backend/core/signals сделай обработчики сигналов pre_save и pre_delete для всех моделей, в которых надо формировать сообщения об апдейтах и засылать их в нужный канал редиса.

Вот процесс работы утилиты (ссылка на Youtube):

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

В результате первой итерации работы я получил вот этот коммит. Из положительных моментов: Codex CLI заметил что модели в Go-шной части проекта имеют теги для сериализации в JSON, которые отличаются от названия поля в модели Django. Это моя ошибка, но утилита сделала сериализатор с ее учетом.

Код по результату оказался рабочий и выполняющий мою задачу, но сервер Django не завёлся, а в консоли я увидел ошибку:

django_backend  | Traceback (most recent call last): django_backend  |   File "/backend/core/apps.py", line 10, in ready django_backend  |     import core.signals  # noqa django_backend  |     ^^^^^^^^^^^^^^^^^^^ django_backend  |   File "/backend/core/signals/__init__.py", line 3, in <module> django_backend  |     from .redis_signals import * django_backend  |   File "/backend/core/signals/redis_signals.py", line 4, in <module> django_backend  |     import redis django_backend  | ModuleNotFoundError: No module named 'redis'

Для чистоты эксперимента я решил сам не исправлять ситуацию, а просто скинуть этот трейсбек в Codex CLI. Вот результат (ссылка на Youtube):

Codex CLI предложил добавить в зависимости redis версии 4.7.0. Я все-же проверил pypi и взял последнюю версию 5.2.1.

После пересборки контейнера сервер Django завелся и все работало нормально. Однако мне было интересно проверить как будет происходить правка кода в той части проекта, которая написана у меня на Go.

Доработка кода на Go

Я запустил codex со следующим промптом:

пройди по всем сторам кеша в папке go_backend/internal/store/cache и везде в методе subscribeUpdates при получении апдейта перед блокировкой мьютекса выводи через s.log.Debug … само сообщение апдейта, чтобы я видел что приходит через редис

Вот процесс работы утилиты (ссылка на Youtube):

В результате я получил то, что хотел, правда утилита немного мне поломала отступы. Линтер поправил все отступы при сохранении и я получил вот этот коммит.

Далее проверил что все работает:

Что по расходам?

Работала модель o4-mini, потратил я 1,363,957 токенов, что стоило 1,17$:

Сейчас дашборд в OpenAI позволяет сохранять и смотреть всю историю запросов к API, и вот какого вида записи там:

Если провалиться в любую строку, то в каждой из них в начале будет набор инструкций из Codex CLI, мои инструкции, которые я положил в ~/.codex/instructions.md, сам промпт и результат работы — либо ответ, либо вызов функции. Думаю что расход можно сократить, немного ужав набор своих инструкций. У меня в ~/.codex/instructions.md были следующие инструкции (копипаста из другой утилиты):

## Global Coding Style  - Preserve my existing code style exactly. - Use single-line formatting even for long lines — do not wrap lines. - Keep comments in English. - Maintain existing comment style, indentation, and spacing. - Always use `//` for inline comments in Go. - Do not reorder imports unless explicitly asked.  ## Code Practices  - Keep logging format consistent. - Use mutexes where concurrency issues may occur — match existing usage patterns. - Respect metrics and monitoring setup already in the codebase. - Avoid introducing external libraries unless explicitly permitted.  ## Output Rules  - Only output changed lines or code snippets — do not repeat unchanged code. - Do not add explanations unless explicitly asked. - Avoid adding TODOs or FIXMEs unless explicitly requested.  ## Language Specific  ### Go  #### SQL Style  - Use raw SQL queries. - If using `database/sql`, use `?` placeholders (MySQL). - If using `sqlx`, use `:named` placeholders and `sqlx.Named` where applicable. - Stick to the existing project style — do not mix styles across projects.  #### General Go Rules  - Preserve code style, comment format, and log structure. - Do not auto-format or refactor unless explicitly requested. - Follow existing patterns for SQL declaration blocks, struct tags, etc.  ### Python - Use Django ORM and DRF conventions. - Use `gettext_lazy as _` for translations. - Use snake_case for variable and function names.

Вывод

Утилита отлично справилась с решением конкретной задачи в проекте с кодовой базой средних размеров и развитой структурой.

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