en un Artículo anterior, escribí sobre cómo modelos como DALL-E e Imagen disocian las concepts de la técnica. En el pasado, si tenías una buena thought en cualquier campo, solo podías realizar esa thought si tenías la destreza y la técnica para respaldarla. Con DALL-E, eso ya no es cierto. Puedes decir: «Hazme una imagen de un león atacando a un caballo», y felizmente generará una. Tal vez no tan bueno como el que cuelga en un museo de artepero no necesitas saber nada sobre lienzos, pinturas y pinceles, ni necesitas mancharte la ropa con pintura.
Sin embargo, esto plantea algunas preguntas importantes. ¿Cuál es la conexión entre la experiencia y la ideación? ¿Te ayuda la técnica a formar concepts? (El artista victoriano William Morris es a menudo citado como diciendo: «No se puede tener arte sin resistencia en los materiales», aunque es posible que solo haya estado hablando de su odio por las máquinas de escribir). la técnica y nosotros aportamos las concepts? Diseñar las indicaciones para lograr que DALL-E haga algo extraordinario requiere un nuevo tipo de técnica que es muy diferente a la comprensión de pigmentos y pinceles. ¿Qué tipo de creatividad permite esa nueva técnica? ¿En qué se diferencian estas obras de las anteriores?
Aprende más rápido. Excavar más hondo. Ver más lejos.
Tan interesante como es hablar de arte, hay un área donde estas preguntas son más inmediatas. GitHub Copilot (basado en un modelo llamado Códice, que se deriva de GPT-3) genera código en varios lenguajes de programación, en función de los comentarios que escribe el usuario. Yendo en la otra dirección, GPT-3 ha demostrado ser sorprendentemente bueno en explicando el código. Los usuarios de Copilot todavía necesitan ser programadores; necesitan saber si el código que proporciona Copilot es correcto y necesitan saber cómo probarlo. Las indicaciones en sí mismas son en realidad una especie de pseudocódigo; incluso si los programadores no necesitan recordar los detalles de la sintaxis del lenguaje o los nombres de las funciones de la biblioteca, todavía necesitan pensar como programadores. Pero es obvio dónde está esto de moda. Necesitamos preguntarnos cuánta «técnica» le pediremos a los futuros programadores: en los años 2030 o 2040, ¿la gente podrá decirle a algún futuro Copilot qué quiere que sea un programa? Más concretamente, ¿qué tipo de conocimiento de orden superior necesitarán los futuros programadores? ¿Serán capaces de concentrarse más en la naturaleza de lo que quieren lograr y menos en los detalles sintácticos de la escritura de código?
Es fácil imaginarse a muchos profesionales del software program diciendo: “Por supuesto que tendrás que saber C. O Java. O Pitón. O Scala. Pero no sé si eso es cierto. Hemos estado aquí antes. En la década de 1950, las computadoras se programaban en lenguaje máquina. (Y antes de eso, con cables y enchufes). Es difícil de imaginar ahora, pero la introducción de los primeros lenguajes de programación (Fortran, COBOL y similares) encontró resistencia por parte de los programadores que pensaban que period necesario comprender la máquina. Ahora casi nadie trabaja en lenguaje máquina o ensamblador. El lenguaje de máquina está reservado para algunas personas que necesitan trabajar en algunas áreas especializadas internas del sistema operativo, o que necesitan escribir algunos tipos de código de sistemas integrados.
¿Qué sería necesario para otra transformación? Herramientas como Copilot, por muy útiles que sean, no están ni cerca de estar listas para hacerse cargo. ¿Qué capacidades necesitarán? En este punto, los programadores todavía tienen que decidir si el código generado por Copilot es correcto o no. No tenemos (generalmente) que decidir si la salida de un compilador C o Java es correcta, ni tenemos que preocuparnos de si, dado el mismo código fuente, el compilador generará una salida idéntica. Copilot no ofrece esa garantía e, incluso si lo hiciera, es muy possible que cualquier cambio en el modelo (por ejemplo, para incorporar nuevas preguntas de StackOverflow o repositorios de GitHub) cambie su resultado. Si bien podemos imaginar compilar un programa a partir de una serie de indicaciones de Copilot, no puedo imaginar un programa que probablemente deje de funcionar si se vuelve a compilar sin cambios en el código fuente. Quizás la única excepción sería una biblioteca que pudiera desarrollarse una vez, luego probarse, verificarse y usarse sin modificaciones, pero el proceso de desarrollo tendría que reiniciarse desde cero cada vez que se encontrara un error o una vulnerabilidad de seguridad. Eso no sería aceptable; nunca hemos escrito programas que no tengan errores o que nunca necesiten nuevas características. Un principio clave detrás de gran parte del desarrollo de software program moderno es minimizar la cantidad de código que debe cambiar para corregir errores o agregar funciones.
Es fácil pensar que la programación se trata de crear código nuevo. no lo es; Una cosa que todo profesional aprende rápidamente es que la mayor parte del trabajo se dedica a mantener el código antiguo. Una nueva generación de herramientas de programación debe tener eso en cuenta, o nos encontraremos en una situación extraña en la que una herramienta como Copilot se puede usar para escribir código nuevo, pero los programadores aún tendrán que entender ese código en detalle porque solo puede mantenerse a mano. (Es posible, incluso possible, que tengamos herramientas basadas en IA que ayuden a los programadores a investigar cadenas de suministro de software program, descubrir vulnerabilidades y posiblemente incluso sugerir soluciones). Escribiendo sobre arte generado por IA, Raphaël Millière cube, «Ningún indicador producirá exactamente el mismo resultado dos veces»; eso puede ser deseable para las ilustraciones, pero es destructivo para la programación. La estabilidad y la consistencia son un requisito para las herramientas de programación de próxima generación; no podemos dar un paso atrás.
La necesidad de una mayor estabilidad podría hacer que herramientas como Copilot pasen de indicaciones en inglés de forma libre a algún tipo de lenguaje más formal. un libro sobre ingeniería rápida para DALL-E ya existe; en cierto modo, eso es intentar aplicar ingeniería inversa a un lenguaje formal para generar imágenes. Un lenguaje formal para indicaciones es un retroceso en la dirección de la programación tradicional, aunque posiblemente con una diferencia. Los lenguajes de programación actuales tratan de describir, paso a paso, lo que desea que haga la computadora con gran detalle. A lo largo de los años, hemos progresado gradualmente a niveles más altos de abstracción. ¿Podría la construcción de un modelo de lenguaje en un compilador facilitar la creación de un lenguaje más easy, uno en el que los programadores simplemente describieran lo que querían hacer y dejaran que la máquina se preocupara por la implementación, al mismo tiempo que proporcionaban garantías de estabilidad? Recuerde que period posible construir aplicaciones con interfaces gráficas, y que esas aplicaciones se comunicaran por Web, antes que la Internet. La Internet (y, específicamente, HTML) agregó un nuevo lenguaje formal que encapsuló tareas que solían requerir programación.
Ahora, avancemos un nivel o dos: de líneas de código a funciones, módulos, bibliotecas y sistemas. Todos los que conozco que han trabajado con Copilot han dicho que, si bien no es necesario recordar los detalles de las bibliotecas de programación que está utilizando, debe ser aún más consciente de lo que está tratando de lograr. Tienes que saber lo que quieres hacer; hay que tener un diseño en mente. Copilot es bueno en la codificación de bajo nivel; ¿Necesita un programador estar en contacto con el arte de la codificación de bajo nivel para pensar en el diseño de alto nivel? Hasta ahora eso ha sido ciertamente cierto, pero en gran medida por necesidad: no permitiría que alguien diseñara un sistema grande si no ha construido sistemas más pequeños. Es cierto (como argumentaron Dave Thomas y Andy Hunt en El programador pragmático) que conocer diferentes lenguajes de programación te brinda diferentes herramientas y enfoques para resolver problemas. ¿Es el oficio de la arquitectura de software program diferente del oficio de la programación?
Realmente no tenemos un buen lenguaje para describir el diseño de software program. Los intentos como UML han tenido un éxito parcial en el mejor de los casos. UML estaba sobreespecificado y subespecificado, demasiado preciso y no lo suficientemente preciso; Existen herramientas que generaron andamios de código fuente a partir de diagramas UML, pero no se usan comúnmente en estos días. El andamiaje definió interfaces, clases y métodos que luego podrían implementar los programadores. Aunque generar automáticamente la estructura de un sistema suena como una buena thought, en la práctica puede haber hecho las cosas más difíciles: si la especificación de alto nivel cambió, también lo hizo el andamiaje, quedando obsoleto cualquier trabajo que se hubiera puesto en implementar con el andamio. Esto es comparable al problema de estabilidad del compilador, modulado en una clave diferente. ¿Es esta un área en la que la IA podría ayudar?
Sospecho que todavía no queremos andamios de código fuente, al menos como UML lo imaginó; eso está obligado a cambiar con cualquier cambio significativo en la descripción del sistema. La estabilidad seguirá siendo un problema. Pero podría ser valioso tener una herramienta de diseño basada en IA que pueda tomar una descripción verbal de los requisitos de un sistema y luego generar algún tipo de diseño basado en una gran biblioteca de sistemas de software program, como Copilot, pero a un nivel superior. Entonces el problema sería integrar ese diseño con implementaciones del diseño, algunas de las cuales podrían ser creadas (o al menos sugeridas) por un sistema como Copilot. El problema al que nos enfrentamos es que el desarrollo de software program se lleva a cabo en dos niveles: diseño de alto nivel y programación de nivel medio. Integrar los dos es un problema difícil que no se ha resuelto de manera convincente. ¿Podemos imaginar tomar un diseño de alto nivel, agregarle nuestras descripciones y pasar directamente del diseño de alto nivel con detalles de nivel medio a un programa ejecutable? Ese entorno de programación necesitaría la capacidad de dividir un proyecto grande en partes más pequeñas, para que los equipos de programadores pudieran colaborar. Tendría que permitir cambios en las descripciones de alto nivel, sin interrumpir el trabajo en los objetos y métodos que implementan esas descripciones. Tendría que estar integrado con un sistema de management de versiones que sea eficaz para las descripciones en inglés como lo es para las líneas de código. Esto no sería concebible sin garantías de estabilidad.
Durante un tiempo estuvo de moda hablar de la programación como “artesanía”. Creo que la moda ha decaído, probablemente para bien; “Code as craft” siempre me ha parecido un poco precioso. Pero la thought de “artesanía” sigue siendo útil: es importante que pensemos en cómo puede cambiar la artesanía, y cuán fundamentales no pueden ser esos cambios. Está claro que estamos muy lejos de un mundo en el que solo unos pocos especialistas necesitan conocer lenguajes como C o Java o Python. Pero también es posible que desarrollos como Copilot nos den una thought de cuál podría ser el próximo paso. Lamentando el estado de las herramientas de programación, que no han cambiado mucho desde la década de 1960, Alan Kay escribió en Quora que “el próximo umbral importante que debe alcanzar la programación es que los programas y los sistemas de programación tengan una comprensión mucho más profunda tanto de lo que están tratando de hacer como de lo que realmente están haciendo”. Un nuevo oficio de programación que se centre menos en los detalles sintácticos y más en comprender lo que los sistemas que estamos construyendo están tratando de lograr, es el objetivo al que deberíamos aspirar.
