GitVelocity: Анализ 50 тысяч PR с помощью ИИ выявляет взаимосвязь со сложностью кода

Как работает GitVelocity

GitVelocity подключается к вашим репозиториям на GitHub, GitLab или Bitbucket и использует Claude (по умолчанию Sonnet 4.6, который работает почти так же хорошо, как Opus 4.6, но дешевле) для анализа каждого объединённого pull request'а. Каждый PR получает оценку от 0 до 100 по шести параметрам:

• Масштаб (0-20)
• Архитектура (0-20)
• Реализация (0-20)
• Риск (0-20)
• Качество (0-15)
• Производительность/Безопасность (0-5)

Оценки по шести параметрам суммируются, затем масштабируются по размеру изменений с помощью множителя — исправление на 10 строк получает более низкую оценку, чем рефакторинг на 500 строк, даже при одинаковой сложности. Полная формула доступна по адресу gitvelocity.dev/scoring-guide.

Ключевые выводы из 50 000+ PR

Анализ более 50 000 PR на нескольких языках программирования выявил несколько неочевидных закономерностей:

• Большие PR не получают автоматически высоких оценок: Миграция на 800 строк с низкой сложностью оценивается хуже, чем архитектурное изменение на 200 строк. Размер даёт полный множитель, но базовый балл всё равно нужно заработать.
• Нельзя получить хорошую оценку без тестов: Параметр качества (0-15) не даёт баллов без покрытия тестами. При схожем уровне опыта это было самым явным различием между инженерами.
• Начинающие разработчики начали опережать некоторых опытных коллег: Они быстрее внедряли ИИ-инструменты и брались за более сложные задачи. Как только они увидели свои оценки, они стали стремиться к более высоким результатам.
• Код, сгенерированный ИИ, оценивается так же, как код, написанный человеком: Код есть код. Инженер, который использует ИИ для более быстрой реализации сложной работы, более продуктивен, и его оценки отражают это.

Технические детали реализации

Согласованность оценок была самой сложной технической проблемой. Без эталонных примеров, закрепляющих каждый параметр, оценки Claude колебались на 15+ баллов между запусками. Команда решила эту проблему, создав 18 калиброванных эталонов (по три на каждый параметр: низкий/средний/высокий), что снизило разброс до 2-4 баллов для одного и того же PR.

Инструмент использует модель BYOK (bring your own Anthropic API key) и стоит копейки за PR. Исходный код не хранится — диффы анализируются и сразу удаляются.

Влияние на поведение и командные функции

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

Каждая оценка полностью видна инженеру, написавшему PR, с разбивкой по параметрам и обоснованием. Нет скрытой панели управления, которую видит руководство, а инженеры — нет.

GitVelocity недавно добавил командные бенчмарки (gitvelocity.dev/demo/benchmarks). Как только вы начинаете оценивать PR, вы можете увидеть, как ваша команда сравнивается с другими в наборе данных — пока около 1000 инженеров в 60 командах. Команды, которые скептически относились к индивидуальным оценкам, искренне заинтересовались, когда смогли измерить себя на фоне других.