Addy Osmani advirtió sobre la deuda de comprensión en la generación de código con AI a escala

Addy Osmani describió un nuevo problema de la era de la codificación con IA: los equipos pueden lanzar más código del que realmente logran entender. En la superficie todo parece normal — pruebas en verde, pull requests se cierran rápidamente — pero internamente se acumula una deuda de comprensión, que luego afecta la calidad y la velocidad de cambio.

De Dónde Surge la Deuda de Comprensión

Osmani define este término como el costo oculto de depender de generadores de código. Si antes el cuello de botella era el desarrollo mismo, ahora se convierte en la revisión humana: el modelo escribe rápido, el ingeniero lee lentamente. Por esto, los equipos comienzan a aceptar cambios basados en señales de precisión externa — formato, sintaxis limpia, pruebas pasando — aunque el significado arquitectónico de la solución sigue siendo poco claro.

El código se ve seguro, pero el conocimiento colectivo sobre por qué el sistema está estructurado exactamente así se erosiona gradualmente. El artículo proporciona el ejemplo de un equipo de estudiantes que después de algunas semanas ya no podía hacer cambios simples sin causar efectos secundarios. El problema no era desorden en el repositorio, sino pérdida de relación causal: nadie podía explicar por qué se tomaron decisiones clave y cómo debían interactuar los módulos entre sí.

Cuando este mapa mental desaparece, incluso código limpio se convierte en territorio extraño. Por eso la deuda de comprensión es más peligrosa que la deuda técnica ordinaria: no avisa de antemano y se disfraza de productividad.

Velocidad vs. Comprensión

Esta idea es parcialmente confirmada por investigación de Anthropic que Osmani cita. En el experimento, 52 desarrolladores estudiaron una nueva biblioteca: el grupo con asistencia de IA completó en aproximadamente el mismo tiempo que el grupo de control, pero mostró comprensión más débil del material en una prueba posterior — 50% versus 67%. La caída más notable se encontró en tareas de depuración. La conclusión no es que la IA sea perjudicial en sí, sino que el uso pasivo degrada significativamente el aprendizaje.

En un equipo real esto se manifiesta en varios lugares a la vez:

• un desarrollador junior puede generar más código del que un senior puede revisar críticamente
• los pull requests crecen más rápido de lo que el equipo puede recuperar el contexto arquitectónico
• aprobar cambios se convierte de análisis en procedimiento formal
• las métricas de velocidad mejoran, aunque la comprensión real del sistema se reduce

Por Qué las Pruebas No Son Suficientes

Osmani argumenta separadamente en contra de la idea popular de que el problema puede resolverse con pruebas y especificaciones detalladas. Sí, la verificación automática es necesaria, especialmente cuando los agentes generan código. Pero las pruebas solo responden a las preguntas que alguien pensó en formular de antemano.

No detectan comportamiento inesperado, no explican compromisos ocultos y no muestran si el cambio realmente se alinea con la intención de diseño del sistema. Si la IA cambia la implementación y reescribe cientos de pruebas en el proceso, un pipeline verde aún no significa que todo esté bien. Lo mismo ocurre con las especificaciones.

Cualquier función no trivial contiene muchas decisiones implícitas: manejo de errores, tratamiento de casos extremos, compromisos de rendimiento, elecciones de estructuras de datos. Una especificación completamente redactada rápidamente se convierte en casi el programa mismo, solo que en un lenguaje no ejecutable. Entonces la pregunta principal cambia: no cómo generar más código, sino cómo mantener la capacidad del equipo de comprenderlo a nivel de comportamiento y arquitectura.

La comprensión aún tendrá que pagarse, y los intereses de esta deuda

crecen rápidamente.

Qué Significa Esto

Para equipos que ya están construyendo productos con codificación con IA, esto es una señal para reconsiderar los propios criterios de calidad. La velocidad de merge, el volumen de código generado y la cobertura de pruebas ya no funcionan como un seguro completo. Lo más valioso se convierte en el ingeniero que puede identificar rápidamente riesgo sistémico, explicar la lógica de la solución e impedir código hermoso pero poco comprendido antes de producción — especialmente donde el costo del error excede un único lanzamiento.