Kevlin Henney y yo estábamos discutiendo algunas ideas sobre Copiloto de GitHub, la herramienta para generar automáticamente código basado en el modelo de lenguaje de GPT-3, entrenado en el cuerpo del código que está en GitHub. Este artículo plantea algunas preguntas y (quizás) algunas respuestas, sin pretender presentar ninguna conclusión.
Primero, nos preguntamos acerca de la calidad del código. Hay muchas formas de resolver un problema de programación dado; pero la mayoría de nosotros tenemos algunas ideas sobre lo que hace que el código sea “bueno” o “malo”. ¿Es legible, está bien organizado? Ese tipo de cosas. En un entorno profesional, donde el software debe mantenerse y modificarse durante largos períodos, la legibilidad y la organización cuentan mucho.
Aprende más rápido. Excavar más hondo. Ver más lejos.
Sabemos cómo probar si el código es correcto o no (al menos hasta cierto límite). Dadas suficientes pruebas unitarias y pruebas de aceptación, podemos imaginar un sistema para generar automáticamente código que sea correcto. Propiedadpruebas basadas en podría darnos algunas ideas adicionales sobre cómo construir suites de prueba lo suficientemente sólidas como para verificar que el código funciona correctamente. Pero no tenemos métodos para probar el código que es “bueno”. Imagine pedirle a Copilot que escriba una función que ordene una lista. Hay muchas formas de ordenar. Algunos son bastante buenos, por ejemplo, ordenación rápida. Algunos de ellos son horribles. Pero una prueba unitaria no tiene forma de saber si una función se implementa usando quicksort, clasificación por permutación(que se completa en tiempo factorial), tipo de sueñoo uno de los otros extraños algoritmos de clasificación sobre los que Kevlin ha estado escribiendo.
¿Nos importa? Bueno, nos preocupamos por el comportamiento O(N log N) frente a O(N!). Pero suponiendo que tengamos alguna forma de resolver ese problema, si podemos especificar el comportamiento de un programa con la suficiente precisión como para estar seguros de que Copilot escribirá un código correcto y con un rendimiento tolerable, ¿nos preocupamos por su estética? ¿Nos importa si es legible? Hace 40 años, podríamos habernos preocupado por el código de lenguaje ensamblador generado por un compilador. Pero hoy en día, no lo hacemos, a excepción de algunos casos de esquina cada vez más raros que generalmente involucran controladores de dispositivos o sistemas integrados. Si escribo algo en C y lo compilo con gcc, de manera realista nunca voy a mirar la salida del compilador. No necesito entenderlo.
Para llegar a este punto, es posible que necesitemos un metalenguaje para describir lo que queremos que haga el programa que sea casi tan detallado como un lenguaje moderno de alto nivel. Eso podría ser lo que depara el futuro: una comprensión de la “ingeniería rápida” que nos permita decirle a un sistema de IA con precisión qué queremos que haga un programa, en lugar de cómo hacerlo. Las pruebas se volverían mucho más importantes, al igual que la comprensión precisa del problema comercial que debe resolverse. El “código de honda” en cualquier idioma se volvería menos común.
Pero, ¿qué sucede si no llegamos al punto en el que confiamos en el código generado automáticamente tanto como ahora confiamos en la salida de un compilador? La legibilidad será primordial mientras los humanos necesiten leer código. Si tenemos que leer el resultado de uno de los descendientes de Copilot para juzgar si funcionará o no, o si tenemos que depurar ese resultado porque en su mayoría funciona, pero falla en algunos casos, entonces lo necesitaremos para generar código que sea legible. . No es que los humanos actualmente hagan un buen trabajo escribiendo código legible; pero todos sabemos lo doloroso que es depurar código que no es legible, y todos tenemos algún concepto de lo que significa “legibilidad”.
Segundo: Copilot fue entrenado en el cuerpo del código en GitHub. A estas alturas, está todo (o casi todo) escrito por humanos. Parte de él es código bueno, de alta calidad y legible; mucho de eso no lo es. ¿Qué pasaría si Copilot tuviera tanto éxito que el código generado por Copilot llegara a constituir un porcentaje significativo del código en GitHub? Sin duda, el modelo necesitará volver a entrenarse de vez en cuando. Así que ahora, tenemos un ciclo de retroalimentación: Copilot entrenado en código que ha sido (al menos parcialmente) generado por Copilot. ¿Mejora la calidad del código? O se degrada? Y de nuevo, ¿nos importa y por qué?
Esta pregunta se puede argumentar de cualquier manera. Las personas que trabajan en el etiquetado automatizado para IA parecen estar adoptando la posición de que el etiquetado iterativo conduce a mejores resultados: es decir, después de un pase de etiquetado, use un humano en el circuito para verificar algunas de las etiquetas, corregirlas donde estén incorrectas y luego use esta entrada adicional en otro pase de entrenamiento. Repita según sea necesario. Eso no es tan diferente de la programación actual (no automatizada): escribir, compilar, ejecutar, depurar, tantas veces como sea necesario para obtener algo que funcione. El bucle de retroalimentación le permite escribir un buen código.
Un enfoque humano en el circuito para entrenar un generador de código de IA es una forma posible de obtener un “buen código” (para lo que sea que signifique “bueno”), aunque es solo una solución parcial. Cuestiones como el estilo de sangría, los nombres de variables significativos y similares son solo el comienzo. Evaluar si un cuerpo de código está estructurado en módulos coherentes, tiene API bien diseñadas y los mantenedores pueden entenderlo fácilmente es un problema más difícil. Los humanos pueden evaluar el código teniendo en cuenta estas cualidades, pero lleva tiempo. Un humano en el ciclo podría ayudar a entrenar los sistemas de IA para diseñar buenas API, pero en algún momento, la parte “humana” del ciclo comenzará a dominar al resto.
Si miras este problema desde el punto de vista de la evolución, ves algo diferente. Si cultivas plantas o animales (una forma de evolución altamente seleccionada) para una cualidad deseada, casi con seguridad verás degradarse todas las demás cualidades: obtendrás perros grandes con caderas que no funcionano perros con caras planas que no pueden respirar bien.
¿Qué dirección tomará el código generado automáticamente? no lo sabemos Suponemos que, sin formas de medir rigurosamente la “calidad del código”, la calidad del código probablemente se degradará. Desde Peter Drucker, a los consultores de gestión les ha gustado decir: “Si no puedes medirlo, no puedes mejorarlo”. Y sospechamos que eso también se aplica a la generación de código: los aspectos del código que se pueden medir mejorarán, los aspectos que no se pueden medir, no lo harán. O, como el historiador de la contabilidad H. Thomas Johnson dijo: “Tal vez lo que mides es lo que obtienes. Lo más probable es que lo que mida sea todo lo que obtendrá. Lo que no mides (o no puedes) medir, se pierde”.
Podemos escribir herramientas para medir algunos aspectos superficiales de la calidad del código, como obedecer convenciones estilísticas. Ya tenemos herramientas que pueden “arreglar” problemas de calidad bastante superficiales como la sangría. Pero nuevamente, ese enfoque superficial no toca las partes más difíciles del problema. Si tuviéramos un algoritmo que pudiera calificar la legibilidad y restringir el conjunto de entrenamiento de Copilot al código que puntúa en el percentil 90, ciertamente veríamos un resultado que se ve mejor que la mayoría del código humano. Sin embargo, incluso con un algoritmo de este tipo, todavía no está claro si ese algoritmo podría determinar si las variables y funciones tenían nombres apropiados, y mucho menos si un proyecto grande estaba bien estructurado.
Y una tercera vez: ¿nos importa? Si tenemos una forma rigurosa de expresar lo que queremos que haga un programa, es posible que nunca necesitemos mirar el C o C++ subyacente. En algún momento, es posible que uno de los descendientes de Copilot no necesite generar código en un “lenguaje de alto nivel”: tal vez genere código de máquina para su máquina de destino directamente. Y tal vez esa máquina objetivo será Ensamblaje webla JVM, o cualquier otra cosa que sea altamente portátil.
¿Nos importa si herramientas como Copilot escriben buen código? Lo haremos, hasta que no lo hagamos. La legibilidad será importante siempre que los humanos tengan un papel que desempeñar en el ciclo de depuración. La pregunta importante probablemente no sea “¿nos importa?”; es “¿cuándo dejaremos de preocuparnos?” Cuando podamos confiar en la salida de un modelo de código, veremos un cambio de fase rápido. Nos preocuparemos menos por el código y más por describir la tarea (y las pruebas apropiadas para esa tarea) correctamente.