Mistral Leanstral 1.5 baja la barrera de verificación formal: agentes que prueban código, no solo escriben tests

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:

1. una prueba que compila;
2. un contraejemplo o propiedad violada que pueda revisarse;
3. 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.

Demanda y ángulo competitivo

La demanda se infiere por fuentes oficiales, repo de Hugging Face, discusión técnica y búsquedas probables como Leanstral 1.5, Lean LSP MCP, formal verification agents, Lean 4 code verification, agentes verificacion formal. No hay tooling SEO conectado, así que no invento volumen.

Agente IA puede competir porque la conversación en español casi siempre se queda en "modelos para programar" o "tests generados". Leanstral abre otra pregunta: cuándo vale la pena pedirle a un agente que demuestre una propiedad en vez de solo escribir un test más.

Si estás construyendo tu primera base de agentes, empieza por el curso gratis. La lectura corta: Leanstral 1.5 no vuelve fácil la verificación formal, pero sí la acerca al workflow real de agentes que editan, ejecutan y revisan evidencia.