El fin de la programación
Si no hay código, no hay cruft
Hace poco escuché a un tecno influencer mencionar que lo más importante de la IA para generar código es su velocidad. Si se equivoca o alucina, de vez en cuando da lo mismo, porque igual estás generando código más rápido que si lo hicieras a mano.
Y tiene razón, en parte. La IA, bien usada, nos permite generar código rápidamente. Pero hay un problema: la calidad es más importante que la velocidad.
Un problema con privilegiar la velocidad de codificación, es que aumenta la cantidad de errores, o malas decisiones, las que impactan en la velocidad general del equipo.
A este conjunto de problemas que hemos acumulado en nuestras bases de códigos las llamamos “cruft”.
«El “cruft” corresponde a los elementos de un programa, sistema o producto que son inútiles, están mal diseñados o ambas cosas. En informática, los elementos de un programa, sistema o producto se refieren a áreas de código redundante, inadecuado o simplemente mal escrito, así como a hardware y componentes electrónicos viejos o de calidad inferior.» 1
El cruft no es deuda técnica, de eso hablaremos en otro artículo. El término empezó a usarse activamente en el MIT, aunque su origen parece ser el laboratorio Cruft, un edificio construido en Harvard en honor a Harriet Ottis Cruft, y que en la Segunda Guerra Mundial se usó como laboratorio para el desarrollo del radar. Con el tiempo, este se convirtió en un almacén de equipo anticuado o que ya no se usaba. De ahí que se convirtió en un símil para todo aquello que es inútil, roto, o simplemente mal diseñado.
También se usa como sinónimo de detrito, esa basura que se acumula y que debe ser eliminada.
Un ejemplo típico de cruft es el código duplicado. Tienes bloques de código que son idénticos distribuidos a lo largo de la base de código, pero con algunos cambios. El problema que trae esto es que si cambias la lógica fundamental que implementa este fragmento de código, tienes que realizar el mismo cambio en muchos lugares.
Mientras haya código, habrá cruft. Uno de los principales objetivos de un buen proceso de desarrollo de software es reducir el cruft, idealmente eliminarlo totalmente.
Pero quizás la mejor solución es no tener que lidiar para nada con el cruft. Después de todo “la mejor linea de código es la que no se escribe”.
Las IA y el Cruft
Los LLM están siendo usados para generar código más rápido, pero están generando cruft de forma silenciosa. Y ya hay varios equipos que están lidiando con algunos problemas generados por esto (sugiero ver este análisis de GitClear)
En mi opinión, se puede hacer una mejor IA que codifique, pero usando otro tipo de modelos, y no sé si está avanzando por ahí. Después de todo, el código tiene una gran ventaja, pues su estructura está formalizada. Entonces, la generación de código automático debería ser más eficiente de lo que está siendo hasta ahora. Si alguien sabe sobre otras formas de generar código usando IA, le agradeceré me informe en los comentarios.
Ahí hay un área de investigación interesante. Me parece que los modelos actuales tienen varias limitaciones, partiendo por el tamaño del contexto, usan mucha energía y capacidad de cómputo, siendo que un compilador o un analizador semántico son herramientas que llevamos años usando y construyendo de manera eficiente. Yo creo que se puede hacer algo mejor, y si tuviera tiempo (o financiamiento) sería algo a lo que me dedicaría.
El desafío es abandonar el paradigma de que generar código es idéntico a generar texto o imágenes. Una IA útil para programar debe entender toda la base de código, debería descubrir el cruft, reducirlo. Proponer refactoring, y ayudar a razonar sobre el código. Hay herramientas que están acercándose a esto y son interesantes, y las exploraremos en futuros artículos.
Yo no creo que la programación vaya a desaparecer en un futuro cercano, en 10 años más vamos a seguir escribiendo código en lenguajes, y quizás durante más tiempo. Pero eso no es algo bueno. En realidad el fin último de nuestra profesión (desarrollador de software) es desaparacer.
La idea de que un usuario va a especificar lo que quiere y una computadora creará un programa para él, no es más que el sueño de crear un lenguaje de alto nivel. Llevar la programación hacia el usuario final. Y ese es el paradigma incorrecto, lo que debemos hacer en realidad es lograr que la programación desaparezca.
Si miran las herramientas actuales que hacen esto, consisten en un bucle de retroalimentación, en que el usuario explica lo que quiere. La IA escribe código, el usuario lo prueba, le pide correcciones o afina el requerimiento. Esto funciona más o menos bien, porque casi todos los ejemplos que se muestran, o muchas necesidades cubiertas, ya están escritos en miles de bases de código a las que tienen acceso los LLM. Si sales de esos problemas típicos, o usas lenguajes que tienen pocas bases de código, las IA fracasan, por ahora. Tampoco es que estén mejorando porque aprenden más; lo que va ocurriendo, es que el “aprendizaje” consiste en aumentar su base de código desde la cual hacer un copy paste. Entonces, las IA de código actual son unas grandes generadoras de cruft, y eso es un problema.
Lo que debemos lograr es que eso no ocurra. Hay que cambiar la arquitectura fundamental de las IA que programan. Es más, no nos debe interesar si programan ni en qué lenguaje lo hacen. El éxito se medirá en nuestra capacidad de eliminar totalmente la programación. Lo que queremos es que usemos las computadoras tal como lo hacen en Star Trek:
DAX: Computadora, crea una base de datos para todas las referencias históricas a los Orbes, incluidos todos los informes de cualquier fenómeno inexplicable en el espacio bajorano.
ORDENADOR: ¿Parámetros de tiempo?
DAX: Diez milenios.
ORDENADOR: Inicializando base de datos. La función solicitada requerirá dos horas para completarse.2
Star Trek Deep Space Nine, episodio 1: Emisario.