- Usar herramientas de codificación con IA implica aumentar la "deuda de código"
- Entre dos empresas con el mismo producto e ingresos, una empresa que opera con 100 mil líneas de código es mucho más rápida de entender y modificar que una con 1 millón de líneas de código
- Es decir, cuanto más código hay, más deuda se acumula; la generación de código con IA aumenta la productividad, pero al mismo tiempo puede interpretarse como una acción que incrementa la deuda
- La deuda tiene una doble cara: positiva y negativa
- Positiva: hace posible un crecimiento rápido en el corto plazo
- Negativa: si no se gestiona bien a largo plazo, puede provocar el riesgo de colapso del proyecto
- En otras palabras, la deuda puede ser buena o mala, puede tener o no intereses, y puede tanto permitir un crecimiento acelerado como hacer colapsar un proyecto
- Lo importante no es si se usa o no la herramienta, sino la actitud de gestionarla con responsabilidad
- Hay que garantizar un acceso fácil a las herramientas, pero también considerar la calidad del código generado y su costo a largo plazo
5 comentarios
Aunque el código sea muy largo, si se puede explicar fácilmente "qué hace", no es deuda.
Por eso se dice que el uso indiscriminado de la IA genera deuda, porque dificulta hacer eso.
https://github.com/kelseyhightower/nocode
No está explícitamente indicado con claridad en el texto principal, pero ¿podría significar también que cuando el código se escribe con IA, al resultar menos familiar en comparación con el escrito directamente por una persona, termina convirtiéndose en deuda?
Opiniones de Hacker News
Se siente que medir todo superficialmente por cantidad de líneas de código (LOC) es una forma fragmentaria de verlo. Si Company A tiene 1 millón de líneas de código mucho más limpias, bien organizadas y documentadas, podría estar en una mejor situación que Company B con 100 mil líneas mal escritas. El punto clave es que el problema no es el código, sino la complejidad, y la cantidad de líneas es solo un indicador aproximado para medirla. El código es un activo. Es el producto y el activo de una empresa de software. Claro, si hay más activos también sube la complejidad, pero eso es algo demasiado obvio. Es como no poder ver de forma totalmente negativa la red de autopistas de EE. UU. solo porque sea difícil de mantener y compleja. Incluso dejando de lado el tema de la IA, al final el argumento del autor se reduce a una conclusión básica que cualquiera conoce: “cuanta menos complejidad, mejor”. Por eso, el punto más importante de este texto se puede resumir al nivel de: “asegúrate de verificar si las herramientas de codificación con IA no están agregando complejidad innecesaria al código final”
Yo más bien creo que la complejidad no es el punto central aquí. Si asumimos al revés que ya existe un negocio de software que logró sobrevivir, entonces en principio lo mejor es reducir todos los costos posibles (compras, sueldos, etc.) tanto como se pueda. Se dice que la complejidad es peor que la simplicidad, pero eso es porque cuando de verdad hay complejidad, sale más caro. Sin embargo, lo que en última instancia importa es el costo en sí, ya sea a corto o largo plazo, de capital u operativo. La verdadera pregunta es si el código generado por LLM reduce los costos o los aumenta. El tamaño del código, la complejidad y muchísimas otras variables que ni OP ni tú mencionaron son importantes
Yo suelo ver la complejidad de mis funciones con cyclomatic complexity. Mido la complejidad con SwiftLint para que marque cuando supera cierto umbral. A veces las divido más o menos por salir del paso, pero por lo general siempre trato de encontrar una forma de simplificarlas más. Mis archivos son bastante largos, pero intento mantener una proporción de 50:50 entre comentarios y código. Si le das a un LLM un prompt para reducir la complejidad y aumentar los comentarios, creo que podría hacerlo bastante bien
El código es un activo y una deuda, como si fuera una sustancia química volátil. Si se usa bien y rápido, puede generar dinero, pero si se abandona o se derrama, se convierte en deuda. El código fuente no se degrada por sí solo, pero a medida que cambian los objetivos y procesos de la organización, su “aptitud para el propósito” sigue cambiando
Me parece interesante el tema de “¿por qué no podemos hacer software simple?”. Sobre la complejidad, me impactó la idea de que “la complejidad surge cuando los sistemas interactúan. Los sistemas complejos pueden derivar en irracionalidad, y también producir creatividad inesperada”
Yo creo que el activo es el software en sí, no el código. Como en una autopista, donde el activo no es el concreto sino la infraestructura terminada. La calidad del concreto afecta la depreciación del valor del activo y los costos de mantenimiento, y eso a su vez impacta el valor del activo. Aquí también hay que considerar necesariamente la perspectiva de gestión de riesgos
Al inicio de mi carrera pensaba que lo importante era escribir mucho código. Ahora, 20 años después, me enorgullece más borrar más código. Desde la perspectiva de un ingeniero de seguridad, el código no es solo deuda, también es riesgo. En especial, las dependencias de bibliotecas externas son un gran riesgo. Hace poco, junto con un colega, escribimos un pequeño init system para Linux de menos de 600 líneas usando solo la biblioteca estándar de Rust, y ya se usa en producción en varias organizaciones. Sin dependencias, y además arranca en menos de 1 segundo. Me hizo sentir que sí se pueden construir servidores Linux tipo appliance sin systemd ni cientos de miles de líneas de código en C. Si lo haces tú mismo, la cantidad de código es mucho menor y puedes entender completamente todo el sistema
Creo que el peor escenario del código generado por IA se ve más claramente no tanto desde la perspectiva de la empresa, sino en proyectos más personales. Yo puedo escribir por mi cuenta 10,000 líneas de código excelente que conozco bien, o puedo sacar a las carreras, varias veces más rápido, 20,000 líneas de código problemático. Yo mismo trato de encontrar un equilibrio entre esos dos extremos. Si lo que quiero es seguir ampliando el desarrollo, creo que el tiempo “ahorrado” en el primer caso al final termina siendo una pérdida
Yo diría que siempre existe un punto medio. En mi caso, las únicas veces que he dejado la generación real de código a la IA han sido con código autocontenido, como scripts de Bash o Python. Como esos scripts solo interactúan con la línea de comandos, los límites están claros y son fáciles de manejar. Es un tipo de código que se escribe una vez y nunca más se vuelve a mirar. Pero generar con IA código del dominio central del negocio no tiene mucho sentido, así que no lo hago. Igual hay que hacer code review, y lo que de verdad necesito es en qué casos puedo verificar la mantenibilidad del código. Si no es una situación donde el código se pueda desechar tal cual o revisar de manera simple, no hace falta usar herramientas de generación de código. Si la IA pudiera asumir el rol de product owner, entender pérdidas reales del negocio e incluso mejorarlas, entonces sería otra cosa, aunque en ese caso habría que preocuparse más bien por el riesgo de que desaparezcan los usuarios
A mí también, cada vez que le confié demasiado código a la IA, tarde o temprano terminé pagando caro en productividad perdida. Si toda una app estuviera hecha con vibe coding, la habilidad más importante probablemente sería poder juzgar: “¿de verdad hacía falta esta funcionalidad?”. Debe ser realmente doloroso depurar código espagueti sin entender en absoluto qué hace cada línea
Dijiste que en el primer caso se pierde tiempo, pero el segundo caso —código peor, más rápido— también termina siendo una pérdida de tiempo. Creo que la esencia está en encontrar el punto medio
Un código breve pero con nombres de variables mal puestos o demasiado “ingenioso” sale mucho peor que un código más verboso, bien documentado y con nombres de variables ricos en contexto. La deuda al final es proporcional al tiempo que toma entender, modificar y extender el código. La cantidad de líneas de código tampoco es una métrica perfecta para medir la deuda. Si realmente todo lo demás fuera igual, reducir la cantidad de código podría sacrificar la legibilidad y, de hecho, aumentar la deuda. Por eso, creo que es más correcto decir que “la ausencia de teoría es deuda”. De hecho, el código corto en sí también podría ser deuda desde la perspectiva de los LLM. Esto se debe a que el uso de LLM minimiza la construcción de teoría, y eso es especialmente cierto en la situación actual, donde la IA no puede construir por sí sola una teoría sobre todo el proyecto ni transmitirla correctamente al ingeniero
Me gusta ver la programación como un proceso de construcción de teoría. Sobre todo en programas de negocio, esa teoría debería estar centrada en el negocio. Por ejemplo, creo que sí o sí deben entrar perspectivas como “¿se puede contratar fácilmente a desarrolladores para este codebase?”, “¿qué tan estable es el modelo de negocio?” o “¿cuál es la importancia comercial de cada funcionalidad?”
Se me acaba de ocurrir una idea. Me pregunto si sería posible preguntarle a una IA sobre los nombres de variables o la explicación de las funciones dentro del código. Hasta ahora yo solo he usado IA para generar código
En algunas empresas donde trabajé durante mucho tiempo, no había activos de código propios, pero el negocio central dependía de servicios empresariales externos de terceros. La duda aquí es cómo se debería medir cuánta “cantidad de código” existe realmente en esos casos. Por ejemplo, si dependemos de un proveedor SaaS legacy, ¿habría que considerar también sus líneas de código como parte de nuestra deuda?
A mi parecer, el mayor riesgo al depender de servicios de terceros es que ese proveedor quiebre o que cambien las condiciones del servicio por una adquisición o fusión. Muchas veces nos toca usar servicios de startups con mucho capital, pero que todavía no logran sostenerse realmente por sí mismas
Estoy totalmente de acuerdo con esto. En una empresa anterior usamos un SaaS de email marketing, y aunque el código de integración que hicimos tenía apenas 500 líneas, sufrimos muchísimo apagando incendios por todos los problemas del servicio. Al final reimplementamos por separado solo las funciones que necesitábamos y las trajimos in-house, y con eso ahorramos muchísimo costo y sufrimiento, aunque las líneas de código aumentaron unas 3 mil
No termino de entenderlo.
Sin duda el código es un activo, pero al igual que el hardware, se deprecia por distintas causas (defectos, cambios en la industria del software/hardware, etc.). Cuanto más código de software hay, mayor es el costo de depreciarlo cada año. Si no se gestiona lo suficiente (por ejemplo, si hay demasiado código para la cantidad de desarrolladores), más adelante el costo de corregir problemas crece de forma exponencial. Es como si al concepto de depreciación se le añadiera “interés”. Por eso entiendo que se use la palabra “deuda”, aunque no es un concepto que encaje a la perfección
Obviamente, el repositorio más perfecto es este
Antes yo presumía de borrar 20 mil líneas netas de código al mes. Hace unos años intenté volver a hacer eso con un equipo remoto de 20 desarrolladores, pero llegaban tantos pull requests que era imposible seguirles el ritmo. Ahora hago pair programming con Claude Code y GPT, y se siente totalmente como esto último. Creo que aquí hay oportunidades inteligentes de refactorización. Pero parece que hace falta más contexto. Probé este tipo de cosas en código legacy con Cursor y Claude opus 4.1, pero ni un millón de tokens alcanzó. Tal vez podría funcionar algo así como traducir entre un LLM personal y un LLM compartido; me pregunto si alguien tiene experiencia con eso
Parece que nadie hace mucho una pregunta muy importante: “¿cuál es la cantidad mínima absoluta de código necesaria para implementar completamente la funcionalidad X?”. Claro, responderla exactamente es imposible, pero pensar así de por sí crea una mentalidad eficiente. En cambio, la gente se interesa mucho por cosas como la verificación formal, que en la práctica no son tan importantes. La verificación formal, si no se considera la cantidad mínima viable de código, puede volverse más bien desperdiciadora y carente de sentido. Y normalmente se asume que el código que escriben los ingenieros siempre es bueno, cuando en realidad la mayoría de las veces agrega abstracciones y complejidad innecesarias y termina generando más trabajo. Una parte considerable de la ingeniería de software en realidad tiene valor negativo. Claro, hay cosas de valor positivo y negativo mezcladas, y por eso es más difícil juzgarlo