El código se abarató

• Con la expansión de las herramientas de codificación con IA, el costo de escribir código cayó de forma drástica, pero en la práctica el costo de entender el código generado aumentó aún más
• Los LLM son no deterministas, no preservan el código fuente original y su rango de salida se extiende a todo el software general, por lo que no pueden equipararse con la salida de un compilador
• Como los LLM generan código mucho más rápido de lo que una persona puede comprenderlo, se recomienda un uso incremental para evitar cambios masivos que nadie entienda
• El riesgo clave cuando el código se vuelve barato es la complejidad, que aumenta al menos geométricamente según la escala del sistema, mientras que los LLM son codificadores prolíficos sin temor a la complejidad
• Como solución, se propone al ingeniero sustractivo que elimina y simplifica en vez de añadir código, y se subraya la importancia de preservar el arte de la programación

---

La era del código barato

• En el último año, la IA ha empezado a generar grandes cantidades de código de calidad bastante decente y a gran velocidad, reduciendo de forma importante el costo de generar código
• Frente a la afirmación de que “programar nunca fue el problema”, el texto responde que programar también era parte del problema, y que esa parte se redujo mucho con las herramientas de codificación con IA
• Plantea qué significa para los desarrolladores que antes se enorgullecían de su capacidad de programar que la importancia de la codificación pura esté bajando

El costo creciente de entender (Understanding is Expensive(er))

• Cuando el código deja de salir con esfuerzo de las manos del programador y pasa a generarse en masa, la comprensión de ese código simplemente no existe
  • Si hace falta comprensión, hay que obtenerla leyendo el código después de haberlo generado
  • Según la idea común, leer código escrito por otra persona es más difícil que escribir el propio
• La defensa pro-IA de que “tampoco entiendes la salida del compilador” se define como un error de categoría (category error)
  • Un compilador es determinista, pero un LLM es no determinista por diseño
  • El flujo de trabajo del compilador preserva el código fuente original, mientras que el flujo de trabajo con LLM por lo general no lo hace
  • La salida del compilador se limita al dominio estrecho del lenguaje máquina, mientras que la salida de un LLM no se limita al software generalizado
• En la mayoría de los casos, especialmente en el software de misión crítica, aunque el código haya sido generado por un LLM el desarrollador debe entender el código subyacente
• Los LLM pueden producir código a una velocidad que nadie puede seguir, lo que crea el riesgo de superar la velocidad de comprensión
  • Por eso se recomienda un uso incremental en lugar de generar de golpe una lista enorme de cambios
  • Puede ser adecuado para refactorizaciones mecánicas, pero es extremadamente peligroso cuando introduce nueva semántica en una base de código

La trampa del aprendiz de brujo (The Sorcerer's Apprentice Trap)

• Se presenta la escena de “The Sorcerer's Apprentice” de la película de Disney Fantasia como una metáfora adecuada para la era de la IA
  • El aprendiz, para librarse del trabajo pesado de limpiar, hechiza una escoba, pero la escoba limpia cada vez con más violencia hasta que la situación se sale de control
  • Al final, reaparece el brujo (Sorcerer), retoma el control de la situación y reprende la necedad del aprendiz mientras pone fin al caos
• La lección de esta metáfora es que hay que ser el brujo, no el aprendiz, y el brujo debe entender el código

La complejidad sigue siendo mala (Complexity: Still Bad)

• Los humanos no entienden bien las curvas geométricas o exponenciales, y creen en cosas como el interés compuesto como si fueran cuentos de hadas
• El riesgo clave cuando el código se abarata es la complejidad, que —según se afirma, sin demostración— aumenta al menos geométricamente y a menudo de forma exponencial con la escala del sistema
• Incluso antes de los LLM ya existían los codificadores prolíficos
  • Un codificador prolífico sin miedo a la complejidad sigue apilando código sobre problemas ya existentes, hasta colapsar el sistema en un estado estancado imposible de arreglar, donde cualquier cambio crea tantos bugs como los que corrige
• Los LLM son peligrosos porque son codificadores prolíficos y, al mismo tiempo, no tienen miedo a la complejidad

El ingeniero sustractivo y restrictivo (The Subtractive, Constraining Engineer)

• Para responder al riesgo del código generado por LLM, se propone al ingeniero sustractivo y restrictivo
  • Este ingeniero sabe decir “no”, revisa con cuidado la salida del LLM, propone simplificaciones y mantiene el control con firmeza
  • Se enorgullece no del código que creó, sino del código (y las capas) que eliminó o impidió que entraran al sistema
  • Esta actitud se parece más a la de un escultor que a la de un constructor
• La actitud de constructor sigue siendo válida en el nivel de diseño de sistemas
  • Un buen ingeniero debe saber combinar componentes de forma efectiva para construir un sistema
  • Aun en ese nivel, la mentalidad sustractiva sirve para simplificar el despliegue y la interacción eliminando componentes innecesarios y fronteras entre sistemas
• El ingeniero sustractivo es un tipo distinto de la mayoría de los codificadores del pasado, y encaja con una actitud que prefiere pulir sistemas existentes antes que decir sí a todo o embarcarse en reescrituras heroicas
• Este enfoque reconoce la doble realidad de que el código se abarató y la complejidad sigue siendo el depredador alfa, y ofrece una forma productiva de preservar el arte de la programación

[GN⁺]

Opiniones en Lobste.rs

• El texto de 1985 de Peter Naur, Programming as Theory Building, parece valer la pena releerlo varias veces hoy en día

• Me parece que la frase “los LLM no pueden temerle a la complejidad” es más bien una exageración
  Ese patrón de fallo sí existe en la práctica. Si les das instrucciones amplias, los LLM agregan capas, inventan abstracciones y con frecuencia producen código excesivo para el problema. Pero ese comportamiento es fácil de observar, fácil de revisar y, sorprendentemente, también fácil de reencauzar. Basta con alinear el estilo de software deseado con archivos como AGENTS/CLAUDE.md
  Puedes pedir el cambio más pequeño posible, preguntar qué se puede eliminar y si esa abstracción realmente se justifica. También puedes preguntar por invariantes, puntos de acoplamiento y carga cognitiva, y solicitar una segunda pasada para quitar lo “ingenioso”; por lo general siguen esa presión. Si lo pones en el prompt, incluso puedes hacer que lo eviten desde el inicio
  El riesgo no está en que un LLM jamás pueda respetar la complejidad, sino en que produce con gusto la forma de código que el proceso que lo rodea recompensa. Los equipos que recompensan cantidad reciben cantidad, y los que recompensan simplicidad normalmente también pueden obtener eso
  Los modelos actuales ya son mejores que la mayoría de los humanos y van a seguir mejorando. Si el código no es bueno, hay que presionar a los laboratorios de IA con feedback. Por ejemplo, creo que la familia GPT es pésima para redactar buena documentación

  • Sí y no. El punto central parece estar menos en la capacidad que en la forma de entrenamiento y los objetivos. Lo que está de moda ahora es eso de “vibe codear todo el proyecto”, y los LLM son muy débiles para modificar código existente en comparación con crear algo desde cero. Probablemente se deba al entrenamiento, y también parece haber un sesgo estadístico. Hay muchísimo más código de codebases grandes y complejas que de proyectos pequeños y simples, así que seguramente eso pesó más en el aprendizaje
    Por eso, quizá “imposible” no sea la mejor palabra, pero sí creo que por defecto hay varios sesgos que inclinan hacia la complejidad
    También existe un sesgo a hacer algo en vez de no hacer nada. Un buen programador usa mucho más contexto que un gerente que lanza una solicitud específica, y además propone alternativas. Un LLM también podría hacerlo, pero los LLM actuales no son buenos haciendo las preguntas correctas, incluso si tienen código para “preguntar durante la planificación” o detectar repetición. Es muy posible que ese tipo de datos de entrenamiento tampoco sea común
    En cierto sentido, el prompt engineering se parece a un hack espantoso alrededor de todo este paquete de problemas
  • No sé si estoy completamente de acuerdo con esa frase, pero claramente hay algo ahí. Por un lado, he visto esa “complejidad común” de generar por defecto un enorme proyecto de CMake aunque bastaría con un Makefile de un solo objetivo
    Por otro lado, me ha tocado tener que convencer y tranquilizar al LLM después de recibir respuestas como “no lo recomiendo para un proyecto de un mes. ¿Qué tal si lo dejamos así, hacemos commit y lo conservamos como demo?”. Y eso aun sabiendo que ambas cosas tomarían menos de una hora. Pero si le dices “va, haz algo completamente nuevo; tú encuentra la forma”, al menos lo intenta, así que en ese sentido también se puede decir que no tiene miedo
  • ¿Una conversación con matices sobre “vibe coding” en Lobsters? Debe de haberse congelado el infierno /s
    Dejando el chiste de lado, estoy de acuerdo. También coincide con mi experiencia

• En general no estoy muy de acuerdo con la frase “se volvió más caro entender el código”
  Puede ser cierto si es código generado por LLM sin pensar, pero si se le guía bien, un LLM también puede producir código fácil de leer y con capas bien separadas. Claro, en ese caso la mayoría de las decisiones de arquitectura las toma una persona, y creo que así debería ser desde el principio
  Como contraejemplo, sentí que los LLM son muy buenos para entender código escrito por alguien que no conoces. Puedes pedirle a Claude Code que analice a fondo cierto código, cree un documento en Markdown explicando cada parte e incluso te sugiera por dónde empezar a revisar o entenderlo
  Eso realmente tiene mucho valor

  • Mi experiencia usando LLM con código desconocido en general ha sido buena, pero cuando algo se sale de la convención a veces se inventan cosas creativamente y mienten. El problema es que, como el código te resulta desconocido, distinguir entre ambas cosas es difícil

• “Los humanos por lo general no entienden bien las curvas exponenciales. Por eso creen en cuentos de hadas como el interés compuesto”. ¿Quiere decir que el interés compuesto es un cuento de hadas? ¿O estoy entendiendo algo mal?