Abres el pull request que produjo un agente. Cuatrocientas líneas en nueve ficheros. Haces lo que siempre has hecho con un pull request: empiezas a leer el diff, de arriba abajo, juzgando cada trozo. Cuarenta minutos después has leído casi todo, corregido algún nombre, y lo apruebas, con la vaga conciencia de que nunca confirmaste que hace lo correcto. Comprobaste que el código estaba escrito con competencia. Nunca comprobaste si debería existir con esa forma.
Ese hábito, el diff primero, vale para el cambio de un compañero y es un error con el de un agente. Revisar código que no escribiste, al volumen al que los agentes lo producen, pide el orden contrario. Primero el alcance. El diff al final. A veces nunca.
Por qué el hábito del compañero falla aquí
Cuando un compañero te manda un pull request, traes un montón de asunciones que hacen funcionar la lectura diff-primero. Asumes que entendió el ticket, porque estaba en la daily. Asumes que respetó la arquitectura, porque ya se ha quemado con ella antes. Asumes que el cambio está acotado a lo que hablasteis, porque una persona que toca un módulo ajeno suele decir por qué. Esas asunciones te dejan saltar directo a las líneas, porque las preguntas caras, intención y alcance, ya las responde el contexto compartido.
Nada de ese contexto existe con un agente. No estaba en la daily. No tiene tejido cicatricial. Refactorizará alegremente un fichero que nunca mencionaste porque le pareció más limpio, y no te lo dirá salvo que mires. Así que las preguntas que te ahorrabas con un humano, «¿es este siquiera el cambio correcto?» y «¿qué tocó que yo no pedí?», están abiertas de par en par, y son justo las que el diff responde el último y peor. El diff te muestra el código que cambió. Esconde todo lo que el cambio debía dejar en paz.
Primero el alcance: ¿es este el cambio correcto siquiera?
Antes de una sola línea, responde una pregunta. ¿Qué se suponía que hacía esto, y la forma del cambio encaja con eso? No la implementación, la forma. ¿Qué ficheros debería tocar una versión correcta de esto? ¿Cómo de grande debería ser, más o menos? ¿El diff vive donde esperabas, o se ha desparramado a sitios que no tienen nada que ver con la tarea?
Es una comprobación de treinta segundos y caza los errores más caros, los que ninguna cantidad de lectura de líneas encuentra, porque son errores del conjunto. Un agente al que pides añadir una feature y en su lugar reescribe una existente. Un cambio tres veces más grande de lo que la tarea justificaba, lo que casi siempre significa que hizo algo que no pediste. Un diff que toca el módulo de auth cuando la tarea iba de formato de exportación. No puedes ver «esto resolvió el problema equivocado» leyendo con cuidado la solución. La solución puede ser impecable. Lo ves sosteniendo el cambio contra la intención antes de que el código te seduzca.
Si el alcance está mal, para. No revises el diff. Devuélvelo. Revisar la calidad línea a línea de un cambio que no debería existir es el desperdicio de atención más puro que hay, y es donde los revisores diff-primero pierden la mayor parte del día. La versión más barata de esta review ocurre antes de que el código exista, sobre la propia spec.
Radio de impacto: ¿qué tocó que no pediste?
Alcance superado. Ahora, antes de las líneas, la segunda pregunta más ancha. ¿Cuál es el radio de impacto? ¿Qué comportamiento existente podría haber alterado este cambio, lo haga evidente el diff o no?
Es la región donde el código escrito por agentes hace daño de verdad, y es casi invisible en el diff. Un modelo escribe cada pieza para que sea localmente correcta y no tiene un sentido duradero de los invariantes que sostienen el resto del sistema. Así que cambia una función compartida para que le venga bien al nuevo llamante y desplaza en silencio el comportamiento de otros cinco viejos. El diff te muestra una edición limpia a una función. No te muestra los cinco llamantes que dependían del comportamiento viejo. Ese es el fallo de lo localmente correcto y globalmente incoherente, y leer las líneas cambiadas con más ahínco nunca lo sacará a flote, porque el daño está en las líneas que no cambiaron.
El radio de impacto no se lee, se prueba. Los tests de integración sobre el área tocada, el chequeo de tipos entre los llamantes, la suite que ejercita los módulos aguas abajo de la edición. Esta es la parte de la review que no escala por ojos humanos en absoluto, e intentarla a ojo es como los cambios grandes de agente cuelan regresiones ante revisores cuidadosos. El trabajo del revisor aquí no es rastrear cada llamante a mano. Es confirmar que algo mecánico lo hizo, y mirar donde la máquina dice que cambió algo que no debía.
El diff al final: y solo las partes que cargan riesgo
Ahora, y solo ahora, las líneas. Y aun aquí, no todas por igual. Con la review humana lees el diff entero en parte para mantener vivo el entendimiento compartido en el equipo. Con código de agente esa función social desapareció, y leer las cuatrocientas líneas con igual atención no es diligencia, es una forma de agotarte hasta perderte las diez que importan.
Gasta la atención donde un defecto sea a la vez probable y caro. El código de frontera, donde el cambio se encuentra con el mundo exterior o con el resto del sistema. La superficie relevante para seguridad, el manejo de entrada, la auth, cualquier cosa que toque datos que salen de la máquina, el tipo de cosa que el OWASP Top Ten existe para recordarte que un agente hará sutilmente mal mientras parece del todo razonable. Las partes que a la especificación de verdad le importaban. Ojea el boilerplate que el agente generó, porque es boilerplate y los tests lo cubren, y vuelca tu lectura en el puñado de sitios donde ser localmente plausible y ser correcto se separan.
El orden es la técnica entera
De lo ancho a lo estrecho. ¿Es este el cambio correcto?, luego ¿qué más tocó?, luego ¿son correctas estas líneas concretas? Cada etapa puede parar la review, y las tempranas son baratas y cazan las cosas caras. El diff-primero invierte esto. Gasta tu recurso más caro y menos escalable, la lectura cuidadosa de líneas, primero y por igual, sobre un cambio que aún no has confirmado que sea el correcto tocando lo correcto. Al volumen de un agente esa inversión es fatal. El código llega más rápido de lo que puedes leerlo, y si leerlo es tu primer movimiento, te quedas atrás el primer día y empiezas a aprobar cosas que ojeaste.
Revisar código que no escribiste es uno de los movimientos centrales de verificar código generado por IA, y la disciplina está entera en el orden. Comprobaciones anchas y baratas por delante, lectura estrecha y cara al final, y disposición a rechazar en cualquier etapa sin descender a las líneas. Así revisas más código del que jamás podrías leer, y aun así sabes qué aprobaste.
Dónde encaja PaellaDoc
La review que empieza por el alcance necesita algo contra lo que comprobar el alcance. Si el único registro de qué se suponía que hacía el cambio es un ticket de una línea y un chat que se fue, «¿es este el cambio correcto?» es una pregunta que en realidad no puedes responder, así que caes por defecto en leer el diff. PaellaDoc guarda la intención, los criterios de aceptación y la superficie afectada como artefactos junto al código, para que las preguntas anchas tengan una referencia fija, y el radio de impacto lo comprueban tests que corren sobre el cambio en vez de rastrearse a ojo. Tu review empieza donde debe, en el alcance, y tu tiempo de lectura aterriza en las pocas líneas que cargan riesgo real en lugar de en las cuatrocientas que no.
Preguntas frecuentes
¿Cómo reviso código que escribió un agente?
En el orden contrario al pull request de un compañero: la pregunta más ancha primero. Confirma el alcance, si es siquiera el cambio correcto en los sitios correctos. Luego el radio de impacto, qué comportamiento existente pudo alterar, comprobado por tests y no a ojo. Luego, y solo entonces, lee las líneas, y solo las que cargan riesgo. Cada etapa puede parar la review, y las tempranas y baratas cazan los errores caros que la lectura de líneas nunca encuentra.
¿Por qué revisar código de IA no funciona como revisar el PR de un compañero?
Porque las asunciones que hacen funcionar la lectura diff-primero desaparecieron. Un compañero estuvo en la daily, respeta la arquitectura y menciona por qué tocó un módulo ajeno, así que la intención y el alcance ya los responde el contexto compartido. Un agente no tiene nada de eso. Refactorizará un fichero que nunca mencionaste y no te lo dirá. Las preguntas que te ahorras con un humano, «¿es este el cambio correcto?» y «¿qué tocó?», están abiertas de par en par, y el diff las responde el último y peor.
¿Qué debo comprobar antes de leer el diff?
El alcance, en unos treinta segundos. ¿Qué se suponía que hacía esto, y la forma del cambio encaja? ¿Qué ficheros debería tocar una versión correcta, cómo de grande debería ser, se ha desparramado a sitios ajenos? Esto caza errores del conjunto, un agente que reescribió una feature en vez de añadir una, un diff que toca auth cuando la tarea iba de formato de exportación. Si el alcance está mal, para y devuélvelo. Revisar la calidad de un cambio que no debería existir es atención pura desperdiciada.
¿Tengo que leer cada línea del pull request de un agente?
No. Leer las cuatrocientas líneas con igual atención no es diligencia, es como te agotas hasta perderte las diez que importan. Gasta la atención donde un defecto sea a la vez probable y caro: el código de frontera, la superficie relevante para seguridad, el manejo de entrada, la auth, cualquier cosa que toque datos que salen de la máquina, y las partes que a la especificación de verdad le importaban. Ojea el boilerplate que los tests ya cubren, y vuelca tu lectura donde lo localmente plausible y lo realmente correcto se separan.