AI ускорил разработку: как понять, что это правда

В эксперименте METR 2025 года опытные разработчики решали реальные задачи в знакомых репозиториях. Участники ожидали ускорения и после работы по-прежнему считали, что сэкономили время. Замеры показали, что с ИИ выполнение задачи заняло в среднем на 19 % больше времени. В эксперименте 16 разработчиков выполнили 246 задач. Условия относятся к знакомым проектам и инструментам начала 2025 года. В обновлении 2026 года оценивать эффект стало сложнее: часть участников уже не хотела работать без ИИ, а параллельные запуски агентов затрудняли учёт времени.

Microsoft наблюдала примерно на четверть больше слитых PR на инженера в день у ранних пользователей агентов. Авторы проверили, давал ли тот же метод похожий рост при выборе более ранней, условной даты запуска, и такого роста не увидели. Anthropic показывала рост числа коммитов на инженера и изменение работы в других функциях компании. Оба наблюдения дают повод посмотреть, какие изменения команда доставила и кому они помогли. Сравнивать эти результаты с METR как три оценки одной величины нельзя: длительность конкретной задачи, число слитых PR и активность сотрудников отвечают на разные вопросы.

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

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

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

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

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

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

На слайдах этот расчёт показан на условной партии из 100 PR. При ставке 60 долларов в час восемь часов работы и 30 долларов на ИИ дают 510 долларов. Пять часов и 20 долларов при новых правилах дают 320 долларов. Разница в 190 долларов имеет смысл при сопоставимом качестве ревью и показывает, сколько ресурсов могло бы освободиться в этом примере.

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

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

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

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