Каждый pull request инженера OpenAI теперь проходит обязательное AI-ревью кода по безопасности, а модель может сама заблокировать merge, если находит уязвимость. Для разработчиков и IT-директоров это важный сигнал: AI в разработке перестает быть подсказчиком в IDE и получает право нажимать на стоп-кран в production-процессе.
О новой практике сообщает The New Stack со ссылкой на интервью Тибо Соттьо, engineering lead команды Codex в OpenAI, подкасту The Pragmatic Engineer. По его словам, проверка безопасности встроена в процесс для всех pull request внутри компании и не требует отдельного человека, который подтвердит блокировку. Если модель считает, что изменение несет риск, код не едет дальше.
Деталей реализации OpenAI не раскрыла: неизвестно, какая именно модель стоит в gate, как устроены правила эскалации, сколько ложных срабатываний получает команда и какие классы уязвимостей система ловит лучше всего. Это важные пропуски, потому что в безопасности разница между полезным фильтром и шумной сиреной измеряется не пресс-релизами, а тем, сколько раз разработчики обходят инструмент через исключения и ручные договоренности.
Соттьо говорит, что security gate — только часть более широкой автоматизации. В OpenAI модели уже используют для проверки корректности кода, поиска регрессий, обновления зависимостей и рутинного рефакторинга. Некоторые code-review-модели, по его словам, на внутренних бенчмарках показывают результат выше человеческого уровня не только по корректности, но и по безопасности. Звучит бодро, но без названия бенчмарка, выборки и метрик это пока не инженерный факт, а аккуратная заявка от команды, которая сама развивает Codex.
Главный сдвиг здесь не в том, что AI нашел очередной баг. Таких инструментов в пайплайнах и раньше хватало: статический анализ, SAST, dependency scanning, secret scanning, policy-as-code. Новое в степени доверия. OpenAI не просто показывает инженеру предупреждение в интерфейсе, а разрешает модели стать обязательным контролером в CI/CD. Это уже ближе к роли автоматического security approver, только с вероятностной природой и всеми радостями LLM: контекст понимает лучше классического линтера, но объяснимость и воспроизводимость поведения остаются вопросом.
Для самой OpenAI ставка понятна. Соттьо утверждает, что процессы review, деплоя и ловли регрессий у компании уже почти полностью автоматизированы, а инженеры могут доставить pull request в ChatGPT в тот же день. Он также упомянул масштаб ChatGPT — примерно миллиард активных пользователей. При таком размере аудитории даже скучный внутренний merge превращается в потенциально дорогой инцидент, а очередь ручных проверок быстро становится бутылочным горлышком.
Есть и менее глянцевая сторона. Если AI пишет все больше кода, а другой AI этот код проверяет, у них могут совпасть слепые зоны. Модель может уверенно пропустить ошибку в логике авторизации, не увидеть цепочку через зависимость или, наоборот, блокировать безопасный патч из-за подозрительного паттерна. Для команды это меняет характер работы: меньше времени на механическую проверку diff, больше — на формулирование намерения, архитектурные решения и разбор спорных блокировок.
Соттьо как раз описывает этот перенос внимания: обсуждение должно начинаться не в конце, когда pull request уже открыт, а раньше — на уровне цели изменения. Что именно разработчик пытается изменить? Нужно ли это делать таким способом? Какие инварианты нельзя сломать? Если AI-ревью кода забирает рутину, люди не исчезают из процесса, а перемещаются ближе к постановке задачи. И да, это звучит менее эффектно, чем «модель заменила ревьюера», зато ближе к реальной работе инженерной организации.
Для русскоязычных команд практический вывод простой: копировать схему OpenAI завтра утром не надо. Но стоит пересмотреть свои gates. Если у вас security-проверки носят рекомендательный характер, а критичные findings годами живут в Jira как интерьер, AI-инструменты ничего не спасут. Если pipeline уже дисциплинированный, модельный reviewer можно тестировать как дополнительный слой: сначала в режиме подсказок, затем на ограниченных репозиториях, потом с правом блокировки для узких классов проблем.
Бизнесу эта история тоже интересна не как очередной сюжет про замену разработчиков. Ценность в другом: проекты, которые раньше откладывали на квартал из-за скучной цены проверки — миграции зависимостей, чистка legacy, массовые security-патчи, — могут стать короче и дешевле. Но только если рядом есть нормальная инженерная гигиена: владельцы сервисов, тесты, observability, понятные правила override и журнал решений. Без этого AI-ревью кода быстро превратится в еще один чат-бот, которому все кивают и которого никто не слушает.
OpenAI показывает вероятное направление для крупных engineering-команд: AI постепенно получает не только клавиатуру, но и полномочия в процессе поставки. Следующий спор будет не о том, может ли модель найти уязвимость, а о том, кто отвечает за merge, который она разрешила или остановила: автор кода, владелец сервиса, security-команда или сама платформа разработки.