Скотт Ву, генеральный директор и сооснователь Cognition, рассказал в материале OpenAI от 12 сентября 2024 года, как модель o1 подходит к решениям при работе с кодом. Центральная мысль его комментария — аналогия с разработчиком, который обдумывает задачу, прежде чем приступить к реализации. Для команд, выбирающих модель для программирования, это повод проверить качество решений на собственных задачах, но не свидетельство того, что o1 уже заменяет инженерную проверку.
Материал опубликован самой OpenAI и представляет взгляд руководителя компании, работающей над ИИ-инструментами для разработки. Это полезный источник о том, как участники рынка видят возможности o1, но не независимое сравнение моделей. В доступном описании публикации нет результатов испытаний, по которым можно было бы оценить преимущество o1 в конкретном проекте.
Аналогия с разработчиком — не описание внутреннего процесса
Ву предлагает смотреть на работу o1 с кодом через принимаемые моделью решения: прежде чем выдать ответ, ей нужно разобраться в задаче и выбрать путь решения. Такой подход отличается от сценария, в котором инструменту поручают дописать небольшой фрагмент по уже заданному образцу. При сложной ошибке или изменении существующего приложения ценность ответа зависит от того, учёл ли он ограничения системы, а не только от правильности синтаксиса.
Однако выражение «как человек» здесь остаётся аналогией. По готовому ответу нельзя установить, что модель рассуждала так же, как инженер, понимала назначение проекта или самостоятельно проверила все последствия изменений. Если предложение o1 выглядит убедительно, его всё равно нужно сопоставить с требованиями задачи, тестами и поведением приложения.
Общий контекст появления модели изложен в анонсе OpenAI o1. Отдельный материал OpenAI о моделях рассуждения помогает понять, как компания описывает это направление. Оба текста — публикации разработчика модели; они не заменяют проверку на кодовой базе читателя.
Где такой подход стоит проверить первым
Практический сценарий для o1 — задача, в которой ответ нельзя оценить по одному сгенерированному файлу. Например, изменение интерфейса функции может затронуть вызывающий код, обработку ошибок и тесты. Здесь полезно сравнивать не длину объяснения модели, а полноту предложенного плана: какие зависимости она заметила, какие предположения обозначила и что предложила проверить после правки.
Для такого сравнения команде не нужен большой публичный бенчмарк. Достаточно взять одну уже разобранную внутреннюю задачу с известными критериями приёмки и дать одинаковые исходные данные o1 и модели, которую команда использует сейчас. Затем стоит проверить результат одинаковым способом: запустить тесты, просмотреть изменения и зафиксировать, сколько исправлений потребовалось до приемлемого решения. Если важны время ответа и расходы, их следует записать отдельно — эффект от более обстоятельного ответа имеет смысл только в контексте затрат на его получение.
Это испытание не докажет, какая модель «лучше пишет код» вообще. Зато оно ответит на более узкий рабочий вопрос: помогает ли o1 именно на тех задачах, где команда тратит время на анализ связей и последствий изменений.
Что комментарий Ву не подтверждает
Из описания выступления нельзя вывести, что o1 надёжнее других моделей при рефакторинге, отладке или работе с большим репозиторием. Для таких выводов нужны сопоставимые задачи, условия запуска и результаты проверки кода. В исходном сигнале их нет. По той же причине не стоит приписывать Ву точные оценки выигрыша в качестве, скорости или стоимости.
Нельзя также делать вывод, что возможности базовой модели устраняют необходимость в инструментах вокруг неё. ИИ-агенту для разработки могут требоваться доступ к файлам, запуск тестов, управление изменениями и контроль разрешённых действий. Удачный план, предложенный моделью, сам по себе не показывает, насколько надёжно вся эта цепочка работает в проекте.
Главное ограничение при чтении материала OpenAI — различать объяснение подхода и демонстрацию результата. Комментарий Ву задаёт вопрос, который разработчики могут проверить: помогает ли дополнительное обдумывание задачи получить более пригодное изменение кода. Ответ следует искать в воспроизводимой проверке, а не в человеческой метафоре или убедительности отдельного примера.
