Mistral Leanstral 1.5 baja la barrera de verificación formal: agentes que prueban código, no solo escriben tests
TL;DR
Mistral lanzó Leanstral 1.5 el 2 de julio de 2026 con 119B parámetros totales, 6B activos y licencia Apache 2.0. La señal para builders es práctica: formal verification empieza a entrar al loop agentic con Lean, MCP y Vibe.
Por qué importa
Esta nota se enfoca en la decisión práctica para builders: qué cambia, qué riesgo agrega y cómo aplicarlo sin romper operación.
Mistral lanzó Leanstral 1.5 el 2 de julio de 2026 y el ángulo más interesante para builders no es "otro modelo open source". Es que un modelo especializado en Lean 4 empieza a empujar la verificación formal hacia un loop más parecido al de un agente de coding: editar archivos, correr comandos, leer feedback del compilador y persistir durante tareas largas.
Según Mistral, Leanstral 1.5 tiene 119B parámetros totales, cerca de 6B activos, licencia Apache 2.0 y disponibilidad vía Hugging Face y API gratuita como leanstral-1-5. La model card de Mistral lo presenta como modelo optimizado para automated theorem proving y autoformalization, con contexto de 256k.
La novedad no es matemática abstracta
El riesgo de cubrir Leanstral es hacerlo sonar como noticia para matemáticos y nada más. Pero el post de Mistral trae una pista más práctica: en su entorno de code agent, el modelo opera sobre un filesystem, edita archivos, corre bash y usa el Lean language server para inspeccionar metas, errores y tipos.
Eso se parece mucho más a un coding agent que a un benchmark estático. La diferencia es que el output no es solo un diff o un test que pasa. El objetivo es una prueba que el compilador de Lean puede verificar.
Mistral reporta 100% en miniF2F, 587 de 672 problemas de PutnamBench con presupuesto alto, nuevos resultados en FATE-H y FATE-X, y mejoras en FLTEval. Más importante para ingeniería: probó un pipeline donde Aeneas traduce Rust a Lean, Leanstral infiere propiedades y luego intenta probarlas o probar su negación.
Por qué esto debería importarle a un equipo de software
La mayoría de equipos no va a migrar mañana todo su backend a Lean. Pero sí hay áreas donde una prueba formal empieza a pagar:
- parsers y serialización;
- criptografía y encoding;
- librerías con overflow o invariantes delicados;
- contratos de datos que no deberían romperse;
- algoritmos donde un test de ejemplo no cubre el espacio real.
Mistral dice que, en 57 repositorios probados, el pipeline marcó propiedades violadas y encontró bugs reales, incluyendo varios no reportados antes. Eso no reemplaza tests, fuzzing ni revisión humana. Sí sugiere que los agentes pueden empezar a usar formal methods como otra herramienta de validación, no como ceremonia académica.
Cómo lo probaría sin vender humo
No empezaría con "verifica toda la app". Empezaría con un módulo pequeño, estable y crítico. Por ejemplo: una función de encoding, un parser, una regla financiera o una estructura de datos con invariantes claros.
Después definiría tres salidas aceptables:
- una prueba que compila;
- un contraejemplo o propiedad violada que pueda revisarse;
- un reporte explícito de bloqueo cuando falta especificación.
También separaría el rol del agente. Leanstral puede ayudar a escribir pruebas y explorar propiedades, pero una persona sigue teniendo que decidir si la propiedad representa el comportamiento correcto. Probar formalmente una especificación equivocada solo vuelve más elegante el error.
Artículos relacionados
Sigue explorando Modelos IA y otras lecturas para builders.
GLM-5.2 aterriza con 1M de contexto: por qué los agentes de coding open source ya no compiten solo por precio
GLM 5.2 llega a Vercel AI Gateway con 1M de contexto: útil para agentes largos, peligroso si lo usas como basurero
SageMaker mete multi-turn RL para agentes: como afinar modelos pequenos contra tareas reales y no solo contra prompts sueltos
