Revisar código cuando la mitad del diff lo ha escrito un agente

Lo primero que ocurre cuando un equipo adopta agentes de código es que las pull requests se vuelven más grandes y más frecuentes. Lo segundo es que la calidad de la revisión baja en silencio, porque un revisor ante un diff de ochocientas líneas que parece razonable hace lo que hacen los humanos: ojear, confiar, aprobar.

Ese es el riesgo, y no va de que el agente escriba código malo. El código escrito por agentes tiende a ser sintácticamente limpio, formateado según la convención y bien comentado, lo que desarma todas las heurísticas que los revisores construyeron en una década para saber dónde mirar.

Puerta 1: acordar el enfoque antes de que exista el código

La revisión más barata es la de un plan. Dos párrafos: qué cambia, qué ficheros e interfaces se ven afectados, qué queda explícitamente fuera y cómo se va a verificar. Se revisa en tres minutos, antes de una hora de generación.

Esto mata el peor modo de fallo: un cambio grande, internamente coherente y construido sobre una premisa que nadie acordó. Una vez existe el código, esa conversación cuesta una reescritura, y hay una atracción psicológica real a aceptar código que funciona antes que tirarlo.

Puerta 2: las comprobaciones automáticas van primero y no se negocian

Pruebas, tipos, linters, una build, un escaneo de seguridad. Nada de esto es nuevo; lo que cambia es que ahora tiene que bloquear de verdad, porque el volumen de cambio ha superado la capacidad del revisor de cazar lo que la herramienta caza gratis.

Dos añadidos que merecen la pena específicamente para la salida de un agente: comprobar que las dependencias nuevas están declaradas y justificadas —los agentes tiran de un paquete donde bastarían tres líneas— y comprobar la calidad de las pruebas, no solo su presencia, porque una batería que afirma sobre la implementación en vez de sobre el comportamiento es peor que no tener ninguna. Unas pruebas escritas por el mismo proceso que escribió el código demuestran menos que unas escritas contra la especificación, así que lo único que un revisor debería leer línea a línea son las aserciones.

Puerta 3: quien firma declara qué verificó

La descripción de la pull request tiene que incluir una línea escrita por la persona: qué ejecutó, qué comprobó a mano y de qué no está segura. «He pasado la batería de integración, he probado la migración sobre una copia de preproducción, no me fío de la lógica de reintentos del tercer commit» dirige la atención del revisor mejor que cualquier resumen automático.

Esto además restaura la responsabilidad. Quien envía el cambio responde por él, lo haya escrito quien lo haya escrito. Hacerlo explícito en la plantilla es un gesto pequeño con un efecto cultural grande: evita que «lo escribió el agente» se convierta en una respuesta disponible en una revisión de incidente.

Puerta 4: revisar por riesgo, no por número de líneas

Parte mentalmente el diff en tres cubos y reparte el esfuerzo.

Interfaces y contratos: formas de API, esquemas de base de datos, firmas públicas, todo aquello de lo que dependen otros sistemas. Lee cada línea. Los errores aquí son caros y permanentes.

Lógica de negocio y casos límite: las condiciones, los caminos de error, la aritmética del dinero. Lee con cuidado; aquí es donde vive la equivocación segura de sí misma.

Volumen mecánico: los doscientos puntos de llamada actualizados por la misma transformación, el andamiaje generado, el formato. Muestrea. Si diez de doscientos están bien, los otros ciento noventa casi con seguridad también, porque el modo de fallo de un cambio mecánico es sistemático, no aleatorio.

Ese último punto es lo que hace revisables los diffs grandes de agente: los cambios uniformes fallan de forma uniforme, así que el muestreo funciona de verdad, cosa que no ocurre con el código escrito a mano.

Qué medimos en lugar de líneas

La tasa de defectos después de integrar, por cambio, y cuánto espera un cambio en revisión. Si el segundo número sube, el equipo genera más rápido de lo que absorbe, y el arreglo son cambios más pequeños, no revisores más rápidos. Los agentes son muy buenos partiendo el trabajo en tres pull requests encadenadas si se lo pides, y nadie se lo pide.

Qué hacer esta semana

Añade dos líneas a tu plantilla de pull request: «Cómo lo he verificado» y «De qué estoy menos seguro». Le cuesta treinta segundos al autor y es el cambio con más retorno que hemos hecho en la práctica de revisión desde que llegaron los agentes.