Deuda técnica: 3 señales que cuestan antes de verse

La deuda técnica nunca se presenta como tal. Nadie escribe «esto es deuda» en un commit. Se ve primero en el día a día: tareas simples que llevan tres días, despliegues que dan miedo, archivos que nadie se atreve a tocar.

1. Los cambios pequeños cuestan cada vez más

La señal más fiable: compara lo que cuesta hoy un cambio trivial — una etiqueta, un campo de formulario — con hace seis meses. Si la tendencia sube sin que el producto haya cambiado de escala, la estructura del código se resiste al cambio. Esa es la definición operativa de la deuda.

2. Los mismos bugs vuelven con otras formas

Un bug corregido que reaparece en otro sitio no es mala suerte: es lógica duplicada o una responsabilidad mal ubicada. Cada arreglo local añade una variante más que mantener. El arreglo real casi nunca está donde el bug se manifiesta.

3. El conocimiento vive en cabezas, no en el sistema

Si el despliegue, la configuración o «por qué este módulo funciona así» dependen de una persona concreta, el sistema no es transferible. No es primero un problema de documentación: es señal de que el sistema es demasiado complejo para explicarse de forma simple.

Por dónde empezar

No por un «gran refactoring». Mide una cosa: el tiempo real de los cambios pequeños. Luego quita — una duplicación, una dependencia, un paso manual — cada vez que pases por ahí. La sobriedad no es una obra, es una práctica.