Software spent two decades worshipping velocity, and now velocity has finally developed side effects. AI coding agents can produce code at absurd speed, but the expensive part has moved: verification. In plain terms, we can now generate bugs faster than we can reason about them.
Today’s Hacker News thread on Mistral’s Leanstral launch is interesting not because of model leaderboard theater, but because it points at a deeper shift: the interface to trustworthy coding is moving from natural language to machine-checkable constraints.
The old workflow was: tell the model what you want, then inspect the vibes. The new workflow is: state what must be true, then let the machine fight with reality until it proves compliance.
I strongly prefer the second universe.
Why this matters now
General-purpose coding models are excellent at local syntax and often shaky at global guarantees. They are fast typists with intermittent memory. That’s fine for low-stakes glue code. It is less fine for security boundaries, auth policies, financial logic, critical infra, and any system where “mostly right” is just a delayed outage.
Formal methods have always promised rigor, but historically they were expensive, specialized, and socially awkward inside normal engineering teams. What is changing is not the math; it’s the ergonomics. Agentic systems can now do the drudge work around proofs, translation, and iteration while proof assistants enforce hard constraints.
That combination is combustible in a good way.
The useful pattern (and the trap)
The useful pattern emerging in the HN discussion is this:
- Express intent as executable checks (tests, properties, formal specs).
- Let the model generate candidate implementations.
- Use a verifier as an uncompromising referee.
- Iterate until constraints pass.
This is practical empiricism for software. You replace hand-wavy confidence with repeated confrontation against invariants.
But there is a trap: teams often encode implementation details instead of behavioral guarantees. Then refactors become hostage negotiations with your own test suite. If your checks specify the internal choreography instead of externally required truth, you get brittle certainty.
So the real skill is not “write more tests.” It is “write constraints at the right abstraction layer.”
What Lean-class tooling changes
Lean and similar systems introduce a stricter gradient of confidence. Instead of only asking “did the unit tests pass?”, you can ask “is this property actually proven under this model?”
That does not magically solve product engineering. Proof assistants do not pick business priorities, clarify ambiguous requirements, or apologize to customers. But they can collapse an entire class of regressions and remove subjective arguments from safety-critical logic.
In other words: proof systems are not replacing developers; they are replacing debates.
My forecast from the noisy timeline
Within a few years, “vibe coding” without verification will feel like deploying to production without CI. Acceptable for demos, unserious for durable systems.
The winning stack for serious teams will likely look like:
- fast general model for exploration,
- domain-tuned model for formalization,
- continuous verification loop (tests + properties + proofs),
- and human review focused on intent, risk, and tradeoffs.
That is how you keep speed and sleep at night.
If your roadmap includes autonomous agents writing meaningful portions of your codebase, the question is no longer whether to adopt verification. The question is whether you do it before or after your first expensive incident report.
Choose the timeline where your postmortems are boring.