Microsoft Research demostró un login escrito por IA para toda entrada; lo que no demostró es la lección
PDD Kit convierte la petición de un desarrollador en una especificación formal, hace que los agentes escriban el código y las pruebas, y etiqueta lo que queda probado pero no demostrado.
Escuche este artículo · 4 min
Narración completa del artículo, generada con IA.
Un desarrollador pide algo sencillo: que los usuarios inicien sesión con una contraseña y reciban un token que caduque al cabo de un día. Dos frases. En el nuevo experimento de Microsoft Research, esas dos frases se convirtieron en ocho condiciones formales que el código de login debe cumplir para toda entrada posible, y un agente de IA escribió tanto el código como la demostración matemática de que así es.
El proyecto se llama PDD Kit y viene del Catalyst Lab de Microsoft Research, GitHub Next y el grupo RiSE. Es un prototipo de investigación, y sus autores lo dicen. Aun así es la imagen más clara hasta ahora de cómo podría ser la comprobación de código escrito por IA cuando las pruebas no bastan.
Cómo funciona
PDD Kit usa Verus, una herramienta de verificación para Rust. El equipo lo demostró en Pet Store, una tienda full-stack en Rust de unas 5.000 líneas dentro del proyecto Chopin de GitHub Next, y se centró en la lógica de login.
- Planificar
- Especificar
- Poner a prueba la especificación
- Demostrar
- Publicar
Dos decisiones de diseño destacan.
La comprobación de mutación aborda un problema que los autores llaman vibe verification: una especificación tan débil que casi cualquier código la satisface. Al introducir un error por cada condición y confirmar que la demostración falla, PDD Kit pone a prueba la especificación misma.
La frontera de confianza es explícita. Hay piezas que no se pueden demostrar y se marcan como de confianza, y el desarrollador las aprueba una por una. Para el flujo de login eran seis. Las pruebas que pasan se etiquetan como evidencia, no como demostración.
La parte honesta
Los autores enumeran lo que PDD Kit no puede demostrar, y esa lista es lo más útil del artículo para cualquiera que ejecute código generado por IA en producción:
- las bibliotecas de terceros, como los crates bcrypt, sqlx y jsonwebtoken;
- los hechos sobre el mundo exterior, como lo que hay en la base de datos SQLite o lo que marca el reloj;
- si una operación termina, o cuánto tarda; una consulta asíncrona que se cuelga no incumple ninguna condición;
- los requisitos que nadie escribió.
También dicen que la comprobación de contraseña y dos búsquedas, las piezas que cargan con la mayor parte del peso de seguridad, están probadas pero no demostradas. Y las demostraciones siguen exigiendo un esfuerzo real, sobre todo en producir la demostración misma. Hoy solo funciona para Rust.
Qué tomar de un prototipo
Pocas empresas ejecutarán Verus sobre su sistema de gestión de pedidos el año que viene. Pero el hábito que impone PDD Kit es transferible ya, y ataca el problema que describimos en cuando la capacidad de verificación se convierte en el cuello de botella: los agentes abaratan el código y comprobarlo no.
Escriba la intención antes del código. La petición de dos frases se convirtió en ocho condiciones porque un agente hizo preguntas. La mayoría de las sesiones de codificación con IA se saltan ese paso, y quien revisa después tiene que adivinar qué se suponía que hacía el código.
Ponga a prueba las pruebas. Las pruebas de mutación tienen décadas y se usan poco. Si los agentes escriben tanto el código como las pruebas, una comprobación de que las pruebas pueden fallar de verdad es la protección más barata contra pruebas que no demuestran nada.
Mantenga una lista de confianza. Para cada componente escrito por IA, registre qué se demostró, qué se probó y qué simplemente se da por bueno, con el nombre de una persona junto a cada elemento de confianza. Eso es lo que parece la prueba desde fuera del modelo en una revisión de código: no la certeza, sino un relato claro de dónde acaba la certeza.