Переделывать за ИИ тоже работа

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

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

Берём изменения из репозитория и замечания к ним. Проверяем, что ИИ знал о задаче, какие ограничения получил и что именно не устроило ревьюера. Может оказаться, что ИИ не хватило знаний о системе. Или сама команда по-разному понимает, когда задачу можно считать готовой.

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

Сравниваем похожие задачи и заранее договариваемся, какой результат считать готовым. Учитываем подготовку контекста и работу с ИИ, затем ревью инженером и исправления. Разовую настройку отмечаем отдельно, чтобы понимать, сколько повторений нужно для её окупаемости.

И сохраняем случаи, где стало хуже. Одно удачное изменение ещё не даёт основания перестраивать весь процесс. Если задачи слишком различаются, результат сравнения останется предварительным.

У команды останутся правила проверки и данные о затраченном времени. По ним решим, что пробовать дальше. Если экономии нет, так и запишем.