Наблюдения за экосистемой Jev (6): оценка качества кода, или реальные цифры против заявлений

В предыдущей статье мы разобрали границы доверия к примитивам принятия решений. Здесь займёмся одним из самых громких заявлений экосистемы: оценкой качества кода. «Ревью кода с Jev», «оценка PR», «проверка достаточности тестов»: десятки таких проектов появились в первые 72 часа после релиза, но лишь немногие провели контролируемые эксперименты и опубликовали данные о стоимости и границах точности. В статье упоминаются только проекты с опубликованными метриками, голословные заявления исключены.

Почему оценка качества кода естественно подходит для Jev

Свойства ревью кода совпадают со свойствами примитивов принятия решений: узкие суждения (соответствует ли код конкретным стандартам), высокая частота (проверка нужна при каждом коммите) и ветвящиеся результаты (принять, отклонить, доработать). Традиционное ревью с LLM требует десятков секунд на инференс и не вписывается в пайплайны CI/CD. Субсекундная задержка Jev впервые делает экономически оправданной проверку каждого коммита.

Однако хорошая совместимость не гарантирует правильности. Независимые оценки в экосистеме дают количественные данные о нескольких ключевых границах.

agentjournal: пять выводов за $1,43

Оценка agentjournal содержит результаты строгих контролируемых экспериментов первой недели: три задачи классификации, 5 477 тестовых записей и общие затраты $1,43. Три из пяти выводов напрямую касаются сценариев, связанных с качеством кода:

Во-первых, разбиение на измерения не всегда улучшает результат. На простой задаче (200 ответов B2B с подвохами) прямой вопрос даёт точность 100%, а разбиение на 12 измерений снижает её до 98%: токенов уходит больше, а результат хуже. Вывод для ревью кода: если критерии ясны, отдельная многомерная оценка не нужна.

Во-вторых, слишком широкий выбор вариантов приводит к сбоям. На бухгалтерских данных один вызов Choice с 12 вариантами дал точность 39,98%. Вывод для классификации PR: не просите модель выбирать из десятков категорий, разбейте их на бинарные вопросы «да/нет».

В-третьих, уверенность не связана с правильностью. На строках, где модель сообщала о высокой уверенности (≥0,9), точность составила лишь 72,2%. Вывод для гейтов в CI: высокая уверенность не может быть достаточным условием для прохождения проверки.

Supercov: сужение вопросов ревью до механических проверок

Supercov — инструмент оценки качества кода на Rust. Автор написал на Reddit, что если передать файл целиком и спросить «какое здесь качество?», результаты получаются плохими, а узкие механические проверки вроде duplicated_code и deep_nesting работают лучше. Сравнение с коммерческими инструментами и заявленная стоимость в 100 раз ниже — самооценка автора, а не независимый бенчмарк.

Главный урок: качество оценки в Jev зависит от того, насколько конкретно сформулирован вопрос.

Jev Review: поэтапное ревью

Jev Review (417★ по состоянию на 21.09.2026) делит ревью кода на несколько этапов, последовательно оценивая структуру, логику и стиль, и на каждом этапе использует свои наборы вопросов Noul/Score.

Где Jev подходит, а где нет

• Подходит: механические проверки в гейтах CI (дублирование кода, глубина вложенности, соглашения об именовании); поэтапное ревью PR; бинарная оценка достаточности тестового покрытия.
• Не подходит: комплексная оценка архитектуры; глубокий аудит уязвимостей безопасности; составные суждения, например о том, готов ли код к работе в продакшене.
• Комбинированный процесс: Jev для быстрого первичного отсева, затем LLM общего назначения для глубокого анализа.

Интеграция с EveryInfra

На вход оценке качества кода подаются диффы или содержимое файлов. Если перед ревью нужно получить код целевого репозитория, комментарии к issue или логи CI, эти задачи загрузки данных поддерживает EveryInfra. Начните с руководства по интеграции единого API данных.

В следующей части разберём ещё один крупный сценарий экосистемы: оценку контента и фильтрацию информации.