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

verified-3d-mesh-intersection is Peter Schilde’s open-source Lean 4 project for a formally verified 3D constructive solid geometry operation: mesh intersection. It deals with a hard review question: when an agent writes the implementation and a mountain of proofs, what should a human actually trust? The answer is not to reread every generated line; it is to shrink the trusted surface, inspect the specification, run the checker, and test the unverified boundary code. For ai coding training for teams, it is a crisp example of how to implement code review habits for ai-generated code without pretending humans can audit everything.

A formal specification is a precise statement of what software must do, written in a language that a proof checker can validate against an implementation. In this repo, the headline number is the hook: trust 93 lines of spec instead of 1,000-plus lines of AI-written implementation and more than 60,000 lines of AI-written Lean proofs.

Read the claim before admiring the trick

The project claims a verified kernel for mesh intersection, not a verified product end to end. That distinction matters.

Constructive solid geometry, or CSG, builds shapes by combining simpler solids with operations such as union, subtraction, and intersection. Mesh intersection is one of those operations: given two triangulated surfaces, compute the surface where the resulting solid should be.

Schilde’s repo says the Lean 4 implementation is checked against a concise formal spec that pins down the resulting mesh surface and guarantees practical well-formedness conditions on the triangulation. As of July 2026, the repository is mainly Lean, MIT licensed, and small enough in public attention to still feel like a Show HN discovery rather than infrastructure everyone already depends on.

The interesting part for Codex, OpenAI’s coding agent, is the review model. The human does not need to trust the LLM that wrote implementation code. The human needs to trust the spec, the Lean checker, and the assumption that the code being called in production is really the verified kernel.

That last assumption is where bugs like to hide. The project discussion surfaced a real boundary lesson: the kernel can be verified while UI and glue code remain ordinary software, with ordinary overflow and conversion problems.

Compare the trust models, not just the code size

The project landed because it makes an uncomfortable point politely: reviewing AI code line by line does not scale when the agent can produce more code than the reviewer can reasonably understand.

The comparison is not formal methods versus tests forever. It is about choosing where trust should sit for a specific kind of code.

Verdict: verified code wins when the correctness property is narrow, expensive to review manually, and worth specifying. Conventional tested libraries win when performance, hardware behavior, and ecosystem maturity matter more than a proof. Ordinary agent PR review still wins for most application work, but it needs tighter guardrails than vibes and green tests.

This is also why the floating-point objection is fair. Many production geometry pipelines need hardware-accelerated floating point and brutal performance. A proof over exact rationals or a carefully modeled kernel may be valuable without being a drop-in replacement for every CAD, game, or Blender pipeline.

Try the project where the boundary is small

This repo is worth trying when you can isolate a small kernel and say exactly what correct means. Geometry is a good candidate because tiny errors can create broken meshes, holes, and non-manifold surfaces.

It is overkill when the behavior is mostly product judgment, UI state, or fast-changing business logic. Formal verification makes you pay upfront in specification work. If the requirement changes every other day, the spec becomes another moving target.

For Codex users, the practical move is to borrow the shape of the review. Put durable repo rules in AGENTS.md. Keep task prompts about the task. Use Codex to generate code, but make the acceptance path executable: a checker, a test, a linter, or a small proof obligation.

A minimal repo note might look like this:

# AGENTS.md

- Treat formally checked specs as the review gate for verified kernel changes.
- Review the specification and unverified boundary code before generated implementation details.
- For mesh operations, include tests at the exact-rational boundary and at any float or serialization boundary.
- MCP tools that read issue trackers, meshes, or docs are read-only unless the task explicitly asks for a write.

That MCP line is not decoration. Model Context Protocol, the open protocol introduced by Anthropic for connecting models to tools and data, is powerful precisely because it gives agents reach. A verified kernel does not help if the agent can silently swap inputs, call the wrong wrapper, or write results through an unreviewed path.

If you want a deeper companion note on the same project, see verified-3d-mesh-intersection Proves 3D CSG. For the broader review and guardrail theme, keep the related training topic nearby.

Use this review checklist before trusting the output

Copy this when you experiment with the repo, or when you adapt the idea to your own Codex workflow.

## AI-generated verified-code review checklist

- [ ] Identify the trusted kernel. Name the exact module or function that is supposed to be verified.
- [ ] Read the spec first. If the spec is unclear, do not approve the implementation.
- [ ] Run the checker from a clean checkout.

      gh repo clone schildep/verified-3d-mesh-intersection
      cd verified-3d-mesh-intersection
      lake build

- [ ] Confirm the production path calls the checked kernel, not a demo wrapper or stale build artifact.
- [ ] Review all unverified boundary code: parsing, float conversion, rational conversion, serialization, UI glue, and overflow handling.
- [ ] Add one regression test that crosses the boundary where real callers enter the verified code.
- [ ] Ask Codex for a handoff receipt: changed files, proof/check command, known unverified code, and remaining risks.
- [ ] Do not review 60,000 generated proof lines unless the checker fails or the spec itself is suspicious.

This is the practical answer to what are the best ways to implement code review habits for ai-generated code? Move review attention from generated volume to trusted contracts, reproducible verification, and the messy edge where verified and unverified code meet.

Codex, Anysphere’s AI code editor, and Codex can both work inside this kind of loop. The tool is less important than the receipt: what changed, what checked it, and what remains outside the proof.

Common questions

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

  The best way is to review smaller trusted artifacts instead of every generated line. In this project, that means reading a 93-line specification, running the Lean checker, and inspecting unverified boundary code such as UI glue, numeric conversion, and serialization. Green tests help, but they should not replace a clear contract.

• Is the whole web demo formally verified?

  No, the claim is about the mesh-intersection kernel, not the entire web demo or every caller around it. That caveat is important because a verified kernel can still be misused by unverified glue code. One reported issue involved boundary conversion behavior, which is exactly where reviewers should keep looking.

• Does this solve floating-point geometry performance?

  No, not by itself. The project is compelling because it verifies a correctness-critical kernel, but production geometry systems often depend on hardware floating point, performance tuning, and large compatibility test suites. The honest read is that formal verification reduces one class of risk while leaving performance and integration tradeoffs alive.

• Should I use this instead of a production CSG library?

  Use it as a serious research artifact and a review-pattern example before treating it as a production replacement. Mature CSG libraries may win on speed, integration, and real-world test coverage. verified-3d-mesh-intersection wins when you need to study or trust a narrowly specified mesh-intersection kernel.

Best ways to use this research

• Best for: correctness-critical kernels where the behavior can be stated in a short spec and checked automatically.
• Best first artifact: an AGENTS.md rule that tells Codex what must be verified, what must be manually reviewed, and what boundary code is out of scope.
• Best comparison angle: formal verification versus test-heavy production code, not formal verification versus no discipline.
• Best caution: do not confuse verified core logic with verified end-to-end behavior. The wrapper can still break the promise.
• Best next experiment: ask an agent to write a handoff receipt after lake build, then review only the spec, command output, and boundary list.

Further reading

• verified-3d-mesh-intersection — source
• OpenAI Codex — docs
• Model Context Protocol — specification
• Codex — Agent
• Lean — documentation

Try the smallest proof-shaped review

Pick one agent-generated change this week and ask what the smallest trustworthy artifact would be: a spec, a test, a type check, a proof, or a boundary receipt. Then make Codex produce that artifact before you read the diff.

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.