Deuda de comprensión: qué pasa cuando nadie entiende el código que sale a producción

Hay un dato circulando que conviene leer con cuidado en lugar de repetir: cerca del 95% de las organizaciones ya permite código generado por máquinas dentro de cargas de trabajo críticas en producción, la mayoría de forma formal.

Toma la cifra exacta con la cautela de siempre. La dirección no está en duda. Microsoft ha dicho que la IA escribe alrededor del 30% de su base de código, la telemetría de GitHub ubica la proporción promedio entre usuarios de Copilot cerca del 46%, y Meta ha señalado una meta del 50%. Sea cual sea el porcentaje exacto en tu organización, no es cero, y subió este año sin que nadie decidiera que debía subir.

Ese no es el problema. El código muchas veces es bueno.

El problema es un pasivo específico que se ha ido acumulando en silencio, y ya tiene nombre: deuda de comprensión, el costo en que se incurre cuando una persona acepta código que no entiende del todo, lo publica, y le deja la carga cognitiva a cada ingeniero que tenga que tocarlo después.

Por qué no es deuda técnica con nombre nuevo

La deuda técnica ordinaria es un atajo conocido. Alguien eligió el camino rápido, normalmente lo sabía, y con frecuencia dejó un comentario diciéndolo. Es legible. Puedes encontrarla, estimarla y discutir si conviene pagarla.

La deuda de comprensión es distinta en algo que importa operativamente: es invisible en el momento en que se crea, y se ve exactamente igual que trabajo terminado.

El código pasa la revisión. Las pruebas están en verde. La funcionalidad sirve. Nada en tus herramientas distingue una función que su autor razonó de una función que su autor hojeó, encontró plausible y aprobó. Las dos son idénticas byte por byte en el repositorio. La diferencia vive únicamente en la cabeza de una persona, y esa persona se va de la empresa en catorce meses.

Un estudio empírico a gran escala de código generado por IA encontró el patrón en los artefactos mismos. Reportes de la industria ubican los pull requests con código asistido por IA con alrededor de 1.7 veces más problemas que sus equivalentes escritos por personas, y organizaciones viendo su deuda técnica subir entre 30% y 41% en los seis meses posteriores a una adopción amplia. Los ingenieros senior reportan dedicar entre 20% y 35% más tiempo a revisión.

Vuelve a leer ese último, porque es el que debería preocupar a quien controla el presupuesto. La ganancia de productividad es real y le llega a quien escribe el código. El costo también es real, y le llega a la persona más cara del equipo.

Los tres lugares donde llega la cuenta

La deuda de comprensión no aparece como partida presupuestal. Aparece como tres síntomas operativos que hoy la mayoría atribuye a otra cosa.

La incorporación se vuelve más lenta. El tiempo que tarda un ingeniero nuevo en ser productivo depende de cuánto del sistema alguien pueda explicarle. Cuando partes grandes del código nunca fueron entendidas del todo por nadie que siga contratado, incorporar deja de ser transferencia de conocimiento y se vuelve arqueología. Si tu tiempo de arranque se estiró calladamente en los últimos dos años, esta es una explicación candidata.

Depurar se vuelve más lento, específicamente bajo presión. Este es el caro. Un incidente a las 2 de la mañana es el momento en que la diferencia entre código que entiendes y código que aceptaste se convierte en un costo medido en minutos de caída. No puedes razonar tu salida de una lógica que nadie sabe explicar, y el modelo que la escribió no está en la llamada del incidente.

Suben las regresiones. Los cambios sobre código opaco rompen cosas que no estaban obviamente conectadas, porque las dependencias nunca estuvieron en el modelo mental de nadie. El equipo lo vive como "el código se volvió frágil", que es una descripción correcta y un diagnóstico equivocado.

Qué hacemos nosotros al respecto

Usamos estas herramientas. Rechazarlas sería una postura rara en una firma cuyo argumento entero es que el costo de construir software se desplomó. La pregunta no es si usarlas, sino qué tiene que seguir siendo cierto de todos modos.

No se integra nada que su autor no pueda explicar. No "que haya leído": que pueda explicar por qué este enfoque, qué pasa en los bordes, qué se rompe si la entrada viene mal formada. Si la respuesta es "el modelo lo sugirió y las pruebas pasan", no está listo, por más correcto que resulte ser. Es una sola regla y hace casi todo el trabajo.

El esfuerzo de revisión escala con el radio de daño, no con el tamaño del diff. Un cambio de 600 líneas en un reporte interno se revisa con soltura. Un cambio de 40 líneas en el código que calcula un monto de finiquito se lee carácter por carácter, porque cuánto cuesta una respuesta equivocada es la única variable que ha importado siempre. La IA cambia de dónde vienen las líneas; no altera este cálculo en absoluto.

El código generado lleva menos abstracciones ingeniosas, no más. Los modelos son buenos produciendo soluciones sofisticadas y generales. Las soluciones sofisticadas y generales son justo las más difíciles de sostener en la cabeza un año después. Empujamos el código generado hacia lo aburrido y explícito, porque la propiedad de mantenimiento que queremos es legibilidad, no elegancia.

El 60% poco vistoso sigue siendo nuestro. Rutas de error, el archivo mal formado, el usuario sin conexión, la excepción que nadie documentó. Los modelos se entrenaron sobre código que en su mayoría atiende el camino feliz, porque eso es casi todo el código del mundo. Las partes que deciden si un sistema sobrevive un mal martes son las partes donde la revisión tiene que ser más dura.

El contraargumento honesto

Alguien va a señalar que los ingenieros llevan décadas publicando código que no entendían del todo, mucho antes de que existieran los modelos. Copiado de Stack Overflow, heredado de un proveedor, incorporado como dependencia con 400 paquetes transitivos.

Es completamente cierto, y es justo la razón para tomarlo en serio en lugar de descartarlo. Ya sabemos cómo se ve ese modo de falla en volumen bajo. Se ve como el sistema que una sola persona entiende, que es exactamente la condición de la que la mayoría de nuestros clientes nos contratan para escapar.

Lo que cambió es el caudal. El mecanismo es viejo; la tasa es nueva. Un equipo hoy puede generar más código en un trimestre del que puede comprender colectivamente en un año, y nada en el flujo de trabajo lo vuelve visible hasta el incidente.

La prueba que aplicaríamos

Si quieres un solo diagnóstico, no es una métrica y no hay tablero que comprar.

Elige un archivo que haya salido en los últimos tres meses y que importe: algo en la ruta de facturación, el modelo de permisos, la parte que toca dinero o expedientes. Pídele a quien lo integró que te explique qué pasa cuando la entrada viene mal.

Si esa conversación es cómoda, tu proceso funciona, y deberías seguir usando todas las herramientas disponibles.

Si no lo es, encontraste la deuda. Vale la pena conocer su tamaño antes de la noche en que necesites conocerlo.

Nuestra postura no ha cambiado desde que empezamos: el software solo está terminado cuando sobrevive el contacto con trabajo real, y alguien tiene que seguir siendo responsable de él después. Así construimos, y por eso nos quedamos después del arranque en lugar de entregar un repositorio y un mensaje de buena suerte.