На встрече команда решила без записки. Компания берёт лицензию ИИ на каждого разработчика и включает ревьюера во всех репозиториях, а правила команда допишет по ходу. Через месяц тимлид не может назвать, что стало лучше. Разработчики закрывают комментарии в пул-реквестах, не читая их, а сам тимлид тратит на этот текст больше времени, чем раньше тратил на изменение в коде.

За этот месяц команда увидела конкретные сбои, и ни один не зажёг красную сборку. Модель дописала в тикет поведение, которого команда не просила. Автор влил исходный вариант в основную ветку, а ревьюер спорил уже с выдуманным списком. Комментарий к пул-реквесту говорил про имена и крайние случаи и не назвал ни одного случая. Сгенерированный тест проверял, что функция возвращает своё текущее значение, вместе с багом. Кто-то вставил в чат вендора пароль от базы, токен доступа и письмо клиента, потому что так быстрее было объяснить ошибку.

Счёт за лицензии компания при этом уже оплатила. Других чисел у тимлида нет. Кроме этого счёта он не может показать на планёрке ни одной цифры.

Почему инструмент не стал шагом

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

Команда не назвала владельца этого шага. Когда комментарий ошибочный, тимлид не назначает человека, который поправит правило. Тимлид не считает фразу «пусть помогает разработчикам» правилом. Модель, которой можно переписывать тикет, одобрять свои тесты и комментировать каждый файл, делает все три вещи. Разработчики видят пустые советы и перестают читать пачку целиком, включая тот комментарий, который попал в настоящий пропуск.

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

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

Отдельно команда получает зелёную проверку, хотя модель промолчала. Этот случай уже разобран в заметке когда проверка ИИ пропускает ошибку и остаётся зелёной. Здесь этот механизм не повторяется. Человек по-прежнему читает путь, куда войдёт изменение: об этом десять признаков, что коду нужно ревью.

Какие правила пишут до пилота

Тимлид выбирает один этап, где боль уже видна, и на время пилота не трогает остальные. Вариантов четыре, и тимлид берёт в работу один. Критерии приёмки в тикете: модель предлагает строки, человек из команды оставляет те, с которыми согласен. Ревью пул-реквеста по чек-листу команды: модель называет пункт, которого нет в изменении, и не придумывает новый чек-лист. Пропуски в тестах на изменённом коде: модель называет ветку или случай без теста и не коммитит тест, который только повторяет текущий возврат функции. Заметки к релизу: модель собирает черновик из закрытых тикетов, а автор релиза правит текст до публикации.

До старта тимлид кладёт в репозиторий три фразы. Что шаг делает: в этом репозитории проверка перечисляет пункты чек-листа, которых нет в изменении. Чего она не делает: не одобряет пул-реквест, не переписывает тикет и не обсуждает имена. Кто утверждает: автор закрывает настоящий пропуск, или ревьюер пишет, что пометка ложная, и ставит своё имя и дату. Слово «команда» тимлид в эту строку не пишет, потому что тогда никто не отвечает за пометку.

В том же файле тимлид пишет правило про данные. Модель может читать код пилотного репозитория и текст тикета. Боевые данные, письма клиентов, пароли от базы и токены доступа она не видит. Тимлид называет в списке репозитории пилота и отдельно те, которые в пилот не входят. Если промпту нужна строка из лога, разработчик вырезает секреты до того, как строка уйдёт с его машины. Разработчик не кладёт дамп с боя в чат вендора.

Как проходит пилот на одном репозитории

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

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

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

Проверка либо останавливает слияние, когда модель не ответила или нашла названный пропуск, либо в самом комментарии написано, что это совет и слияние он не блокирует. Зелёную сборку на ошибке модели тимлид не называет контролем качества. Как устроить проверку, которая не пропускает молчание модели, описано в соседней заметке. Следующий этап начинают только после того, как одна цифра сдвинулась и люди всё ещё читают пометки. Лицензии для тех, кто не трогает пилотный репозиторий, ждут, пока второй репозиторий повторит результат.

Что специалист оставляет после сессии

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

Эта страница и есть план внедрения. Это не новый продукт и не чат на сайте. Услуги закрывают такой проход по коду, который команда уже выпускает. Перед тем как открывать второй этап внедрения, стоит начать с технического аудита и ревью кода вашего рабочего репозитория. Работы оставляют каждый результат рядом со своей операцией. Если нужна эта страница, пришлите этап, который болит, чек-лист, которым команда уже пользуется, и умеет ли текущая проверка ИИ остановить слияние. Пароли, токены доступа и данные клиентов в сообщение не кладите.