[Ø Null Review](/)[Безопасность и архитектура](/security)

ДЛЯ КОМАНДЫ И РУКОВОДИТЕЛЯ

# Проверить пользу AI-ревью.На одном репозитории.

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

[Обсудить пилот ↗](/#book-demo)[Посмотреть пример ревью](/#review)

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

01 · ПРОБЛЕМА И ГИПОТЕЗА

## Что хотим изменить

### Сейчас

- Готовые MR ждут внимания занятого ревьюера.
- Договоренности после инцидента остаются в документах.
- Под давлением сроков замечания проверяют поверхностно.

### Проверяем в пилоте

- Может ли Null дать полезное замечание раньше ручного ревью.
- Помогают ли правила проекта находить повторяющиеся ошибки.
- Окупается ли разбор замечаний временем и полезными находками.

Это гипотезы, не установленная ситуация в конкретной компании. Исходные показатели снимаем вместе с командой.

02 · ГРАНИЦЫ

## Ограничить риск и объем работы

РЕПОЗИТОРИЙ 

### Один понятный участок

Выбрать проект и закрытые MR с известными дефектами. Зафиксировать версии и условия оценки.

ДАННЫЕ 

### Согласованный маршрут

Определить модель, доступные файлы, хранение результатов и допустимые сетевые выходы.

ДЕЙСТВИЯ 

### Сначала черновики

Начать без публикации. Действия в GitLab включать отдельно после проверки прав и правил. Merge за командой.

РЕШЕНИЕ 

### Критерии до старта

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

03 · ПОРЯДОК РАБОТЫ

## От закрытых MR к рабочему процессу

- ШАГ 1 

### Ретро-прогон

Сравнить находки с известными дефектами. Отдельно записать пропуски и ложные тревоги.

- ШАГ 2 

### Разбор командой

Оценить замечания и донастроить правила. Не использовать те же MR как независимое доказательство улучшения.

- ШАГ 3 

### Новые MR

Проверить на свежих изменениях: время до полезного ответа, шум и нагрузку на ревьюеров.

- ШАГ 4 

### Решение

Расширять, дорабатывать или остановить. Причину зафиксировать в отчете.

04 · ОЦЕНКА

## Как поймем, что пилот полезен

Пороги согласуются с командой до запуска

| Что измеряем | Как фиксируем | Зачем это нужно

| Доля полезных замечаний | Ревьюер оценивает каждое замечание по согласованным правилам | Отделить помощь от объема сообщений

| Время команды | Ожидание первого полезного ответа и минуты на разбор | Проверить, не создали ли боту больше работы, чем он снял

| Известные пропуски | Сопоставление с дефектами в выбранных MR | Видеть границы инструмента, а не только удачные находки

| Контроль действий | Проверка прав, смены версии кода, истории и остановки | Не расширять доступ до приемки процесса

| Полные затраты | Модель, инфраструктура, внедрение и время команды | Сравнить пользу с реальной стоимостью

05 · ОТВЕТСТВЕННОСТЬ

## Кто нужен для запуска

### Со стороны компании

- Владелец пилота: критерии, сроки и решение.
- Техлид и ревьюеры: примеры и оценка замечаний.
- Platform / ИБ: инфраструктура, доступы, модель и маршрут данных.

### Со стороны Null

- Василий Петров, владелец проекта.
- Совместная настройка правил и процесса.
- Разбор результатов и согласование следующего этапа.[vasiliy.petrov@uwukl.com ↗](mailto:vasiliy.petrov@uwukl.com?subject=Null%20Review%20pilot)

СЛЕДУЮЩИЙ ШАГ

## Согласовать один репозиторий и владельца пилота

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

[Обсудить пилот ↗](/#book-demo)[Что готово и что в планах](/docs#limits)

[Продукт и сравнение подходов](/) · [Оставить обратную связь](/#feedback)

Null Review дополняет тесты и ревью людей. Публичные показатели экономии и SLA пока не заявлены. Бюджет и сроки согласуются до начала работ.