Tabla de enlaces
Resumen y 1 Introducción
2. Conceptualizaciones previas de asistencia inteligente para programadores
3. Una breve descripción de los modelos de idiomas grandes para la generación de código
4. Herramientas de programación comercial que utilizan modelos de idiomas grandes
5. Implicaciones de fiabilidad, seguridad e seguridad de los modelos de IA generadores de código
6. Usabilidad y estudios de diseño de programación asistida por AI-AI
7. Informes de experiencia y 7.1. Escribir indicaciones efectivas es difícil
7.2. La actividad de la programación cambia hacia la verificación y la depuración desconocida
7.3. Estas herramientas son útiles para la boilerplate y la reutilización de códigos
8. La insuficiencia de las metáforas existentes para la programación asistida por AI-AI
8.1. Asistencia de IA como búsqueda
8.2. Asistencia de IA como compilación
8.3. Ayuda de IA como programación de pares
8.4. Una forma distinta de programación
9. Problemas con la aplicación a la programación del usuario closing
9.1. Problema 1: Especificación de intención, descomposición del problema y pensamiento computacional
9.2. Problema 2: corrección del código, calidad y (sobre) confianza
9.3. Problema 3: Comprensión y mantenimiento del código
9.4. Problema 4: Consecuencias de la automatización en la programación del usuario closing
9.5. Problema 5: Sin código y el dilema de la respuesta directa
10. Conclusión
A. Fuentes de informes de experiencia
Referencias
6. Usabilidad y estudios de diseño de programación asistida por AI-AI
Vaithilingam et al. (2022) realizó un estudio comparativo dentro de los sujetos (n = 24) del copiloto de GitHub, comparando su experiencia del usuario con la de autocompleto tradicional (específicamente, el complemento Intellisense, no lo mismo que la función Intellicode mencionada anteriormente). Los participantes no pudieron completar las tareas con más frecuencia con copiloto que con IntelliSense, y no hubo un efecto significativo en el tiempo de finalización de la tarea. Quizás, como period de esperar, los autores encuentran que evaluar la exactitud del código generado es difícil y un cuello de botella de eficiencia, particularmente cuando el código generado tiene una falla basic o ineficiencia que lleva al programador a un ‘Chase Wild Goose’ de reparación o depuración. Sin embargo, la abrumadora mayoría (19 de 24) de los participantes informó una fuerte preferencia por el copiloto en una encuesta posterior a la tarea. Si bien los participantes tenían menos confianza sobre el código generado por Copilot, casi universalmente (23 de 24) lo percibieron como más útil, porque tenía el potencial de generar puntos de partida útiles y guardar al programador el esfuerzo de buscar soluciones documentadas que pudieran ser la base para la reutilización.
Ziegler et al. (2022) realizó una encuesta (n = 2,047) de la productividad percibida de los usuarios de copilotes en los Estados Unidos. Los coincidieron con las mediciones de uso telemétricos del complemento de copilot, que incluía métricas como la frecuencia con la que se mostraba una autocompletar, con qué frecuencia se aceptaba, con qué frecuencia persistía sin cambios en el documento durante un cierto período de tiempo, con qué frecuencia persistía con variaciones menores (eg, medida por la distancia de levenshtein) y así. Encuentran que la tasa de aceptación (la relación de sugerencias aceptadas para las sugerencias mostradas) es el predictor más fuerte de la productividad percibida de los usuarios debido al copiloto. Fascinantemente, encuentran que el patrón de tasas de aceptación para todos los usuarios en conjunto sigue un ritmo “circadiano” diario y semanal, de modo que es más possible que los usuarios acepten las finalizaciones de copilotes fuera de las horas de trabajo y los fines de semana. Sin embargo, para cualquier usuario dado, la tasa de aceptación depende de las horas de trabajo normales de ese usuario; Las sugerencias fuera de las horas de trabajo normales tienen menos probabilidades de ser aceptadas. Se necesita trabajo futuro para ver si este hallazgo se duplicate, y de ser así, establecer cómo y por qué las tasas de aceptación se ven tan significativamente afectadas por las horas de trabajo.
Xu, Vasilescu y Neubig (2022) realizaron un estudio dentro de los sujetos (n = 31) comparando la experiencia de programación con y sin un complemento de generación de código. Su complemento experimental toma la forma de un campo de texto en el que el usuario ingresa un mensaje de lenguaje pure, el sistema responde con una lista de fragmentos de código y, cuando se hace clic, se inserta el fragmento deseado en el cursor. Este flujo de trabajo difiere de Copilot’s, donde el “aviso” es texto dentro del archivo fuente, y puede contener una combinación de comentarios y código del lenguaje pure. El complemento admitió tanto la generación de códigos (utilizando una purple neuronal basada en árbol) como la recuperación de fragmentos de código (buscando el desbordamiento de la pila del foro de programación). Los resultados de la generación y la recuperación se muestran en la misma lista, pero visualmente demarcadas. Los autores no encontraron un efecto significativo del complemento en el tiempo de finalización de la tarea o la corrección del programa. Descubrieron que las consultas simples tenían más probabilidades de ser respondidas correctamente a través de la generación, y las consultas más complejas que requirieron múltiples pasos tenían más probabilidades de ser respondidas correctamente a través de la recuperación, y que period posible predecir qué enfoque tendría éxito en función de la palabra contenido de las consultas. Además, descubrieron que la mayoría de las consultas de lenguaje pure (60%) que los participantes escribieron en su experimento no estaban lo suficientemente bien especificados para que un experto humano escribiera código que implementan esas intenciones. Los fragmentos recuperados se editaron con más frecuencia de los fragmentos generados, principalmente para cambiar el nombre de identificadores y elegir diferentes parámetros. En una encuesta posterior a la experiencia, los participantes informaron que principalmente se sintieron neutrales o algo positivos (30 de 31). Estos participantes consideraron que el complemento fue útil para encontrar fragmentos de los que eran conscientes pero que no podían recordar, y menos perjudicial que usar un navegador, pero la interacción funcionó mejor cuando el desarrollador tenía un conocimiento preexistente de las API y los marcos objetivo, y se necesitó la experimentación para comprender la “manera correcta” para formular las preguntas. No hubo una indicación clara de preferencia entre la recuperación y la generación.
Jiang et al. (2022) desarrollaron una herramienta basada en LLM para convertir las declaraciones de lenguaje pure en código. Como en Xu, Vasilescu y Neubig (2022), las indicaciones se ingresan en un diálogo emergente invocado en el cursor desde un editor de código, en lugar de como comentarios. En un estudio (n = 14), los participantes recibieron una semana para completar dos tareas de construcción de sitios net con la herramienta, mientras grababan la pantalla, y fueron entrevistados después. Al igual que en otros estudios, los participantes vieron utilidad en la herramienta para facilitar las búsquedas API rápidas y para escribir código de calderas. Descubrieron que las consultas de los programadores novatos eran principalmente un lenguaje pure, mientras que los expertos tenían más probabilidades de mezclar código en sus solicitudes. Si bien algunas consultas eran abstractas y expresaban objetivos de alto nivel, la mayoría tenía baja granularidad, siendo “aproximadamente equivalente a una línea de código”. Para hacer frente a las fallas del modelo, los participantes utilizaron una variedad de estrategias para volver a redactar su consulta, como reducir el alcance de la solicitud o reemplazar las palabras con alternativas, pero no se observó que ninguna estrategia specific fuera más efectiva que cualquier otra. Los participantes lucharon por formar un modelo psychological de lo que el modelo puede entender y la “sintaxis” del lenguaje que requería: este es precisamente el problema de coincidencia de abstracción difusa que describimos anteriormente, que los autores llaman un “Valle extraño”. Los autores sugieren posibles soluciones, como la reamidación automatizada de las indicaciones, sugiriendo tareas más simples, sugiriendo desgloses de tareas y una mejor incorporación y tutoriales.
Barke et al. (2022) estudiaron cómo los programadores (n = 20) usan Copilot GitHub para completar tareas de programación cortas en Python, Rust, Haskell y Java. A través del análisis de las grabaciones de pantalla, los autores identificaron dos modos principales de interacción con copiloto: la aceleración, donde el programador tiene una intención bien formada y el código de copiloto acelera la autorización de código en “pequeñas unidades lógicas”, y la exploración, donde las sugerencias de copilotos se utilizan con el proceso de planificación, “ayudarlos a comenzar, sugieren una estructura potencialmente útil y llamadas de API, o explorar soluciones alternativas”. En la aceleración, las sugerencias de código largo, que llevan tiempo leer y evaluar, pueden romper el flujo del programador. Los participantes desarrollaron heurísticas para escanear rápidamente sugerencias, como buscar la presencia de ciertas palabras clave. En exploración, los participantes tenían más probabilidades de instalar usando comentarios de lenguaje puramente pure, en lugar de una combinación de comentarios y código. Además, estos comentarios rápidos a menudo se “limpian” después de aceptar una sugerencia, lo que implica una forma de “lenguaje de instrucción” que está separado del “lenguaje de explicación”.
MADI (2022) comparó la legibilidad del código generado por Copilot con el del código escrito por programadores humanos en un estudio de usuario (n = 21). Descubrieron que el código generado por el modelo es comparable en complejidad y legibilidad con el código autorizado por los humanos.
El asistente de desarrollador de Bing (Y. Wei et al., 2015; Zhang et al., 2016) (también conocido como Bing Code Search) fue una extensión experimental para Visible Studio lanzada inicialmente en 2015. Habilitó una búsqueda de identificadores de identificación e identificador de fragmentos de código de foros como Stack Overflow. Tenía la capacidad de reescribir código recuperado para usar identificadores del archivo precise del programador. Un estudio del usuario (n = 14) que comparó el tiempo de tarea en la realización de 45 tareas de programación cortas con la extensión versus la búsqueda net common encontrada en promedio el 28% del tiempo se guardó con la extensión. Los datos de telemetría de Morever reunidos durante tres semanas (que representan alrededor de 20,000 usuarios y alrededor de 3.000 consultas por día) mostraron que varios programadores usaban la función con frecuencia. Algunos lo usaron repetidamente para problemas relacionados en rápida sucesión, mostrando su uso en problemas de varios pasos. Otros emitieron la misma consulta varias veces en días separados, lo que sugiere que la velocidad de completar automáticamente period útil incluso si el programador conocía la solución.
