Это не ваш партнер по искусственному искусству: поверхностная аналогия парного программирования
7 августа 2025 г.Таблица ссылок
Аннотация и 1 введение
2. Предыдущие концептуализации интеллектуальной помощи для программистов
3. Краткий обзор больших языковых моделей для генерации кода
4. Коммерческие инструменты программирования, которые используют большие языковые модели
5. Надежность, безопасность и последствия безопасности моделей ИИ, генерирующих код,
6. Изузаение юзабилити и дизайна программирования A-ассистентного
7. Опыт отчетов и 7.1. Писать эффективные подсказки сложно
7.2 Активность программирования сдвигается в сторону проверки и незнакомой отладки
7.3. Эти инструменты полезны для шаблона и повторного использования кода
8. Неадекватность существующих метафор для программирования A-A-Advisted
8.1. Помощь ИИ в качестве поиска
8.2. Помощь ИИ в качестве компиляции
8.3. Помощь ИИ в качестве парного программирования
8.4. Отчетливый способ программирования
9. Проблемы с применением программирования конечного пользователя
9.1. Выпуск 1: Спецификация намерений, разложение проблемы и вычислительное мышление
9.2. Выпуск 2: Правильность кода, качество и (над) уверенность
9.3. Выпуск 3: Понимание и обслуживание кода
9.4. Выпуск 4: Последствия автоматизации в программировании конечных пользователей
9.5. Выпуск 5: Код без кода и дилемма прямого ответа
10. Заключение
A. Источники отчета о испытании
Ссылки
8.3. Помощь ИИ в качестве парного программирования
Третья распространенная перспектива заключается в том, что программирование с помощью A-A-Actisting подобно парному программированию. Коммерческий слоган Github Copilot описывает его как «ваш программист из AI Pare». В отличие от поиска и компиляции, которые являются относительно безличными инструментами, аналогия с парным программированием запоминается более индивидуальным опытом; Помощь от партнера, который больше понимает ваш конкретный контекст и о том, чего вы пытаетесь достичь. A-A-Assisted Programming может быть более персонализированным, в той степени, в которой оно может принять во внимание ваш конкретный исходный код и файлы проекта. Как пишут хакерские новости. Комментаторы:
«[...] в какой -то момент он сам написал целую функцию, и это было правильно.
«[...] это похоже на то, как стереотипный« стажер »в качестве ассоциированного встроенного в ваш редактор.
Помимо персонализации, аналогия также напоминает об традиционном ролевом распределении парного программирования между «драйвером» и «навигатором». При программировании необходимо сформировать ментальные модели программы на многих уровнях: от конкретного утверждения, над которым работают, до его контекста в подпрограмме, до той роли, которую подпрограмма играет в модуле, до модуля в рамках программы. Тем не менее, код должен быть записан на уровне заявления, который заставляет разработчиков постоянно поддерживать этот самый низкий уровень на переднем крае их рабочей памяти. Опытные разработчики тратят больше времени на то, чтобы наметить свой код, чтобы они могли тратить меньше времени на его написание. Исследования на дисплее и навигации кода изучали, как различные способы представления строк кода могут помочь программистам лучше помнить об этих различных уровнях ментальных моделей (Henley & Fleming, 2014). Аргумент пары, позволяющий двум партнерам поделиться бременем ментальной модели. Драйвер кодирует на операторе и уровне подпрограммы, в то время как навигатор отображает подход на уровне модуля и программы.
По аналогии с сочетанием программирования, помощник искусственного интеллекта, играющий роль водителя, сольный программист теперь может занять место навигатора. Но, как мы видели, опыт программирования с помощью ИИ помощи не последовательно освобождает человеческого программиста от ответственности за понимание кода на утверждении и уровне подпрограммы. Программист может стать«Lazier [...] о изучении различных деталей синтаксиса и библиотек», но опыт по-прежнему включает в себя гораздо большую проверку на уровне заявлений.
В то время как сессия парного программирования требует сознательного, согласованного решения об обмене роли, сольный программист с помощником ИИ может оказаться, что плавно пересекает спектр от движения до навигации, от одного момента до другого. Это может частично объяснить, почему в предварительном эксперименте (n = 21), сравнивающем опыт «парного программирования» с GitHub Copilot с программированием в человеческой паре, либо в качестве драйвера, либо навигатора, Imai (2022) обнаруживает, что программисты пишут больше линий кода с Copilot, чем в человеческой паре, но эти строки имеют более низкое качество (больше в последнее время).
Кроме того, метаанализ парного программирования показали смешанную эффективность программирования пар человека во время задачи, качества кода и правильности (Salge & Berente, 2016; Hannay et al., 2009), что позволяет предположить, что эмуляция опыта парного программирования не обязательно является целевой целью. Многочисленные исследования пришли к выводу, что очевидные успехи парного программирования могут быть отнесены не с ролевым делением на водителя и навигатора, а скорее высокую степень вербализации, которая возникает, когда парные программисты вынуждены рационализировать свои решения друг с другом (Hannay et al., 2009). Другие обнаружили, что программирование в парах вызывает больше внимания из -за уважения к общему времени; Пары программистов с меньшей вероятностью читают электронные письма, просматривают Интернет или принимают длинные телефонные звонки (L.A. Williams & Kessler, 2000). Эти особые преимущества парного программирования вообще не захватываются инструментами помощи ИИ.
Сравнение с парным программированием, таким образом, является относительно поверхностным, и сегодняшний опыт программирования A-ассистентного A-ассистента не сопоставим с парным программированием в той же степени, что и с поиском или компиляцией.
Авторы:
(1) Advait Sarkar, Microsoft Research, Кембриджский университет (advait@microsoft.com);
(2) Эндрю Д. Гордон, Microsoft Research, Эдинбургский университет (adg@microsoft.com);
(3) Карина Негрину, Microsoft Research (cnegreanu@microsoft.com);
(4) Christian Poelitz, Microsoft Research (cpoelitz@microsoft.com);
(5) Sruti Srinivasa Ragavan, Microsoft Research (a-srutis@microsoft.com);
(6) Бен Зорн, Microsoft Research (ben.zorn@microsoft.com).
Эта статья есть
Оригинал