Почему ИИ в разработке не ускорил релизы: куда уходит выигранное время
С тех пор, как искусственный интеллект взял на себя часть задач по написанию кода, бизнес закономерно начал ожидать ускорения разработки и сроков выхода продуктов. Но в реальности если даты релизов и начали сдвигаться, то незначительно. Сегодня обсуждаем, почему это происходит и какую роль играет ИИ в процессе создания продукта.
Разработка как часть проекта
Искусственный интеллект действительно помогает разработчику быстрее закрывать задачи — писать код, тесты, документацию, находить ошибки. Но здесь мы сталкиваемся с подменой понятий: нельзя оценивать скорость всего проекта по одному, пусть и важному, этапу. Прежде чем разработчик приступит к задаче, нужно провести предпроектное обследование, продумать архитектуру, согласовать решение и написать ТЗ. После создания код должен пройти ревью, тестирование, проверку безопасности, интеграцию и развертывание. Не забываем про то, что многие этапы нужно согласовывать с заказчиком.
Само программирование занимает лишь часть этого цикла. Условно говоря, если функцию написали за день вместо трех, но затем она неделю ждет проверки, срок релиза почти не изменится. Это хорошо показал кейс консалтинговой компании Thoughtworks. В одном из сценариев ИИ применялся примерно в половине задач и сэкономил на них около 30% времени. Но так как непосредственно разработка занимала только 55% совокупного времени команды, то в итоге весь цикл ускорился лишь на 8%.
Можно сказать так: скорость проекта определяется не самым быстрым этапом, а главным ограничением всей цепочки. Если раньше таким ограничением было написание кода, то теперь оно может переместиться в аналитику, тестирование или согласования.
Больше кода — больше очередь
На первый взгляд может показаться неочевидным, но рост производительности разработчиков способен увеличить нагрузку на смежные команды — аналитиков, тестировщиков, ревьюеров и других специалистов.
Почему так происходит? Представим, что до внедрения ИИ команда передавала на ревью около десяти изменений в неделю, а после — пятнадцать или двадцать. Но количество опытных разработчиков, способных проверить код, при этом не увеличилось. Как результат — pull request создаются быстрее, зато дольше ждут проверки.
То же происходит в тестировании: разработчики выпускают больше функций, а QA-команда должна проверить больше сценариев, интеграций и возможных регрессий. Если ее ресурсы остались прежними, время, выигранное на написании кода, превращается в очередь на тестирование.
Кроме того, ИИ-код не всегда проще проверять. Он часто выглядит аккуратно и убедительно, даже когда содержит контекстную или логическую ошибку. Это хорошо демонстрирует еще одно свежее исследование, на этот раз от CodeRabbit: из 470 открытых pull request в ИИ-сгенерированных оказалось около 10,8 проблем в среднем — против 6,45 в написанных человеком. Разница особенно проявлялась в логике, поддерживаемости, безопасности и производительности.
Быстрее, но не то
Кроме создания очередей, ИИ может растянуть и сам процесс разработки: специалисту нужно проверять сгенерированный код, уточнять запросы, отбрасывать неудачные варианты и исправлять скрытые ошибки. Если задача поставлена плохо, алгоритм поможет быстрее реализовать решение, которое затем придется дорабатывать, заново согласовывать и тестировать. Иначе говоря, ускорится не выпуск продукта, а производство переделок.
Особенно это заметно при работе со сложными системами и легаси-кодом. Модель не всегда знает весь контекст проекта, историю архитектурных решений и внутренние ограничения — так что сэкономленные на первоначальном написании минуты могут в итоге превратиться в часы отладки.
И проблема вовсе не обязательно в плохой работе искусственного интеллекта. Когда создавать код становится проще, команды начинают делать больше изменений и укрупнять их — а даже качественный код требует внимания человека, особенно если он затрагивает критичные части продукта.
Что поможет ускорить релизы
Конечно, все это не значит, что компаниям нужно отказаться от ИИ в разработке. Вопрос в другом: недостаточно выдать программистам помощника и ждать пропорционального ускорения всей команды. Вместо этого нужно оптимизировать полный цикл создания продукта.
Для начала стоит смотреть не на количество коммитов и закрытых задач, а на время от идеи до выхода изменения в продакшен. Важно замерять не только каждый этап, но и время между ними — например, пока задача ждет аналитики, ревью или тестирования. Это позволяет найти новое узкое место и поработать именно с ним. Может оказаться, что проблема решается наймом в команду двух дополнительных тестировщиков.
Автоматизацию тоже нужно распространять дальше написания кода: использовать ИИ для подготовки требований, первичного ревью, поиска рисков и создания тестовых сценариев. При этом важно не укрупнять изменения только потому, что теперь их проще генерировать — небольшой pull request быстрее понять, проверить и безопасно выпустить.
В конечном счете эффективность ИИ определяется не объемами написанного кода, а тем, насколько быстрее полезное и стабильное изменение дошло до пользователя. Писать код мы уже научились быстрее — теперь предстоит разогнать все, что происходит вокруг него.
