«Билд нашего инструмента для клиента падает на скачивании образа, — сказала Аня, пересылая мне ошибку из CI. — Контейнер весит под четыре гига, и каждый раз Docker тянет его целиком. Мы что, всё это таскаем в продакшен?» Цена вопроса была в сроках: если не ужать образ, развёртывание у клиента затянется, и мы сорвём график.
Широкий запрос как у OpenAI
Я вспомнил историю от OpenAI, где они дали GPT-6 Astra расплывчатый запрос на поиск мёртвого кода, и модель сама искала доказательства в Slack и трекерах. «Попробуем так же, — сказал я. — Если Codex сам пройдёт по истории PR и таблицам производительности, сэкономит нам дни ручного аудита». Мы открыли Codex и ввели почти дословно: «Can you help identify and clean up dead code in the repo please, feel free to check slack, statsig, or any other source you need to confirm that things are indeed no longer being used and can be cleaned up or simplified».
Разработчики OpenAI, получив доступ к GPT-6 Astra, дали ей именно такой неопределённый промпт. Модель справилась с неоднозначностью: изучала прошлые пул-реквесты, собирала контекст из Slack и проверяла внутренние трекеры, читая таблицы профилирования, чтобы подтвердить, что удаляемые строки никогда не достигались.
Codex начал работу. Через полчаса у нас был список из нескольких десятков кандидатов — устаревшие утилиты и закомментированные блоки. Я уже представлял, как мы одним махом почистим репозиторий.
Стоп-сигнал от Ани
«Стой, — Аня ткнула пальцем в строчку `emergency_flags.py`. — Это же флаги аварийного отключения. Они могут годами не использоваться, но удалить их — всё равно что выкинуть огнетушитель из серверной». Это был поворот. Автоматический поиск мёртвого кода — не то же самое, что понимание операционных рисков.
Задача сместилась: нужно провести уборку, не затрагивая механизмы безопасности. Именно здесь разработчик должен остановить автоматизацию и уточнить правила.
В OpenAI при поиске устаревших экспериментов в промпте явно требовалось сохранять производственное поведение и операционные safeguards, включая флаги, предназначенные для аварийного отключения.
Мы отредактировали запрос, добавив условие: «Сохрани производственное поведение, операционные safeguards и флаги, предназначенные для аварийного отключения». Codex принял уточнение и скорректировал список. Теперь он готовил небольшие draft PR на каждую чистку, а я проверял, что помечено как безопасное.
Наши масштабы против их кейса
За пару дней параллельной работы мы смержили около тридцати пул-реквестов. Это не те масштабы, о которых сообщала команда OpenAI.
Пять инженеров OpenAI запускали варианты промпта в разных репозиториях; команда объединила более 1 400 пул-реквестов, удалив свыше 800 тысяч строк кода. Основную часть работы выполнили параллельно с другими проектами за две недели.
Для нас результат был конкретным. После удаления ненужных зависимостей образ целевого сервиса сократился на 35%. Это не 48%, как в их примере, но достаточно, чтобы CI/CD клиента перестал утыкаться в таймауты.
В OpenAI после удалений образ одного сервиса уменьшился с 3,31 ГБ до 1,72 ГБ — на 48%.
Финал — новый Docker-образ, который Аня отправила заказчику. Следующий шаг — перенести подход на другие проекты, но каждый раз начинать с договорённости о том, что мы считаем «безопасным для удаления». Инструмент ищет кандидатов, а черту проводим мы.