Qué es la deuda técnica
Es la diferencia entre lo que hay y lo que haría falta para que eso se pueda mantener. Copiar y pegar en vez de hacer una función, no escribir la prueba, dejar la versión vieja de una dependencia, el nombre que ya no dice lo que hace. Cada atajo se paga después, en horas de quien viene detrás.
No toda deuda es mala. La que se toma a sabiendas y se apunta se devuelve; la que nadie apuntó se descubre el día que algo se rompe y nadie sabe por qué.
Tipos de deuda técnica
La clasificación más citada es la de Martin Fowler, que cruza dos preguntas: si la deuda se tomó a sabiendas o sin darse cuenta, y si fue prudente o imprudente. La deliberada y prudente es un atajo que se apunta para devolverlo; la inadvertida e imprudente es la que aparece cuando nadie sabía que había otra forma de hacerlo.
Por dónde vive, se ve en el código (lo duplicado, las funciones enormes), en la arquitectura (piezas que dependen demasiado unas de otras), en las pruebas que faltan, en las dependencias viejas, en la documentación y en la infraestructura, como el servidor que nadie sabe volver a montar.
Ejemplos de deuda técnica
Una misma regla de negocio copiada en tres sitios, que se cambia en dos y se olvida en el tercero. Una librería con una vulnerabilidad conocida que no se actualiza porque rompe algo. Una consulta que va bien con mil filas y tarda segundos con un millón. Una contraseña escrita en el código porque era una prueba.
Y la más cara, la que no se ve: un proceso que falla sin avisar y deja datos a medias. Se reduce como cualquier deuda: primero se mide, después se paga lo que más interés genera, y se deja de tomar deuda nueva sin apuntarla.
Por qué crece más rápido con IA
La IA escribe mucho código en poco tiempo, y ese código llega sin el contexto de por qué está así. Se duplica lo que ya existía, se repiten patrones distintos para lo mismo y se añaden dependencias que nadie eligió. En laboratorio, el 45% del código generado por IA traía vulnerabilidades conocidas cuando no se le daban instrucciones de seguridad.
El efecto no se nota en la primera semana: se nota cuando hay que cambiar algo y cada cambio toca cinco sitios.
Cómo se mide y por dónde se empieza
Se mide con el código delante: duplicación, dependencias sin actualizar y con vulnerabilidades conocidas, pruebas que no existen, rutas sin protección, consultas que no aguantan el volumen real y puntos donde el sistema falla sin avisar. Cada uno con su evidencia, no con una opinión.
Y se ordena por lo que cuesta si se rompe, no por lo que molesta al leerlo. Nosotros entregamos esa lista y el orden; la reparación es un segundo nivel: la aplica tu equipo o la hacemos nosotros si nos lo encargas.