Бенчмарк AI-кодинга: какой агент пишет код для продакшена

Паскаль Ческато работает с WordPress-проектами много лет. OpensLiteSpeed с LSCache давал хорошую производительность, но управление через CyberPanel стало невыносимым — баги в бесплатных функциях, которые чудесным образом исчезали в платной версии. aaPanel оказался стабильнее, но полностью абстрагировал OLS от прямого управления.

Потом проекты сменились. Astro, квазистатичные сайты, PHP больше не нужен. OLS потерял смысл за пределами WordPress. Caddy с авто-HTTPS и читаемым конфигом — логичная замена. Но кто будет писать скрипты для управления VPS?

Вместо того чтобы делать самому, Ческато решил провести бенчмарк. Восемь комбинаций «инструмент + модель» получили идентичное задание: написать минимальный тулкит для управления VPS на Ubuntu 24.04 — Caddy, PHP-FPM в двух версиях, MariaDB и PostgreSQL, Valkey, shell-скрипты, FastAPI-интерфейс. Без Docker, без панелей управления, без лишних абстракций.

Методология: два этапа и анонимный суд

Протокол разделён на две фазы, между которыми стоит человеческая валидация.

Этап 1 — Архитектура. Каждой комбинации даётся идентичный functional brief. Без подсказок, без конфигурационных файлов. Инструмент должен предложить архитектуру, структуру проекта, список скриптов с ответственностью, карту API-роутов. И — если он хорошо спроектирован — задать уточняющие вопросы перед тем, как что-то писать.

Этап 2 — Код. После утверждения плана всем четырём финалистам отправляется единый development prompt: утверждённая архитектура, десять подтверждённых технических решений, конвенция кодов возврата, и чёткая инструкция — доставить тридцать файлов на диск, по порядку зависимостей, без кратких изложений.

Восемь протестированных комбинаций:

Haiku 4.5 появляется трижды — это не ошибка. Модель на трёх разных инструментах позволяет отделить влияние инструмента от влияния модели.

Стоимость этапа планирования — отдельная таблица, которая показывает разброс:

Gemini 3.1 Pro произвёл самый концентрированный output — 27k токенов за качественный план. Haiku 4.5 на OpenCode сожрал 69k токенов за более слабый результат. Объём токенов не предсказывает качество.

Этап планирования: кто думает до, а не после

Первое, что замечаешь в результатах — ни одна модель не задала вопросы до того, как выдала план. Все выдают полную архитектуру, а уточнения просят в конце. Человеческий архитектор делает наоборот — блокирует на неоднозначностях до того, как рисовать схему.

Это не мелочь. Некоторые вопросы, поднятые после факта, могли бы изменить архитектурные решения. Одна модель обнаружила напряжение между «без секретов на диске» и конфигурационными файлами приложений, которым легитимно нужны креды — wp-config.php как очевидный пример. Это блокирующий вопрос. Заданный после плана, он становится сноской.

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

Структура предложений — второй сигнал. Только одна модель спонтанно предложила унифицированную точку входа — bin/vpsmgr — которая диспетчирует вызовы к скриптам. Это превращает набор скриптов в цельный инструмент. Остальные об этом не подумали.

Одна модель единственная предложила документированную конвенцию кодов возврата с самого этапа планирования: 0 — успех, 1 — невалидный ввод, 2 — не найдено, 3 — конфликт, 4 — отсутствует зависимость, 5 — внутренняя ошибка. Это не косметика. Это контракт между shell-скриптами и FastAPI-слоем — без него HTTP-маппинг становится произвольным.

Этап кода: кто тестирует, а кто просто генерирует

Код-фаза начинается с единого development prompt. Четыре финалиста (A, B, C, D) получили утверждённую архитектуру и инструкцию: тридцать файлов, в порядке зависимостей, без сокращений.

Model C (впоследствии оказался Claude Code на Haiku 4.5) доставляет 366 строк. Шаблоны для секретов конфигурируемые через environment variable — не захардкожены. JSON-хелперы на чистом shell с Python-фолбэком, если jq отсутствует. print_credentials() оборачивает вывод в маркеры <<>> как указано в брифе. render_template() для конфигов — без зависимости от Jinja. Генерация паролей с исключением неоднозначных символов (0/O/1/l/I). Единственная реализация, которая Anticipates каждую edge case из development prompt.

Но главное — Model C тестирует свой код в течение сессии. После написания schemas.py он запускает его с тестовыми случаями, находит две ошибки и исправляет сразу: Pydantic v2 валидатор реализован через field_validator вместо model_validator для cross-field валидации, и взаимное исключение не enforced на уровне схемы. Также исправляет sed-подстановку в render_template() — сломанную на путях с / — заменяет на чистый bash parameter expansion.

В конце сессии Model C выдаёт verification summary: bash -n на все скрипты, Python AST на все файлы, 19/19 API routes проверены через OpenAPI spec, 18/18 bash-хелперов протестированы, правило PHP-fallback verified (8.5→8.4, 8.4→none, 7.x отклонён).

Model A проверяет shebangs перед финалом. Model B поставляет полированную пользовательскую документацию. Model D валидирует bash и Python syntax. Ни одна из трёх не тестирует функциональную логику.

Внешний ревью: критические баги, которые нашёл нейтральный судья

Код четырёх реализаций отправили модели, которая не участвовала в бенчмарке. Фиксированная evaluation grid: security, correctness, idempotency, code quality, completeness. Пять репрезентативных файлов на реализацию — common.sh, site-create.sh, site-delete.sh, backup.sh, api/runner.py. Двадцать файлов, загружены в один проход.

Стоимость ревью: $0.0766 за 543k токенов. В десять раз дешевле часа работы джуниор-разработчика.

На site-create.sh ревьюер нашёл silent bug в Model D: SFTP-пароль генерируется, но никогда не возвращается вызывающей стороне. Пользователь никогда не видит своих кредов. Базовая функциональность сломана без единого error message. У Model B local используется вне функции в трёх скриптах — bash error, который вызывает runtime failure. Это не тонкие баги — это блокеры.

На site-delete.sh Model C единственный обрабатывает оба режима вызова — интерактивный TTY и --confirm флаг для неинтерактивных API-вызовов. Model D реализует только интерактивный режим, блокируя API-driven deletion со skip-backup.

На backup.sh Models A и B используют eval "$POST_HOOK" — потенциальная command injection. Model C передаёт путь к архиву как аргумент — существенно безопаснее. Model A не реализует автоматический pruning архивов.

На api/runner.py Model C единственный использует asyncio и никогда не логирует stdout — который может содержать креды. Model D содержит мёртвый код: build_command() определена, но никогда не вызвана. Model A доставляет 28 строк без timeout, без логирования, без error handling — hung request блокирует всё.

Результаты и стоимость

Победитель — Model C (Claude Code + Haiku 4.5). Полная стоимость: $1.73. Время: 23 минуты 37 секунд. Но за эти деньги вы получаете протестированный, верифицированный код с документацией и zero critical bugs по результатам внешнего ревью.

Model D (DeepSeek V4 Pro) стоил $0.24 — в семь раз дешевле. Скорость: 9 минут 42 секунды. Но critical bugs нашли в каждом проверяемом файле.

Что это значит для инженера

Три вывода.

Первый: дорогие модели быстрее не потому, что генерируют быстрее, а потому что генерируют реже. Model C потратил 23 минуты против 9 у Model D. Но Model C нашёл и исправил баги в сессии — до того, как код ушёл на ревью. Model D сэкономил 14 минут, но сломался в продакшене. Общее время на багфикс — вопрос.

Второй: тестирование во время сессии — это то, что отличает «просто код» от «кода для продакшена». Model C запускает Pydantic-валидацию, проверяет схему, тестирует PHP-fallback. Model A, B, D генерируют и доставляют. Разница в подходе видна в результатах внешнего ревью.

Третий: для задач средней сложности (VPS-тулкит, не суперкомпилятор) бюджетный агент достаточен — но только если выделять время на ручную проверку. Model D при стоимости $0.24 произвёл 184 строки качественного кода с оригинальными идеями (exit codes as named functions, json_output() в common.sh). Но без самотестирования критические баги прошли. Если вы используете бюджетные модели на продакшен-задачах — закладывайте время на ревью.

Почему это важно в 2026 году

Рынок AI-кодинг агентов в 2026 году разделился на два лагеря. Первый —enterprise-решения по подписке ($20–$200/месяц), которые позиционируются как «полная замена джуниора». Второй — бюджетные модели через OpenRouter или DeepInfra по $0.001–0.01 за тысячу токенов.

Бенчмарк Ческато показывает, что разрыв в стоимости между ними — не проблема. Проблема в том, что дешёвые модели генерируют код, который выглядит работающим, но ломается в edge cases. Дорогие модели (в данном случае Claude Code) тратят часть бюджета на self-testing и возвращают верифицированный результат.

Для инженера это означает простой выбор: либо платите за самотестирование явно (через дорогую модель), либо платите неявно (через время на ревью после бюджетной модели). Третий путь — генерация без ревью — это технический долг с отложенным взрывом.

Две конкретные причины, почему это актуально именно сейчас:

Во-первых, AI-кодинг агенты стали mainstream. Copilot, Claude Code, Cursor — почти каждый разработчик попробовал хотя бы один. Но разговоры в интернете делятся на два лагеря: «это магия, заменило мне джуниора» и «это генерирует красивый мусор». Бенчмарк с независимым ревью даёт data point, который объясняет почему: результат зависит от модели, от инструмента и от того, кто смотрит на output.

Во-вторых, стоимость внешнего ревью через модель ($0.07 за файл) делает экономику интересной. Ручной ревью джуниора стоит $30–50/час. Модель может проверить двадцать файлов за семь центов. Это не замена экспертному ревью на сложной бизнес-логике — но для VPS-скриптов, конфигов и инфраструктурного кода это рабочий вариант.

FAQ

Можно ли заменить AI-агента на бюджетной модели полноценным CI/CD-пайплайном? Частично. Model D произвёл рабочий код, который ломался на edge cases. Хороший CI/CD с линтерами, тестами и security scanners поймает часть этих багов. Но линтеры не поймают логическую ошибку «сгенерировать пароль и не вернуть его пользователю» — для этого нужен либо ревью, либо self-testing агент.

Почему Haiku 4.5 на разных инструментах показывает разное качество? Потому что инструмент определяет не только то, какие модели доступны, но и то, как происходит работа с кодом. Claude Code имеет встроенный механизм multi-file editing и контекст-менеджмент, который влияет на то, как модель видит проект. Copilot CLI работает иначе — и результат другой.

Сколько стоит внешний ревью через модель? $0.0766 за 543k токенов в этом бенчмарке. Это примерно в 10–20 раз дешевле минимальной ставки час работы джуниор-разработчика. Для некритичных задач (скрипты, конфиги, не бизнес-логика) это экономически осмысленная замена ручного ревью.

Стоит ли переплачивать за Claude Code ради самотестирования? Зависит от задачи. Для VPS-тулкитов и инфраструктурных скриптов — да, если вы не хотите тратить время на ревью. Для прототипов и экспериментов — бюджетная модель достаточна при условии, что вы понимаете риски и готовы проверять output. Ключевой инсайт из бенчмарка: Model C потратил на self-testing столько же, сколько Model D на всю генерацию. Это не переплата — это другая модель работы.