Бенчмарки ИИ для реальной работы в репозитории, которым доверяют команды

Почему публичные рейтинги не отражают вашу реальную работу

Публичные бенчмарки выглядят аккуратно, потому что задачи аккуратные. Чаще всего используются короткие промпты, изолированные файлы и проблемы с одним очевидным ответом. Реальные команды почти никогда так не работают.

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

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

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

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

Выбирайте задачи из собственного репозитория

Лучшие тестовые задачи происходят из реальной работы, которую ваша команда уже закрыла. Закрытые тикеты — идеальны. Они дают реальную проблему, известное решение и честный способ сравнить вывод модели с тем, что действительно ушло в прод.

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

Полезный набор обычно включает:

• исправление бага с явным упавшим тестом,
• рефактор, меняющий структуру, но не поведение,
• обновление зависимости или фреймворка, требующее мелких правок по репо,
• и хотя бы один «грязный» тикет с неясными заметками, старым кодом или слабым покрытием тестами.

Это сочетание важно. Если тестировать только блестящие фичи, вы пропустите рутинные задачи, которые отнимают большую часть времени инженерии. Многие команды тратят больше часов на патчи, уборку и миграции, чем на новые фичи.

Также важно разнообразие по сложности. Включите несколько простых задач, несколько средних и как минимум одну задачу, которую неприятно делать вручную. Простые задачи показывают, следует ли модель указаниям. Средние — умеет ли она прослеживать логику в нескольких файлах. Грязные — сможет ли она восстановиться по фрагментарным подсказкам, не делая опрометчивых изменений.

Перед тем как давать задачу модели, вычистите секреты и данные клиентов. Замените ключи API, емейлы, номера счетов, внутренние URL и приватные имена безопасными плейсхолдерами. Сохраняйте при этом форму проблемы. Если баг зависел от конкретного payload или строки лога, сохраните их структуру и формулировку.

Не удаляйте упавший тест, стек трейc или исходную заметку об ошибке. Эти детали часто отделяют умное исправление от догадки. "Checkout returns 500 when coupon is empty" нормально, но точный упавший тест и номер строки ошибки — намного лучше.

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

Пишите брифы, которым модели могут следовать

Размытый промпт портит честный тест. Если одной модели дают чистое задание, а другой — неопрятную заметку, вы оцениваете промпт, а не модель.

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

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

Строка «готово» важнее, чем многие думают. "Refactor this service" слишком расплывчато. "Remove duplicate parsing logic, keep the same output, and update tests for the two affected endpoints" даёт модели финишную цель.

Контекст должен быть коротким, но он должен покрывать скрытые предположения. Если задача зависит от бизнес-правила, спрятанного в старом чате или тикете, положите это правило в бриф. Не ожидайте, что модель догадается, почему один граничный кейс важнее другого.

Объём тоже имеет значение. Не бросайте в промпт двадцать файлов, если две файлы и один упавший тест объясняют задачу. Лишний шум заставляет слабые ответы выглядеть мыслительными, а хорошие — медленными.

Держите бриф идентичным для всех моделей. Не давайте одной модели подсказок после того, как она встала. Не вставляйте стек трейс в один прогон и забывайте о нём в другом. Если вы хотите второй раунд с подсказками, считайте это отдельным раундом и сравнивайте его отдельно.

Бриф вроде этого достаточен:

"Fix the retry bug in billing/webhook.ts. Duplicate invoices appear when the payment provider sends the same event twice. Follow the existing TypeScript style, use the current logger, and do not add dependencies. Done means one invoice per event, tests updated, and no change to the webhook response."

Это тот стандарт, который вам нужен. Модель получает достаточно контекста для действий, а ваша команда — результат, который можно сравнить между запусками.

Запускайте бенчмарк одинаково каждый раз

Честный тест требует скучной последовательности. Если одна модель стартует с другого коммита, видит дополнительные файлы или получает больше инструментов, вы измеряете настройку, а не модель.

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

Простой процесс работает хорошо:

1. Сбросьте репо на точный коммит.
2. Дайте модели одну задачу с одним письменным брифом.
3. Разрешите одинаковые инструменты — доступ в терминал, поиск, команды для тестов.
4. Сохраните полный промпт, вывод модели, изменённые файлы и затраченное время.
5. Попросите инженера применить патч ровно как сгенерирован, без предварительной чистки.

Запуск по одной задаче важен. Если вы объединяете исправление бага, рефактор и миграцию в один промпт, планирующие модели получают преимущество, а быстрые модели выглядят хуже, чем есть на самом деле. Разделяйте задачи, чтобы видеть, где каждой модели полезно и где она тормозит людей.

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

Сохраняйте всё, включая неуклюжие части. Храните оригинальный бриф, все последующие промпты, сырой вывод, логи терминала, результаты тестов и общее время. Позже, когда две модели будут близки, эти записи объяснят, почему одна заняла 8 минут, а другая — 25.

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

Когда вы это организуете, бенчмаркинг ассистентов по программированию начнёт выглядеть как реальная работа с репозиторием, а не как успех на демо‑дне.

Оценивайте результат простыми терминами

Модель не выигрывает потому, что написала больше кода или закончила первой. Она выигрывает, если ваша команда может вмержить изменение без долгой починки. Начните с базового вопроса: действительно ли вывод решил задачу?

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

Простейшая карточка оценки держит тест на земле:

• Задача решена: 1, если изменение соответствует брифу, и 0, если нет.
• Тесты: сколько существующих тестов проходят и появились ли новые провалы.
• Доработка вручную: сколько работы сделал инженер после остановки модели — минуты или число дополнительных коммитов.
• Контроль области изменений: изменения вне целевых файлов или проблемы.
• Читаемость и стиль: соответствует ли код вашим соглашениям по именованию, структуре и обработке ошибок.

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

Доработка вручную многое говорит о качестве. Если одна модель почти попала в цель, но разработчик всё равно потратит 40 минут на правки имён, импортов, граничных случаев и тестов, эта стоимость реальна. Другая модель может сгенерировать меньше кода, но потребовать только пару мелких правок. Большинство команд выберет вторую.

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

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

Держите рубрику достаточно простой, чтобы двое ревьюеров пришли к почти одинаковому выводу. Если каждая оценка превращается в спор, рубрика слишком расплывчата и не поможет выбрать модель.

Простой пример из одной продуктовой команды

Одна небольшая SaaS‑команда пропустила публичные таблицы лидеров и протестировала три задачи из одного репозитория. В репозитории был старый сервис логина, страница аккаунта на React и API‑клиент, сломавшийся после обновления пакета. Это напоминало обычную работу с репозиторием, а не лабораторное упражнение.

Первая задача была про логин. Пользователи со старыми хэшами паролей не могли войти после изменения в сервисе аутентификации. Обе модели нашли плохую ветку, но поступили очень по‑разному. Модель A переписала часть флоу, добавила хелпер и затронула пять файлов. Баг исчез, но дифф оказался больше, чем команда хотела. Модель B изменила одну проверку, добавила сфокусированный тест и оставила остальной сервис как есть.

Вторая задача — небольшой рефактор React. Два компонента настроек аккаунта повторяли одну и ту же форму. Модель A построила новую абстракцию и вынесла состояние в общий хук. Это работало, но изменяло страницу больше, чем нужно. Модель B сохранила компоновку компонентов, вынесла один хелпер и соответствовала именам и файловой структуре, уже принятой в репозитории. Ревью шло быстрее, потому что никому не пришлось переучиваться.

Третья задача пришла от обновления пакета. Новый клиентский библиотечный метод поменял одно поле запроса, и API‑вызов перестал работать. Модель A запатчила вызов, но ещё изменила обработку ошибок и обновила несвязанные импорты. Модель B исправила имя поля, поправила один тест и остановилась.

Команда держала простую систему оценки. Решила ли правка проблему? Сколько файлов было затронуто? Сколько длилось ревью? Похож ли код на остальной репозиторий?

Модель A выглядела сильнее, если считать только «сырый» вывод. Она написала больше кода, работала быстрее и предлагала широкие улучшения. Модель B выиграла, потому что инженеры вмержили её изменения с меньшими правками и меньшим числом комментариев к ревью. Это важнее эффектного ответа.

Распространённые ошибки, искажающие результат

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

Самая частая ошибка — дать одному прогону дополнительную помощь. Разработчик вставляет стек трейс в один промпт и забывает включить его в другой. Или отвечает на уточняющий вопрос только для одной модели. Это превращает тест модели в обучающий сеанс.

Дрейф сложности даёт другой плохой сравнительный результат. Одна задача — опечатка в React‑странице. Другая — миграция БД, обновление тестов и рискованный рефактор в шести сервисах. Если задачи не в одной шкале, оценки мало что говорят.

Доступ к инструментам важен так же, как и качество промпта. Если одна модель может искать по репо, запускать тесты и смотреть историю git, а другая получает только вставленные файлы, вы не сравниваете модели — вы сравниваете окружения.

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

Скорость может обманывать команды. Одна модель отвечает за 20 секунд кодом, который проходит один тест и ломает три скрытых предположения. Другая тратит две минуты и оставляет чище диффы, более безопасные имена и меньше побочных эффектов. Быстрый ответ приятнее в моменте, но затем инженеры платят за оставшийся беспорядок.

Команды также подбирают современные части кода, потому что их проще тестировать. Это создаёт ложное ощущение соответствия. Реальная работа с репозиторием включает старые миграции, shell‑скрипты, частично задокументированные сервисы и странные имена, оставшиеся от пяти лет назад. Если ваш бенчмарк игнорирует эти области, он переоценивает модели, которые хороши только на аккуратном коде.

Если вы хотите надёжных результатов, относитесь к честности как к части бенчмарка. Жёсткие правила лучше красивой системы оценок.

Быстрая проверка, прежде чем довериться победителю

Одна победа не гарантирует стабильности через неделю. Цель — не найти одноразового чемпиона, а инструмент, на которого команда может полагаться.

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

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

Результаты должны держаться в разных частях кода. Модель может отлично справляться с UI‑уборкой и плохо — с бэкенд‑багами или миграциями. Если у продукта есть два разных участка кода, протестируйте оба, прежде чем делать выбор.

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

Стоимость тоже нужно смотреть прямо. Если Модель A экономит 10 минут на рефакторе, но стоит в три раза дороже, чем Модель B, такое решение может не выдержать проверку временем. Небольшие улучшения качества могут быть реальны и при этом не окупаться по счетам.

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

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

Что делать после первого раунда

Первый запуск даёт снимок, а не окончательный ответ. Команды получают больше пользы, если превращают тест в небольшую рутину.

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

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

Небольшая рутина достаточна: держите 8–12 переиспользуемых задач в приватном наборе, перезапускайте набор каждый квартал или перед продлением контракта, заменяйте задачи, которые больше не соответствуют вашему стеку или стилю, отслеживайте результаты по типу задач и делитесь примерами хороших и плохих выводов с командой.

Обновляйте бенчмарк при смене стека. Набор, собранный вокруг Node.js монолита, мало скажет после переноса части продукта в сервисы на Go, добавления Terraform или изменения инструментов тестирования. Тестирование репозитория остаётся полезным лишь тогда, когда оно отражает код, с которым люди работают каждую неделю.

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

Если вашей команде нужна вторая точка зрения по процессу, Oleg Sotnikov на oleg.is делает Fractional CTO и консультации по AI‑первому подходу. Такой обзор полезен после того, как у вас уже есть один раунд результатов и вы хотите сделать следующий раунд точнее.