AI-ассистенты для кода: почему продуктивность растёт не у всех и не всегда

AI-ассистенты для написания кода часто продают как универсальное средство, которое резко повышает продуктивность команды. Но статья показывает более сложную картину: выигрыш зависит от задачи, опыта разработчика, зрелости кодовой базы и того, как именно измерять результат. В некоторых случаях инструмент действительно помогает быстрее писать шаблонный код, небольшие функции, тесты и документацию, особенно в знакомых фреймворках. В более реалистичной работе, где нужно разобраться в существующей системе, сохранить архитектурные договорённости, отладить крайние случаи и согласовать изменения между файлами, преимущество может сократиться, исчезнуть или стать отрицательным. В тексте приводится пример: исследование GitHub, Microsoft и MIT 2024 года показало, что разработчики с GitHub Copilot быстрее справились с относительно простой задачей. Этот результат поддерживает идею, что ассистенты ускоряют некоторые рабочие процессы. Однако более поздние исследования с опытными разработчиками и большими кодовыми базами дали менее воодушевляющие результаты. В частности, работа METR 2025 года сообщала, что опытные разработчики open-source, работавшие в собственных репозиториях, были медленнее при использовании AI-инструментов, хотя обычно считали, что те помогли им двигаться быстрее. Разрыв между ощущаемой и измеренной продуктивностью статья называет одним из самых важных наблюдений в этой области. Практическая причина в том, что разработка ПО — не только набор текста. Предложение, которое выглядит правдоподобно, всё равно нужно проверить: запустить локальные тесты, оценить безопасность, привести код к стилю команды и встроить в существующие абстракции. Если ассистент выдаёт код, правильный на 80 процентов, оставшиеся 20 процентов могут стоить дорого. Разработчику сначала нужно понять, что именно сгенерировала модель, а затем решить, принять код, отредактировать его или отклонить. Для новичка это может быть полезным ускорением на простых учебных задачах, но для поддержки сложной системы — дополнительной нагрузкой. Отдельно статья говорит о проверке и ревью. Сгенерированный код часто выглядит связным и даже компилируется, создавая ощущение прогресса. Но нужно убедиться, что он соответствует требованиям, правильно обрабатывает авторизацию, соблюдает контракты данных, использует нужные абстракции и безопасно завершается при ошибках. Если ассистент придумал API, пропустил проверку на null, выбрал неэффективный запрос или проигнорировал принятый в команде шаблон, разработчик должен это заметить и исправить. Такой разбор может занять больше времени, чем написать код вручную, особенно если инженер уже хорошо знает участок. Ещё один источник замедления — избыточная генерация. Небольшое изменение может превратиться в большой патч с вспомогательными функциями, абстракциями или тестами, которые добавляют стоимость поддержки без явной пользы. Ревьюерам приходится отделять осознанные проектные решения от машинного «наполнителя» и проверять код, который автор не всегда может полностью объяснить. Поэтому статья советует командам измерять реальные результаты: время цикла, долю дефектов, нагрузку на ревью, опыт разработчиков и стоимость поддержки. Главный вывод не в том, что AI-ассистенты бесполезны, а в том, что их эффект неравномерен и зависит от контекста; оценивать его нужно по выпущенному и корректному коду, а не по ощущению скорости.