Revisa la intención, deja que las máquinas comprueben el resto

Los pull requests de agentes llegan en mayor número, se ven seguros de sí mismos, y luego no puedes preguntarle al autor "¿en qué estabas pensando?". La investigación temprana empieza a mostrar qué significa eso en la práctica.

Un estudio de 7156 PR de agentes encontró que el tipo de tarea importa más que qué agente la escribió: "documentation tasks achieve 82.1% acceptance compared to 66.1% for new features." Ningún agente ganó en todas las categorías. [2] Un segundo estudio analizó 654 PR de agentes rechazados y encontró siete modos de rechazo que ocurren solo en PR de agentes — y que "a large proportion of rejected PRs (67.9%) lack explicit reviewer feedback." [1] En otras palabras: la mayoría de las veces, nadie le dice al agente por qué.

Ambos estudios usan el mismo conjunto de datos público de PR de agentes (AIDev), y ambos se publicaron en febrero de 2026; los agentes han cambiado desde entonces — lee las cifras como tendencia, no como una clasificación.

Todo lo que una máquina pueda comprobar nunca debería llegar a una persona: formateo, tipos, lint, complejidad, tests. Cada uno de ellos pertenece a un punto anterior en la cadena — en la edición del agente, en el commit, en la CI. Explicamos cómo configurarlo en nuestra guía de feedback instantáneo para agentes de código.

La guía de revisión de código de Google sigue aplicando a los agentes: el revisor mira el diseño, la funcionalidad, la complejidad, los tests, los nombres y los comentarios — lo que hace que una base de código sea más saludable con el tiempo. [3] La diferencia con los agentes es que la parte mecánica de esa lista se puede automatizar casi por completo.

"Listo, todos los tests pasan" es una afirmación. Pide evidencia en su lugar. Añade una línea de entrega en cada story pidiendo al agente que "summarize changed files, checks run, failures encountered, and any remaining risk." [8] Los Cloud Agents de Cursor también pueden adjuntar capturas de pantalla, vídeos y referencias de logs al pull request, para que puedas ver el cambio funcionando sin hacer checkout de la rama. [7]

## What changed
- auth/login-form.tsx — locked-account message + reset link
- auth/login-form.test.tsx — new test for the locked case

## Checks run
- npm run typecheck ✔
- npm test -- auth ✔ (14 passed)

## Failures hit
- First run broke the signup error style; fixed by reusing ErrorBanner.

## Remaining risk
- Copy not reviewed by product. Lockout threshold unchanged (non-goal).

No dejes que el agente califique su propio trabajo. Un revisor automático en un contexto nuevo detecta cosas para las que el autor está ciego. La documentación de Claude Code describe un patrón escritor/revisor: "A fresh context improves code review since Claude won't be biased toward code it just wrote." [4] Cursor Bugbot "analyzes PR diffs and leaves comments with explanations and fix suggestions" [5], y GitHub Copilot code review hace lo mismo en GitHub. [6] Claude Code en la web puede ir un paso más allá y auto-arreglar pull requests: vigila un PR y responde a fallos de CI y comentarios de revisión — un buen ejemplo de devolver los hallazgos al agente. [9]

Hay una cara menos amable, y la misma documentación es honesta al respecto:

"A reviewer prompted to find gaps will usually report some, even when the work is sound, because that is what it was asked to do. Chasing every finding leads to over-engineering." [4]

Así que actúa solo sobre los hallazgos que afectan a la corrección o a los requisitos indicados. Todo lo demás es opcional.

Recuerda el 67,9 %: la mayoría de los PR de agentes rechazados no llevan un motivo explícito. [1] Cuando rechaces un PR o pidas cambios, di por qué — en el PR o en la story. "Mal" no enseña nada. "Esto debería reutilizar el ErrorBanner existente, ver signup-form.tsx" arregla esta ejecución y la siguiente. Si el mismo feedback se repite, pertenece a vuestras convenciones compartidas, no a otro comentario.

El argumento de esta guía es que la revisión debería ser por capas: primero las máquinas, luego un revisor independiente, tú al final — medido contra la story. Aerunit cubre la capa intermedia y la vara de medir. Cuando un agente abre un pull request, Aerunit lo revisa automáticamente y puede devolver los hallazgos a la misma sesión del agente para que los arregle, así el PR que abres ya ha pasado por una ronda.

La vara de medir es la propia story: el story writer de Aerunit propone issues de Linear con alcance, criterios de aceptación y no-objetivos, para que revises contra un objetivo con nombre. Y las convenciones de equipo que de otro modo repetirías en comentarios de revisión viven una vez en contexto y skills compartidos, y alimentan cada story y cada ejecución.