vercel deploy --dry da a los agentes un preflight real antes de subir código

Vercel añadió dry-run deployments al CLI el 1 de julio de 2026. El comando importante es simple: vercel deploy --dry. La novedad para builders de agentes no es solo ver un resumen antes de desplegar. Es darle al agente un objeto verificable para responder una pregunta crítica: ¿qué estoy a punto de subir exactamente?

La intención de búsqueda se concentra en vercel deploy --dry, Vercel CLI dry run, agent deployment preflight, vercel manifest json. No invento volumen de búsqueda; la demanda se infiere por el changelog oficial, la utilidad directa para CI/CD y la conversación actual sobre agentes que modifican, prueban y despliegan sin supervisión constante.

El deploy no debería ser la primera verificación

En muchos flujos agentic, el agente corre tests, arma un resumen y empuja cambios. El problema aparece cuando el deploy incluye archivos inesperados, ignora assets necesarios, detecta mal el framework o sube un paquete inflado por cachés, videos o artefactos temporales.

vercel deploy --dry muestra el framework detectado, cantidad de archivos, tamaños, directorios incluidos, archivos grandes y paths ignorados. Además, vercel deploy --dry --format=json devuelve un manifiesto completo con hashes, modos de archivo y distribución de tamaño. Eso cambia el rol del preflight: ya no es una inspección visual, es una entrada que un agente puede comparar contra reglas.

Para un equipo pequeño en Latinoamérica que ya usa Vercel, esto puede ser más valioso que otro dashboard. Permite automatizar revisiones concretas:

• confirmar que Next.js fue detectado como framework correcto;
• bloquear deploys si faltan imágenes, MDX o rutas esperadas;
• detectar assets demasiado grandes antes de subirlos;
• revisar que .vercelignore no excluya algo necesario;
• guardar el manifiesto como evidencia en un PR generado por agente.

Cómo lo usaría en un flujo con agentes

El patrón práctico es tratar el dry run como una etapa más del cierre, no como un comando opcional.

Primero, el agente modifica código o contenido. Luego corre tests locales. Después ejecuta vercel deploy --dry --format=json y revisa el manifiesto contra una lista corta de invariantes. Si algo no cuadra, corrige .vercelignore, mueve archivos o ajusta configuración. Solo cuando el manifiesto coincide con la intención, crea el deployment real.

La diferencia frente a una revisión humana es que el agente puede repetir el loop sin costo de despliegue: dry run, corregir, dry run otra vez. Ese ciclo reduce errores tontos que suelen aparecer tarde, cuando ya hay una URL de preview rota.

Errores comunes que puede atrapar

El primer error es olvidar assets generados. En sitios editoriales, eso suele verse como MDX que referencia imágenes inexistentes o rutas públicas que no entran al deploy.

El segundo es subir demasiado. Un agente puede generar capturas, logs, paquetes temporales o archivos de prueba y dejarlos bajo una ruta que el CLI incluirá. Si el manifiesto marca archivos grandes o directorios inesperados, hay que detenerse.

El tercero es confiar en el nombre del proyecto. Vercel dice que el output incluye framework detection; si el framework cambia o cae a un preset inesperado, el agente debería tratarlo como bloqueo.

Criterio de adopción

No hace falta construir una plataforma interna para aprovecharlo. Basta con añadir tres reglas al runbook del agente:

1. Ejecutar dry run después de build local.
2. Guardar el JSON como evidencia si el agente abre PR.
3. Bloquear deploy si hay archivos inesperados, assets faltantes o tamaño anómalo.

Si todavía estás definiendo cómo validar acciones antes de delegarlas, empieza por Instala Tu Propio Agente de IA. La conclusión es concreta: un agente que despliega sin saber qué va a subir está trabajando a ciegas.