Cuando era un joven ingeniero, había un viejo programador llamado Larry que a menudo impartía su sabiduría a los jóvenes. Un hombre de unos cuarenta años, tenía esa manera arenosa, vista todo lo que hizo años de batallas muy reñidas en las trincheras de codificación. El suyo era un corazón de oro cubierto de una capa de cinismo; Imagine a Philip Seymour Hoffman como un programador de Perl.
Durante su decimocuarta taza de café, Larry dispensaría sus reflexiones en la vida de la codificación, las realidades de los proyectos (y los gerentes de proyectos) y las virtudes de vi Versus emacs. Una cosa que dijo, que se ha quedado conmigo todos estos años, fueron que los idiomas de cuarta generación (4GL) nunca habían funcionado y nunca lo harían.
Como la mayoría de los desarrolladores de software, he sido Rodeando en los jardines del código generado por la IA Por un par de años. Estoy empezando a preguntarme: ¿es esto? ¿Hemos llegado a la tan esperada utopía de 4GL?
¿Qué es 4GL?
Wikipedia tiene un Buena descripción del concepto de lenguaje de cuarta generaciónque se suponía que se extendería a través del software como una revelación. Entre otras cosas, los 4GL a veces se describen como «idiomas que generan programas». Son una abstracción de nivel superior de idiomas familiares de tercera generación como Java y Javascripty tienden a centrarse en una sintaxis del lenguaje más natural.
Términos como interfaz del lenguaje natural y generación de programas Ciertamente suena como IA generativa¿no? Incluso había un libro escrito en 1981 llamado Desarrollo de aplicaciones sin programadoresque previó un futuro donde la inteligencia artificial reemplazaría a los desarrolladores humanos.
Pero 4GL reales como ENFOCARjunto con derivados modernos como editores de Wysiwyg, marcos de desarrollo de aplicaciones rápidas (RAD), y plataformas de bajo código/sin códigotodos no cumplen con esa promesa por una simple razón: todos requieren un desarrollador que sepa cómo usarlos. Incluso con Soluciones de codificación del lenguaje naturalhay momentos en que alguien necesita poder caer al sistema subyacente y arreglarlo. (Vea mi reciente Revisión del código de ROO para más sobre esto.)
4GL y IA generativa
La mayoría de los no programadores estarían de acuerdo en que usar una solución derivada de 4GL se parece mucho a la programación. Incluso un marco RAD Wysiwyg requiere un pensamiento considerable y algún conocimiento de los conceptos de programación. Necesita una comprensión básica de los almacenes de datos y esquemas (sí, incluso con Coso), el middleware que conecta un almacén de datos a la interfaz y la interfaz misma. También debe comprender la relación entre los servicios y las API y la infraestructura que los permite y los asegura.
Esto también parece ser cierto cuando se usa Modelos de idiomas grandes (LLM) generar código, pero en menor grado. Las descripciones de funcionalidad de lenguaje natural muy amplio no son terriblemente efectivas. Lo que es más efectivo al programar con IA, en mi experiencia, es un proceso iterativo de ida y vuelta Eso entran y sale de diversos grados de granularidad.
Cuanto más empujamos las abstracciones para manejar la complejidad, más evidente se hace que un ser humano competente aún debe impulsar el trabajo en sí. Comprender los detalles que se suavizan por la abstracción se vuelven más importantes cuando cada una de las partes y todas sus interrelaciones se estiran.
Cuando se trabaja directamente en los detalles de un componente, usar una herramienta 4GL para interactuar con ella puede tener ganas de tratar de hacer un trabajo detallado con guantes voluminosos. Creo que los programadores más experimentados dirían lo mismo sobre el uso de un asistente de codificación de IA.
Lo que la IA hace bien
No me malinterpreten: es increíblemente útil poder pedirle a una herramienta de IA que escupe una función decente que hace exactamente lo que necesita, y un estudio reciente muestra que Más desarrolladores senior están aprovechando al máximo las capacidades de IA. Pero cuanto más ampliamente tomamos el poder de IA en problemas complejos, más creamos algo que se siente como deuda técnica. Tal vez un término mejor en este caso sería deuda de comprensión.
La IA es una gran herramienta para interactuar con el conocimiento general sobre el diseño y la arquitectura. La capacidad de llevar el código de programación y los conceptos a un marco común es una gran ventaja de la IA y de 4GL. Pero para aprovechar cualquiera de las herramientas, el usuario debe tener una comprensión básica de los conceptos de programación y cómo se aplican.
Sin la voluntad de finalización
Las abstracciones de orden superior tienden a sobresalir en la creación de prototipos, pero no son tan adecuados para desarrollar el producto final en la producción. Ese último acto tiende a requerir una o más personas que no solo entiendan la infraestructura subyacente sino que tengan lo que yo llamo el Voluntad hasta la finalización.
Lo que digo es que necesitas a alguien que tome cualquier mecanismo que se proporcione y conduzca hacia un objetivo previsto, y que seguirá adaptándose y avanzando hasta que se realice ese objetivo. Este es un rasgo único humano que no se puede abstraer. Al igual que 4GL, la inteligencia artificial puede servir ese final, pero no puede conducirlo.
Un programador humano trae algo a la mesa que llamaré cariñosotambién conocido como «dar un @#^$». Cada desarrollador experimentado ahora ha notado la forma en que AI simplemente entregará con confianza la solución incorrecta una y otra vez, o romperá una cosa mientras arregla otra. Eso se debe a que AI en realidad no le importa el resultado.
Cuando la pereza conduce a más trabajo
Es una paradoja extraña que cuanto más necesite la IA, menos útil es. Los desarrolladores de software experimentados pueden usar con confianza la IA porque, cuando sale mal, podemos saltar allí y solucionarlo. Años de experiencia en programación facilitan ver dónde se está saliendo la inteligencia de la máquina. Pero cuando los desarrolladores menos experimentados confían en la IA, están menos equipados para captar los errores. Este es el peligro de «programación perezosa«Escribir grande.
Como ejemplo, considere mi relación disfuncional de larga data con CSS. La verdad es que no soy muy bueno en eso. Por un tiempo, pensaba que la asistencia de codificación de IA podría resolver mi problema. Con IA, de repente podría convertirme en un desarrollador de CSS más competente y menos estresado. En cambio, sigo siendo un desarrollador de CSS mediocre, y ahora también un usuario de CSS generado por IA.
Puedo seguir confundiéndome con CSS y apoyándome en las herramientas de IA para atraparme cuando fallo. Pero la verdadera solución, he encontrado, es trabajar con un ser humano quien realmente entiende CSS de todas las formas que no. Eso está bien; Me gustan esas personas y disfruto trabajar con ellos. Son seres mágicos, algo así como aquellos que pueden cocinar pasta correctamente.
Conclusión
El sueño de AI se parece mucho al sueño de 4GL. Claramente, la IA ha logrado más importancia en sus efectos prácticos que 4GLS. Pero las limitaciones y las fallas son lo suficientemente similares como para merecer nuestra atención. Me pregunto seriamente si los vastos extensiones de código generado por IA simplemente aumentarán la demanda de una mayor experiencia en ingeniería de software, con manos como Larry, que siguen siendo escépticas, todo esto conducirá a mucho.
