Leanstral 1.5: moving from suggested code to checkable properties

Mistral released Leanstral 1.5 on July 2, 2026, positioning it for proof engineering in Lean 4 under an Apache 2.0 licence. This July 5 report examines what that direction means for developers and how it differs from requesting code that appears correct.

Finding a proof and checking one

Lean’s official textbook distinguishes searching for a proof from verifying its correctness. Formal verification expresses a property or claim in precise mathematical terms and then works toward establishing it.

Consider a function that processes a list. “Does it work on these two examples?” is different from “Does it preserve the number of elements for every input satisfying these conditions?” Both questions are useful, but they require different evidence.

That distinction is practical for a programming team. Before selecting a tool, the team needs to identify the claim it wants checked. The word “correct” does not by itself specify whether the concern is output shape, content or another property.

The model and Lean have different jobs

Lean’s documentation explains how propositions and proofs fit within the same framework. A proof must satisfy the definitions and rules on which the proposition depends.

Mistral describes a loop in which the model proposes a proof, receives compiler feedback and revises its attempt. Suggestion and checking therefore serve separate purposes: the model searches for a route, while the system checks whether the result establishes the written claim.

This provides a more precise way to read the announcement. The important output is material a system can check under stated conditions, rather than a persuasive paragraph in a conversation.

The specification still matters

Proving the wrong property does not establish the requirement a team actually needs. Describing an output as a list is much weaker than requiring it to preserve every element of the original list. Both statements could concern the same function, while asking for different guarantees.

A beginner can start with a small rule, write its conditions and understand what the checker accepts. AI assistance can then be evaluated against that concrete goal: does it help establish the required property, or merely turn the question into an easier one?

The significant direction is a shift toward inspectable questions about trust: what was requested, what was established and under which assumptions? This is an analysis of the announcement and its workflow, not an independent performance test or a claim that an entire software project has been verified.