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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Что в итоге

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

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

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

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

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

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

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

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

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

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

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