Hacer que el código generado por IA sea seguro para desplegar: una puerta de revisión para PRs de agentes

Tu cola de revisión se llena de solicitudes de extracción de agentes, y cada parche parece razonable por sí solo. Un solo agente puede abrir una docena de PRs en una hora. El viejo hábito de hojear un parche y confiar en el autor ya no funciona cuando el autor es un proceso. Trata cada PR de agente como entrada no confiable y construye una puerta que haga que el camino seguro sea el camino fácil.

Las PRs de agentes necesitan una superficie de confianza

La superficie de revisión ha cambiado: el código generado por IA contiene 1,57 veces más vulnerabilidades de seguridad que el código escrito por humanos. El número no hace que cada parche sea peligroso. Convierte el problema de revisión en un problema de capacidad: los cambios plausibles llegan más rápido de lo que un humano puede inspeccionarlos.

La puerta es el rediseño

Coloca la puerta donde se crea la PR, no en una wiki. Debe responder a la pregunta del diseñador: ¿qué necesita ver el revisor antes de que el siguiente paso sea seguro? Para el código de agentes, el revisor necesita procedencia, alcance, evidencia, compatibilidad y excepciones. La puerta debe ser visible para los diseñadores, no solo para los ingenieros, porque la decisión de merge es una decisión de producto. La lista de verificación a continuación es el rediseño: un pequeño conjunto de comprobaciones que convierte «parece plausible» en «seguro para fusionar».

• Procedencia: La PR debe indicar el agente, la tarea y el linaje de commits. Si no puede decir de dónde viene el cambio, no entra en revisión.
• Alcance del diff: El parche debe permanecer dentro de la tarea declarada. Módulos no relacionados, archivos de configuración o artefactos generados son una señal de detención.
• Cobertura de regresión: La suite de pruebas relevante debe ejecutarse contra el parche, y los nuevos fallos deben ser visibles. La cobertura inferida no cuenta.
• Estabilidad de formato: Los formatos de almacenamiento, API y serialización deben mantenerse compatibles o estar explícitamente versionados. Las migraciones silenciosas no pasan la puerta.
• Registro de divergencias y seguridad: Las diferencias de comportamiento conocidas y los hallazgos de seguridad deben listarse con un responsable y una disposición. Las excepciones ocultas en comentarios no cuentan.

Cada comprobación le da al revisor una razón clara para detenerse. La procedencia hace que la salida del agente sea responsable. El alcance del diff impide que una tarea pequeña arrastre un gran radio de impacto. La cobertura de regresión permite que las propias pruebas del sistema hablen antes de que un parche defectuoso se propague. La estabilidad de formato le da al control de versiones un contrato de reversión. El registro de divergencias y seguridad mantiene los huecos conocidos asignados a una persona.

DoltLite muestra las pruebas

DoltLite tenía cinco meses cuando se convirtió en Beta en la versión 0.50.0. El lanzamiento Beta de DoltLite siguió a unas 2.000 solicitudes de extracción de un equipo de agentes. La parte útil es la huella de evidencia detrás de la velocidad: DoltLite superó las 5,8 millones de consultas de la suite sqllogictest, una suite de pruebas SQL. Superó el 99,46 % de las 892.277 pruebas de aceptación basadas en TCL de SQLite, con 4.809 divergencias conocidas. DoltLite necesitó 12 cambios de formato de almacenamiento antes de la Beta y luego mantuvo el formato actual durante 57 versiones en más de tres meses.

Las pruebas cambian la pregunta de revisión. Un proyecto puede avanzar rápidamente y aun así llegar a producción cuando el equipo puede señalar pruebas ejecutadas, excepciones conocidas y un formato estable. La puerta no le pide al agente que sea perfecto. Le pide al producto que haga visible la evidencia antes de que el botón de merge tenga sentido. También le da al equipo un registro compartido para preguntas posteriores.

Haz que la puerta sea el valor por defecto

Empieza por integrar la lista de verificación en la plantilla de PR. La procedencia es un campo obligatorio, no un comentario. El alcance del diff se muestra como un resumen visual, no como una esperanza. Los resultados de regresión bloquean el merge cuando fallan. Los cambios de formato requieren una etiqueta de versión. Las divergencias y hallazgos de seguridad aparecen en una tabla con responsables. Entonces el equipo puede aprobar el merge con la misma evidencia que necesitaría en una revisión de incidente.