La deuda técnica no depende de quién escribió el código, sino de cuánto cuesta cambiarlo. Un módulo perfectamente correcto que nadie del equipo entiende es deuda técnica, aunque no tenga un solo error, porque cada modificación futura exigirá reconstruir un razonamiento que nadie hizo.
Esto importa ahora más que nunca porque ha aparecido una vía rápida para acumular código correcto e incomprendido: aceptar lo que genera un modelo sin haber entendido por qué está así.
Cuando un equipo modifica un sistema, el trabajo real no es escribir las líneas nuevas. Es responder a tres preguntas antes de escribirlas: qué hace esto ahora, por qué está hecho así y qué se rompe si lo cambio.
Ese trabajo se llama comprensión, y consume la mayor parte del tiempo de cualquier cambio en un sistema maduro. Si nadie entendió el código cuando entró, esa factura no desaparece: se aplaza y se paga con intereses, porque quien la pague no tendrá siquiera el contexto de la conversación original.
Hay una asimetría incómoda: generar es más rápido que entender. Un modelo puede producir en segundos algo que a una persona le lleva veinte minutos comprender. Cuando la generación se acelera y la comprensión no, el desequilibrio se acumula en el repositorio.
Nadie sabe si una parte se usa. Aparece código que quizá sea necesario y quizá no, y ante la duda se conserva. El sistema engorda con material que nadie se atreve a borrar.
Las revisiones se vuelven superficiales. Cuando llegan cambios grandes con frecuencia, la revisión pasa de «entiendo esto y estoy de acuerdo» a «parece razonable». Es un cambio silencioso y decisivo.
Se resuelven los mismos problemas dos veces. Aparecen tres funciones que hacen casi lo mismo, porque nadie sabía que las otras existían.
Los errores se corrigen envolviendo, no arreglando. Se añade una condición encima del problema en lugar de resolverlo, porque tocar el original da miedo.
GitClear puso números al tercer síntoma: los bloques de código duplicados se multiplicaron por ocho en 2024, y su informe posterior señaló que la duplicación seguía creciendo. La duplicación es la huella estadística de la incomprensión: se copia lo que no se entiende lo bastante como para reutilizarlo bien.
Proponemos una sola, y es fácil de defender en cualquier equipo:
Nadie fusiona código que no podría explicar en una pizarra.
No exige entender cada detalle de implementación. Exige poder responder a tres cosas: qué problema resuelve, por qué se resolvió de esta forma y no de otra, y qué pasaría si dejara de existir.
Aplicada de verdad, esta regla no frena la velocidad: la reordena. Sigue siendo válido generar el 80% del código con asistencia. Lo que deja de ser válido es incorporarlo sin haberlo leído.
|
Práctica |
Before |
Con generación asistida |
|---|---|---|
|
Tamaño del cambio |
Limitado por el tiempo de escribirlo |
Puede crecer sin límite natural |
|
Foco de la revisión |
Buscar errores |
Comprobar comprensión y encaje |
|
Riesgo principal |
Un fallo concreto |
Aceptar estructura que nadie decidió |
|
Control eficaz |
Revisión entre pares |
Límite de tamaño de cambio y prueba obligatoria |
La fila del tamaño explica el hallazgo de DORA de 2024: al aumentar la adopción de IA, la estabilidad de entrega caía un 7,2%. La causa no es la calidad del código generado, sino que desaparece el freno natural que suponía el esfuerzo de escribirlo. Un cambio de mil líneas no se revisa igual que uno de cincuenta, por muy bueno que sea el revisor.
De ahí que el control más eficaz no sea una herramienta, sino una norma de proceso: limitar el tamaño de los cambios. Es poco sofisticado y funciona.
Pruebas escritas por una persona. Que el modelo genere la implementación es razonable; que genere también la prueba que valida esa implementación cierra el circuito sobre sí mismo. La prueba debe expresar lo que el negocio espera, y eso lo sabe una persona.
Documentación de la decisión, no del código. No hace falta comentar cada línea. Hace falta un párrafo que diga por qué se eligió este enfoque y qué alternativa se descartó. Es lo que permite que alguien lo cambie dentro de un año sin repetir el análisis.
Un límite de tamaño por cambio. Cualquier límite razonable funciona. Su valor no está en el número, sino en que obliga a partir el trabajo en unidades comprensibles.
Los tres son baratos y ninguno requiere herramienta nueva. Es la misma lógica de fondo que sostiene los estándares de ingeniería que aplicamos en cada entrega: contratos explícitos, entornos aislados y documentación transferida al cliente, porque el código y su documentación son propiedad de quien los paga
En una auditoría hay una pregunta que ordena el diagnóstico más rápido que cualquier métrica: elige un módulo al azar y pide a alguien del equipo que explique por qué está hecho así.
Si la explicación llega y es coherente, el sistema es mantenible aunque tenga defectos. Si la respuesta es que funciona y nadie sabe muy bien por qué, el coste de cada cambio futuro será mayor de lo que indica cualquier estimación, y esa diferencia irá creciendo.
Ese es el verdadero indicador de deuda técnica. No las líneas, no la antigüedad, no la herramienta con la que se escribió: la distancia entre lo que el sistema hace y lo que la organización entiende de él.
Es el sobrecoste que se paga en cada cambio futuro como consecuencia de decisiones tomadas para ir más rápido en su momento. No se mide por la antigüedad ni por quién escribió el código, sino por cuánto cuesta modificarlo con seguridad.
No por su calidad intrínseca, sino porque desaparece el freno natural que suponía el esfuerzo de escribirlo: los cambios crecen de tamaño, las revisiones se vuelven superficiales y aumenta la duplicación. GitClear documentó que los bloques duplicados se multiplicaron por ocho en 2024.
Con una regla simple: nadie fusiona código que no podría explicar en una pizarra, respondiendo a qué problema resuelve, por qué se resolvió así y qué pasaría si dejara de existir. No exige entender cada detalle de implementación.
Tres: pruebas escritas por una persona que expresen lo que el negocio espera, documentación de la decisión y de la alternativa descartada, y un límite de tamaño por cambio que obligue a partir el trabajo en unidades comprensibles.
Porque copiar es la respuesta habitual cuando no se comprende lo suficiente lo existente como para reutilizarlo. Cada copia multiplica el número de sitios donde habrá que aplicar la misma corrección en el futuro.
Pidiendo a alguien del equipo que explique por qué un módulo elegido al azar está hecho como está. Si la explicación es coherente, el sistema es mantenible aunque tenga defectos; si la respuesta es que funciona y nadie sabe por qué, cada cambio costará más de lo estimado.
¿Cuánto de tu sistema entiende hoy tu equipo? Auditamos arquitectura, código, deuda y seguridad y entregamos el diagnóstico por escrito en 10 días hábiles, con precio cerrado. Request the audit →
Español Español 
English
Français
العربية
Português
Deutsch
Italiano
