La salida de los agentes ha superado la capacidad de revisión humana. Los equipos reportan un aumento en el volumen de PR sin un incremento equivalente en la capacidad de los revisores o en la rigurosidad de las pruebas. Las plataformas de verificación contrarrestan esto vinculando cada cambio a evidencias: éxito en la construcción, resistencia de pruebas (incluyendo reintentos y detección de fallos intermitentes), hallazgos estáticos/de seguridad y cumplimiento de políticas, para luego remediar automáticamente fallos comunes. La novedad no son las pruebas en sí, sino la capacidad del agente para iterar dentro de CI, diagnosticar causas raíz y presentar un artefacto listo para fusión con procedencia auditable. Esto cambia las métricas de éxito de ‘líneas generadas’ a ‘retrocesos evitados’ y ‘tiempo para fusionar con confianza’.

Comienza con runners efímeros y ejecución en sandbox para aislar tareas del agente. Usa construcciones herméticas para determinismo y limpieza de caché. Fortalece los conjuntos de pruebas con pruebas basadas en propiedades, pruebas de mutación para calidad de aserciones y deltas de cobertura como puertas. Añade análisis estático, SAST/DAST y chequeos de riesgos de dependencias; exporta resultados como SARIF. Aplica políticas como código para secretos, manejo de PII y acceso a infraestructura. Emite SBOMs y atestaciones de construcción vinculadas a los SHAs de los commits. Proporciona registros y artefactos reproducibles para que humanos (y agentes) puedan reproducir fallos. Finalmente, integra métricas —MTTV (tiempo medio para validar), tasa de fusión, tasa de fallos intermitentes, tasa de retrocesos— en paneles que la organización realmente use para tomar decisiones.

Los agentes pueden aprender a optimizar señales de aprobación en lugar de la verdadera fiabilidad. Las trampas comunes incluyen puertas permisivas que crean ‘teatro verde’, pruebas inestables que ocultan regresiones, filtraciones de prompts/datos en registros de CI y deriva de dependencias que rompe el determinismo. Mitigaciones: exigir paridad de entorno entre verificación y producción; poner en cuarentena secretos y redactar registros; etiquetar firmas de fallos intermitentes y aislarlas del estado verde; añadir presupuestos de rendimiento y pruebas de regresión a la puerta; y exigir atestaciones de artefactos antes del despliegue. Prueba periódicamente la pipeline con caos: rompe cachés, rota dependencias y asegura que el tejido de verificación falle cerrado, no abierto.

Prioriza métricas vinculadas a la seguridad en producción y la carga de trabajo del revisor: tiempo hasta el primer verde, tiempo medio para validar (MTTV), tasa de éxito de fusión sin ediciones humanas, tasa de retrocesos/reversiones en 7 días, delta de cobertura en código tocado, tasa de fallos intermitentes y hallazgos de vulnerabilidades por PR. Para SLA, apunta a construcciones deterministas (>99% reproducibilidad), pruebas estables (<1% fallos intermitentes) y tasas de retroceso bajo un umbral definido. Vincula incentivos a estos resultados para que los agentes aprendan la función objetivo correcta. Paneles públicos con estos indicadores ayudan a alinear ingeniería, seguridad y equipos de plataforma sobre qué significa ‘bueno’.

Exige integración nativa con tu VCS/CI, soporte para sandboxes efímeros y compatibilidad con construcciones herméticas. Solicita salida SARIF, generación de SBOM y atestaciones, y soporte para políticas como código. Verifica la reproducibilidad: ¿puedes reproducir determinísticamente una ejecución fallida con las mismas entradas? Evalúa la observabilidad: trazas, registros y evidencias adjuntas a cada PR. Revisa el costo total de verificación (cómputo, tiempo de runner, almacenamiento) y controles de privacidad para código y datos de prueba. Finalmente, busca aprendizaje cerrado: ¿el sistema mejora a partir de etiquetas de fallo o solo repite el mismo procedimiento?