La Deuda de Comprensión Se Está Acumulando

Hay una métrica que ningún tablero de sprint registra: cuánto tiempo le toma a un nuevo ingeniero entender qué construyó realmente el sprint anterior.

Ese número está empeorando. No porque los desarrolladores estén escribiendo lógica más compleja — sino porque están escribiendo menos de ella por su cuenta. Y el código que genera la IA tiende a ser verboso, sin contexto y optimizado para la corrección más que para la comprensión. Addy Osmani le puso nombre a este problema en una publicación que está circulando en círculos de ingeniería esta semana: comprehension debt.

El argumento atraviesa el ruido en torno a las herramientas de codificación con IA de una manera que pocas opiniones logran. No es "la IA reemplazará a los ingenieros" ni "el código de IA tiene errores." Es más silencioso y más corrosivo que ambas cosas. Osmani escribe que cuando los equipos adoptan la programación en pareja con IA a escala, ganan velocidad en el output mientras pierden progresivamente fluidez en su propia base de código. El código se lanza. Nadie lo entiende del todo. La deuda se acumula silenciosamente — hasta que ya no puede más.

Qué Es Realmente la Deuda de Comprensión

La deuda técnica es un concepto familiar. Recortas caminos bajo la presión de los plazos y lo pagarás después. La deuda de comprensión es estructuralmente diferente. No la contraes por hacer algo mal. La contraes por moverse rápido de una manera que desconecta al equipo de lo que está construyendo.

Cuando un ingeniero escribe una función desde cero, modela el problema en su cabeza. Toma decisiones. Entiende los compromisos. Cuando una IA genera esa misma función — o una versión más elaborada — el ingeniero revisa el output en lugar de ser autor de la intención. La función puede ser mejor. El modelo mental que tiene el ingeniero de ella suele ser más superficial.

Multiplica esto en toda una base de código. Multiplícalo en todo un equipo. Multiplícalo en seis meses de sprints asistidos por IA. El resultado es una base de código que funciona, pero que ninguna persona puede tener completamente en su cabeza — y donde incorporar a un nuevo ingeniero toma dos meses en lugar de dos semanas.

Esto se conecta directamente con algo con lo que la comunidad de Lobste.rs ha estado lidiando bajo un enfoque diferente: "Every layer of review makes you 10x slower" argumenta que agregar procesos multiplica los costos exponencialmente. La deuda de comprensión es el problema inverso — cuando eliminas la capa en la que los humanos internalizan lo que están construyendo, la velocidad se acumula a corto plazo y la confusión se acumula a largo plazo.

La Señal de QCon

El momento importa. InfoQ's QCon London 2026 acaba de presentar una sesión titulada "AI Agents Write Your Code. What's Left For Humans?" — lo que sugiere que no es una preocupación marginal. Es la pregunta que los ingenieros senior están debatiendo activamente en los espacios donde se toman las decisiones de arquitectura.

La respuesta que está surgiendo de esa conversación no es "escribe código sin IA." Es más matizada: los equipos necesitan invertir deliberadamente en la comprensión como práctica, y no asumir que ocurre automáticamente cuando los ingenieros hacen revisión de código. Un revisor que lee código generado por IA, pero que no lo escribió, no lo especificó y apenas lo tocó, técnicamente lo aprobó — pero no lo absorbió.

Dev.to tiene un artículo relacionado que circula esta semana y plantea una tensión similar desde otro ángulo: Claude Code as a full dev team, describiendo un ciclo TDD autónomo desde la solicitud de una funcionalidad hasta el PR fusionado con mínima intervención humana. Es genuinamente impresionante como demostración técnica. También es un ejemplo perfecto de cómo un equipo podría lanzar una funcionalidad sin que nadie en el equipo entienda profundamente la implementación. El test pasa. El PR se fusiona. La comprensión no se transfirió.

Por Qué Esto Es un Problema de PM, No Solo de Ingeniería

Los product managers no escriben el código, pero son dueños del roadmap que determina qué tan rápido se escribe el código y qué se omite para cumplir un plazo.

Si tu equipo está ejecutando desarrollo asistido por IA a toda marcha y la deuda de comprensión se está acumulando, así es como se ve desde el asiento del PM: las estimaciones se vuelven menos confiables a medida que la base de código es más difícil de razonar. El trabajo en funcionalidades que toca módulos más antiguos generados por IA tarda más de lo esperado porque nadie sabe con certeza qué hacen esos módulos. Las investigaciones de bugs se inflan. Incorporar nuevos miembros al equipo se vuelve costoso. Y el equipo comienza a sentir que está manteniendo un sistema que les fue entregado, no uno que construyeron.

Este es el impuesto oculto sobre la velocidad. Los sprints se sienten productivos. Las métricas de output se ven bien. El throughput está en alza. Pero el dominio colectivo del equipo sobre el producto se está debilitando, y eso se refleja en la precisión de la planificación, el tiempo de respuesta ante incidentes y, eventualmente, en la rotación de personal.

El artículo de Changelog sobre "The mythical agent-month" toca una realidad relacionada: los agentes de IA pueden producir un enorme volumen de output, pero el volumen no es lo mismo que trabajo comprendido y mantenible. El mítico hombre-mes de Brooks demostró que agregar personas no aumenta el output de forma lineal porque la sobrecarga de comunicación escala. El problema del mítico agente-mes es diferente — los agentes no crean sobrecarga de comunicación, crean brechas de comprensión.

Qué Pueden Hacer los Equipos en la Práctica

La solución no es frenar el uso de IA. Es diseñar puntos de control de comprensión explícitos en el flujo de trabajo.

Exige resúmenes de autoría, no solo revisión de código. Cuando la IA genera una parte significativa del código, el ingeniero que lo solicitó debería escribir un resumen de 3 a 5 oraciones explicando qué hace y por qué fue estructurado de esa manera. Esto no es documentación — es un mecanismo que obliga a la comprensión. Si no puede escribir el resumen, no ha entendido el output.

Rota la propiedad deliberadamente. En equipos con uso intensivo de IA, es tentador dejar que quien solicitó la generación "sea dueño" del módulo resultante. Rota esa propiedad explícitamente. Obligar a un segundo ingeniero a familiarizarse con el código generado por IA que no solicitó crea una segunda capa de comprensión.

Registra el tiempo de incorporación como una métrica de salud. ¿Cuánto tiempo le toma a un nuevo ingeniero hacer su primera contribución significativa a un módulo determinado? Ese número es un indicador de la deuda de comprensión. Si está creciendo, algo está mal — incluso si las métricas de velocidad se ven bien.

Presupuesta tiempo de comprensión en los sprints. Esta es la incómoda. El desarrollo con IA es lo suficientemente rápido como para que los equipos a menudo tengan capacidad para reducir el ritmo y entender lo que están construyendo. Simplemente no lo priorizan. Hacer de la comprensión una partida en la planificación del sprint — "dos horas esta semana para revisar el nuevo módulo de autenticación como equipo" — la trata como el trabajo que es.

La lección más amplia del enfoque de Osmani es que el desarrollo con IA no produce automáticamente un entendimiento compartido. Produce output. El entendimiento compartido sigue siendo un proceso humano que requiere inversión deliberada. Los equipos que descubran cómo hacer ambas cosas — lanzar rápido y mantener la comprensión — multiplicarán su ventaja. Los equipos que optimicen solo para el output eventualmente se encontrarán manteniendo una base de código que nadie posee del todo.

Esa brecha ya se está abriendo. La pregunta es de qué lado está tu equipo.