Решение загадок кодирования: эволюция инструментов помощи программиста
4 августа 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. Источники отчета о испытании
Ссылки
2. Предыдущие концептуализации интеллектуальной помощи для программистов
То, что считается «интеллектуальной помощью», может быть предметом некоторых дебатов. Выбираем только только функции, которые обусловлены технологиями, которые сообщество исследований искусственного интеллекта (само по себе не определено) будет признавать как искусственный интеллект? Включите ли мы те, которые используют эвристику, кодируемую экспертом,? Системы, которые делают выводы, с которыми человек может не согласиться, или системы с возможностью ошибок? Смешанные инициативные системы (Horvitz, 1999)? Или те, кто заставляет пользователя чувствовать себя умным, помогающим или уполномоченным? Хотя эта дискуссия выходит за рамки данной статьи, мы считаем, что для правильной контекстуализации качественного различия, создаваемого крупными языковыми моделями, требуется широкий и инклюзивный подход к термину «интеллект».
Программирование конечных пользователей долгое время было домом для вывода или интеллектуальной помощи. Стратегия прямых манипуляций (Shneiderman & Norwood, 1993) очень успешна для определенных типов ограниченных, хотя и полезных, вычислительных задач, где используемый интерфейс («что вы видите», например, текстовый редактор или редактор изображений) для разработки информационного артефакта может тесно представлять артефакт («Что вы получаете», например, текстовый документ или изображение). Тем не менее, эта стратегия не может быть просто применена к программам. Программы отмечают множественные возможные пути исполнения одновременно, и они определяют «поведение, которое возникает в будущее» (Blackwell, 2002b). Предоставление множества будущих в настоящем является основной проблемой исследований в прямом эфире (Tanimoto, 2013), которая направлена на экспрессию программ по мере их отредактирования (Basman et al., 2016).
Необходимость преодолеть разрыв в абстракции между прямыми манипуляциями и множественными путями исполнения привела к изобретению программирования с помощью демонстрации (PBD) (Kurlander et al., 1993; Lieberman, 2001; Myers, 1992). Форма логической помощи, PBD позволяет программистам конечным пользователям делать конкретные демонстрации желаемого поведения, которые обобщаются в исполняемых программах. Несмотря на их обещание, системы PBD не достигли широкого успеха в качестве инструментов программирования конечных пользователей, хотя их идея сохранилась в рудиментальной форме как различные инструменты «записи макро-записи», и этот подход видит возрождение с растущей коммерциализацией «автоматизации роботизированных процессов».
Дизайн языка программирования уже давно связан с изменением бремени интеллекта между программистом, программой, компилятором и пользователем. Компиляторы языка программирования, в переводе между языками высокого уровня и машинным кодом, являются своего рода интеллектуальной помощью для программистов. Декларативный язык пролог призван принести своего рода интеллект, где программист будет нести только за указание («объявления»), что вычислить, но не за то, как его вычислить; Эта ответственность была оставлена переводчику. В то же время язык был разработан с учетом интеллектуальных приложений. Действительно, он обнаружил широко распространенное использование в исследованиях искусственного интеллекта и вычислительной лингвистики (Colmerauer & Roussel, 1996; Rouchy, 2006).
Формальные инструменты проверки используют язык спецификации, такой как тройки Hoare (Hoare, 1969), и написание таких спецификаций можно считать программированием на «более высоком» уровне абстракции. Синтез программы, в частности, синтез через уточнение, направлено на разумное преобразование этих правил в исполняемый и правильный код. Тем не менее, термин «синтез программы» также используется в более широком смысле, и программы могут быть синтезированы из других источников, чем спецификации более высокого уровня. Конкретно, программный синтез по примеру или простое программирование по примеру (PBE) облегчает генерацию исполняемого кода из примеров ввода-вывода. Примером успешной коммерциализированной PBE является Flash Flash Excel (Gulwani, 2011), который синтезирует трансформации струн в электронных таблицах из небольшого количества примеров.
Структура когнитивных измерений (T. R. Green, 1989; T. Green & Blackwell, 1998) идентифицирует три категории программирования: авторизация, транскрипция и модификация. Современная помощь программиста охватывает каждую из них. Например, инструменты синтеза программы преобразуют прямое авторизацию кода в (возможно, проще) авторизацию примеров. Интеллектуальные завершения кода (Marasoiu et al., 2015) поддерживают прямое авторизацию кода. Интеллектуальная поддержка повторного использования, такая как Smart Code Copy/Paste (Allamanis & Brockschmidt, 2017), поддерживая транскрипцию и инструменты рефакторинга (Hermans et al., 2015). Исследователи исследовали логическую поддержку для навигации исходного кода (Henley & Fleming, 2014), отладки (J. Williams et al., 2020) и отборочно отменять изменения кода (Yoon & Myers, 2015). Кроме того, интеллектуальные инструменты также могут поддерживать обучение (Cao et al., 2015).
Allamanis et al. (2018) Обзор работы на пересечении машинного обучения, языков программирования и разработки программного обеспечения. Они стремятся адаптировать методы, впервые разработанные для естественного языка, таких как языковые модели, к исходному коду. Появление больших органов открытого кода, иногда называемого «Большой код», позволило эту область исследования. Языковые модели чувствительны к лексическим функциям, таким как имена, форматирование кода и порядок методов, в то время как традиционные инструменты, такие как компиляторы или проверки кода, нет. Благодаря «гипотезе естественности», которая утверждает, что «программное обеспечение является формой человеческой коммуникации; программные корпорации обладают аналогичными статистическими свойствами с корпорациями естественного языка; авторы утверждают, что эти свойства могут быть использованы для создания лучших инструментов разработки программного обеспечения». Некоторая поддержка этой гипотезы исходит из исследования, в которых использовались модели N-граммы для создания механизма завершения кода для Java, который превзошел функцию завершения Eclipse (Hindle et al., 2012, 2016). Этот подход может лежать в основе рекомендательных систем (таких как автозаполнение кода), отладчики, анализаторы кода (такие как проверки типов (Raychev et al., 2015)) и синтезаторы кода. Мы можем ожидать недавнего расширения способности к языковым моделям, обсуждаемым дальше, чтобы повысить эффективность этих приложений.
Авторы:
(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).
Эта статья есть
Оригинал