Dsight

ИИ в разработке: одного пилота на всю IT-функцию недостаточно Вопрос «ускоряет ли ИИ разработку» поставлен слишком широко. GitHub Copilot, Claude Code и Cursor могут ускорить одни типы работ и замедлить другие. Усреднение по компании это скроет. В трёх рандомизированных экспериментах Microsoft, Accenture и компании из Fortune 100 разработчики с GitHub Copilot завершали примерно на четверть больше задач. Но эксперимент METR дал обратный результат: опытные специалисты в зрелых проектах, которые они хорошо знали, тратили с ИИ примерно на пятую часть больше времени. В исследовании 2026 года в технологической компании среднего размера (802 разработчика) рост числа одобренных изменений кода пришёлся в основном на новый код. При этом количество изменений на одного проверяющего почти удвоилось. То есть результат зависит не только от инструмента, но и от типа работы. Поэтому пилот стоит делить не по командам, а по трём очередям: - новая функциональность и новые сервисы; - изменения зрелого критичного ядра; - исправление дефектов и поддержка. В каждой очереди нужен поэтапный запуск на сопоставимых задачах, чтобы оставалась контрольная группа. Считать стоит не строки кода и не принятые подсказки, а медианный срок от постановки задачи до выпуска, часы проверки и переделок, долю откатов и инцидентов, полную стоимость инструмента и контроля на успешно выпущенное изменение. Масштабировать нужно только тот сегмент, где полный цикл стал короче без роста ошибок и стоимости проверки. Результат на новом сервисе нельзя автоматически переносить на зрелые критичные системы.

Источники: три полевых эксперимента; эксперимент METR; кейс 802 разработчиков; метрики GitHub.