Четыре ИИ-модели пишут один сервис. Как понять, чей код ближе к продакшену

Я хотел устроить простой эксперимент. Отдать GPT-5.6 Sol, Claude Opus 5, Grok 4.6 и Gemini 3.7 Flash одинаковое техническое задание на небольшой сервис с регистрацией, авторизацией и заявками, а потом выбрать победителя. Но здесь легко незаметно превратить эксперимент в выдумку. Если не сохранить четыре исходных репозитория, настройки reasoning, версии API, логи запуска и результаты тестов, нельзя честно написать, что одна модель забыла проверку прав, а другая идеально настроила JWT.

Поэтому я сделал полезнее. Составил один воспроизводимый запрос, определил одинаковый конвейер приёмки и сверил ожидаемую расстановку сил с двумя большими независимыми наборами реальных запусков моделей. Вывод получился менее эффектным, зато гораздо практичнее. Если выбирать кодовую базу для дальнейшей работы, первой я бы смотрел Claude Opus 5. GPT-5.6 Sol идёт рядом. Grok 4.6 уже способен обгонять обоих в отдельных агентных сценариях. Gemini 3.7 Flash заметно дешевле тяжёлых моделей и выглядит рационально для массовых задач, но по сложной разработке пока уступает этой тройке.

А в продакшен без проверки я не взял бы код ни одной модели.

Материал посвящён легальной разработке и защитному анализу программ. Проверяйте правила сервисов и законодательство своей страны, включая российское. Инструменты анализа нельзя применять для несанкционированного доступа, взлома, слежки или незаконного обхода ограничений.

Один промт и один конвейер вместо оценки «на глаз»

Для теста я выбрал FastAPI, PostgreSQL и обычный сервис обработки обращений. Специально не перечислял модели обязательные меры защиты. Если написать в запросе «поставь Argon2, rate limiting, проверь ownership и не храни секреты в репозитории», мы проверим способность следовать инструкции. Гораздо интереснее увидеть, какие решения модель примет самостоятельно.

Сделай production-ready REST API сервиса приёма заявок. 
 
 Стек
 Python
 FastAPI
 PostgreSQL
 SQLAlchemy
 Alembic
 Docker Compose
 
 Функции
 - регистрация по email и паролю
 - вход в аккаунт
 - создание заявки с темой и текстом
 - пользователь видит только свои заявки
 - администратор видит все заявки
 - администратор меняет статус заявки
 - валидация данных
 - обработка ошибок
 - миграции базы
 - автоматические тесты
 - README с запуском
 
 Проект должен запускаться через docker compose up. 
 
 Сгенерируй структуру проекта и весь необходимый код. 
 Не задавай уточняющих вопросов. 
 Сам выбери разумные настройки для production.

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

После генерации я бы вообще не читал объяснение модели. Фразы вроде «implemented secure authentication and comprehensive tests» ничего не доказывают. Репозиторий должен пройти один и тот же набор команд.

docker compose up --build
 
 pytest -q
 
 ruff check . 
 
 mypy app
 
 semgrep --config p/owasp-top-ten . 
 
 pip-audit
 
 gitleaks detect --source . 
 
 trivy fs .

Такой прогон проверяет разные классы проблем. pytest показывает функциональные поломки, ruff и mypy находят часть дефектов ещё до запуска, Semgrep ищет опасные конструкции, pip-audit проверяет Python-зависимости, Gitleaks ищет секреты, Trivy добавляет проверку файлов проекта и компонентов.

Одного зелёного CI всё равно мало. Самые неприятные ошибки авторизации часто выглядят совершенно нормальным Python-кодом.

# Плохо
 request = db.get(Request, request_id)
 
 # Лучше
 request = db.scalar(
     select(Request).where(
         Request.id == request_id,
         Request.owner_id == current_user.id
     )
 )

В первом варианте сервер проверил, что пользователь вошёл, но не проверил владельца объекта. Если идентификаторы заявок можно подобрать, пользователь потенциально получает доступ к чужим данным. Статический анализатор не всегда поймёт бизнес-смысл такого запроса, поэтому места, где код работает с объектами, ролями и правами, я читаю вручную.

То же касается административной роли. Такой код сам по себе выглядит правильно.

if not current_user.is_admin:
     raise HTTPException(status_code=403)

Но проверка бесполезна, если регистрация разрешает прислать is_admin=true прямо в JSON или роль пользователя берётся из данных, которым клиент может управлять. Безопасность нельзя оценивать по отдельной красивой функции.

Реальные прогоны сильно портят красивый рейтинг моделей

Самый интересный открытый материал для такого сравнения сейчас даёт Agents on Rails. Авторы взяли 21 реальную задачу в Rails-приложении, запускали каждую модель по три раза в одинаковом минимальном агентном окружении и проверяли результат скрытыми тестами. Для анализа опубликованы команды, diff, трассировки и вердикты.

Модель	Успешные запуски	Результат	Что интересно в поведении
Claude Opus 5	58 из 63	92%	Лучший результат среди этой четвёрки, но самые объёмные diff
GPT-5.6 Sol	примерно 84%	второе место среди выбранных моделей	При написании тестов часто сначала создаёт падающий тест, затем исправляет код
Grok 4.6	52 из 63	83%	Почти догнал GPT-5.6 Sol и показал сильную работу с Rails API
Gemini 3.7 Flash	45 из 63	71%	Самые компактные изменения и длительная самопроверка после последнего edit

На первый взгляд победитель найден. Opus 5 набирает 92%, GPT-5.6 Sol около 84%, Grok 4.6 получает 83%, Gemini 3.7 Flash набирает 71%.

Но другой реальный benchmark меняет картину. CursorBench 3.2 использует неоднозначные многофайловые задачи из настоящих сессий Cursor. При максимальных или близких к максимальным настройках reasoning Grok 4.6 Extra High получает 70,8%, Claude Opus 5 Max 70,0%, GPT-5.6 Sol Max 67,2%, Gemini 3.7 Flash High 61,6%.

Получается неудобный для маркетинга результат. В одном тесте лидирует Claude, в другом Grok. Разница объяснима. Benchmarks используют разные репозитории, agent harness, лимиты, инструменты и уровни reasoning. Agents on Rails специально запускает модели с настройками по умолчанию, а CursorBench отдельно показывает разные режимы вычислительного усилия.

Поэтому фраза «модель X лучше всех пишет код» почти лишена технического смысла. Правильнее спрашивать, какая модель лучше решает конкретный класс задач внутри конкретного агента при заданном бюджете.

Интереснее итоговых процентов оказались сами траектории. GPT-5.6 Sol заметно чаще применял подход, похожий на TDD. Когда модель решала добавить тест, падающий тест появлялся перед исправлением более чем вдвое чаще, чем после него. Gemini 3.7 Flash делал самые небольшие diff и дольше остальных проверял проект после последнего изменения. Opus 5, наоборот, оказался самым многословным и генерировал изменения примерно в 1,65 раза объёмнее медианного размера патча для задачи.

Причём ни одна из этих привычек сама по себе не предсказывала победу. Много тестовых запусков не гарантировало правильное решение, маленький diff не гарантировал отсутствие ошибки, а подробные комментарии не делали код автоматически лучше.

Есть ещё показательная деталь. У Anthropic имеется более мощная линейка Fable 5, поэтому возникает резонный вопрос, почему в четвёрке оказался Opus 5. Fable действительно показывает очень сильные результаты, но модель использует дополнительные защитные классификаторы для чувствительных сценариев. В Agents on Rails Fable 5 отказалась выполнять одну задачу, формулировка которой напоминала security-аудит. Для теста сервиса с авторизацией такой фактор способен искажать сравнение, поэтому Opus 5 здесь выглядит более чистой контрольной точкой.

Рабочий код и безопасный код всё ещё разные вещи

Главная ловушка вайбкодинга не изменилась. Приложение запускается, тест регистрации проходит, заявка появляется в PostgreSQL, интерфейс возвращает красивый JSON. Мозг быстро ставит проекту мысленную галочку «готово».

Исследования безопасности такой оптимизм пока не подтверждают. Свежий GenAI Code Security Report Veracode проверяет 80 задач на Java, JavaScript, C# и Python. В среднем около 56% генераций проходят проверки безопасности, примерно 44% содержат обнаруживаемую известную уязвимость. За несколько поколений моделей синтаксическая корректность приблизилась к почти идеальной, а результат по безопасности вырос намного слабее.

Цифру 44% нельзя переводить в заголовок «44% всего ИИ-кода уязвимо». Методика Veracode специально построена на заданиях, где существует безопасный и небезопасный способ реализации, а результаты анализирует SAST. Более того, авторы прямо признают ограничение исследования. Они не проверяют полную функциональную корректность каждого решения.

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

Поэтому я бы проверял сгенерированный сервис минимум по следующим направлениям.

• Пароли. Нормальная password hashing function, отсутствие паролей в логах и ответах API.
• Токены. Проверка подписи, срока действия и ожидаемых параметров. Секрет нельзя зашивать в исходный код.
• Права. Проверка роли недостаточна. Нужна проверка доступа к конкретному объекту.
• Регистрация. Клиент не должен сам назначать себе административный статус или другие привилегии.
• Секреты. Рабочие ключи, пароли БД и токены не должны попадать в Git, Dockerfile, compose-файл или тестовые фикстуры.
• Зависимости. Пакет должен существовать, иметь ожидаемое происхождение и не содержать известных уязвимостей.
• Ошибки. API не должен возвращать stack trace, SQL, токены или внутренние детали инфраструктуры.
• Тесты доступа. Нужны отдельные проверки чужой заявки, недостаточной роли, просроченной сессии и неправильных входных данных.

Особенно мне понравился побочный эффект открытого Rails-эксперимента. Один из тестировавшихся агентов решил выполнить env и вытащил API-ключ из окружения в свою trajectory. Исследователям пришлось удалять секрет перед публикацией результатов. Модель не «взломала» стенд и не пыталась украсть ключ. Агент просто получил доступ к секрету и использовал команду, которая показалась полезной для диагностики.

Для корпоративной разработки вывод неприятный. Секрет, доступный coding agent, потенциально доступен и его контексту, журналам команд, трассировкам и внешней системе наблюдения. Изоляция агента поэтому должна ограничивать не только запись файлов и запуск команд, но и доступ к переменным окружения, production credentials и сети.

Кого я бы выбрал и почему победитель всё равно не получает Deploy

Если мне нужно выбрать один репозиторий вслепую и известно только имя модели, первой я бы проверял версию Claude Opus 5. Причина не в рекламных заявлениях Anthropic. В открытом Agents on Rails модель закрыла 58 из 63 запусков, а в CursorBench остаётся в верхней группе. Для сложных многофайловых изменений такая стабильность ценнее эффектного первого ответа.

GPT-5.6 Sol поставил бы совсем рядом. Модель сильна в длинных агентных задачах, а наблюдавшаяся привычка сначала писать тест и только затем исправление мне нравится с инженерной точки зрения. При этом Rails-эксперимент обнаружил интересный характер ошибок. Когда модели семейства GPT-5.6 проваливали задания, они примерно в четырёх случаях из пяти находили правильные файлы, но вносили неправильное исправление. Для ревьюера такое поведение даже удобнее ситуации, когда агент ушёл совсем не в ту часть проекта.

Grok 4.6 перестал выглядеть запасным вариантом. В Agents on Rails модель отстаёт от GPT-5.6 Sol всего на один успешный запуск, а в CursorBench при Extra High reasoning выходит на первое место среди рассматриваемой четвёрки. Если стоимость агентных прогонов имеет значение, Grok заслуживает отдельного пилота, а не места «четвёртой модели для полноты таблицы».

Gemini 3.7 Flash проигрывает трём тяжёлым моделям по абсолютному результату в этих двух тестах. Но сравнение немного нечестное по самой конструкции. Flash ориентирован на скорость и стоимость. Для массовой генерации тестов, небольших изменений, boilerplate и первичного разбора репозитория меньшая цена может оказаться важнее нескольких пунктов benchmark.

Мой итоговый рейтинг поэтому выглядит не как пьедестал, а как очередь на code review.

Задача	С чего бы я начал
Сложное изменение существующего backend	Claude Opus 5 или GPT-5.6 Sol
Длинная агентная работа с учётом стоимости	Grok 4.6 обязательно включить в сравнительный прогон
Большой поток небольших задач	Gemini 3.7 Flash имеет смысл проверить по цене одного принятого изменения
Security-critical код	Ни одной модели не доверять без отдельной проверки

Последняя строка для меня главная. Хорошая модель сокращает путь от задачи до pull request. Она не сокращает путь от pull request до доверенного релиза.

LLM
  |
  v
 git diff
  |
  v
 unit + integration tests
  |
  v
 lint + type checking
  |
  v
 SAST + dependency scan + secret scan
  |
  v
 ручная проверка данных и прав
  |
  v
 code review
  |
  v
 staging
  |
  v
 production

Если завтра новый Claude, GPT, Grok или Gemini поднимет benchmark ещё на десять пунктов, я поменяю модель в начале схемы. Остальные ступени оставлю. Именно такой подход позволяет пользоваться вайбкодингом как ускорителем разработки, не превращая уверенный ответ нейросети в разрешение на публикацию кода.