Не просто компилятор: что делает генерацию кода ИИ таким другим?
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.2. Помощь ИИ в качестве компиляции
Альтернативная перспектива заключается в том, что помощь ИИ больше похожа на компилятор. С этой точки зрения, программирование через подсказки и запросы естественного языка является формой спецификации более высокого уровня, которая «составлена» через модель к исходному коду на целевом языке, который является более низким уровнем.
Давайте (грубо) предположим, что по мере того, как программирование проходит по континууму абстракции от «более низких» к «более высоким» уровням, программист становится, во -первых, менее озабоченным механистическими деталями выполнения программы, а во -вторых, все больше и больше декларативно, указывая, что требуется вычисления, а не как его вычислить. В целом, это желательные свойства программирования ночеек, но они не всегда делают деятельность программирования проще или более доступным. Как скажут вам люди, которые пишут код на декларативных языках или формальных инструментах проверки, часто гораздо сложнее указать, что, чем как. Гораздо более широко принятая практика разработки, управляемой тестированием, находится рядом; Хотя тесты не обязательно написаны на языке более высокого уровня, чем в коде, они стремятся захватить понятие правильности более высокого уровня, что из-за решения проблемы. Обучение для инженера -тестирования требует времени и опыта, и весь четкий карьерный путь «Инженер -программист в тестировании» подтверждает специализированные требования программирования на более высоких уровнях абстракции.
Некоторые извлекут различие между программированием на языке спецификации и скомпилированным языком программирования. Сам Тони Хоар считает эти разные на том основании, что, хотя компилятор только стремится составить программу из исходного языка в конечный набор действительных программ на целевом языке, спецификация может быть удовлетворена бесконечным количеством действительных программ (Pers Comm., First Author, Ca. 2014). Таким образом, задачи технического проектирования и проектирования взаимодействия с помощью уточнения спецификации охватывают, но гораздо шире, чем технические задачи и задачи проектирования взаимодействия компиляторов. Несмотря на то, что мы признаем это различие, существует недостаточно эмпирических данных из отчетов о опыте, обобщенных в разделе 7, что сами рабочие программисты последовательно проводят значимое различие между этими понятиями.
Программирование с большими языковыми моделями, например, в нотации более высокого уровня, также позволяет программисту меньше озаботиться подробностями целевого языка. Например, разработчики в нашем опыте, отчеты об опыте, полагались на помощь ИИ, чтобы заполнить правильный синтаксис или обнаружить и правильно использовать соответствующий вызов API, что позволяет им сосредоточиться на аспектах решаемой проблемы. Тем не менее, существуют фундаментальные различия между этим опытом и опытом использования компилятора. Во -первых, абстракция не завершена, то есть программист не может полностью не знать о целевом языке, они все равно должны иметь возможность понимать и оценивать сгенерированный код, чтобы эффективно использовать такие инструменты. С компиляторами, хотя знание целевого языка может помочь опытным разработчикам в определенных обстоятельствах, оно далеко не предпосылка для эффективного использования. Более того, компиляторы можно полагаться практически на универсально, чтобы генерировать правильный и полный перевод с источника к целевому языку, тогда как программирование с помощью ИИ помогает активной проверке и адаптации переведенного кода. Затем компиляторы (сравнительно) детерминистичны в том смысле, что они последовательно производят один и тот же выход для того же входа, но это не относится к текущим инструментам программирования ИИ (хотя это не является фундаментальным ограничением, и может быть обеспечена согласованность). Наконец, хотя их часто критикуют за то, что они загадочны и бесполезны (Barik et al., 2018), компиляторы действительно предлагают уровни взаимодействия и обратной связи через предупреждения и сообщения об ошибках, которые помогают программисту улучшить код на исходном языке; В настоящее время нет такого объекта с инструментами программирования ИИ, и это считает нас областью с потенциалом для инноваций.
Возможно, более глубоко, в то время как естественный язык может использоваться для выражения концепций на более высоком уровне абстракции, диапазон абстракции, выражаемый на естественном языке, намного шире, чем с другими формами программирования. Традиционные записи программирования с специальными возможностями абстракции (подпрограммы, классы и т. Д.) позволяют программистам вручную повысить уровень абстракции своего собственного кода и API. Но с кодом, сгенерированным языковыми моделями, как мы видели из отчетов в разделе 7, подсказка может охватить гамму от описания всего приложения в нескольких предложениях до кропотливо описывающего алгоритм в пошаговом псевдокоде. Таким образом, было бы ошибкой рассматривать программирование с помощью ИИ помощь как еще одну ступеньку на лестнице абстракции. Скорее, его можно рассматривать как устройство, которое может телепортировать программиста в произвольные ступени лестницы по желанию.
Мы закрываем обсуждение помощи ИИ как компилятора с несколькими разными заметками. Идея использования естественного языка в качестве нотации программирования имеет долгую историю (например, (Miller, 1981; Lieberman & Liu, 2006)), которую мы здесь не будем освещать. Тем не менее, примечательно, что есть много способов, которыми естественный язык был интегрирован с программированием, такими как отладка (Ko & Myers, 2004). С большими языковыми моделями существуют лучшие возможности для вывода намерения и перевода в код, но, следовательно, также могут открыть новые стратегии для проверки и объяснения кода. Есть также новые режимы сбоя для этой парадигмы программирования.
Авторы:
(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).
Эта статья есть
Оригинал