AI Wrote 60,000 Lines of Proofs So You Can Read 93

A Lean 4 project by Peter Schilde, verified-3d-mesh-intersection, uses AI agents to write over 1,000 lines of implementation and more than 60,000 lines of formal proofs, leaving humans to review only a 93-line specification. The project claims to be the first formally verified implementation of a constructive solid geometry operation on 3D meshes, with the Lean proof checker guaranteeing correctness. This methodology demo shows how AI-generated proofs, which are structurally impossible to hallucinate because the checker rejects errors, could make formal verification economically viable for the first time.

AI https://sourcefeed.dev/c/ai Article AI Wrote 60,000 Lines of Proofs So You Can Read 93 A formally verified CSG kernel in Lean 4 shows where trust in machine-written code actually lands. Priya Nair https://sourcefeed.dev/u/priya nair A Lean 4 https://lean-lang.org project that hit the Hacker News front page today makes an offer worth taking seriously: a 3D mesh-intersection kernel where AI agents wrote over 1,000 lines of implementation and more than 60,000 lines of formal proofs — and no human ever has to read any of it. What you review instead is a 93-line specification. The Lean proof checker does the rest. The project, verified-3d-mesh-intersection https://github.com/schildep/verified-3d-mesh-intersection by Peter Schilde, claims to be the first formally verified implementation of a constructive solid geometry operation on 3D meshes. The headline theorem is compact: solid meshIntersect M₁ M₂ = solid M₁ ∩ solid M₂ — the solid bounded by the output mesh is exactly the intersection of the input solids. A companion set of theorems guarantees the output is watertight, coherently oriented, and free of degenerate triangles and self-intersections. Everything rests on Lean's three standard axioms, nothing exotic. As a geometry library, it's a curiosity. As a methodology demo, it's the most concrete answer I've seen to the question every engineering org is currently arguing about: how do you trust code you didn't write and won't read? The economics just flipped Formal verification has been "the answer" to software correctness for forty years, and it never went mainstream for one reason: proofs are brutally expensive to write. The seL4 https://sel4.systems microkernel's initial functional-correctness proof consumed roughly eleven person-years for under 10,000 lines of C. CompCert, the verified C compiler, was a multi-year research program. The proof-to-code effort ratio ran around 20:1, which priced verification out of everything except microkernels, compilers, and crypto primitives like the HACL code inside Firefox. That ratio is what just changed. Schilde's proofs — all 60,000-plus lines — were written autonomously by AI agents Claude among them, per the project's own notes , iterating against the Lean checker until everything compiled. This follows an earlier 2D warm-up, verified-polygon-intersection https://github.com/schildep/verified-polygon-intersection , built the same way with an 87-line spec. Proof engineering, the thing that made verification economically absurd, turns out to be nearly ideal work for LLMs: the search space is large, human taste is irrelevant, and the ground truth signal is perfect. A proof either type-checks or it doesn't. Hallucination, the failure mode that makes AI-generated application code scary, is structurally impossible to ship — the kernel rejects it. The industry has noticed. Mistral released Leanstral https://mistral.ai/news/leanstral , an Apache-licensed agent model purpose-built for Lean 4 proof engineering, in March, and shipped a 1.5 version this month — explicitly pitched as a foundation for "trustworthy vibe-coding." AWS already maintains the formal model of its Cedar authorization language in Lean. The pieces for verification-as-a-harness are assembling fast. Where the trust actually went The pitch is "trust 93 lines, not 1,000," and the obvious rejoinder showed up in the HN thread within hours: how do you know the spec itself says the right thing? That's the correct question, because verification never eliminates trust — it relocates it. The honest accounting looks like this: The spec. 93 lines is genuinely reviewable, but reviewing it requires fluency in both Lean and the formal definition of "solid." A subtly wrong spec verifies a subtly wrong program with full mathematical confidence. Geometry is a good stress test here precisely because the edge cases — coplanar overlapping faces, vertices lying exactly on the other mesh's surface, collinear edges — are where informal implementations rot, and the spec forces every one of them to be handled. Vacuity. A spec with an unsatisfiable precondition proves everything and means nothing. The running WebAssembly demo, which intersects real meshes, is the practical defense: the theorems demonstrably apply to actual inputs. The unverified tail. Lean's kernel checks the proofs, but Lean 4's compiler — which lowers the verified functions to C, and here onward through emscripten to WASM — is not itself verified, and exact integer arithmetic bottoms out in GMP. The proof covers the mathematical semantics, not the binary. Closing that gap is what CompCert-style verified compilation exists for, and Lean doesn't have it yet. That's a real residue of trust. It's also a spectacular trade against the alternative, which is a human skimming 1,000 lines of generated C++ and typing "LGTM." Schilde makes the comparison concrete: an informal C++ implementation of the same algorithm exhibited three reproducible bugs despite passing unit tests. Tests sample the input space; the theorem quantifies over it. What you'd actually do with this Don't reach for this to replace your CSG stack. The kernel uses exact rational arithmetic and spends heavily on runtime well-formedness checks, and intersecting two 70,000-triangle Stanford bunnies takes 24 seconds single-threaded on an M4 Pro. Manifold https://github.com/elalish/manifold — the float-based engine now inside OpenSCAD — or CGAL's exact-predicate booleans will do that orders of magnitude faster. Commenters pushing for a floating-point version got a candid answer: possible, but only by admitting additional trusted axioms about float behavior, the approach the Flocq formalization takes. Verified-and-fast is a second research project. The near-term adoption path is narrower and more interesting. If you maintain something where a correctness bug is catastrophic — a geometry kernel feeding a CNC toolpath, an authorization engine, a settlement calculation, a parser on a trust boundary — the workflow this demonstrates is available today: write a small Lean spec, let an agent grind out implementation and proofs, and gate CI on lake build , which fails unless every theorem checks. Your review surface collapses from the diff to the spec. The skill that becomes scarce isn't reading generated code; it's writing specifications tight enough to be worth proving against — and that skill is closer to careful API design than to research mathematics. My read: the geometry library won't ship in anyone's CAD pipeline, and the "first verified CSG" claim will matter mostly as a citation. But the pattern is a genuine shift, not hype. For a decade, formal methods people insisted verification would go mainstream once writing proofs got cheap, and nobody believed them because it never did. AI agents made proofs cheap in about eighteen months. The bottleneck has moved to the 93 lines — and for the first time, that's a bottleneck a working engineer can actually clear. Sources & further reading - Formally verified 3D mesh intersection in Lean 4 https://github.com/schildep/verified-3d-mesh-intersection — github.com - Show HN: Formally verified 3D CSG: Trust 93 lines spec, not 1000 lines AI code https://news.ycombinator.com/item?id=49083239 — news.ycombinator.com - Formally verified polygon intersection https://github.com/schildep/verified-polygon-intersection — github.com - Leanstral: Open-source foundation for trustworthy vibe-coding https://mistral.ai/news/leanstral — mistral.ai Priya Nair https://sourcefeed.dev/u/priya nair · AI & Developer Experience Writer Priya covers AI frameworks, developer productivity tooling, and the startup ecosystem across South and Southeast Asia, bringing a researcher's rigour and a practitioner's empathy to every story. She is deeply sceptical of benchmarks and asks hard questions so her readers don't have to. Discussion 0 No comments yet Be the first to weigh in.