Deuda cognitiva con IA: qué es y cómo evitarla

El agente termina. Los tests pasan. El resumen dice que todo está correcto. Le das a aprobar y pasas a lo siguiente. Una semana después alguien te pregunta por qué ese módulo funciona así y te das cuenta de que no tienes ni idea.

Antes estabas dentro del código, picando, con las manos manchadas. Ahora flotas por encima, como si miraras el proyecto desde un globo aerostático. Ves que pasan cosas, pero has perdido el mapa: esas pelotitas unidas por flechas que tenías en la cabeza y que te decían por dónde entran los datos, dónde se transforman y por dónde salen. Eso es la deuda cognitiva, la distancia entre lo que hace tu sistema y lo que tú entiendes de él.

Y tiene una prima hermana más peligrosa: el sesgo de automatización. Es la sensación de que, como el modelo es cada vez mejor y además pagas por él, todo lo que hace está bien. Y si algo se escapa, ya lo pillará quien revise después. Es como esa gente que, con niebla, conducía pisando la raya del medio porque así no se salía de la carretera. Funciona fenomenal hasta que viene otro con la misma idea en sentido contrario. Tu revisor también puede estar pisando la raya.

No hace falta volver a programarlo todo a mano para salir de aquí. Hace falta meter al humano otra vez dentro del bucle. Empezamos por tres hábitos de base, los que más se notan en la cabeza.

¿Cuántos agentes puedes vigilar a la vez? ¶

Se ha puesto de moda presumir de agentes en paralelo: cinco en local, cinco en remoto, otros diez en worktrees. La productividad parece multiplicarse. Lo que se multiplica de verdad es la velocidad a la que se quema tu atención.

Es la mecha del Coyote: siempre corre más rápido de lo que él calcula, y la dinamita acaba explotándole en la cara. Cada ventana abierta es algo que tienes que entender, y tu capacidad para atender no escala con tu suscripción. Encima aparece una ansiedad muy parecida a la de las notificaciones del móvil: si un agente está parado, sientes que pierdes el tiempo y abres otro. Y otro. Al final del día has producido mucho código y comprendido muy poco.

El paralelismo no es malo en sí. El problema es abrir agentes por inercia, sin haber decidido antes qué esperas de cada uno.

Cómo aplicarlo: planifica la sesión antes de abrir el primer agente. Igual que planificarías tu jornada, decide qué tareas vas a lanzar, qué quieres que haga cada una, cuáles son sus criterios de aceptación y en qué orden encajan. Ese ratito de papel te dice cuántas puedes sostener sin perder el hilo. Y si una tarea va a tardar cuatro horas, no te quedes mirando cómo pasan las líneas: sal a dar un paseo.

Las tareas nacen de tu criterio, no del agente ¶

Ponte delante de tu proyecto y pídele al agente “dame diez cosas que mejorar”. Te las dará encantado. Algunas serán chorradas, otras no tanto, y si le pides que piense en grande te inventará features con las que nunca habías soñado. Has automatizado justo la parte del proceso que más te conecta con el proyecto: decidir qué merece la pena construir.

Que la IA detecte bugs de forma sistemática está bien. Revisar logs, analizar el repositorio, todo eso se puede delegar. Pero decidir qué se construye tiene que salir de conocimiento humano: tu equipo, los usuarios, los informes de errores, tu propio criterio. Si eso también lo genera el modelo, el proyecto se vuelve más opaco todavía, porque ya ni siquiera sabes por qué existe cada cambio.

Hay un matiz que casi nadie cuenta. Cuando una idea te genera dudas, hoy es baratísimo montar una prueba de concepto. El error está en lo que pasa después: el prototipo funciona, da pena tirarlo y acaba en producción con todos los atajos que tomaste para validar rápido.

Cómo aplicarlo: la necesidad la pones tú y el POC se tira. Deja que la IA te ayude a redactar la tarea, pero sin añadir nada que no hayas pedido. Y cuando hagas una prueba de concepto, decide antes de empezar que es desechable. Si la idea vale, se construye de nuevo, con un plan, como cualquier otra tarea.

¿Qué automatizas y qué decides tú? ¶

El sesgo de automatización no aparece porque automatices. Aparece cuando no distingues qué parte del trabajo es comprobable por una máquina y qué parte necesita juicio.

Hay mucho que puedes soltar sin remordimientos. Que el agente lance los tests unitarios y de integración, los tipos, el lint, el build, y corrija lo que falle. Que pase una revisión automática estándar, la /code-review de turno, que funciona como un corrector ortográfico: saca lo gordo antes de que gastes atención en ello.

Lo que no puedes soltar es la decisión. Que todo salga en verde te dice que el código hace lo que se comprobó, no que haga lo que tenía que hacer. Y tampoco merece lo mismo un experimento en una carpeta aparte que un cambio en pagos, autenticación o migraciones. La IA sabe dónde suelen estar los peligros, pero tiende a ponerlos donde no importan tanto, porque su instinto es complacerte.

Cómo aplicarlo: separa verificación de aprobación. Deja en automático todo lo determinista y la primera pasada de revisión. Y antes de aprobar, pregúntate en qué parte del sistema cae este cambio y cuánto te jugarías si fuera mal. Esa respuesta la tienes tú, porque eres quien conserva, o debería conservar, el mapa del proyecto.

Con esto frenas la caída. Recuperar el modelo mental es otra cosa: hay que conseguir que el agente te cuente lo que ha hecho, igual que te lo contaría un compañero sentado a tu lado, y no un log de máquina lleno de jerga. Eso pide añadir pasos humanos al flujo de tarea, plan, implementación, tests y revisión, y saber cuándo merecen el gasto de tokens.