Довайбкодились. ИИ-инструменты экономят время, но убивают понимание кода?

ИИ увеличивает продуктивность разработчиков на 55% — по крайней мере, к такому выводу пришли в этом исследовании.

Неужели мы наконец-то нашли вот ту самую пушку, которую индустрия ждала не один десяток лет? Бери инструмент, закрывай задачи в два раза быстрее и иди пить кофе трать оставшееся время на саморазвитие или что-то в таком духе.

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

Кстати, несколько дней назад в блоге ISPsystem своими мыслями насчет использования ИИ в разработке поделился наш коллега Александр Брюханов — очень советуем прочитать его статью!

+55% к скорости — иллюзия и полуправда?

В основе оптимистичного тезиса из начала статьи лежит известное исследование GitHub. Для него взяли 95 профессиональных разработчиков, случайным образом разделили их на две группы и засекли время, необходимое им для написания HTTP-сервера на JavaScript. Одна группа использовала GitHub Copilot для выполнения задания, а другая — нет. При этом все разработчики уже были знакомы с JavaScript, и им всем дали одинаковые инструкции.

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

Что из этого вышло:

• Группа, использовавшая GitHub Copilot, показала более высокий процент выполнения задания — 78% по сравнению с 70% в группе, не использовавшей Copilot.

• Разработчики, использовавшие GitHub Copilot, выполнили задачу значительно быстрее — на 55% быстрее, чем разработчики, которые его не использовали. В частности, разработчикам с Copilot в среднем потребовалось 1 час 11 минут для выполнения задачи, а другой группе — 2 часа 41 минута. 

Кстати, сами испытуемые в этом исследовании честно признались, в чем именно заключается главная ценность инструмента на практике:

«Разработчики отмечали, что GitHub Copilot помог им оставаться в потоке (73%) и сохранить ментальные силы при выполнении повторяющихся задач (87%)» 

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

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

Парадокс опыта

Казалось бы, раз ИИ так хорош в рутине, он должен делать экспертов еще быстрее. Или нет?

Это решили проверить METR в рандомизированном контролируемом исследовании с участием квалифицированных специалистов.

Ученые взяли опытных разработчиков, каждый из которых имел в среднем пятилетний опыт работы в конкретных зрелых проектах, и предложили им решить 246 реальных задач, случайным образом разрешая или запрещая использование современных ИИ-инструментов вроде Cursor Pro и Claude.

Перед началом эксперимента разработчики прогнозировали, что ИИ сократит время выполнения задач на 24%. По итогам работы они субъективно оценили свою экономию времени в 20%. А вот реальные замеры показали, что использование ИИ-инструментов на самом деле увеличило время выполнения задач на 19%. То есть нейроассистенты создавали видимость более быстрого получения решения, но на самом деле замедляли разработчиков.

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

Почему так произошло?

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

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

Ловушка для джунов

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

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

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

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

Теперь абстрактному джуну в вакууме совсем не обязательно сталкиваться с какими-то первичными трудностями при решении задач — ведь за него все может сделать ассистент. А что произойдет, когда его код пойдет на ревью? Ведь ревьюер или даже просто старший коллега может задать вполне логичные вопросы, например, о выборе метода или особенностях его работы. Сможет ли автор кода ответить на эти вопросы или скажет, что оно само так сгенерировалось? В лучшем случае ревьюеру придется потратить не 15 минут на стандартную проверку, а два часа на объяснение базовых концепций, которые джун должен был освоить самостоятельно. 

Что в итоге

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

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

Тут нужно сделать еще одну оговорку, этот обзор на данных 2019-2023 гг., когда ИИ-инструменты были слабее, хуже держали контекст и пр., однако фундаментальный риск остается актуальным и по сей день.

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

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

Экзоскелет, а не автопилот

Да, мир изменился. И в разработку без ИИ-ассистентов мы уже не вернемся — это точно.

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

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

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

Расскажите, сталкивались ли вы сами с тем, что код, написанный с ИИ, оказался в поддержке сложнее, чем написанный вручную? Как, по вашему мнению, должно строиться использование ИИ в разработке? Будем рады подискутировать с вами в комментариях!