Частоту ошибок ИИ в коде проверяют на задачах своего проекта, а не по общему проценту

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

В нашем бенчмарке РуБенч агент получает 25 задач, по три независимых прогона. Скрытый тест принимает или отклоняет починку; внутри захода дорешивать нельзя.

Рабочая задача живёт иначе: инженер уточняет условие, агент исправляет правку, команда принимает результат. Для выбора инструмента экзамен полезен. Для бюджета CTO нужны ещё возвраты и время проверки на своём коде.

Тесты проверяют только записанные условия. В правке 24 сентября функция начала отдавать новое поле, а валидатор ответа его не разрешал. Страница без кэша падала при чтении данных.

Проверка кода прошла, потому что тестовый инструмент не сверял ответ с этим валидатором. На открытой странице машины 8 октября показано «2 685 тестов на каждом пуше + ревью». Даже такой набор не доказывает, что проверено каждое условие.

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

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

Одна задача попадает в долю возвратов один раз, даже если агент переписывал её несколько раз. Число кругов исправления записывают рядом. Иначе одна трудная задача превращается в несколько «ошибочных задач» и портит знаменатель.

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

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

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

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

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

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

Повторяемость ответа модели ещё не гарантирует одинаковую правку агента при новом запуске.

Проверка дрейфа модели требует повтора контрольных задач и учёта смены версии.

Anthropic в руководстве от 9 января 2026 года связывает проверку агентов с определёнными задачами, стабильной средой и тестами результата. У нас есть опыт машины на vibecoding.ru; клиентского замера доли возвратов пока нет.

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

В журнале времени разделите проверку инженера, исправления агента и ожидание в очереди. Быстрая первая сдача с долгой проверкой не разгружает команду. Число коммитов эту работу не показывает.

Наш формат разработки по подписке «Один проект» стоит 250 000 ₽ в месяц на 8 октября 2026 года. Первый месяц и есть пилот. Его результатом для этой проверки станет журнал принятых и возвращённых задач одного репозитория.

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

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

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

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

1. Бенчмарк помогает выбрать кандидата; долю переделок измеряйте на задачах своего репозитория.
2. Зафиксируйте критерий до работы. Новый запрос клиента отмечайте отдельно от ошибки.
3. Считайте возврат задачи один раз на первой приёмке; круги исправлений и открытые попытки сохраняйте рядом.
4. К доле возвратов добавьте время проверки и дефекты после выпуска за названное окно.
5. Повторяющийся возврат превращайте в проверку и измеряйте тот же тип задач снова.