Son las cuatro de la tarde y has aprobado cosas que en realidad no leíste. No por vagancia. Los diffs seguían llegando, cada uno plausible, cada uno otra pared de código que un agente produjo en lo que tú tardabas en terminar el anterior. En algún punto de las últimas horas «revisar» se convirtió en silencio en «ojear y esperar». Lo sabes, y sientes ese desasosiego bajo que lo acompaña.
Esto es la fatiga de review, y no es un problema de disciplina del que puedas salir a fuerza de voluntad. Es aritmética. Los agentes escriben más rápido de lo que lees, y el hueco no se cierra leyendo más rápido.
Por qué revisar IA cuesta más, no menos
Hay una razón concreta de que revisar código de agentes pese más que revisar el de un compañero, y conviene nombrarla con precisión. Cuando un colega te manda una pull request, la intención viene adjunta. Estuviste en la daily. Viste el ticket. Sabes por qué eligió este enfoque porque puedes preguntar, o porque el mensaje de commit lleva el razonamiento de una persona que tenía el problema entero en la cabeza. Revisar ese código es sobre todo comprobar un entendimiento compartido.
El código del agente llega despojado de todo eso. No hay intención viajando con él, ni razonamiento que puedas reconstruir preguntando, ni contexto compartido de una conversación en la que estuvierais los dos. Te entregan un artefacto plausible y te piden reconstruir, solo desde el diff, qué se suponía que hacía y si lo hace. Las encuestas a desarrolladores repiten lo que los profesionales sienten: revisar código generado por IA cuesta con frecuencia más atención que revisar el de un colega humano. No es un desprecio a los modelos. Es lo que pasa cuando no se puede interrogar al autor y la intención no viajó con el código.
Multiplica ese coste por diff por el caudal de los agentes y la fatiga no es un riesgo, es el estado estacionario garantizado.
Leer con más fuerza es el eje equivocado
El instinto es esforzarse más: concentrarse más, revisar cada línea, atrapar todo. Falla por una razón estructural. Tu capacidad de lectura es fija y la capacidad de producción de los agentes no. Cualquier estrategia que responda a más output con más lectura cuidadosa pierde por construcción, y pierde de la peor forma, degradándose poco a poco hasta que estás sellando con goma sin admitirlo.
El otro instinto es rendirse y fiarse del output, que es como se acumula código localmente correcto, globalmente incoherente hasta que el sistema deja de tener sentido como un todo. Ni leerlo todo ni leer nada están disponibles. Lo que está disponible es leer distinto: gastar tu atención fija donde compra más certeza por minuto.
Los momentos que llevan más información
No todos los momentos de revisión son iguales. Unos cuestan un minuto y fijan la dirección de una tarea entera. Otros cuestan una hora y atrapan una errata. El truco es gastar tu atención en el orden del apalancamiento.
El alcance, primero. Antes de que el agente construya, aprueba lo que va a hacer. Qué comportamiento cambia, qué queda intacto, qué tiene que cumplir el resultado. Este es el minuto de más apalancamiento que vas a gastar, porque dirigir la intención antes de que exista el código es mucho más barato que auditar una implementación terminada y descubrir que resolvió el problema equivocado. La revisión más barata es la que haces sobre el plan, antes de escribir una línea, que es buena parte de para qué sirve el desarrollo guiado por especificaciones.
El diff, contra el alcance. Cuando el código vuelve, léelo contra el alcance que aprobaste, no contra un recuerdo vago de lo que querías. La pregunta es estrecha y respondible: ¿hace este diff lo que acordamos, y solo eso? Una pregunta acotada es revisable. «¿Está esto bien?» no lo es.
La evidencia, al final. Luego mira qué se ejecutó de verdad: qué comandos, qué imprimieron, contra qué contrato. Aquí es donde confirmas el comportamiento en vez de inferirlo, y es el más rápido de los tres cuando la evidencia se capturó según pasaba el trabajo en vez de reconstruirla tú después.
Alcance, luego diff, luego evidencia. Tres puntos de control sustituyen a una tarea de lectura sin límites. Cada uno es una pregunta concreta y respondible, y juntos dejan a un humano en control de mucho más output del que jamás podría leer línea a línea.
No todos los diffs merecen la misma lectura
Los tres puntos de control te dicen cuándo gastar atención. El triaje te dice cuánta, porque tratar cada cambio como igual de arriesgado es su propia forma de quemarse. Un arreglo de una línea de copy y un cambio en la ruta de autenticación son ambos «un diff», y leerlos con la misma intensidad significa o sobre-leer el trivial o infra-leer el peligroso. Normalmente ambas cosas, en la misma tarde.
Ordena por radio de impacto, no por orden de llegada. Un cambio que toca dinero, auth, borrado de datos o una interfaz compartida se gana una lectura lenta, línea a línea, y una mirada dura a la evidencia, siempre, por muy seguro que suene el informe. Un cambio en una hoja aislada con tests alrededor a menudo se puede creer a nivel de alcance y evidencia sin una lectura completa de líneas, porque el coste de que esté mal está acotado y la prueba está ahí mismo. La habilidad no es leerlo todo a fondo. Es saber qué cambios no se pueden permitir una lectura ligera y reservar tu atención más profunda para esos.
También por eso el punto de control del alcance rinde doble. Aprobar el alcance por adelantado no solo dirige el trabajo, te dice de antemano a qué cubo pertenece el cambio entrante. Ya sabes, antes de que llegue el diff, si este es una hoja o un muro de carga, así que el esfuerzo de revisión se presupuesta antes de que estés cansado en vez de decidirse en el momento en que tu juicio está peor.
Qué tiene que ser cierto para que esto funcione
Este orden solo funciona si se cumplen dos cosas. El alcance tiene que existir como algo que realmente aprobaste, no algo que puedas reconstruir a posteriori. Y la evidencia tiene que capturarse de forma automática, como subproducto del trabajo, o vuelves a re-ejecutar cosas a mano y la fatiga regresa por la puerta de atrás.
Esa segunda condición es el vínculo entre la fatiga de review y el resto de la verificación. Si la compleción ya exige una demostración real, la evidencia está ahí cuando llegas al tercer punto de control. Si el trabajo cierra con su prueba adjunta, el último paso de la revisión es leer un registro, no reconstruirlo. La revisión deja de ser el sitio donde se amontona toda la verificación que falta, que es justo por qué el cuello de botella es la confianza, no el output: una revisión en la que puedes confiar es lo que hace que el caudal signifique algo.
Dónde encaja PaellaDoc
PaellaDoc está construido alrededor de aprobar el alcance por adelantado y capturar la evidencia según corre el trabajo, para que la revisión aterrice donde tiene apalancamiento en vez de al final como una última línea de defensa agotadora. Diriges la intención antes de que el agente construya. La evidencia está ahí cuando el cambio vuelve. El diff se lee contra un contrato que ya acordaste, no contra tu memoria cansada. El revisor sigue en control sin fingir que lo lee todo, porque es el proceso, no el heroísmo, lo que hace fiable el output.
El código seguirá llegando más rápido de lo que puedes leerlo. Eso es permanente. Revisar en los momentos correctos es cómo sigues al mando de él de todas formas.
Preguntas frecuentes
¿Por qué revisar código de IA cansa más que revisar el de un compañero?
Porque la intención no viaja con él. La pull request de un colega llega con contexto compartido: la daily, el ticket, un mensaje de commit que lleva el razonamiento de una persona, un autor al que puedes preguntar. El código del agente llega despojado de todo eso, así que tienes que reconstruir solo desde el diff qué se suponía que hacía y si lo hace. Multiplica ese coste por diff por el caudal de los agentes y la fatiga es el estado estacionario garantizado.
¿Cómo sigo el ritmo de código que un agente escribe más rápido de lo que leo?
No puedes, ni leyendo más rápido ni con más fuerza, porque tu capacidad de lectura es fija y el output del agente no. Lee distinto: gasta tu atención fija donde compra más certeza por minuto. Aprueba el alcance antes de que el agente construya, lee el diff contra ese alcance y luego confirma la evidencia de lo que corrió. Tres puntos de control acotados sustituyen a una lectura sin límites.
¿Tengo que revisar cada línea de código generado por IA?
No por igual. Leer un arreglo de una línea de copy con la misma intensidad que un cambio en la ruta de autenticación significa sobre-leer el trivial e infra-leer el peligroso. Ordena por radio de impacto: los cambios que tocan dinero, auth, borrado de datos o interfaces compartidas se ganan una lectura lenta línea a línea siempre. Una hoja aislada con tests alrededor a menudo se puede creer a nivel de alcance y evidencia.
¿Qué tiene que estar en su sitio para que la revisión por etapas funcione?
Dos cosas. El alcance tiene que existir como algo que realmente aprobaste por adelantado, no algo reconstruido a posteriori. Y la evidencia tiene que capturarse de forma automática como subproducto del trabajo, o vuelves a re-ejecutar cosas a mano y la fatiga regresa por la puerta de atrás. Cuando la compleción ya exige una demostración, la evidencia espera en el último punto de control.