El error de revisar como si fuera código humano

Durante un tiempo revisé el código que me daba un agente exactamente igual que revisaba el código de una persona: leyendo línea por línea, de arriba a abajo, intentando entender la intención completa antes de opinar. Es la forma correcta de revisar código humano y la forma equivocada de revisar código de agente.

El motivo es que los errores típicos son distintos. Una persona suele equivocarse en la lógica de negocio o en un caso borde que no pensó. Un agente rara vez se equivoca en sintaxis o en seguir un patrón, pero comete errores propios: inventa una API que no existe, asume un comportamiento de una librería que no es el real, o resuelve el síntoma que le pediste en vez de la causa. Leer línea por línea buscando errores de lógica humana no encuentra esto de forma eficiente.

Cambié el método y pasé de media hora por PR a unos minutos, sin bajar el nivel de exigencia donde importa.

Primero, no leo el código: leo el plan

Antes de mirar el diff, miro qué dijo el agente que iba a hacer, si el flujo que usas lo expone (un resumen de plan, una lista de pasos, un mensaje de commit generado antes del cambio). Comparo esa intención con lo que el PR realmente toca. Si el plan dice "arreglar la validación del formulario" y el diff toca también un archivo de configuración de red, eso es la primera señal de alarma, antes de leer una sola línea de lógica.

Esto detecta el error más caro de un agente: resolver algo distinto a lo que le pediste, de forma que parece coherente si lo lees en aislamiento pero no encaja con la intención original.

Segundo, busco lo inventado antes que lo incorrecto

La categoría de error más específica de un agente es la alucinación de API: un método que no existe en esa versión de la librería, un parámetro que suena razonable pero no está documentado, un comportamiento asumido de una función que en realidad hace otra cosa. Esto no se detecta leyendo la lógica, se detecta verificando cada llamada a algo externo al propio código que no reconozco de memoria.

Mi regla es simple: cualquier línea que llame a algo que no soy capaz de decir de memoria que existe con esa firma, la verifico antes de aprobar, aunque el resto del cambio parezca perfecto. Es la comprobación que más falsos "esto está bien" evita.

Tercero, reviso los bordes, no el camino feliz

Un agente casi siempre resuelve bien el caso que le pediste explícitamente. Lo que no cubre por defecto son los casos que no mencionaste: qué pasa con una entrada vacía, qué pasa si la llamada externa falla, qué pasa si esto se ejecuta dos veces seguidas. No reviso el camino feliz porque ya sé que probablemente está bien, reviso específicamente qué pasa fuera de él.

Esto también me dice algo sobre el prompt original, no solo sobre el código: si el agente no cubrió un borde importante, muchas veces es porque yo no lo mencioné, no porque el agente lo ignorara.

Cuarto, los tests que el propio agente escribió no cuentan como validación

Si el mismo agente que escribió el código escribió también los tests, esos tests validan que el código hace lo que el agente entendió que tenía que hacer, no que eso sea lo correcto. Es circular. Reviso los tests como parte del código a revisar, no como prueba de que el código está bien.

Si la tarea es lo bastante importante, escribo yo mismo uno o dos tests del caso que más me preocupa antes de aprobar, en vez de confiar en los que vinieron con el PR.

El orden importa más que la exhaustividad

Con este orden, la mayoría de los PRs generados por agente se descartan o se aprueban en los primeros dos pasos: comparar intención con diff, y verificar las llamadas a algo externo que no reconozco. Solo cuando esos dos pasos no encuentran nada raro, invierto tiempo real en los bordes y en escribir tests propios. Eso es lo que ahorra el tiempo: no revisar menos, sino revisar en el orden que encuentra antes los errores más caros.

La recomendación

No revises código de agente como revisas código humano. Empieza comparando lo que dijo que iba a hacer con lo que realmente cambió, verifica cada llamada externa que no reconozcas de memoria antes de mirar el resto, y no confíes en los tests que vinieron con el mismo cambio que estás revisando. Ese orden es lo que separa una revisión de minutos de una de media hora.

Relacionado: Cómo uso Cursor IDE sin perder el control del código