Tratar responsablemente el código generado por agentes: el marco de Vercel

• Los agentes de programación generan código a una velocidad sin precedentes, pero usarlos sin criterio riguroso se convierte en una vía eficiente para llevar a producción suposiciones equivocadas
• El código generado por agentes puede incluir descripción de PR, pasar análisis estático e incluso tener cobertura de pruebas, y parecer escrito por un ingeniero con experiencia, pero no refleja en absoluto los patrones de tráfico, modos de falla ni restricciones de infraestructura del entorno real de producción
• Aprovechar (leveraging) la IA y depender (relying) de ella son cosas fundamentalmente distintas; aprovecharla de verdad significa entender por completo cómo funciona el resultado del agente, cuáles son sus riesgos, y asumir su propiedad
• Con tres principios —despliegues autónomos, validación continua y guardrails ejecutables— es posible construir un entorno en el que los agentes actúen con alta autonomía sin dejar de ser seguro
• Ya no sobrevive el ingeniero que más código genera, sino el que mantiene un criterio frío para decidir qué desplegar

---

Problema: un CI en verde ya no es prueba de seguridad

• Pasar CI solo refleja la capacidad del agente para convencer al pipeline, no la seguridad real de la infraestructura
  • Se puede desplegar una consulta que pasa las pruebas pero hace un escaneo completo de filas en producción
  • Una lógica de reintentos que parece normal puede provocar un Thundering Herd en servicios downstream
  • Un caché sin TTL puede llevar silenciosamente a Redis a su colapso
• Los agentes no saben si una instancia de Redis está al límite de capacidad, si la base de datos tiene una región específica codificada de forma rígida, o que un rollout de feature flags cambia el perfil de carga de los sistemas downstream
• La brecha entre "este PR parece correcto" y "este PR se puede desplegar de forma segura" siempre ha existido, y los agentes la amplían aún más

Distinción clave: aprovechar vs. depender

• Depender (Relying): asumir que si el agente lo escribió y las pruebas pasan, entonces ya está listo para desplegarse
  • El autor no construye un modelo mental del cambio
  • Se generan PR enormes, llenos de supuestos ocultos, donde ni el autor ni el revisor entienden realmente qué hace el código
• Aprovechar (Leveraging): usar al agente para iterar rápido, manteniendo la propiedad total sobre el resultado
  • Entender exactamente cómo se comporta el código bajo carga
  • Comprender los riesgos involucrados y estar dispuesto a asumirlos
• Poner tu nombre en un PR significa: "lo leí y entiendo lo que hace"; ese es el punto de referencia del proceso de ingeniería

Criterio de evaluación: la prueba de fuego

• Prueba simple: "¿Me sentiría cómodo asumiendo la responsabilidad por un incidente en producción asociado a este PR?"
• Tres preguntas que uno debe hacerse antes de abrir el PR
  • ¿Qué hace este código? ¿Cómo se comportará después del rollout?
  • ¿Qué impacto negativo podría tener en producción o en los clientes?
  • ¿Me sentiría cómodo haciéndome cargo de un incidente asociado a este código?
• Si la respuesta es "sí", entonces estás aprovechando la IA y puedes desplegar; si es "no", todavía falta trabajo

Solución: tres principios para defender producción

• Despliegues autónomos (Self-driving deployments): todos los cambios se liberan gradualmente mediante pipelines con compuertas, y los despliegues canary hacen rollback automático si el desempeño se degrada
  • No dependen de que un ingeniero vigile dashboards
  • Si surge un problema, se aísla solo en una parte del tráfico y no en todo el sistema
• Validación continua (Continuous validation): probar constantemente la propia infraestructura, no solo en el momento del despliegue
  • Las pruebas de carga, experimentos de caos y simulacros de recuperación ante desastres se ejecutan continuamente
  • Por eso el failover de base de datos que Vercel ensayó en producción el verano pasado no tuvo ningún impacto en clientes cuando ocurrió una falla real en Azure
• Guardrails ejecutables (Executable guardrails): codificar el conocimiento operativo como herramientas ejecutables, no como documentos
  • La skill safe-rollout no es una página de Notion que explica cómo funcionan los feature flags, sino una herramienta que conecta flags, genera un plan de rollout con condiciones de rollback y especifica cómo verificar el comportamiento esperado
  • Cuando los guardrails son ejecutables, el agente puede seguirlos de forma autónoma y las personas no tienen que memorizarlos

En qué está invirtiendo Vercel en la práctica

• Reforzar guardrails compartidos de infraestructura aplicando validación en runtime en cada etapa del pipeline de despliegue
• Reforzar verificaciones estáticas en la etapa de PR, especialmente alrededor de feature flags
• Introducir pruebas end-to-end con espejado de producción en entornos de staging
• Operar agentes de solo lectura que validan continuamente invariantes del sistema en producción, y usar agentes especializados para auditar los supuestos de los agentes generativos
• Introducir métricas como la tasa de defectos escapados frente a commits defectuosos para detectar si el riesgo está aumentando en toda la plataforma

Conclusión: el ingeniero con criterio es el que compite mejor

• La implementación se volvió abundante, y ahora el recurso escaso es el criterio para decidir qué puede desplegarse de forma segura
• Se terminó la época en que el código de mala calidad parecía de mala calidad; las herramientas de IA serán cada vez más poderosas, los diffs más grandes y también crecerá la tentación de confiar ciegamente en el resultado
• La meta no es un mundo donde se aplique un rigor extraordinario a cada cambio, sino uno donde la propia infraestructura sea rigurosa y donde desplegar rápido sea seguro por defecto