LLMs y la deuda técnica: ¿matan la buena ingeniería?

La pereza como virtud perdida en la era de los LLMs

En 1987, Larry Wall, creador de Perl, definió las tres virtudes del programador: pereza, impaciencia y soberbia. Para Wall, la pereza no era un defecto, sino la fuerza que empuja a los ingenieros a construir abstracciones poderosas que eliminan el trabajo repetitivo para siempre. Un programador verdaderamente perezoso no resuelve el mismo problema dos veces: lo automatiza, lo abstrae, lo encapsula. Y en ese proceso, crea software más limpio, más mantenible y más valioso a largo plazo.

Esta virtud, que ha sido el motor silencioso de décadas de avances en ingeniería de software, está en riesgo. Bryan Cantrill, cofundador de Oxide Computer Company y reconocida voz en el ecosistema de sistemas distribuidos, plantea en su artículo The Peril of Laziness Lost una pregunta incómoda para cualquier equipo técnico que hoy usa asistentes de IA: ¿están los LLMs destruyendo la pereza virtuosa del programador?

Qué hace diferente a un LLM frente a un programador humano

Un programador con experiencia, cuando enfrenta un problema recurrente, tiene un incentivo muy claro para crear una buena abstracción: su propio tiempo futuro. La pereza virtuosa es, en el fondo, una función de optimización orientada al futuro. El ingeniero piensa: «Si construyo esto bien hoy, no tendré que hacerlo nunca más».

👥 ¿Quieres ir más allá de la noticia?

En nuestra comunidad discutimos las tendencias, compartimos oportunidades y nos ayudamos entre emprendedores. Sin humo, solo acción.

👥 Unirme a la comunidad

Los modelos de lenguaje de gran escala no tienen ese incentivo. No van a mantener el código que generan. No sufrirán la deuda técnica que acumulan. Su objetivo implícito es generar una respuesta que aparente resolver el problema en el momento de la consulta, no minimizar el costo futuro de mantenimiento. En otras palabras, los LLMs optimizan para el ahora, mientras que la buena ingeniería optimiza para el mañana.

Esta diferencia no es un detalle técnico menor. Es una divergencia fundamental en la función objetivo, y sus consecuencias se están volviendo medibles a escala industrial.

Los datos que confirman el problema: deuda técnica en aumento

El análisis más contundente proviene de GitClear, que estudió 211 millones de líneas de código producidas entre 2020 y 2024 en repositorios de Google, Microsoft, Meta y grandes empresas. Los hallazgos son reveladores:

La tasa de rotación de código (code churn) aumentó de 3,1% en 2020 a 5,7% en 2024, correlacionada con la adopción masiva de asistentes de IA.
La duplicación de código creció de 8,3% (2021) a 12,3% (2024), una expansión de casi 4x en bloques duplicados.
El refactoring cayó un 60%, pasando de representar el 25% de los cambios en 2021 a menos del 10% en 2024.
Por primera vez, el código «copiado y pegado» superó al código «movido y reutilizado», señal inequívoca de que las abstracciones están cediendo terreno al copy-paste.

Complementando esto, un análisis de 2026 sobre herramientas de IA para programación revela que los pull requests asistidos por IA generan aproximadamente 1,7 veces más issues que los pull requests humanos, y que el 96% de los desarrolladores no testea completamente el código generado por IA antes de integrarlo.

Productividad superficial: más líneas, menos valor

Existe una narrativa dominante en el ecosistema tech: los LLMs hacen a los programadores 4 veces más rápidos. Y en cierta medida, es cierto. Para tareas repetitivas, boilerplate y generación de tests unitarios, las ganancias de velocidad son reales y valiosas.

Pero hay un problema con medir productividad solo en velocidad de commits o en volumen de código generado. Cuando el incentivo del equipo es escribir más código más rápido, y la herramienta está perfectamente optimizada para exactamente eso, el resultado predecible es: más código, con menos cohesión, menos reuso y más deuda técnica.

El análisis de Baytech Consulting lo denomina «el impuesto oculto»: los defectos introducidos por IA (condiciones de carrera, inconsistencias arquitectónicas, lógica implícita no documentada) que los equipos solo descubren semanas o meses después, cuando el costo de corrección se ha multiplicado.

El dato más inquietante de cara a 2026: el número de incidentes por pull request creció un 23,5% en equipos con alta adopción de IA, y los desarrolladores están destinando más de 20 horas semanales a resolver incidents directamente vinculados a código generado por asistentes.

El riesgo para los equipos de startups: cuando la velocidad se convierte en trampa

Para un equipo de startup, la presión de velocidad es máxima. El time-to-market puede ser la diferencia entre capturar o perder un mercado. En ese contexto, los asistentes de IA son tentadores: prometen más features, más rápido, con menos personas.

Pero la trampa es sutil. Un equipo que construye su base de código principalmente con IA generativa en las etapas tempranas puede estar hipotecando su capacidad de escalar. Cuando el producto crece, cuando el equipo crece, cuando llegan los primeros mil usuarios concurrentes, la deuda técnica acumulada se vuelve el cuello de botella. Y ese cuello de botella no lo ve ninguna métrica de velocidad de desarrollo.

La pereza virtuosa que describía Larry Wall era, en esencia, una inversión en el futuro. Las abstracciones bien construidas son activos. El código duplicado y sin refactorizar es pasivo. Los LLMs, por su naturaleza, están inclinados a generar pasivos que se disfrazan de activos.

¿Cómo equilibrar IA y calidad en ingeniería de software?

Esto no es un argumento contra el uso de IA en desarrollo. Es un argumento a favor de usarla con criterio ingenieril. Algunas prácticas que los mejores equipos técnicos están adoptando en 2026:

Revisión humana obligatoria con foco en abstracciones: No basta con revisar que el código «funcione». Hay que revisar si introduce duplicación innecesaria o evita una abstracción que debería existir.
Métricas de calidad, no solo velocidad: Medir churn de código, tasa de refactoring y deuda técnica acumulada, no solo velocidad de entrega o número de PRs.
IA para lo repetitivo, humanos para el diseño: Los LLMs son excelentes generando tests, documentación, y boilerplate. Las decisiones de arquitectura y diseño de abstracciones deben seguir siendo territorio humano.
Cultura de refactoring activo: Equipos que reservan tiempo deliberado para refactorizar y mejorar el código existente, en lugar de solo añadir features nuevas.
Testing exhaustivo antes de integrar: Con solo el 4% de developers testeando completamente el código de IA, esta es una de las vulnerabilidades más fáciles de corregir con proceso.

El futuro de la ingeniería de software: ¿recuperaremos la pereza virtuosa?

La reflexión de Bryan Cantrill llega en un momento crítico. Las herramientas de IA seguirán mejorando, y su adopción será prácticamente universal en los equipos de desarrollo técnico. La pregunta no es si usar IA, sino cómo preservar la capacidad humana de pensar en abstracciones mientras lo hacemos.

Hay indicios de que la industria está empezando a notar el problema. El nivel de confianza en los outputs de IA para código cayó al 29% en 2025, según datos recientes. Los equipos más sofisticados ya no miden el éxito de sus asistentes de IA en velocidad de generación, sino en calidad de integración y tasa de incidentes post-deploy.

La pereza virtuosa de Larry Wall no era sobre hacer menos. Era sobre pensar más profundo para trabajar menos en el futuro. Esa capacidad de pensamiento profundo sobre abstracciones es, hoy, el diferencial más escaso y más valioso en un equipo de ingeniería.

Conclusión

Los LLMs han transformado la productividad en ingeniería de software, pero lo han hecho optimizando para el corto plazo, exactamente lo contrario de la pereza virtuosa que Larry Wall celebraba. Los datos de GitClear, Baytech y múltiples estudios de 2025-2026 muestran un patrón consistente: más código, más rápido, con más deuda técnica, menos abstracciones y más incidentes.

Para los founders que lideran equipos técnicos, el mensaje es claro: la velocidad de desarrollo impulsada por IA es real, pero sus costos ocultos también lo son. La ventaja competitiva sostenible no la tendrá el equipo que genera más código con IA, sino el que preserve la capacidad humana de construir sistemas elegantes, mantenibles y escalables. Esa sigue siendo, después de todo, la virtud más importante en ingeniería de software.

Descubre cómo otros founders implementan IA sin sacrificar la calidad de su ingeniería

Aprender con founders