Пять месяцев разработки с AI: что ускорилось, а где остались узкие места

С февраля разработчики RetailCRM массово переходят на работу с AI-агентами. За пять месяцев число смерженных merge request выросло на 26%, средний time to market задач снизился на 39%. При этом медиана осталась примерно прежней. Для меня это повод посмотреть на весь путь задачи и понять, где теперь накапливается ожидание.

С какими результатами подошли к июлю

В промежуточных итогах я привёл несколько показателей. MR — предложение изменений кода, которое проходит рассмотрение и затем вливается в целевую ветку. Time to market, или TTM, — показатель длительности прохождения задачи. Точные границы расчёта в исходном посте не раскрыты.

В посте нет абсолютного числа задач, формального определения начала и конца TTM и точных границ периода сравнения. Поэтому по этим данным нельзя восстановить расчёт или оценить статистическую значимость. Это наблюдение за изменением нашей работы во время внедрения. Изолированный вклад агентов такой набор показателей не определяет.

Почему среднее и медиана расходятся

Медиана описывает середину упорядоченного ряда: половина задач проходит быстрее этого значения, половина — медленнее. Среднее учитывает длительность каждой задачи и сильнее реагирует на очень долгие работы. Поэтому снижение среднего при почти прежней медиане заслуживает отдельного разбора.

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

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

Рост кода ставит вопросы к остальному процессу

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

В наших наблюдениях объём изменений вырос заметнее, чем число MR. Для меня это сигнал внимательнее смотреть на размер поступающих на ревью изменений. Однако по опубликованным метрикам нельзя установить, сколько именно времени задачи провели на каждом этапе. Ревью здесь — один из кандидатов на дальнейшее исследование.

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

Переход начинается с привычки разработчика

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

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

При этом агенты участвуют пока лишь в 50–55% MR. В июльском сообщении я называл две причины. Небольшую правку иногда быстрее сделать напрямую. Молодых разработчиков мы переводим осторожнее: меня беспокоит риск поверхностного понимания и избыточного доверия результату. Это наша оценка риска, без отдельного исследования по уровням опыта.

Подготовленное окружение снимает повторяющиеся проблемы

Под harness я имею в виду всё, что помогает агенту работать внутри проекта: понятное окружение, быстрое развёртывание, линтеры, статический анализ, автотесты и инструкции в AGENTS.md. Эту часть я выделял ещё в заметке о начале перехода. Мы вкладывались в окружение до массового использования AI, и, по моему наблюдению, это помогло стартовать.

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

Мы также дали агентам инструменты и скиллы для Redmine и GitLab: оформление MR, проверку CI и работу с задачей по принятому процессу. Так часть повторяющихся операций ушла из ручной работы разработчика. На крупных проектах с историей подготовка окружения к июлю остаётся незаконченной.

Что будем менять дальше

Ближайший план на момент публикации — подключить агентов к ревью и продолжить улучшать окружение. Хочется увидеть, как это повлияет на путь задачи целиком. Результатов этого этапа в июльских цифрах ещё нет.

Ещё одно направление — небольшие автономные команды. Часть наших команд уже работает так. Я вижу смысл в том, чтобы люди могли быстрее принимать решения и доводить задачу до выпуска с меньшим числом передач. Сами приведённые метрики пока не доказывают преимущество определённого размера команды.

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