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

verified-3d-mesh-intersection is schildep's open-source Lean 4 project for a formally verified 3D mesh intersection kernel. It deals with a very practical question: can you trust a complex AI-written geometry algorithm without reading every generated line? The answer is yes, sometimes, if the thing you review is a small formal spec and the thing you run is an independent checker. That is also a clean way to implement code review habits for ai-generated code without turning every review into archaeology.

The project is small enough to read, but weird enough to matter. For ai coding training for teams, it is a better example than another toy CRUD app because it puts pressure on a real failure mode: generated code that looks plausible and is painful to inspect.

Read the spec before the generated code

The headline claim is wonderfully blunt: trust 93 lines of spec, not 1,000+ lines of AI-written implementation.

Formal verification is a way to prove that code satisfies a precise specification using a proof checker, rather than relying only on tests or human review. Here the proof checker is Lean 4, and the domain is 3D constructive solid geometry, or CSG. CSG builds shapes by combining solids with operations such as union, subtraction, and intersection.

The repository says the verified part is the kernel for mesh intersection. The spec pins down the surface of the resulting mesh and checks useful well-formedness properties of the triangulation. As of July 28, 2026, the GitHub repo showed 69 stars, an MIT license, and mostly Lean code.

The neat part is the review shape. A human reads the spec. Lean checks the implementation and proofs. The AI-generated proof volume can be huge, reported at more than 60,000 lines, but the reviewer does not need to admire it by hand.

Do not stretch the claim. The web demo and glue code are not the formally verified kernel. One reported issue involved overflow while converting exact rationals through glue code, not a failure of the verified core.

Notice what Hacker News cared about

Developers cared because geometry code is famously good at producing bugs that look like geometry. A mesh intersection can leave holes, corrupt topology, or pass a visual smoke test while breaking later operations.

The project also lands in the middle of the agentic coding debate. If a coding agent writes a thousand lines, normal review gets tired fast. If the agent writes code plus proofs against a small contract, the review target changes.

That is the real move. It does not make the model trustworthy. It makes the model less relevant to trust.

The trap is to call this a general answer to AI code review. It is not. It works best where the core behavior can be specified tightly and checked mechanically. Many application changes are messier than that.

Take the floating-point objection seriously

The strongest objection is not philosophical. It is performance and numerics.

Many production geometry systems need hardware-accelerated floating point. This project works with exact mathematical objects in the verified kernel. That is attractive for correctness, but it can be too slow or awkward for some real-time workflows.

That does not make the project academic dust. It means the boundary matters. A verified exact kernel can be the right place to establish truth, generate test cases, or handle high-value operations. A fast floating-point implementation may still win in an editor loop, game engine, or renderer path.

The boring engineering answer is the honest one. Use the verified kernel where corruption is expensive. Use fast approximate code where latency is the product.

Compare review strategies, not vibes

The interesting comparison is not Lean versus AI. It is which artifact a reviewer is being asked to trust.

Verdict: the spec-and-checker path wins when correctness can be stated compactly and failure is expensive. Normal implementation review wins when the behavior is product-shaped, underspecified, or mostly about integration. Hand-reviewing generated proofs is the wrong trophy; the checker is there so you do not have to.

Try the idea safely in a real repo

You do not need to port your app to Lean tomorrow. The useful takeaway is smaller: make the trusted artifact shorter than the generated artifact.

In Claude Code, Anthropic's coding agent, that can look like a spec-first review boundary. Ask the agent to implement freely, but require a short contract and a repeatable check before a reviewer looks at the diff. A concise CLAUDE.md note can say which files define contracts and which command proves or tests them.

Use this when a change has a crisp invariant. Parser round-trips, authorization rules, billing math, serialization formats, migration safety checks, and geometry kernels are good candidates. It is overkill for copy changes, UI layout tweaks, and exploratory refactors.

Here is a lightweight review receipt you can copy. It is deliberately not a grand process.

## Spec-first review receipt

Change: <short name>

Trusted contract:
- [ ] The contract is under 120 lines.
- [ ] It defines the behavior, not the implementation strategy.
- [ ] It names the boundary: kernel, adapter, UI, migration, or API.

Independent check:
- [ ] The checker command is documented.
- [ ] The command runs from a clean checkout.
- [ ] CI runs the same command, or the PR explains why not.

AI-written code:
- [ ] Generated implementation can be treated as replaceable.
- [ ] Reviewer is not expected to read generated proof/code volume line by line.
- [ ] Any unverified glue code is listed separately.

Claude Code boundary:
- [ ] The agent may edit implementation files.
- [ ] The agent may propose spec changes, but a human reviews them first.
- [ ] A hook or pre-merge check runs the verifier/test command before review.

Decision:
- [ ] Merge because the contract is right and the check passes.
- [ ] Block because the contract is vague, too large, or bypassed.

This is one practical answer to what are the best ways to implement code review habits for ai-generated code? Start with the smallest artifact a human can genuinely understand, then make the machine prove or test the larger artifact against it.

If your repo uses integrations through the Model Context Protocol, keep write access boring while the contract is in flux. Let the agent read issue context, docs, and test failures. Do not let it silently rewrite the trusted spec through an unchecked path.

For another angle on the same project, see verified-3d-mesh-intersection Verifies 3D CSG. For the broader review habit, keep it near the related training topic, not buried in one heroic PR.

Common questions

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

  The best habit is to review a short contract before reviewing generated implementation. In this project, that means about 93 lines of Lean specification, then an independent Lean check over much larger AI-written code and proofs. The caveat is important: the habit works only when the contract is precise enough to be meaningful.

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

  No. The verified claim is about the mesh intersection kernel, not every layer around it. UI code, conversion code, and demo glue can still have ordinary bugs. That boundary matters because a correct kernel can still be fed bad inputs or displayed through broken adapter code.

• Is formal verification practical for everyday agentic coding?

  Sometimes, but not everywhere. It is practical when the risky part is small, stable, and easy to specify. It is usually not practical for broad product behavior, fast-moving UI work, or features where the real question is what users want rather than whether an invariant holds.

• Should I use this pattern in ai coding training for teams?

  Yes, as a case study, not as a mandate. It teaches a strong instinct: make agents produce checkable evidence, not just plausible diffs. The concrete artifact can be a formal spec, a property test, a migration invariant, or a small review receipt like the one above.

• How does this compare with fast production geometry libraries?

  It solves a different problem. A production geometry library may prioritize speed, hardware-friendly floats, and broad integration. This project prioritizes a verified correctness contract for one kernel. The right comparison is not glamour; it is whether your current risk is corruption, latency, integration cost, or developer time.

Best ways to use this research

• Best for: critical kernels where a compact contract can describe correctness better than a long implementation review can.
• Best first artifact: a spec-first review receipt that separates the trusted contract, the checker command, and the unverified glue code.
• Best comparison angle: compare review surfaces. Ninety-three spec lines are reviewable in a way that thousands of generated implementation or proof lines are not.
• Best Claude Code habit: let the agent generate implementation and tests, but protect the contract behind human review and a pre-merge hook.
• Best Claude comparison: Claude, Anysphere's AI code editor, also pushes agent workflows toward reviewable checkpoints; the useful question is still what artifact you trust.

Further reading

• verified-3d-mesh-intersection — source
• Lean — documentation
• Claude Code — hooks
• Model Context Protocol — specification
• Claude — Agent

Next step

Pick one generated-code review from this week and ask a blunt question: what is the smallest contract we could have reviewed instead? If the answer is clear, write that contract before asking the agent for the next implementation.

One methodology lens

One useful way to read this through our methodology is the Design step: delegate option mapping and pattern exploration, review the interfaces and tradeoffs, and keep ownership of architecture and contracts. If that split is still fuzzy, the workflow usually is too.