El dry-run: la función más importante de un agente que escribe

Hay un dato de Autodesk Vault que casi nadie tiene presente hasta que lo necesita: no existe el deshacer masivo. Cero operaciones. Si un proceso cambia el estado de doscientos archivos y ese cambio estaba mal, no hay un botón que lo devuelva todo a como estaba. Se corrige archivo por archivo, con tiempo, con nervios y con alguien preguntando cada media hora si ya quedó.

Ese dato fue el punto de partida de la decisión de diseño más importante de VaultPilot, el agente de IA para Vault Professional 2026 que construimos junto a Avant Leap. No fue elegir el modelo de lenguaje. Fue esta regla: el agente no ejecuta ninguna escritura sin antes mostrar el plan completo.

Qué es un dry-run de verdad

Un dry-run no es un mensaje de confirmación genérico. Es la simulación completa de la operación, presentada antes de tocar un solo dato: qué archivos se van a modificar, qué propiedades van a cambiar y con qué valores, a qué estado del ciclo de vida se va a mover cada componente. El plan entero sobre la mesa, en un formato que un ingeniero puede leer y cuestionar.

Y la parte que más importa: la ejecución no arranca hasta que el usuario la confirma. Si el plan muestra algo raro, un archivo que no debería estar ahí, una propiedad con un valor inesperado, se cancela sin costo. El error se muere en el papel.

Lo que detienen las compuertas

Durante dos meses de desarrollo contra una instancia de Vault Professional 2026, el log registró 249 llamadas que llegaron al Vault. De ellas, 80 escrituras fueron detenidas por una compuerta antes de tocar datos: 45 por anclaje de identidad y 35 por el interruptor de solo lectura. Es un log de desarrollo, no una tasa de éxito en producción, y por eso lo cito con ese caveat. Pero la lección es transferible: un agente que trabaja con lenguaje natural va a intentar cosas que no debe, y la diferencia entre un incidente y una anécdota es que exista una compuerta delante.

El dry-run es la primera de esas compuertas y la que más trabajo hace. Cada uno de esos intentos detenidos habría sido, en el mejor de los casos, una tarde de correcciones manuales. En el peor, un lote de componentes liberados con datos equivocados.

El dry-run tampoco trabaja solo. Su pareja natural es la verificación de escritura: después de ejecutar, el agente relee lo que escribió y lo compara con lo que prometió. En ese mismo log, 23 veces la API devolvió éxito y la relectura lo desmintió. Sin esa comprobación, esos 23 casos serían hoy datos corruptos con cara de operación exitosa. Toda escritura es una afirmación; la relectura es la prueba.

Autonomía no es ausencia de humano

En mi sesión de Autodesk University 2026 defendí una frase que resume esta filosofía: el agente ejecuta el flujo de trabajo, pero no autoriza la escritura. Eso lo haces tú. Autonomía significa que el agente hace el trabajo pesado, recorre el vault, arma el plan, prepara la operación. No significa que decida solo sobre datos de producción.

Por eso, cuando evalúo cualquier herramienta que promete escribir en un PDM, la primera pregunta que hago es la misma que le hago a la mía: muéstrame el plan antes de ejecutar. Si la respuesta es que no hay plan, que la herramienta simplemente hace, la evaluación terminó ahí.