GitHub начал измерять ревью: где команды теряют скорость с AI

GitHub отдал медиану и p90 стадий code review через API. Разбираем Sonnet 5.5, валидатор политик Copilot и почему AI оценивают по времени до мержа.

  • Повод: пять обновлений GitHub за неделю
  • Генерация дешевеет, и это измеримо
  • Узкое место переехало в ревью
  • Политики, которые молча не применяются

Повод: пять обновлений GitHub за неделю

  1. За последнюю неделю сентября GitHub выпустил пять обновлений: Claude Sonnet 5.5 в Copilot, стадии code review в Usage metrics API, валидатор корпоративных настроек Copilot, AI-агент для аудита безопасности и Git 2.56.

  2. Вместе они показывают, где команда теряет время.

  3. Модели уже пишут код быстро и дёшево.

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

Генерация дешевеет, и это измеримо

По внутренним тестам GitHub, Sonnet 5.5 решает задачи по коду на уровне Sonnet 5, но тратит меньше шагов, токенов и вызовов инструментов и заканчивает быстрее. Вызов инструмента - это действие агента: прочитать файл, запустить тест, поискать по репозиторию. Каждое действие стоит времени и денег. Copilot списывает стоимость модели по прайсу провайдера в рамках usage-based billing, поэтому сэкономленные токены напрямую уменьшают счёт.

Отсюда правило для руководителя: новую модель сравнивают по цене и времени одной закрытой задачи. Бенчмарк «насколько модель умная»

на этот вопрос не отвечает.

Узкое место переехало в ревью

Самое важное обновление недели выглядит скромно. В отчётах Copilot usage metrics появился массив `pull_request_review_times`.

Он отдаёт медиану и 90-й перцентиль для трёх интервалов: - от статуса «готов к ревью» до первого ревью; - от первого ревью до финального; - от финального ревью до мержа.

Медиана описывает типичный pull request

90-й перцентиль (p90) описывает хвост: 9 из 10 PR проходят стадию быстрее этого значения, а десятый застревает.

Задачи из хвоста и срывают релизы

В этой версии оба поля, `authored_by` и `reviewed_by`, относятся к людям. GitHub начал с того, сколько ждут живые ревьюеры, и это логично.

Если AI удвоил число PR, а ревьюеров столько же, очередь растёт, и путь от идеи до продакшена может даже удлиниться.

Эти три интервала - часть того, что DORA называет lead time for changes.

Раньше команды собирали такие данные своими скриптами, теперь GitHub отдаёт их по стадиям через API.

Мы в KT.Team называем это TTU, time to use: время от задачи до работающего результата.

Если PR три дня ждёт первого взгляда, скорость набора кода на TTU почти не влияет. Туда же бьёт Git 2.56.

Его собрали 104 контрибьютора, 39 из них впервые, и среди изменений есть возможность проиндексировать разрешённые конфликты, не добавляя в индекс остальные правки.

Пока веток мало, эта функция почти не нужна.

Когда агенты параллельно открывают десятки веток, конфликтов слияния, по нашей гипотезе, становится больше (GitHub это не измерял), и аккуратное разрешение конфликтов сбережёт ревьюерам часы.

Оценить, где ИИ даст эффект в вашем процессе

Политики, которые молча не применяются

  1. Валидатор enterprise managed settings проверяет файлы `copilot/managed-settings.json`, `copilot/team-mappings.json` и связанные настройки команд.

  2. Он ловит битый JSON, неподдерживаемые параметры и неверные привязки команд, то есть ошибки, из-за которых политика не применяется.

  3. Для каждой ошибки он указывает файл и JSON-путь. Цена такой ошибки высокая.

  4. Служба безопасности считает, что команде запрещена модель или внешний контекст, а запрет не действует из-за опечатки в конфиге. В проектах LLM & Security Gateway мы храним правила доступа к моделям в репозитории и проверяем их до выкатки: какие модели доступны, какие данные можно отправлять наружу, что пишется в лог.

  5. Непроверенная политика защищает компанию только на слайде.

Агенту нужен маршрут

  1. Команда GitHub Security Lab нашла 24 уязвимости в Android-приложениях своим открытым Taskflow Agent.

  2. Исследователь разбивает аудит на последовательные шаги и упаковывает их в переиспользуемый сценарий, taskflow.

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

  4. Результат дала связка модели и спроектированного процесса.

  5. По тому же принципу мы строим AI-native development: задача, контекст из кодовой базы и документации через MCP, генерация, автотесты, ревью.

  6. Модель в этом контуре мы меняем за день.

  7. Процесс вокруг неё строится месяцами, и результат даёт именно он.

  8. Со стороны контур выглядит простым, но за этой простотой стоят месяцы инженерной работы и отлаженные правила команды.

Что сделать до следующего бюджета на AI

Снимите медиану и p90 по трём стадиям ревью сейчас, до смены модели или покупки новых лицензий. Без базовой линии эффект потом не доказать.

Следите за p90 времени до мержа

Если после внедрения AI он вырос, поставка замедлилась, хотя генерация ускорилась.

Сравнивайте модели по стоимости и времени закрытой задачи, с учётом шагов и вызовов инструментов.

Проверяйте конфигурацию политик как код, автоматически и до выкатки.

Давайте агентам явные сценарии из шагов вместо одного промпта «найди всё».

Вывод

Мы читаем эти метрики так: GitHub предлагает оценивать инструмент генерации кода по времени, за которое код доходит до мержа. Бизнес платит за изменения в продакшене. Если через квартал после внедрения Copilot или Claude ваш p90 от «готов к ревью» до мержа не сократился, вы купили дорогую клавиатуру. Цифры для проверки теперь лежат в API, и через год финансовый директор не примет отговорку «эффект сложно измерить».

Обсудить статью: GitHub начал измерять ревью: где команды…

Укажите email или телефон, чтобы мы могли вам ответить.

Отправить через: