Revisar código escrito por un agente de IA

Objetivo

Revisar un cambio escrito por un agente basado en un modelo de lenguaje, o con una asistencia intensa de uno, de modo que se detecten los modos de fallo típicos del código generado, mientras que el estándar de revisión habitual sigue aplicándose a todo lo demás.

Requisitos previos

Una descripción del cambio que indique qué se pidió, qué hizo el agente y qué no verificó; un revisor que pueda ejecutar el código y las pruebas; la lista de verificación de revisión habitual del equipo.

Pasos

1. Leer primero la intención: comparar la solicitud con lo que hace el diff. Un patrón comúnmente reportado en los cambios generados es la deriva de alcance: refactorizaciones no solicitadas, identificadores renombrados o «mejoras» en código adyacente. Pedir que los añadidos se separen antes de revisar el resto.
2. Confirmar que toda dependencia, API, indicador (flag) y función nuevos existen en las versiones en uso: abrir la importación, la entrada del registro o la documentación. Las API plausibles pero inexistentes son un modo de fallo comúnmente reportado en el código generado.
3. Verificar las afirmaciones sobre pruebas mediante evidencia, no mediante la frase: encontrar la ejecución de CI. Ejecutar las pruebas que añadió el cambio y romper temporalmente el código bajo prueba para confirmar que pueden fallar.
4. Leer las pruebas antes que la implementación. Las pruebas generadas a menudo verifican la salida actual de la implementación en lugar del requisito, simulan (mock) precisamente lo que está bajo prueba, o protegen la aserción con una condición que nunca se cumple.
5. Buscar errores manejados silenciosamente: bloques except o catch demasiado amplios, valores predeterminados devueltos en caso de fallo, reintentos sin límite, y registro en el log en lugar de propagación.
6. Aplicar el cuidado habitual a los límites y a las rutas relevantes para la seguridad: validación de entradas, manejo de rutas de archivo, construcción de shell y de SQL, secretos en el código o en los registros. El código generado se lee con fluidez, lo que invita a una lectura superficial; conviene frenar precisamente donde parece más seguro de sí mismo.
7. Comprobar que los comentarios y las docstrings describen el código tal como quedó, no tal como se redactó por primera vez; los comentarios desactualizados son habituales tras una generación iterativa.
8. Indicar en la revisión qué partes se ejecutaron, se leyeron con detenimiento o solo se hojearon, de modo que el siguiente lector sepa hacia dónde se dirigió la atención humana.

Resultado esperado

Los defectos característicos del código generado (API inventadas, pruebas tautológicas, ampliación de alcance, manejo de errores oculto) se detectan en la revisión, y el registro de la revisión muestra qué verificó una persona.

Límites y base de verificación

Este es un protocolo propuesto; no se afirma ninguna comparación de las tasas de defectos entre cambios generados y escritos a mano. Los pasos añaden tiempo de revisión, y en cambios muy pequeños los pasos 2 a 5 pueden bastar. Un cambio sin ninguna indicación de cómo se produjo debe revisarse como si hubiera sido generado.

Automatizar antes de leer

Ejecutar las comprobaciones mecánicas antes de que una persona lea el cambio, y hacer que el autor adjunte los resultados. Una compilación con el verificador de tipos o el resolutor de importaciones resuelve si toda API y dependencia existe (paso 2). Una ejecución de pruebas de mutación acotada al diff resuelve si las pruebas nuevas pueden fallar (paso 3), y una ejecución de pruebas fallida anterior a la corrección es una evidencia aceptable cuando no se dispone de una herramienta de mutación. Un linter configurado para señalar los bloques except y catch vacíos o ciegos cubre la mitad obvia del paso 5. El tiempo del revisor se dedica entonces a las preguntas que las herramientas no pueden responder: si el diff coincide con la solicitud, si las pruebas verifican el requisito en lugar de la implementación, y si los límites están manejados.