Пробный период AI-ассистента для программирования на один реальный спринт

Почему слишком ранний полный запуск может ввести в заблуждение

Яркая демонстрация может легко ввести команду в заблуждение. Ассистент за секунды пишет функцию, объясняет баг и предлагает тесты. Это выглядит впечатляюще. Но спринт — это другое. В него входят ревью, переделки, упавшие тесты, исправления в названиях, пограничные случаи и все те мелкие правки, которые могут съесть целый день.

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

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

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

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

Честная метрика — не «он быстро написал код?». Она звучит так: «закончился ли этот спринт с меньшим общим объёмом работы?». Если один инженер сэкономил 90 минут на написании кода, но добавил час на ревью и ещё 45 минут на исправление тестов, это не очевидная победа.

Выберите одного инженера и один реальный спринт

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

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

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

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

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

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

Определите, что вы будете измерять

Большинство пробных запусков проваливаются потому, что команды считают только результат и игнорируют дополнительную работу вокруг него. Полезный вопрос не «написал ли инженер больше кода?». Полезный вопрос — «потратила ли команда меньше общего времени на безопасное слияние кода?».

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

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

Время на ревью важно, потому что оно показывает скрытую стоимость. Запрос на изменения может выглядеть быстрым в написании, но всё равно съесть 40 минут времени ревьюера, если код шумный или ему трудно доверять.

Падения тестов рассказывают другую историю. Считайте только те сбои, которые связаны с частью изменения, созданной ассистентом. Если flaky integration test упал по несвязанной причине, не учитывайте его. Вам нужен сигнал, а не драма.

Доработки — это место, где многие пилоты выглядят лучше, чем есть на самом деле. Ревьюеры часто просят небольшие исправления, которые складываются в заметную сумму: убрать дублирующие хелперы, упростить условия, добавить недостающие пограничные случаи, поправить именование или подогнать код под существующие шаблоны. По отдельности это не выглядит большим, но десять минут тут и пятнадцать там могут полностью съесть выигрыш.

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

Для базы сравнивайте последние три–пять похожих запросов на изменения того же инженера. Старайтесь максимально точно сопоставлять тип работы. Багфиксы должны сравниваться с багфиксами. Небольшие изменения API не должны конкурировать с большим рефакторингом.

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

Настройте пилот так, чтобы его можно было повторить

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

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

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

Сама настройка может оставаться очень простой. Добавьте один ярлык к каждому запросу на изменения, где ассистент помог. Попросите инженера записывать время начала и окончания каждой задачи в одной общей таблице. Фиксируйте задержки из-за встреч, ожидания ответа или проблем с локальной настройкой. Сохраняйте ваше обычное определение готовности. Запускайте те же тесты, проверки и утверждения, которые вы бы использовали и без ассистента.

Не смягчайте правила разработки только потому, что инструмент пишет быстрее. Оставьте linting, тесты, security checks и правила ревью такими же, как были. Иначе вы измеряете не ассистента, а то, что происходит, когда команда снижает планку.

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

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

Проведите спринт и зафиксируйте работу

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

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

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

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

Комментарии на ревью важнее, чем ожидают команды. Сохраняйте замечания, которые повторяют одну и ту же проблему: отсутствующие пограничные случаи, небезопасные запросы, слабые названия или код, который игнорирует существующие шаблоны. Один комментарий — это шум. Тот же комментарий на четырёх задачах — это уже закономерность.

Отслеживайте упавшие тесты вместе с причиной, а не только по количеству. Неудачный прогон из-за того, что инженер изменил требование, — это не то же самое, что прогон, который упал из-за выдуманных методов, неправильных моков или хрупкого сгенерированного кода. Запишите причину одной короткой строкой, пока она ещё свежа.

Время на доработки часто теряется, а вместе с ним и реальная стоимость. Считайте работу, которая идёт после слияния: багфиксы, небольшие рефакторинги, обновления документации, hotfixes и помощь другого инженера, которому пришлось распутывать код. Если инженер тратит 40 минут на более быструю разработку, а команда потом 90 минут на зачистку, спринт лучше не стал.

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

Команды, которые работают экономно, уже мыслят так. Им важно, куда реально уходит время, а не просто как быстро код появляется на экране. Именно так на это смотрит и Oleg Sotnikov в своей работе с небольшими командами, переходящими к подходу AI-first: перепроверки, падения тестов и доработки после слияния важны не меньше, чем скорость черновика.

Смотрите на цифры в контексте

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

Разделите цифры на две части: время на черновик и время на ревью. Измерьте, сколько ушло на первую рабочую версию, а затем сколько — на проверку логики, исправление тестов, переписывание неясных мест и подготовку к безопасному слиянию. Такое разделение часто полезнее, чем общее время задачи.

Ищите не только итоги, но и группы. Если большинство сбоев связано с одним типом работы, это говорит больше, чем простой счёт pass/fail. Возможно, ассистент нормально справлялся с небольшими изменениями интерфейса, но буксовал на настройке тестов, пограничных случаях или изменениях данных. Такое ограничение тоже полезно.

Доработкам тоже нужна отдельная строка. Мелкие исправления тихо съедают сэкономленное время: более понятные названия, удалённый мёртвый код, менее хрупкие тесты, лучшее обработка ошибок и комментарии, которые объясняют, что код на самом деле делает. Если инженер сэкономил 90 минут на черновике, а команда потратила 70 минут на доработку, выигрыш есть, но он гораздо меньше, чем казалось.

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

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

Простой пример из одного спринта

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

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

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

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

Эти ошибки проявились в падениях тестов. CI дважды упал за спринт. Один прогон провалился потому, что сгенерированные тесты замокали не тот ответ сервиса. Второй — потому что миграционный скрипт сломался на старых строках с отсутствующими значениями. Инженер исправил оба случая, но доработка добавила около 90 минут.

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

Поэтому они сначала купили несколько мест и продолжили измерять ещё один спринт. Обычно это умнее, чем быстрый полный запуск.

Ошибки, которые искажают результат

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

Одна из частых ошибок — брать только лёгкие задачи. Если инженер весь спринт переименовывает переменные, пишет простые CRUD-экраны или правит тексты, ассистент будет выглядеть быстрее, чем он может быть на реальной продуктовой работе. Используйте задачи с обычной неопределённостью: багфикс, фичу с пограничными случаями или небольшой рефакторинг, где всё ещё нужен здравый смысл.

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

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

Одна из худших метрик здесь — количество строк кода. Больше сгенерированных строк может означать больше потерь, а не больше прогресса. Важна завершённая работа: слитый код, найденные дефекты, время на ревью, повторные тесты и исправления после ревью. Изменение на 40 строк, которое безупречно попадает в прод, лучше, чем 400 строк, которые потом два дня приводят в порядок.

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

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

Быстрая проверка перед покупкой дополнительных мест

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

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

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

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

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

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

Доработки должны оставаться на виду. Отслеживайте последующие коммиты, удалённый код, переименованные функции и мелкие исправления после слияния. Если каждый спринт доработки съедают полдня, стоимость лицензии — не главная проблема.

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

Что делать после пилота

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

Сделайте эту заметку простой и конкретной. Если время на ревью сократилось на 25 минут на задачу, но доработки добавили 10 минут из-за поспешных подсказок, так и напишите. Если тесты чаще падали в одной части кодовой базы, назовите эту часть. Краткая запись вроде этой не даст следующему обсуждению превратиться в спор мнений.

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

Эти правила не обязаны быть сложными. Достаточно одной короткой страницы во внутренней документации. Цель в том, чтобы убрать случайное использование и дать людям честный способ повторять то, что сработало.

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

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

Если перед покупкой мест для более широкой команды вам нужна вторая оценка, Oleg Sotnikov на oleg.is может посмотреть данные спринта, сопоставить реальную стоимость с сэкономленным временем и помочь выстроить запуск, который подходит небольшой команде, а не копирует привычки больших компаний.