Code review en la era de los agentes: quién revisa el código de la IA

Cuando un agente escribe el código, la primera pregunta no es “¿funciona?”, sino “¿quién lo revisa?”. La vieja intuición (el autor escribe, el revisor lee) deja de encajar, porque el “autor” es un modelo que no asume consecuencias y no recuerda la decisión de ayer. El code review no desaparece. Cambia su estructura. Los mejores equipos que observo montan dos revisiones: primero un agente revisor y después una persona. Cada uno detecta una clase distinta de errores, y de eso se trata precisamente.

El modelo de las dos revisiones

La primera capa es el agente revisor: una pasada independiente de un modelo que lee el diff antes que una persona. La segunda capa es la persona, que lee lo que queda después del agente. El orden no es casual. El agente es barato y nunca se cansa, así que va primero: filtra el ruido antes de que empiece a costar tiempo de un senior. La persona llega al final, porque la atención humana es el recurso más caro de todo el proceso y no se debe desperdiciar en cosas que una máquina detecta por sí sola.

No es “lo mismo dos veces”. Si el agente y la persona detectaran los mismos errores, la segunda capa sería un desperdicio. El valor aparece precisamente porque sus campos de visión no se solapan. El agente ve patrones en el código. La persona ve el sentido del problema.

Por qué cada revisión detecta errores distintos

El agente revisor es excelente en lo mecánico y repetitivo: estilo incoherente, tipos que faltan, una rama de error sin manejar, una ruta de código ingenua que nadie va a probar, duplicación que el autor no vio porque solo miraba su propio archivo. El modelo lee mil líneas sin aburrirse y señala veinte sitios donde falta el manejo de null. Lo hace con la misma constancia a las 9 de la mañana y a las 11 de la noche, en el primer PR del día y en el trigésimo.

La persona detecta lo que el modelo, por su propia estructura, no puede ver: una mala interpretación del dominio. Al agente le pidieron “calcula el descuento” y calculó el descuento, solo que en esta empresa el descuento se calcula sobre el precio neto, no sobre el bruto, y ese dato no aparece en ninguna parte del código porque vive en la cabeza de tres personas. El modelo no sabe que está escribiendo una respuesta correcta a la pregunta equivocada. Eso lo detecta una persona que conoce el contexto.

Lo segundo que queda reservado a la persona: el “problema resuelto a medias”. Un agente puede cerrar un ticket con código que cubre el happy path y parece completo, mientras guarda silencio sobre la migración de datos que se saltó, el caso límite de la lista vacía y la retrocompatibilidad de la API. El código compila, los tests pasan y el PR parece terminado. Solo que el problema está resuelto al 50%, y el 50% restante es justo lo que estalla en producción. El modelo no tiene la sensación de “¿esto cierra de verdad el tema?”. La persona, sí.

El agente revisor comenta, nunca aprueba solo

Esta es la regla que no se rompe: el agente revisor puede comentar, pero no puede aprobar un PR por su cuenta. La diferencia entre un ayudante y alguien que decide es aquí absoluta. En el momento en que el agente empieza a hacer merge de sus propias observaciones sin una decisión humana, cierras un bucle en el que la máquina juzga a la máquina, y ambas tienen los mismos puntos ciegos.

La razón es práctica, no filosófica. El agente revisor funciona sobre la misma distribución de entrenamiento que el agente autor. Los mismos supuestos que el autor asumió en silencio, el revisor los da por obvios y los deja pasar. Un error de dominio invisible para el autor también lo es para un revisor de la misma familia de modelos. Por eso la aprobación humana no es una formalidad: es el único punto del bucle por el que entra contexto de fuera de los datos de entrenamiento.

En la práctica, el agente revisor deja comentarios en el PR, señala los puntos de riesgo y sugiere correcciones. El estado “approved” lo pone una persona, de forma deliberada, asumiendo la responsabilidad de lo que entra en main. El agente nunca es la última firma.

Qué pasa cuando el agente entrega 5x más PR

Aquí empieza el verdadero problema de escala. El agente no escribe cinco veces mejor: escribe cinco veces más. Un ingeniero con un agente bien ajustado abre tantos PR como antes un equipo pequeño. El cuello de botella deja de ser escribir código. Pasa a ser la revisión.

Los equipos que no lo previeron caen en uno de dos modos. O la revisión se convierte en un mero trámite: la gente hace clic en “approve” porque la cola tiene cuarenta elementos y nadie los lee con honestidad. O la revisión se convierte en el cuello de botella que borra toda la aceleración que aportan los agentes: escribes 5x más rápido, pero entregas al ritmo de siempre, porque los PR pasan tres días en la cola.

La salida no es leer más rápido. Es leer menos, pero mejor. El agente revisor debería encargarse de toda la base de la pirámide: estilo, tipos, carencias evidentes. La persona recibe un PR ya filtrado, con los puntos de riesgo marcados, y lee solo lo que requiere criterio humano. El segundo mecanismo es diferenciar: un PR que cambia el texto del pie de página no necesita la misma revisión que un cambio en el código de facturación. El tercero: PR pequeños. Un agente que entrega 5x más debería entregar también fragmentos 5x más pequeños; revisar diez diffs pequeños es más honesto que revisar uno enorme.

La fatiga de revisión y cómo combatirla

La fatiga de revisión no es pereza: es la fisiología de la atención. Después del vigésimo PR del mismo día, una persona ya no lee, escanea. El cerebro pasa al reconocimiento de patrones: “se parece a los anteriores, seguro que está bien”. Ese es justo el momento en que se cuela un error de dominio, porque, por definición, parece correcto.

Con agentes el problema se agrava, porque el código de un agente es uniformemente pulcro. Sin erratas, sin sangrías raras, sin nada que detenga la mirada. Todo parece correcto, así que el revisor deja de detenerse. Paradójicamente, la perfección cosmética del código de un modelo adormece la vigilancia más rápido que el código tosco de un junior, que te obliga a pensar.

Qué funciona en la práctica. Pon un límite de revisiones por persona y día: a partir de cierto umbral, la calidad cae por debajo de cero, es decir, dejas pasar más errores de los que detectas. Rota a los revisores para que nadie lea treinta PR seguidos. Exige al autor (también al agente) que describa “qué y por qué” en el PR, porque la lectura empieza por la intención, no por el diff. Y separa las revisiones “triviales” de las “arriesgadas”: haz las segundas por la mañana, con la cabeza despejada, no a las 6 de la tarde como la vigésima seguida.

Una checklist práctica de PR para la era de los agentes

Esta es la lista que una persona repasa de forma deliberada, después de que el agente revisor haya dejado sus comentarios. El agente se ocupa de los puntos mecánicos; esta lista trata de lo que el modelo no va a detectar:

1. ¿Este código resuelve el problema correcto, y no el de al lado?
2. ¿El problema está cerrado, o es solo el happy path? ¿Dónde están los casos límite?
3. ¿Los supuestos de dominio son correctos para esta empresa, y no para el manual?
4. ¿Qué pasa con la migración de datos y la retrocompatibilidad?
5. ¿Los tests comprueban el comportamiento, o solo que una línea se ejecutó?
6. ¿El agente revisor marcó los puntos de riesgo, y se resolvió cada uno de ellos?
7. ¿El PR es lo bastante pequeño como para leerlo con honestidad?
8. ¿Asumo la responsabilidad de este merge, o estoy haciendo clic en “approve” por cansancio?

El último punto es el más importante. Si la respuesta es “hago clic por cansancio”, el proceso tiene demasiados PR para muy poca atención humana, y lo que hay que arreglar es el proceso, no forzar el PR para que pase.

Mito: si el agente lo escribe, que el agente lo revise

Tentador y falso. Sí, un segundo agente detectará algunas cosas, y debe hacerlo: ese es todo el papel de la primera capa. Pero dos modelos de la misma familia comparten los mismos puntos ciegos. La interpretación del dominio, el problema “resuelto a medias” y la responsabilidad sobre producción siguen siendo humanos. El agente revisor escala la revisión hacia la base de la pirámide, donde los errores son numerosos y mecánicos. La persona vigila la cúspide, donde los errores son raros, caros e invisibles para la máquina. Quita a la persona y quitarás el único punto del bucle que ve más allá de los datos de entrenamiento.

TL;DR

El code review en la era de los agentes son dos revisiones: primero el agente revisor, después la persona. El agente detecta estilo, tipos y carencias mecánicas; la persona detecta la mala interpretación del dominio y el problema resuelto a medias. El agente comenta, nunca aprueba solo, porque comparte los puntos ciegos del autor. Cuando el agente entrega 5x más PR, la revisión se convierte en el cuello de botella: sálvala con filtrado, diferenciación del riesgo y PR pequeños. Combate la fatiga de revisión con límites y rotación. Cíñete a la checklist, y la última pregunta siempre es: ¿asumo la responsabilidad de este merge?