Давайте послушаем от разработчиков: каково это на самом деле кодировать с ИИ
5 августа 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. Источники отчета о испытании
Ссылки
7. Опыт отчетов
В настоящее время не так много исследований пользовательского опыта программирования с большими языковыми моделями, помимо исследований, которые мы суммировали в разделе 6. Однако, поскольку доступность таких инструментов увеличится, профессиональные программисты получат долгосрочный опыт в своем использовании. Многие такие программисты пишут о своем опыте в отношении личных блогов, которые затем обсуждаются в онлайн -сообществах, таких как Hacker News. Вдохновленный потенциалом для этих источников предоставить богатые качественные данные, как указано Барик (Barik et al., 2015; Sarkar et al., 2022), мы опираемся на несколько таких отчетов о опыте. Полный список источников предоставляется приложение A; Ниже мы суммируем их ключевые моменты.
7.1. Писать эффективные подсказки сложно
Как и в нескольких других приложениях генеративных моделей, ключевой проблемой является написание подсказок, которые увеличивают вероятность успешной генерации кода. Картирование, которое эти модели изучают между естественным языком и кодом, очень плохо изучено. Посредством экспериментов некоторые разработали эвристику для подсказок, которые улучшают качество кода, генерируемого моделью. Один разработчик, построив несколько приложений и игр с моделью Code-Davinci от Openai (модель кодекса второго поколения), советует «числа ваши инструкцииИ создание «логика сначала«Перед элементами пользовательского интерфейса. Другой, используя Copilot для создания классификатора для заявлений о естественном языке, предлагает предоставить»более подробно”В ответ на неспособность генерировать правильный код. Например, при запросе на копии«бинариза”Массив терпит неудачу, они переписывают подсказку«Превратите его в массив, где [первое значение] равно 1, а [второе значение] - 0»- Эффективно псевдокод - который генерирует правильный результат.
Комментаторы на Hacker News делятся на достоинства усилий, инвестированных в разработку методов для подсказки. Хотя некоторые считают это новым уровнем абстракции для программирования, другие считают его косвенно приближающимся к более фундаментальным вопросам, которые должны решать с помощью лучшего инструмента, документации и языкового дизайна:
«Вы не кодируете непосредственно на языке, но теперь вы кодируете на неявном языке, предоставленном Copilot. [...] все, что на самом деле указывает, это то, что документация кода и обнаружение ужасны. Но я не уверен, что написание неявного кода в комментариях действительно является лучшим подходом, чем поиск способов сделать обнаружение языка и библиотечные функции более обнаруженными».
«[...] Комментарии, используемые для генерации кода через GitHub Copilot, являются просто еще одним очень неэффективным языком программирования».
«[Отвечая на вышеупомянутые], тем не менее, есть что -то чрезвычайно ценное в том, чтобы писать на разных уровнях абстракции при разработке кода. Copilot позволяет вам делать это так, что вы можете сделать, что вы можете сделать, что вы, конечно, имеют свою собственную, очень жесткую, абстракции. Возможность иметь такую способность, даже если вы думаете об этом как о другом языке программирования сама по себе, огромна ».
Без разбора обучаемого на корпус, содержащий кодекс различного возраста и (субъективного) качества, имеет недостатки; Разработчики сталкиваются с генерируемым кодом, который технически правильный, но содержит практики, считающиеся плохими, такими как развернутые петли и жесткие константы. Один пользователь Fopilot обнаружил, что:
«Copilot [...] сделал мой код более условно.
Другой пользователь Copilot размышлял о своем опыте создания кода, который использует API Fastai, который часто меняется:
«[...] Поскольку последняя версия Fastai была опубликована только в августе 2020 года, Github Copilot не смог предоставить какие -либо соответствующие предложения и вместо этого предоставил код для использования более старых версий Fastai. [...] для меня это является серьезной проблемой [...], если мы используем передовые инструменты [...] Copilot не знают об этом и не могут предоставить полезные предложения».
С другой стороны, разработчики также могут подвергаться лучшей практике и API с помощью этих моделей. Разработчик, который нашел Copilot, чтобы сделать свой код более многословным, также заметил, что:
«Копилот дает структуру для ошибок. Это помогло мне написать эти раздражающие имена иностранных ключей в последовательном формате [...]
[Кроме того,] одной из наиболее удивительных особенностей была [то, что] [...] Я обнаруживаю, что обнаруживаю новые методы API, либо более высоких уровней, либо из тех, которые лучше для моего варианта использования ».
Чтобы обнаружить новые API, конечно, сами API должны быть хорошо разработаны. Действительно, в некоторых случаях впечатляющая полезность крупных языковых моделей может быть в значительной степени связана с тем фактом, что дизайнеры API уже проделали тяжелую работу по созданию абстракции, которая подходит для реальных вариантов использования (Myers & Stylos, 2016; Piccioni et al., 2013; MacVean et al., 2016). Как разработчик, который использовал Copilot для разработки классификатора настроений для сообщений в Твиттере, соответствующих определенным замечаниям ключевых слов,«Такие вещи возможны не только из -за пилота CO [sic], но и потому, что у нас есть потрясающие библиотеки, которые абстрагировали много сложных вещей».Это говорит о том, что дизайн API, не только для человеческих разработчиков, но и как цель для крупных языковых моделей, будет важен в ближнем и среднем будущем.
Более того, разбивание подсказки на «правильном» уровне детализации также становится важным навыком разработчика. Это требует, по крайней мере, некоторого знакомства или хорошей интуиции для доступных API. Разрушение подсказок на шаги, настолько подробные, что программист эффективно пишет псевдокод, может рассматриваться как анти-паттерн и может привести к возражениям, упомянутым ранее, что программирование с помощью крупных языковых моделей-это просто «».очень неэффективный язык программирования”. Мы завершаем эту проблемуНечеткая абстракция сопоставлениеПолем Проблема выяснения того, что система может и не может делать, и сопоставление своих намерений и инструкций с возможностями системы, не нова-она была хорошо документирована в взаимодействии с естественным языком (Mu & Sarkar, 2019; Luger & Sellen, 2016). Это также наблюдается в дизайне программирования как гипотеза «матча» (T. R. Green & Petre, 1992; Chalhoub & Sarkar, 2022). В наиболее широком смысле их можно рассматривать как особые случаи «проката» Нормана (Hutchins et al., 1985), возможно, центральной дисциплинарной проблемы первой и второй волны (Bødker, 2015). Исследование взаимодействия с человеком и компьютером: «Как мне заставить компьютер делать то, что я хочу делать?».
Что отличает нечеткую абстракцию, соответствующую предыдущим воплощениям этой проблемы, так это устойчивость к различным уровням абстракции, обеспечиваемых большими языковыми моделями. В предыдущих интерфейсах естественного языка или языках программирования пользователь должен был сформировать чрезвычайно конкретную ментальную модель, прежде чем они смогут выразить свои идеи в терминах машин. Напротив, крупные языковые модели могут генерировать правдоподобные и правильные результаты для операторов в чрезвычайно широком диапазоне абстракции. В контексте помощи в программировании это может варьироваться от запроса модели до написания программ на основе расплывчатых и недооцененных утверждений, требующих знаний о домене, до чрезвычайно специфических и подробных инструкций, которые эффективно являются псевдокодом. Эта гибкость в конечном итоге является обоюдоострым мечом: у него есть нижний этаж для пользователей, чтобы начать получать полезные результаты, но более высокий потолок для того, чтобы пользователи были максимальной производительностью.
В контексте программных действий,Исследовательское программирование, где цель неизвестна или не определена (Kery & Myers, 2017; Sarkar, 2016), не соответствует формированию нечеткого сопоставления абстракции (или действительно каких -либо вариаций проблемы проката). Когда ставится вопрос о кристаллизованном намерении пользователя, или когда цель проектирования заключается в том, чтобы система повлияла на намерение пользователя (как и в случае с работой HCI Designerly и третьей волны), вопросы основных вопросов взаимодействия меняются. Одна очевидная роль, которую система может играть в этих сценариях, - помочь пользователям усовершенствовать свои собственные концепции (Kulesza et al., 2014) и решить, какие возможности исследовать. Помимо отмечения, что такие действия существуют, и выйдут за пределы предложения, которые мы здесь предложили, мы не будем изучать их более подробно в этой статье.
Авторы:
(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).
Эта статья есть
Оригинал