verified-3d-mesh-intersection Verifies 3D CSG

verified-3d-mesh-intersection is schildep’s open-source Lean 4 project for formally verified 3D constructive solid geometry, focused on mesh intersection. It deals with a nasty review question: when an AI writes the implementation and tens of thousands of proof lines, what should a human actually trust? The useful answer is small and sharp: review the 93-line formal spec, run the Lean checker, and treat the generated implementation as untrusted until the checker accepts it. For users of Cursor, Anysphere’s AI code editor, doing ai coding training for teams, it is a concrete way to implement code review habits for ai-generated code without pretending humans can read every generated line.

Read the spec before the generated code

Constructive solid geometry is a way to build 3D shapes by combining solids with operations like union, subtraction, and intersection. Mesh intersection is one of those operations, and it is the kind of code that gets unpleasant fast: edge cases, degenerate triangles, numerical choices, and output meshes that look fine until they do not.

The project’s claim is deliberately narrow. As of July 28, 2026, the repository is mainly Lean, MIT licensed, and describes a verified kernel for 3D mesh intersection. The spec pins down the surface of the result and checks practical well-formedness conditions for the triangulation.

That narrowness is the point. The verified part is the kernel, not every pixel in the demo or every line of glue code around it. Discussion around the project surfaced exactly that boundary: UI and conversion code can still have ordinary bugs, even when the mathematical kernel checks out.

The trap is reading “formally verified” as “the whole product cannot be wrong.” Formal verification buys you a contract for the thing you specified. It does not bless code outside the proof boundary.

Notice how small the trust boundary gets

The clever move is not that AI wrote a lot of code. The clever move is that humans are not asked to trust most of it.

The README frames the review surface as 93 lines of formal specification, instead of 1,000-plus lines of AI-written implementation and more than 60,000 lines of AI-written Lean proofs. Lean checks conformance at compile time. If the checker accepts the proof, the implementation satisfies the spec.

A formal spec is executable accountability for a claim about code. It is not a vibe, a prompt transcript, or a “looks reasonable” diff review.

This is why developers cared. It changes the review question from “Can I understand every generated branch?” to “Is this the right spec, and did the checker verify the implementation against it?” That is a much better question, especially when coding agents produce large diffs faster than reviewers can read them.

The trap is outsourcing judgment to the theorem prover. The spec can still encode the wrong intent. A reviewer still has to ask whether the spec describes the real operation the application needs.

Compare it with normal CSG review

The Hacker News reaction quickly went where geometry engineers always go: performance, floating point, and existing production libraries. That is the fair comparison. A verified exact-rational kernel is not automatically the thing you ship in a game loop.

Verdict: verified-3d-mesh-intersection wins when the kernel’s correctness is the thing you are studying or depending on. A mature production library wins when throughput, platform integration, and real-world workload coverage matter more. Raw AI-generated geometry code only wins for exploration, and it should graduate into tests, specs, or deletion before it becomes a dependency.

Try it when correctness beats raw throughput

The strongest objection is practical: many geometry systems eventually need hardware-accelerated floating point, not exact rational arithmetic. That objection is real. A proof over exact math may be beautiful and still not match the performance envelope of a renderer, CAD pipeline, or realtime editor.

So treat the project as a boundary lesson first, and a drop-in library only after testing your actual workload. It is a good fit when you want a reference kernel, a correctness oracle, or a small proof-backed component. It is probably overkill when you need fast approximate geometry in a UI-heavy path.

This is also where the related training topic becomes less abstract. Good ai coding governance is not “review more carefully.” It is choosing the right thing to review: the spec, the tests, the permission boundary, the generated diff, or the runtime behavior.

We saw a different version of that review choice in FeyNoBg Opens a Background Removal Library: for model-heavy code, the review target is often packaging, fixtures, and behavior. For verified geometry code, the review target can be a formal statement small enough to read in one sitting.

Copy this Cursor review checklist

Use this when you want to implement code review habits for ai-generated code in a repo that has a small trusted core and a larger generated surface. Keep it boring. Boring is reviewable.

# .cursor/rules/verified-kernel-review.mdc
---
description: Review AI-generated kernel code by checking the spec, proof boundary, and unverified glue before reading generated implementation details.
alwaysApply: false
---

When reviewing generated kernel code:

- Identify the trusted artifact first: spec, tests, proof, or golden fixture.
- State what is inside the trusted boundary and what is outside it.
- Do not approve generated implementation code because it looks plausible.
- For Lean or proof-backed code, review the formal specification before the proof body.
- Run the repository’s documented checker command locally.
- Record the commit SHA, checker result, and any assumptions about runtime glue.
- Review conversion, serialization, UI, MCP, and API boundary code normally.
- Ask for a small failing fixture when behavior is unclear.

A matching PR comment can be short:

Review receipt:

- Trusted artifact reviewed: 93-line formal spec
- Checker run: yes, using repo-documented command
- Generated implementation inspected deeply: no, treated as checked artifact
- Outside boundary reviewed normally: demo glue, data conversion, API calls
- Remaining risk: spec may not match product intent or performance target

This works nicely in Cursor because the rule gives the agent a review shape before it starts summarizing the diff. If the agent is also using an MCP server, keep that boundary explicit too: external data access does not make generated code more trustworthy.

Common questions

• What are the best ways to implement code review habits for ai-generated code?

  Start by shrinking the trusted surface. For verified-3d-mesh-intersection, that means reviewing the 93-line Lean spec and running the checker, not manually auditing more than 1,000 generated implementation lines. In ordinary repos, the equivalent artifact might be a test oracle, permission table, AGENTS.md rule, or small fixture suite.

• Does verified-3d-mesh-intersection prove the whole web demo is correct?

  No. The project’s formal claim is about the mesh intersection kernel, not every UI path or glue-code conversion around it. That distinction matters because a bug outside the verified boundary can still create bad output, even if the kernel itself satisfies the Lean specification.

• Is this useful if my production geometry code uses floating point?

  Yes, but mostly as a reference point or correctness oracle. The common concern is that exact verified arithmetic may not match hardware-accelerated floating-point performance. If your product path is realtime or heavily optimized, compare outputs and edge cases before treating the verified kernel as production-ready.

• Is this engineering team ai adoption or just a formal methods demo?

  It is both, if used carefully. The project is a formal methods demo for 3D CSG, but it also gives engineering team ai adoption a concrete review pattern: let agents generate large artifacts, then require a small human-reviewed contract and an independent checker before trust increases.

Best ways to use this research

• Best for: engineers evaluating agentic coding on correctness-heavy code, especially kernels, parsers, compilers, geometry, and financial logic.
• Best first artifact: a tiny reviewable contract. That might be a Lean spec, a property test, a golden fixture, or an AGENTS.md boundary that says what the agent may not change.
• Best comparison angle: compare review surface, not just output quality. A 93-line spec plus checker is a different object than a 1,000-line generated diff with passing smoke tests.
• Best Cursor move: add a scoped .mdc review rule for high-risk generated code, then ask the agent to produce a review receipt instead of a prose summary.
• Best limitation to remember: proof-backed code still depends on the spec being the right spec. The checker verifies conformance, not product intent.

Further reading

• verified-3d-mesh-intersection — source
• Lean — theorem prover and programming language
• Model Context Protocol — specification
• Cursor — Agent

Next step

Open one generated PR in Cursor and identify the smallest artifact you can actually trust. If there is no spec, fixture, checker, or boundary note, ask for that before asking for more code.

One methodology lens

One useful way to read this through our methodology is the Plan step: delegate first-pass decomposition and dependency mapping, review the sequencing and assumptions, and keep ownership of scope and priorities. If that split is still fuzzy, the workflow usually is too.