Verified 3D CSG: 93 Lines of Trust Beats 1000 Lines of AI Slop

The Story: Spec vs. Slop

A developer dropped a quietly explosive Show HN post: a formally verified 3D Constructive Solid Geometry (CSG) engine where the core mesh-intersection logic fits in 93 lines of specification. The counterpoint? An AI-generated attempt at the same problem sprawled across 1000+ lines and still got it wrong.

CSG is the computational backbone of parametric CAD, game level editors, and surgical simulation. You take two 3D solids—say, a cube and a sphere—and compute their union, intersection, or difference. The math is brutal: floating-point edge cases, coplanar face handling, and vertex-vertex near-misses that silently corrupt topology.

The author's approach is radical simplicity. Instead of generating imperative code that "does the thing," they wrote a declarative specification in a language called F*, then extracted a provably correct implementation. The spec describes what must be true about the output mesh, not how to compute it. The verifier ensures zero divergence.

The AI-generated version, produced by a capable LLM, looks plausible at first glance. It compiles. It passes a few hand-crafted test cases. But when you throw the fuzzed edge cases at it—overlapping faces, degenerate triangles, nearly-coincident vertices—it produces non-manifold garbage. The code is verbose, defensive, and wrong in ways that are invisible to a code review.

This isn't an AI-bashing post. It's a precision-trust calibration exercise. When the cost of failure is a corrupted mesh that silently breaks a downstream simulation, 93 verified lines beat 1000 plausible ones. Every time.

Why This Hits Different for Engineers and FDEs

Forward Deployed Engineers live at the intersection of prototype velocity and production reliability. You're the person who gets paged when the customer's CAD pipeline chokes on a model that worked fine in your dev environment. You've learned—probably the hard way—that "looks correct" is not a property you can bank on.

This CSG project surfaces three principles that map directly to the FDE skillset:

1. Trust is a Spec Property, Not a Test Property

You can't test your way into correctness for geometric algorithms. The input space is combinatorially explosive. Every vertex coordinate is a double. Every face normal is subject to floating-point rounding. A test suite of 100 hand-picked cases covers approximately 0% of the failure surface.

Formal verification flips the burden. The spec says: "For all inputs, the output mesh must be 2-manifold, watertight, and geometrically within epsilon of the exact result." The verifier proves it holds for all inputs. That's a fundamentally different category of confidence.

When you're debugging in a customer's environment without direct access, you don't have the luxury of running a fuzzer. You need to know the algorithm is correct by construction, so you can eliminate it as a variable and focus on the data pipeline, the coordinate transforms, or the export format.

2. Line Count is an Inverted Metric for Correctness

The AI-generated 1000-line version is what happens when you optimize for "looks like code I've seen before." It has helper functions, error handlers, edge-case branches, and comments explaining what each block does. It feels thorough.

The 93-line spec is what happens when you optimize for "cannot be wrong." Every line is a logical statement about the output. There's no room for off-by-one errors because there's no indexing. There's no accidental mutation because there's no state.

This is the same dynamic we see in the highest-leverage AI-era FDE skills: the ability to compress a problem to its essence is worth more than the ability to generate volume. Stakeholders don't pay for lines of code. They pay for guarantees.

3. AI-Generated Code Creates a Verification Debt Trap

The seductive thing about LLM-generated code is that it lowers the activation energy to "just try something." But every line of unverified generated code you ship becomes a liability you now own. The 1000-line CSG implementation isn't just wrong—it's confidently wrong. It will pass code review because the reviewer is pattern-matching against their mental model of "reasonable CSG code," and the LLM has perfectly replicated that pattern.

This is exactly the class of problem that OpenAI's Codex security rules are designed to catch: generated code that is syntactically valid, semantically plausible, and subtly dangerous.

The Formal Verification Litmus Test

Let's get concrete about what "formally verified" actually means in this project, because the term gets thrown around loosely.

The author uses F*, a dependently-typed programming language that compiles to OCaml (and from there to native code). F* lets you write specifications as types. If your function compiles, the specification holds.

Here's a simplified sketch of what a CSG intersection spec looks like in this style (not the actual 93 lines, but the shape of it):

// The spec says: for any two meshes a and b that are valid solids,
// the intersection mesh must be a valid solid AND its volume must
// equal the volume of the geometric intersection of a and b
let csg_intersection_spec (a: mesh) (b: mesh) (result: mesh) : prop =
  (is_valid_solid a /\ is_valid_solid b) ==> (
    is_valid_solid result /\
    volume result == geometric_intersection_volume a b
  )

// The implementation is extracted from a proof that this spec
// is realizable. The compiler guarantees no divergence.
let csg_intersection (a: mesh) (b: mesh) : Pure mesh
  (requires is_valid_solid a /\ is_valid_solid b)
  (ensures fun result -> is_valid_solid result /\ 
    volume result == geometric_intersection_volume a b)

The key word is Pure. It means this function has no side effects, no exceptions, no partiality. Given valid inputs, it will produce a valid output, and that output will satisfy the spec. Not "probably." Not "for the tested cases." Provably.

The 93 lines aren't the implementation. They're the specification from which the implementation is derived. The actual executable code is generated by the F* compiler's extraction mechanism, which erases the proof terms and leaves behind a correct-by-construction OCaml program.

This is a radically different development model from "write code, write tests, fix bugs, repeat." It's closer to "state the property you want, prove it's achievable, and let the compiler produce the artifact."

How to Actually Use This Today

The project is open-source and functional, but let's be honest about the on-ramp. You're not going to drop this into a production CAD pipeline in an afternoon. Here's the practical path:

Step 1: Clone and Build

git clone https://github.com/schildep/verified-3d-mesh-intersection
cd verified-3d-mesh-intersection
# Follow the README for F* and OCaml toolchain setup
make

The build produces a native binary that takes two mesh files and computes their CSG intersection. The output is guaranteed watertight if the inputs are valid solids.

Step 2: Understand the Trust Boundary

The verification guarantees correctness within the algorithm. It does not guarantee:

• That your input meshes are valid solids (you need separate validation)
• That the mesh file parser is bug-free (it's not part of the verified core)
• That floating-point rounding in the I/O layer doesn't introduce errors

The spec operates on an abstract representation. The trust boundary is the serialization layer. This is fine—it's the same pattern as verified crypto libraries where the math is proven correct but the wire format parsing is conventional.

Step 3: Integrate as a Correctness Oracle

The highest-leverage use case isn't replacing your existing CSG pipeline. It's using the verified implementation as an oracle for testing your production code. Run both on the same input, compare outputs, and flag divergences.

This is how aerospace and medical device shops use formal methods: not by formally verifying everything, but by maintaining a golden reference implementation that keeps the production code honest.

Step 4: Apply the Pattern Elsewhere

The meta-lesson is more valuable than the CSG algorithm itself. The pattern—write a tight spec, prove it, extract—applies to any algorithm where correctness matters more than feature velocity:

• Financial settlement logic
• Access control and authz rules
• Protocol state machines
• Data migration transforms

You don't need to learn F* to benefit from this mindset. Just asking "could I specify this in 20 lines of logic?" before writing 200 lines of code is a practice shift that pays dividends.

The Balanced Take: Where AI Still Wins

This post could read as "formal verification good, AI code bad." That's not the argument. The argument is about matching the tool to the risk profile.

AI-generated code is excellent for:

• Boilerplate that has no algorithmic content (CRUD endpoints, config parsing, data shape munging)
• Exploratory prototypes where failure is cheap and iteration speed matters
• Code where the test suite can realistically cover the input space (form validation, string formatting)
• Glue code between well-specified components

Formal verification is excellent for:

• Algorithms with combinatorial input spaces where testing is hopeless
• Code where a silent wrong answer is catastrophic
• Core invariants that the rest of the system depends on

These are complementary, not competing. The smartest teams I've seen use LLMs to generate the 80% of code that's low-risk plumbing, and reserve formal methods for the 20% that's high-risk algorithmic core. They don't ask an LLM to write a mesh intersection algorithm any more than they'd ask it to write a crypto primitive.

This maps directly to the FDE workflow. When you're building trust with non-technical stakeholders under pressure, you need to know which parts of your solution are provably sound and which parts are best-effort. Being able to say "the intersection algorithm is mathematically guaranteed correct" is a very different conversation from "we tested it on a bunch of models and it looked okay."

FAQ

Q: Is this ready for production use in a CAD pipeline?

A: As a standalone intersection engine, yes, with the caveat that you need to validate your inputs are well-formed solids. As a drop-in replacement for a full CSG pipeline (with union, difference, chamfer, fillet, etc.), it's a building block, not a complete solution. The intersection is the hardest operation to get right, which is why it was the focus of verification.

Q: Do I need to learn F to use this?*

A: To use the compiled binary, no. To modify the spec or extend it to other CSG operations, yes. F* has a steep learning curve. The value proposition is that one person climbs that curve once, and everyone else benefits from the verified artifact.

Q: How does this compare to CGAL or Manifold?

A: CGAL is a mature, battle-tested computational geometry library with extensive testing but no formal verification of its core algorithms. Manifold is a newer CSG library that prioritizes robustness through numeric techniques. This project is unique in providing a machine-checked proof of correctness. In practice, you might use CGAL for breadth of features and this project as a correctness oracle for the operations it covers.

Q: Could an AI generate a correct formal spec?

A: Current LLMs can produce plausible-looking F* or Coq code, but the proofs usually don't typecheck. The gap between "looks like a spec" and "is a valid proof that compiles" remains wide. This is an active research area—benchmarking coding agents beyond standard tests shows that formal proof generation is one of the hardest tasks for current models.

Q: What's the real-world failure mode this prevents?

A: Non-manifold output meshes. A mesh is non-manifold when it has edges shared by more than two faces, vertices that don't form a closed volume, or self-intersections. Downstream operations—rendering, finite element analysis, 3D printing slicers—either reject non-manifold meshes or produce silently wrong results. The verified spec guarantees 2-manifold output for all valid inputs, which eliminates an entire class of production incidents.