El peligro de perder la virtud de la pereza

• En programación, la pereza no se define como simple desidia, sino como una virtud intelectual que busca la abstracción y la simplicidad
• La verdadera pereza es un proceso de reflexión profunda sobre un problema para ahorrar tiempo en el futuro, y eso también beneficia a las generaciones posteriores de desarrolladores
• Las abstracciones modernas de alto nivel y la cultura ‘brogrammer’ hacen que se pierda esta virtud y la reemplazan por una falsa laboriosidad
• Los LLM llevan esta tendencia al extremo y funcionan como una herramienta de sobreproducción que hace confundir la cantidad de código con el valor
• Debemos conservar la pereza virtuosa que nace del tiempo finito de los humanos y usar los LLM para diseñar sistemas simples y sostenibles

---

La pereza como virtud del programador y el peligro de su pérdida

• Larry Wall enfatiza que, de las tres virtudes del programador presentadas en 『Programming Perl』 —pereza (laziness), impaciencia (impatience) y arrogancia (hubris)—, la pereza es la que tiene el significado más profundo
  • La pereza no es simple autodesprecio, sino un concepto que contiene la necesidad y la estética de la abstracción
  • Es la fuerza que impulsa a hacer que un sistema sea lo más simple posible y que permita hacer más cosas con mayor facilidad mediante abstracciones poderosas
• La verdadera pereza, como en ‘hammock-driven development’, parece descanso a simple vista, pero en realidad es un proceso de trabajo intelectual en el que se reflexiona profundamente sobre el problema para ahorrar tiempo en el futuro
  • Cuando se crea la abstracción correcta, esta beneficia no solo al propio desarrollador, sino también a las generaciones futuras de desarrolladores
  • Esta pereza permite escribir software con mayor facilidad y configurar sistemas más fácilmente

• Una era en la que desaparece la virtud de la pereza

  • En los últimos 20 años, a medida que se amplió el alcance de la creación de software, aumentó la cantidad de personas que no se consideran programadores
    • Para ellas, la virtud de la pereza perdió su significado original
  • La explosión de productividad que trajeron las abstracciones modernas de alto nivel, en realidad, fomenta una falsa laboriosidad (false industriousness)
    • Esto se manifiesta en la cultura ‘brogrammer’ y el ‘hustle porn’, reemplazando la pereza irónica por la conducta de producir código sin fin

• El nuevo exceso provocado por los LLM

  • La aparición de los LLM (modelos de lenguaje de gran escala) lleva esta tendencia al extremo
    • Los LLM son herramientas que amplifican la actitud creativa humana y actúan como esteroides para la cultura ‘brogrammer’
  • Como ejemplo, Garry Tan mencionó que usando LLM escribió 37,000 líneas de código en un solo día
    • Como comparación, todo el codebase de DTrace ronda las 60,000 líneas
  • Sin embargo, este enfoque es un vicio que carece de la virtud de la pereza y revela el error de evaluar el valor del software por la cantidad de código

• Los límites de los LLM y el valor de la pereza humana

  • Como los LLM tienen un costo laboral de 0, generan sistemas infinitamente complejos sin considerar el ahorro de tiempo futuro
    • Como resultado, hacen los sistemas más grandes y complejos, satisfacen métricas basadas en la vanidad, pero perjudican la calidad esencial
  • La pereza humana surge de la restricción del tiempo finito, y eso obliga a una diseño de sistemas con abstracciones claras y simplificado
    • La mejor ingeniería siempre nace de las restricciones, y la limitación del tiempo humano reduce la carga cognitiva y empuja a buscar la simplicidad
    • Como los LLM no tienen esas restricciones, no tienen una motivación propia para buscar la simplicidad

• Cómo aprovechar los LLM como herramienta

  • Los LLM todavía pueden desempeñar un papel importante como herramienta poderosa para la ingeniería de software
    • Según las guías de uso de LLM de Oxide, los LLM son solo una herramienta y no pueden reemplazar las virtudes humanas
  • Los LLM pueden usarse para resolver problemas de pereza improductiva, como la deuda técnica (technical debt), o para reforzar el rigor de ingeniería
  • Sin embargo, su propósito de uso debe orientarse necesariamente a realizar una ‘pereza virtuosa’
    • Es decir, deben usarse para crear sistemas más simples y poderosos, dejando resultados que ayuden a las futuras generaciones de desarrolladores

[GN⁺]

Opiniones en Hacker News

• Incluso en mi campo, Computational Fluid Dynamics, hay gente que presume tener muchos tests como si presumiera LOC
  Pero si los miras de cerca, esos tests no son muy estrictos y son mucho más flojos que los tests que hago yo manualmente
  Un millón de tests fáciles no significan nada si no cubren las partes clave del código

  • Yo también me di cuenta de que tenía que escribir los tests por mi cuenta
    Y para evitar que Claude “arregle” los tests cuando el código no funciona, siempre reviso los cambios en los tests con git diff
    Si administras los tests con rigor, Claude incluso implementa bien algoritmos difíciles de papers y te ahorra tiempo, pero requiere mucho cuidado
  • Esto se parece a una especie de reward hacking
    El modelo está explotando la función de recompensa que son los tests para poder “declarar victoria”
    Supongo que tal vez ese patrón también esté presente en los datos de preentrenamiento de RL
  • Hacer que un LLM genere tests que no sean tontos es realmente difícil
    Aparecen cientos de tests inútiles como assert(1==1)
    Por eso hay que mantener por separado una lista de cosas prohibidas, del tipo “no hagas este tipo de test”

• Después de programar directamente durante 30 años, ahora hice la transición por completo a AI coding, y me parece raro que la gente se atribuya como mérito propio el LOC o las funciones del código generado por IA
  Presumir que “programaste” cientos de miles de líneas al día al final no es más que haber escrito unas cuantas líneas de prompt, ¿no?

  • Esto parece más bien un espectro
    Se puede reconocer cierto mérito en los cambios que aprobaste directamente, pero una app hecha totalmente con vibe coding casi no implica participación real
    Yo estoy en un punto medio: no reviso todo el código que hace la IA, pero sí dirijo la arquitectura y la dirección del refactor
    El resultado se parece a lo que habría hecho yo mismo, pero termina mucho más rápido
  • En Meta ahora hay incluso un leaderboard de uso de IA que muestra quién consume más tokens de Claude
    Si Meta usa Claude, supongo que para Anthropic debe ser bastante motivo de alegría
  • En realidad, tener mucho LOC también puede ser una señal de un mal resultado
  • Algunas personas sostienen que LoC ya no tiene sentido como métrica de calidad
    Porque ahora estamos en una era donde implementación, testing y mantenimiento los hacen agentes
    Ven el LoC solo como una métrica de capacidad que muestra cuánto puede empujar un agente los requisitos
    La revisión crítica humana todavía puede inyectarse como feedback

• La idea de que “hay que usar más abstracciones” quizá antes era correcta, pero ahora siento que más bien es al revés
  A mí me gusta la filosofía WET (Write Everything Twice): escribirlo dos veces y recién a la tercera considerar una abstracción

  • A esto también se le suele llamar la Rule of Three
    Ver el artículo en Wikipedia
  • La verdadera belleza del software está en la abstracción correcta
    Innovaciones como los sistemas operativos, los RDBMS o la orquestación en la nube son ejemplos de eso
    Pero la mayor parte del código es simple lógica de negocio, así que la abstracción más bien estorba
    Por eso yo sigo la regla de “no construyas una plataforma hasta que haya tres casos de uso reales que lo demuestren”
  • Escribir algo más de dos veces es un estándar bajo, así que ni siquiera entra en conflicto con la cita de Perl
  • La segunda vez que lo escribes es una oportunidad para mejorarlo con una comprensión más clara del problema
    Y cuando intentes abstraerlo a la tercera, hay que cuidarse del Second-System Effect: el exceso de confianza produce sistemas complejos
  • La explosión de capas de abstracción que hubo desde Programming Perl en 1991 es realmente asombrosa

• Comparten la famosa cita del general alemán Kurt von Hammerstein-Equord
  La gente inteligente y diligente sirve para el estado mayor, la gente tonta y perezosa para el trabajo rutinario, la gente inteligente y perezosa para liderar,
  y la gente tonta y diligente es peligrosa, así que nunca se le debe dar responsabilidad

  • Alguien respondió en tono de broma: “¿y dónde quedamos los del 90% perezosos como yo?”

• Presumir que escribiste 200 mil LOC con un LLM es una tontería, pero ver eso y burlarse diciendo “ese código es estúpido” me parece una actitud igual de equivocada
  Al final, lo importante no es la salida de código sino la creación de valor
  No sé si Garry Tan realmente haya construido algo valioso

  • Pensar que la calidad del código no importa sería gravísimo
    Casos como el escándalo de Horizon IT muestran que el mal código provoca daños reales
    Según la reseña del desarrollador polaco Gregorein sobre el proyecto de Garry, esa app incluía un test harness, una app Hello World y archivos de logo duplicados, o sea, un desastre
    Preocupa si ese tipo de código no habrá ampliado la superficie de ataque de seguridad
  • Garry no es un simple desarrollador sino el CEO de YC
    No estaba hablando de LOC: estaba publicando un post promocional de IA
  • La métrica real es valor – costo
    La IA reduce costos de desarrollo y operación, pero aumenta costos ocultos como riesgos de seguridad y legales
    Los entusiastas de la IA solo enfatizan lo primero
  • No hay tiempo para leer 200 mil LOC y demostrar que era una mala idea
    Eso es algo que debe demostrar el propio vibe coder
    Seguir presumiendo LOC sigue siendo una tontería
  • La propia idea de “crear valor” también puede ser peligrosa
    Como pasa con el crecimiento basado en combustibles fósiles, el valor a corto plazo puede generar costos a largo plazo

• Viendo algunos PR recientes, he notado seguido que el LLM propone soluciones equivocadas
  Por ejemplo, implementa un parser JSON desde cero aunque ya exista uno en el proyecto
  Un humano pensaría “esto es demasiado ineficiente”, pero como el LLM no tiene pereza, trabaja duro en la dirección equivocada

  • Tampoco reconoce en absoluto las funciones duplicadas dentro del proyecto
    Ignora que haya tres funciones como formatTimestamp, aunque bastaría con un solo grep para darse cuenta

• Me identifico con la idea de que el LLM no es perezoso
  Pero no sé si eso será un problema permanente o si se resolverá con la siguiente actualización del modelo o en el pipeline de CICD
  Yo suelo darle el prompt de “revisa si hay bugs o partes para refactorizar” después de terminar una función,
  y quizá más adelante lleguemos a una etapa donde automáticamente analice commits recientes y proponga simplificaciones

  • Pero si le dices “encuentra X”, el LLM siempre encuentra algo
    Por eso existe el problema de que es difícil definir la condición de salida
  • Al final, el problema no es la naturaleza de la herramienta sino las limitaciones de cómo se usa
    Si solo le dices “agrega”, siempre agrega, y si le dices “reduce”, baja el LOC
    Si le encargas trabajo grande y omites la revisión, es fácil que se acumule código slop

• El LLM tiende a hacer una SPA completa en vez de un simple programa de salida por consola
  Y además no logra mantener conciso un archivo spec.md
  Si le dices “actualiza este documento y simplifica el contexto alrededor”, en realidad lo vuelve más complejo
  Al final, para que salga un documento fácil de leer, la persona tiene que resumirlo directamente
  Editar la salida de un LLM es doloroso, y escribirlo uno mismo ayuda a mantener la comprensión

• Ya es hora de enseñarles a los LLM y a los vibe coders las lecciones clásicas del desarrollo de software
  Como en la historia de Negative 2000 Lines of Code, muchas veces reducir código es el verdadero progreso

• Da la impresión de lo bueno que sería poder trabajar con un liderazgo así
  Trabajar con un líder que de verdad entiende las cosas es una gran suerte