En 1985, Peter Naur escribió que un programa muere cuando se disuelve el equipo que posee su teoría: la idea de por qué el código es como es. Con agentes de programación, un programa puede empezar a morir sin que se vaya nadie.
Esta pieza defiende una tesis incómoda: el riesgo de programar con agentes no es solo el código que falla, sino el código que funciona y que nadie del equipo sabe explicar. La especificación escrita antes del código paga una parte de esa deuda, no toda. La otra parte solo se paga con una regla: un cambio no entra hasta que una persona del equipo sabe explicarlo, no solo aprobarlo.
Una deuda que no avisa
Addy Osmani lo describió en marzo de 2026 como deuda de comprensión: la distancia creciente entre cuánto código hay en tu sistema y cuánto de él entiende de verdad alguna persona. Una frase suya lo resume: que el código sea barato de generar no hace barato saltarse entenderlo.
La diferencia con la deuda técnica de siempre es que esta no da señales. Ninguna prueba falla, ninguna métrica de la revisión se mueve. Se descubre tarde, cuando un error en producción obliga a depurar un módulo que nadie escribió de verdad.
| Deuda técnica | Deuda de comprensión | |
|---|---|---|
| Qué es | Atajos en el código que habrá que rehacer | Código que nadie del equipo sabe explicar |
| Cómo se nota | Cambios que cuestan cada vez más | No se nota: funciona y pasa las pruebas |
| Cuándo aparece | Poco a poco, en el día a día | De golpe, al depurar o al cambiar ese código |
| Qué la hace crecer | Las prisas y los atajos | Generar más deprisa de lo que se lee |
Comparación elaborada por onext a partir del artículo de Addy Osmani (2026)
Lo que dice un estudio con grupo de control
En enero de 2026, Judy Hanwen Shen y Alex Tamkin publicaron con Anthropic un experimento con 52 ingenieros, sobre todo junior, que aprendían una biblioteca nueva. Un grupo trabajó con ayuda de IA; el otro, a mano. Después, todos hicieron una prueba de comprensión.
Hay que leerlo con cuidado. Los propios autores avisan de que la muestra es pequeña y de que midieron la comprensión justo después de la tarea; no saben si eso predice cómo aprende alguien a largo plazo. No es un dato de cuánta deuda de comprensión hay en los equipos: nadie lo ha medido. Lo que sí sugiere es dónde se nota primero, en depurar, que es justo cuando la deuda se cobra. Qué significa esto para quien empieza lo contamos en desarrolladores junior con IA: aprender a revisar.
Qué parte paga la especificación
Con Spec-Driven Development (SDD, desarrollo guiado por especificaciones), el cambio se describe por escrito antes de que el agente escriba código: qué debe hacer, por qué y cómo se comprueba. Eso paga una parte de la deuda. Cuando alguien tenga que tocar ese código dentro de un año, sabrá qué se pretendía, como explicamos en SDD: código controlado.
No la paga entera, y conviene decirlo. Osmani recuerda que pasar de una especificación a código implica muchísimas decisiones implícitas que ninguna especificación recoge del todo: dos ingenieros con la misma especificación construyen sistemas que se comportan distinto. Naur lo vio hace más de cuarenta años: el código y su documentación no bastan para transmitir algunas de las ideas de diseño más importantes. Esas ideas viven en las personas.
La especificación dice qué debía hacer el cambio. Solo una persona que lo ha entendido puede decir por qué el código lo hace así y qué se rompe si se toca.
La otra parte: explicar, no solo aprobar
Aprobar una revisión y entender un cambio no son lo mismo. Con agentes, la revisión tiende a comprobar que el cambio cumple lo pedido y que las pruebas pasan, que es necesario pero no basta. Lo que el proceso de revisión detecta y lo que no lo tratamos en revisar código generado por IA.
La regla que proponemos es sencilla de enunciar: un cambio no entra hasta que una persona del equipo sabe explicarlo con sus palabras, qué hace y por qué de esa manera. Si nadie sabe, el cambio se divide, se reescribe o se acompaña de lo que falta. Es la misma lógica de dónde se firma en un ciclo con agentes: una persona decide donde hay riesgo.
Riesgo Esta regla solo funciona si decir «no entiendo este código» es normal en el equipo. Si admitirlo se vive como un fallo personal, la gente aprobará lo que no entiende y la deuda seguirá creciendo en silencio.
Dos piezas ayudan a que la explicación tenga dónde apoyarse. Las decisiones que no se pueden revertir sin coste, escritas con su contexto, como contamos en decisiones de arquitectura. Y una red de pruebas que detecte los errores antes de que el agente acelere, en antes del agente, la red. En código heredado, el punto de partida es especificar primero la parte que el agente va a tocar: especificar el código legacy antes de los agentes.
Tres preguntas para tu equipo esta semana
- Del último cambio grande que entró con ayuda de un agente, ¿quién sabría explicarlo sin abrir el código?
- Si mañana falla en producción, ¿quién lo depura y cuánto tardaría en entender qué hace?
- ¿Alguien ha dicho en una revisión de este mes «no entiendo este cambio»? Si nadie lo ha dicho, ¿es porque todo se entiende?
Dónde encaja onext
En AI-Accelerated Development construimos con tu equipo el contexto en el que trabaja la IA y el proceso con el que trabajáis. Los dos se quedan en tu casa. Una persona decide donde hay riesgo. El primer paso es un diagnóstico gratuito, y si en el diagnóstico no vemos diferencia, no hay Quick-start. Si quieres ver antes dónde está tu equipo, el autodiagnóstico de 16 preguntas es un buen punto de partida.
Preguntas frecuentes
¿Qué es la deuda de comprensión?
Addy Osmani la define como la distancia creciente entre cuánto código hay en tu sistema y cuánto de él entiende de verdad alguna persona. Es código que funciona y pasa las pruebas, pero que nadie del equipo sabe explicar.
¿En qué se diferencia de la deuda técnica?
La deuda técnica suele notarse: cambios que cuestan cada vez más o dependencias enredadas. La deuda de comprensión no avisa. Aparece el día que hay que cambiar o depurar ese código y nadie sabe por qué hace lo que hace.
¿Por qué crece más deprisa con agentes de IA?
Porque generar código se ha vuelto barato y entenderlo no. Osmani lo resume así: que el código sea barato de generar no hace barato saltarse entenderlo. Un agente produce cambios más deprisa de lo que una persona los lee con calma.
¿Hay datos de que la IA reduzca la comprensión del código?
Hay un estudio de Anthropic con 52 ingenieros, sobre todo junior: el grupo que aprendió una biblioteca con ayuda de IA sacó un 50 % en una prueba de comprensión, frente al 67 % del grupo sin IA, y la mayor diferencia fue en depuración. Los autores avisan de que la muestra es pequeña y de que midieron justo después de la tarea. No dice cuánto de extendido está el problema en los equipos.
¿La especificación escrita antes del código resuelve el problema?
Paga una parte: deja por escrito qué debía hacer el cambio y por qué. No la paga entera. Osmani recuerda que pasar de una especificación a código implica muchísimas decisiones implícitas que ninguna especificación recoge del todo, y Naur ya escribió en 1985 que el código y su documentación no bastan para transmitir algunas de las ideas de diseño más importantes.
¿Qué regla conviene añadir en la revisión?
Que un cambio no entre hasta que una persona del equipo sepa explicarlo, no solo aprobarlo. Y que decir «no entiendo este código» sea algo normal en el equipo, no una confesión.
Fuentes
- Addy Osmani, «Comprehension debt», 14 de marzo de 2026; reeditado en O'Reilly Radar como «Comprehension Debt: The Hidden Cost of AI-Generated Code», 13 de abril de 2026.
- Peter Naur, «Programming as Theory Building», 1985 (copia del texto completo).
- Judy Hanwen Shen y Alex Tamkin, «How AI assistance impacts the formation of coding skills», Anthropic, 29 de enero de 2026 (artículo completo: arXiv 2601.20245).
- Las citas de fuentes en inglés están traducidas por onext. La comparación entre deudas, la regla de explicar antes de aprobar y las tres preguntas son elaboración propia de onext.
Bernat López es fundador y CEO de onext, boutique de IA. Acompaña a equipos de desarrollo y de producto a trabajar con IA con método —especificación antes de programar, una persona que decide donde hay riesgo y Spec-Driven Development— y aplica a su propia empresa lo que propone: onext funciona con su propio sistema agéntico.
LinkedIn →