Usa Microsoft PDD Kit para verificar Rust de agente

Un agente de programación puede desviarse del plan que le diste y luego escribir pruebas que alaban la deriva. Microsoft Research nombró esa brecha en su publicación del 5 de noviembre de 2026 sobre PDD Kit. El plan está destinado a ser el contrato. Nada obliga al agente a conservarlo, y leer cada línea que el agente escribió no escala cuando una tarea puede tocar miles de líneas.

PDD Kit es la corrección que Microsoft Research construyó con GitHub Next. Convierte la intención en una especificación formal, es decir un conjunto de afirmaciones precisas que una computadora puede revisar. Una herramienta llamada Verus luego demuestra que el código Rust cumple esa especificación para cada entrada en el modelo. Donde una prueba no puede llegar, el kit recurre a pruebas y lo dice a simple vista.

Lo que vas a construir o aprender

Terminarás con un método claro para verificar una pieza de Rust escrito por un agente, y con Verus instalado y demostrado en un archivo de muestra de su propia guía. El método sigue el ejemplo trabajado que Microsoft publicó. Ese ejemplo es Pet Store, una aplicación web de pila completa de unas 5,000 líneas de Rust, con un backend Axum y SQLite y una tienda Leptos compilada a WebAssembly.

El equipo en ese ejemplo verificó el inicio de sesión. Este tutorial usa el mismo objetivo porque el inicio de sesión muestra cada parte difícil a la vez. Tiene una regla que puedes declarar en una frase, una regla de rol que importa para la seguridad, búsquedas en base de datos que el verificador no puede ver y una revisión de contraseña que vive en una crate externa. Si puedes mapear el inicio de sesión, puedes mapear una revisión de pago, una revisión de permiso o un analizador con reglas estrictas.

También aprenderás el límite que más importa. Una prueba cubre su especificación y nada más. El trabajo que está fuera de la especificación aún necesita pruebas, revisión o una nota honesta de que nadie lo prometió.

Antes de empezar

Lee primero el límite de acceso, porque da forma a todo el tutorial. El propio PDD Kit vive dentro de Chopin y permanece en vista previa de investigación. No hay comando cargo que instale PDD Kit, y cualquier guía que te dé uno lo ha inventado. Los Pasos 4 a 8 describen el flujo como lo documentan Microsoft y GitHub Next, para equipos con ese acceso. Los Pasos 1 a 3 y el trabajo de Verus en el Paso 2 son útiles por su cuenta, y son la preparación que un equipo necesita antes de que llegue el acceso a PDD Kit.

Respalda el código Rust que planeas verificar, y elige una rama para el trabajo. El flujo agrega una crate verificada y contratos nuevos. No debería llegar a tu rama principal hasta que la prueba y las pruebas para las partes confiables pasen ambas. Usa valores marcadores en cada ejemplo que toque un secreto, un token o una clave de firma. Ningún paso en este tutorial necesita una credencial real.

Nuestra cobertura de sesiones de agente aisladas con Google Agent Substrate muestra la otra mitad de este problema, mantener a un agente contenido mientras trabaja. Este tutorial cubre la mitad de la prueba: mostrar que el trabajo que el agente entregó coincide con lo que pediste.

Paso 1: Elige una función pequeña donde un error cueste dinero real o confianza real

Acción: elige el primer objetivo como aconseja Microsoft. Empieza con la parte más sensible de la aplicación y verifica el resto una pieza a la vez. Inicio de sesión, pagos y permisos son los ejemplos que Microsoft nombra. Un buen primer objetivo tiene entradas claras, salidas claras y reglas que puedes declarar sin gusto ni juicio.

Resultado esperado: puedes escribir el objetivo como una función y una lista corta de resultados. En Pet Store, esa función se convirtió en login_flow. Toma los campos de una solicitud de inicio de sesión y devuelve un token o un error HTTP. Cinco funciones más pequeñas están bajo ella: login_core, lookup_target, decide_login e issue_token entre ellas. Cada una tiene su propio contrato, así que un cambio en una pieza solo necesita que esa pieza se demuestre de nuevo.

Un mal primer objetivo es una pantalla entera, un ranking de búsqueda o cualquier comportamiento donde correcto es una cuestión de opinión. Estaciona esos para pruebas y revisión humana. La prueba necesita una regla, y una regla necesita palabras que signifiquen lo mismo para todos los que las leen.

Paso 2: Instala Verus y demuestra la muestra de su propia guía

Acción: instala Verus desde su versión binaria. Este es el verificador que PDD Kit usa hoy, y funciona por su cuenta sin ningún acceso a Chopin en absoluto. El archivo de instalación de Verus da este orden: descarga la versión más reciente para tu plataforma, descomprímela, muévete a la carpeta que crea y ejecuta el binario. En macOS, ejecuta primero el script en esa carpeta que borra la cuarentena de Gatekeeper.

bash macos_allow_gatekeeper.sh
./verus

Resultado esperado: Verus o se ejecuta o te dice qué instalar. Si falta rustup, imprime el comando exacto para instalarlo y la cadena de herramientas que necesita. Si rustup existe pero la cadena de herramientas no, imprime el comando de instalación de rustup para esa cadena de herramientas. Sigue el comando impreso, y luego ejecuta el binario de nuevo. No adivines una versión de cadena de herramientas. El binario nombra la que fue construido para usar.

Después, crea el archivo de muestra de la guía de Verus. Nómbralo getting_started.rs y pega este contenido, que la guía usa como su primer ejemplo:

use vstd::prelude::*;

verus! {

spec fn min(x: int, y: int) -> int {
    if x <= y {
        x
    } else {
        y
    }
}

fn main() {
    assert(min(10, 20) == 10);
    assert(min(-10, -20) == -20);
    assert(forall|i: int, j: int| min(i, j) <= i && min(i, j) <= j);
    assert(forall|i: int, j: int| min(i, j) == i || min(i, j) == j);
    assert(forall|i: int, j: int| min(i, j) == min(j, i));
}

} // verus!

La guía explica la forma en una línea que vale la pena aprender ahora. El archivo es Rust. La macro verus! lo extiende con lenguaje de especificación, como forall, y le dice a Verus que verifique las funciones dentro del bloque. Una spec fn es código fantasma. El verificador lo revisa, y el compilador lo borra del programa que entregas.

./verus getting_started.rs

Resultado esperado: Verus imprime una nota de que está verificando el módulo raíz, y luego una línea de resultados que dice 1 verified, 0 errors, en la forma que muestra la guía. Esa línea es tu primera prueba. Verus revisó las afirmaciones sobre min para todas las entradas, no solo los dos pares en los asserts simples. Si quieres un binario también, la guía da el mismo comando con la bandera de compilación agregada. La verificación sola no compila el archivo.

Paso 3: Escribe la intención en lenguaje simple, en ambos sentidos donde importe

Acción: escribe la solicitud para tu objetivo en frases simples, tan en bruto como quieras. Pet Store empezó con dos frases para el inicio de sesión. Solo obtienes un token con la contraseña correcta. Solo las cuentas admin obtienen tokens admin. PDD Kit trata la entrada en bruto como normal. Convertir la intención en bruto en reglas comprobables es su trabajo.

Luego lee cada frase en busca de la trampa que Microsoft encontró en la primera. Una regla que dice que un token viene solo con la contraseña correcta también la cumple un inicio de sesión que rechaza a todos. La mitad faltante es que la contraseña correcta siempre obtiene un token. Microsoft llama a la primera lectura una implicación y al par de lecturas un si y solo si. Juntas descartan tanto el inicio de sesión malo como el inicio de sesión perezoso.

Resultado esperado: cada regla clave declara lo que debe ocurrir y lo que nunca debe ocurrir. Para el inicio de sesión, la forma resuelta cubre ambas mitades. Un token se emite si y solo si la solicitud nombra una cuenta real y la contraseña coincide con el hash guardado para esa misma cuenta. Esa redacción de misma cuenta importa. Atrapa un error de cableado donde el código revisa una cuenta y firma un token para otra, un error que una suite de pruebas rara vez piensa buscar.

Paso 4: Ejecuta pdd-plan en Chopin y responde las tarjetas de decisión

Acción: con acceso a Chopin, abre el plan para tu repositorio y dale a PDD Kit el objetivo y la intención del Paso 3. Su flujo de planificación se llama pdd-plan. Lee el código primero. Luego regresa con preguntas en tarjetas de decisión antes de escribir nada. Cuando una pregunta depende de cómo funciona el código, la tarjeta explica esa parte primero, para que puedas responder sin abrir el código fuente.

Responde cada tarjeta como una decisión de equipo, no como un clic rápido. En el ejemplo de inicio de sesión, la primera tarjeta preguntaba si la contraseña correcta debe siempre obtener un token. El equipo eligió la lectura en ambos sentidos del Paso 3. Una tarjeta posterior preguntaba cuánto del inicio de sesión demostrar. El primer borrador demostró la decisión en el centro y mantuvo el manejador confiable y probado. El desarrollador eligió más: una especificación para el propio manejador, para que la prueba cubra el pegamento donde las búsquedas se esperan y el token se firma.

Resultado esperado: PDD Kit conserva una sección de trabajo en bruto en la parte superior del plan, con un diagrama de flujo del objetivo, un mapa de lo que se demostrará y lo que se confiará, y un mapa de intención. Cada entrada de intención se vincula de vuelta a tus propias palabras y hacia adelante a la sección de la especificación formal que la modela y las pruebas que la cubren. Si ese mapa no coincide con lo que quisiste decir, detente aquí. El resto del flujo demostrará fielmente lo incorrecto.

Paso 5: Aprueba la especificación y el límite confiable, no el código

Acción: revisa el artefacto de intención en su conjunto y apruébalo antes de que empiece cualquier construcción. La especificación formal es la intención en lenguaje simple escrita como contratos Verus. Cada función obtiene un bloque ensures. Ese bloque declara lo que debe cumplirse sobre su resultado para cada entrada posible. En el inicio de sesión, dos frases en bruto se convirtieron en ocho cláusulas ensures en login_flow, que cubren un token solo para la cuenta nombrada, la contraseña correcta siempre obteniendo un token a menos que un paso de búsqueda o firma falle con un 500, una cuenta faltante obteniendo un 401, una contraseña incorrecta obteniendo un 401, un hash ilegible obteniendo un 500 y ningún token, y el rol admin solo para una fila admins encontrada por nombre de usuario sin correo enviado.

Luego revisa el límite con el mismo cuidado. La Base de Computación Confiable es el código que la prueba supone que se comporta como se describe. PDD Kit hace esa línea explícita y te pide aceptar cada pieza por su cuenta. Para el inicio de sesión, el desarrollador aceptó seis piezas:

En código, una pieza confiable está detrás de un envoltorio pequeño con un contrato supuesto. Verus lee el contrato y no el cuerpo. La especificación marca eso con términos como external_body para un envoltorio, o una especificación externa para una función cuyo código permanece donde está. Los nombres para cosas que la prueba no puede modelar, como lo que la base de datos guarda ahora mismo, aparecen como funciones abstractas sin cuerpo. La prueba luego dice que sea lo que sea que la base de datos guarde, el inicio de sesión hace lo correcto con ello, y el contrato confiable dice que la búsqueda devuelve lo que la base de datos guarda.

También lee la lista de lo que nadie promete. Para el inicio de sesión, esa lista nombra un futuro que nunca se completa, un reloj que está fuera de rango y entra en pánico, tiempo y tasa de intentos, y cómo otros endpoints leen el rol. Una prueba dice cuál será su resultado si la función responde. No dice nada sobre qué tan rápido, o si responde en absoluto.

Resultado esperado: has aprobado una especificación que puedes leer, un límite que aceptaste pieza por pieza y una lista de brechas que nadie afirma cubrir. Dos agentes revisores en el flujo también exploran la especificación en busca de brechas y de promesas que una prueba no podría mostrar, y esa revisión se ejecuta hasta que la especificación se lee como sólida. Tu aprobación sigue siendo el acto que cuenta. Coincidir con tu intención no es prueba, así que un alcance más amplio o una elección de confianza nueva regresa para una aprobación fresca.

Paso 6: Deja que el agente implemente, y luego ejecuta pdd-prove

Acción: entrega el plan aprobado a la etapa de prueba. En términos de Microsoft, un plan de construcción convierte el plan en un grafo pequeño de tareas. Para el inicio de sesión ese grafo tenía siete tareas: hacer que el archivo se compile bajo Verus dentro de la crate backend, demostrar la decisión, el paso del token y todo el flujo, y luego escribir las pruebas para los envoltorios confiables y para el inicio de sesión en su conjunto.

Cada tarea ejecuta el mismo ciclo. Un agente de programación escribe el código y la prueba. Verus los revisa contra la especificación. Cualquier cosa en el límite confiable obtiene las pruebas que el plan pidió. Un agente revisor luego lee el plan, la especificación y los resultados lado a lado y busca brechas, es decir requisitos sin prueba y sin revisión que pase. Las brechas regresan al agente de programación. Una brecha en la propia especificación regresa a ti como una decisión.

Observa el modo de falla que Microsoft llama verificación por ambiente. Una cláusula débil puede verificar mientras descarta casi nada. La protección es una revisión de mutación. La etapa de prueba planta un error por cláusula ensures en una copia de prueba del código, como rechazar a todos o revisar el nombre de usuario antes que el correo, y Verus tiene que rechazar cada copia alterada en la cláusula que apunta. Un mutante que pasa significa que esa cláusula no constriñe nada, y regresa como una brecha.

Resultado esperado: cada cláusula o está demostrada o está listada como una brecha con una razón. El ciclo es estricto sobre mover los postes de la meta. Si una construcción no puede declararse en la versión de Verus en uso, la tarea se detiene y pregunta al equipo. No cambia a una forma más simple ni suaviza un contrato para obtener un resultado verde.

Paso 7: Prueba el límite confiable como si fuera el producto

Acción: ejecuta las pruebas que el plan escribió para cada pieza confiable contra las partes reales, no contra simulaciones de ellas. Microsoft describe las entradas del plan como planificadas hasta que se ejecutan, después de lo cual registran el resultado del comando y el commit contra el que se ejecutaron. En el inicio de sesión, eso significa pruebas contra el bcrypt real, el esquema SQLite real y el router real.

Usa el mismo cuidado que usarías para trabajo de secretos. Nuestro tutorial sobre evitar que Claude Code filtre secretos a GitHub hace el mismo punto desde el otro lado: un resultado de herramienta es evidencia sobre las entradas que probó, y nada más. PDD Kit etiqueta una prueba que pasa de la misma manera. Evidencia, no prueba.

Resultado esperado: cada cláusula supuesta en el Paso 5 tiene al menos una prueba nombrada que la revisa, y el plan muestra esa prueba como ejecutada y pasada en un commit nombrado. Si una pieza confiable no tiene prueba, trata cada promesa que descansa en ella como una afirmación, no como un resultado. En el inicio de sesión, dos piezas llevan la mayor parte del peso: check_password para cada promesa de contraseña, y las dos búsquedas para cada promesa sobre qué cuenta nombra un token.

Paso 8: Entrégalo con pdd-ship y mantén la prueba en CI

Acción: deja que la etapa de prueba abra sus solicitudes de extracción, revisa la solicitud de extracción como un recibo, y fusiona. En el ejemplo de inicio de sesión, el cambio agregó una crate verificada con el flujo, sus piezas, sus pruebas y los envoltorios confiables con sus pruebas. También enrutó el manejador real de inicio de sesión mediante ese flujo y conservó los códigos de estado HTTP que la aplicación ya usaba. La lógica verificada endurece la ruta de producción. No es una copia conservada a un lado.

Luego ejecuta la etapa de entrega. El flujo pdd-ship agrega la revisión de Verus a CI junto a las pruebas para las partes confiables. Cada cambio posterior, por una persona o por un agente, debe seguir demostrando contra la misma especificación. Una prueba rota falla la compilación de la misma manera que una prueba fallida lo hace. Microsoft también señala un efecto secundario ordenado: las pruebas que solo repiten lo que la prueba ahora cubre pueden recortarse, mientras las pruebas que protegen el límite confiable permanecen. CI se vuelve más fuerte y más ligero al mismo tiempo.

Resultado esperado: la descripción de la solicitud de extracción marca cada requisito como verificado formalmente o revisado por pruebas. Tu revisión ya ocurrió en el artefacto de intención. No se te pide leer el código generado línea por línea, y deberías poder decir, para cualquier promesa en la lista, cuál de los dos tipos de evidencia la respalda.

Ejecutar varios agentes a la vez mientras este trabajo llega es una habilidad separada. Nuestra guía para ejecutar Claude Code, Codex y OpenCode con Corgi cubre el lado del espacio de trabajo de ese problema.

Verificación

Trabaja esta lista antes de llamar verificado al objetivo.

Primero, vuelve a ejecutar Verus en la crate verificada y lee la línea de resultados. Debería informar las funciones como verificadas con cero errores. Segundo, revisa el registro de mutación de la etapa de prueba. Cada cláusula ensures debería mostrar un mutante que Verus rechazó. Una cláusula sin registro de mutante no ha sido probada en fuerza. Tercero, abre el plan y confirma que cada pieza confiable del Paso 5 muestra una prueba que se ejecutó y pasó, con un commit nombrado junto a ella. Cuarto, rompe la prueba a propósito en una copia de prueba, cambiando una línea de lógica, y confirma que Verus falla en la cláusula que la cubre. Quinto, confirma que CI ejecuta la revisión de Verus en la rama, para que un cambio futuro que rompa la prueba falle antes de la fusión.

Si las cinco se cumplen, puedes declarar el resultado en la forma exacta que Microsoft usa para el inicio de sesión. Demostrado: las funciones nombradas cumplen sus contratos para cada entrada. Confiable y probado: los envoltorios nombrados están fuera de la prueba, cada uno detrás de un contrato que una persona aceptó y una prueba que lo revisa. Supuesto: la propia cadena de herramientas Verus, Rust y el solucionador, y la biblioteca estándar de Verus.

Solución de problemas

Próximos pasos

Elige la siguiente función sensible y repite el ciclo: una revisión de pago, una puerta de permiso o un analizador con reglas estrictas de entrada. Mantén cada objetivo pequeño. El hábito de prueba crece una función a la vez, y el límite confiable debería encogerse a medida que más código se mueve dentro de él.

Conserva el artefacto de intención con el código. Es el registro de lo que tu equipo quiso decir, qué promesa descansa en prueba y qué promesa descansa en una prueba y un nombre. Cuando el próximo agente llegue para cambiar esa función, ese registro es lo que lo detiene de reescribir en silencio el contrato mientras reescribe el código.

Datos verificados el 9 de noviembre de 2026, contra el relato de Microsoft Research de PDD Kit, la página del proyecto GitHub Next para PDD Kit, la guía de Verus y el archivo de instalación de Verus. Este tutorial sigue el flujo que esas fuentes documentan para el ejemplo de inicio de sesión de Pet Store y el archivo de muestra en la guía de Verus. No afirma que el flujo completo de PDD Kit se haya ejecutado dentro de Chopin para este artículo, porque PDD Kit es un prototipo de investigación y el acceso es limitado.

Fuentes

• El flujo de PDD Kit, la aplicación Pet Store, la solicitud de inicio de sesión de dos frases, las tarjetas de decisión, las ocho cláusulas, las seis piezas confiables, la revisión de mutación y la etapa de entrega: Formally verifying agent written full stack web apps with PDD Kit, Microsoft Research
• PDD Kit como un socio dentro de Chopin, el artefacto de intención y la ruta de especificación Verus: PDD Kit, GitHub Next
• La muestra getting_started.rs, la macro verus!, el código fantasma y la línea de resultados esperados: Verus Tutorial and Reference
• Orden de versión binaria, compilaciones de plataforma, el script de cuarentena de macOS y los avisos de cadena de herramientas: Verus INSTALL.md
• Diagrama de flujo y diagrama de límite de prueba: Microsoft Research, de la publicación de PDD Kit arriba. Arte del héroe y otras páginas: Dirty Static.