ИИ замедляет работу разработчиков — мы может объяснить почему

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

Когда разработчикам разрешают использовать ИИ-инструменты, они тратят на 19% больше времени на выполнение задач — это значительное замедление, которое противоречит убеждениям разработчиков и прогнозам экспертов. Этот разрыв между восприятием и реальностью поразителен: разработчики ожидали, что ИИ ускорит их работу на 24%, и даже после того, как они столкнулись с замедлением, они по-прежнему считали, что ИИ ускорил их работу на 20%.

Мы не можем обобщить эти результаты на всех разработчиков программного обеспечения. Разработчики, участвовавшие в этом исследовании, представляют собой очень специфическую группу, работающую над очень специфическими проектами. Это опытные разработчики открытого исходного кода, работающие над собственными проектами. Это исследование показывает, что текущий набор ИИ-инструментов, по-видимому, замедляет работу таких разработчиков, но это не означает, что мы можем предположить, что то же самое относится и к другим разработчикам. Например, мы можем ожидать, что корпоративные сотрудники, работающие над приложениями next.js, которые в основном были созданы другими людьми, давно ушедшими из компании (я), увидят огромное повышение производительности!

Еще мы можем выдвинуть теорию о том, почему эти конкретные разработчики открытого исходного кода были замедлены инструментами, которые обещали ускорить их работу.

Я сосредоточусь в частности на том, почему они были замедлены, а не на разрыве между воспринимаемой и реальной производительностью. Неспособность разработчиков определить, ускорил ли их инструмент или замедлил, сама по себе увлекательна, вероятно, применима ко многим другим формам человеческой деятельности и объясняет такие разные вещи, как то, почему так много людей думают, что ИИ сделал их в 10 раз более продуктивными, почему я продолжаю использовать Vim, почему люди водят машину в Лондоне и т.д. Я просто не имею никаких особых мыслей о том, почему возникает этот разрыв. У меня есть мнение о том, почему они замедляются.

Так почему же они замедляются

Некоторое время назад я написал, несколько в отрыве от обсуждаемой темы, о старой статье Питера Наура под названием «Программирование как построение теории». В этой статье говорится:

Программирование следует рассматривать как деятельность, посредством которой программисты формируют или достигают определенного рода понимания, создания теории, относящейся к рассматриваемым вопросам.

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

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

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

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

Вот почему инструменты кодирования ИИ, в том виде, в котором они существуют сегодня, как правило, замедляют работу того, кто знает, что делает, и работает над проектом, который он понимает.

Стоит ли запретить использование LLM на рабочих местах?

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

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

Итак, если мы примем эту узкую и краткосрочную точку зрения на производительность и скажем, что это просто время для создания бизнес-ценности, то да, я думаю, что LLM может сделать разработчиков более продуктивными. Я не могу это доказать, поскольку у меня нет данных, но я был бы рад, если бы кто-нибудь провел такое исследование. Если никто не возьмется за это, то я, возможно, попробую поэкспериментировать на себе.

Но в этом контексте есть проблема с использованием инструментов ИИ.

А как же построение ментальных моделей?

Хорошо, если у вас нет ментальной модели программы, то, возможно, LLM может повысить вашу продуктивность. Однако ранее мы согласились, что основная цель написания программного обеспечения — построение ментальной модели. Если мы передадим нашу работу LLM, сможем ли мы по-прежнему эффективно строить ментальную модель? Я в этом сомневаюсь.

Так стоит ли избегать использования этих инструментов? Возможно. Если вы планируете работать над проектом в долгосрочной перспективе, хотите по-настоящему его понять и иметь возможность эффективно вносить изменения, то, на мой взгляд, вам следует просто написать код самостоятельно. Если же вы просто штампуете код на фабрике по производству кода, то установите cursor и приступайте к делу — yolo.

Источник