A YC startup open-sourced text-to-CAD — an embedded engineer called the V8 demo 'a lie'

What Adam actually built

CADAM is the open-source core of Adam (YC W25), a web app that turns natural-language prompts and images into 3D CAD models. The architecture is the interesting part: it uses the Claude API (with OpenAI and OpenRouter fallback) to generate OpenSCAD code, then compiles OpenSCAD to WebAssembly to render the model in-browser via Three.js and React Three Fiber. The backend runs on TanStack Start and Supabase; export targets are STL, SCAD and DXF, with the BOSL, BOSL2 and MCAD libraries available.

Two design choices stand out. The system parses the generated SCAD for adjustable dimensions and auto-builds interactive sliders — and a slider change does a deterministic regex edit on the source rather than calling the model again. One commenter questioned exactly that: "Why do you use regex for that? OpenSCAD allows you to pass data natively." The project is GPLv3, a licensing choice another reader asked the founder to explain.

The README leads with showpiece benchmarks generated from single prompts: a V8 engine with 22 adjustable dimensions, a 9-cylinder radial aircraft engine, a turbofan, and an axial turbine blisk.

'That's a lie. This isn't a CAD model.'

The demo reel is exactly where the thread's most credentialed skeptic struck. An engineer who works in hardware refused the framing outright:

"A complete V8 internal combustion engine — Yeah, no, that's a lie. This isn't a CAD model. It's a fantasy 3d model that looks like it's straight out of Gearhead Garage (1999)… Show me something functional that you've actually manufactured… something that can actually be assembled and isn't just a bunch of boxes with no fasteners to hold them together."

The complaint got an empirical backstop. A developer who tested it on a real component asked CADAM to model a specific part number, "AMF-O97L45-DB". It pulled the datasheet and generated something — wrong. He posted a side-by-side: wrong pitch, wrong pin positions, missing pins. A practicing mechanical engineer was categorical about the use case: "I can model that and know it's right much quicker than I can ask the AI to do it and then check its work. There is no time savings here."

The root cause everyone names: spatial reasoning

The critiques converged on a single limitation. A commenter who works with LLMs put the technical diagnosis plainly: "I find all current LLMs to have pretty poor spatial awareness… How are you dealing with that?" Another linked an OpenSCAD-LLM benchmark showing models are still weak at spatial reasoning, improving but not there. The question under all of it, from a commenter thinking about the long-term approach: is text-as-code even the right representation, or will world models eventually generate geometry directly?

The dissent inside the dissent

Not everyone piled on, and the praise is worth the same weight as the criticism because of who gave it. A contractor in Hamburg whose former employer was acquired by Anthropic — a self-described AI skeptic — was won over by the experience, not the demos:

"I'm pretty skeptical of AI products, but your onboarding and first design experience has been pretty awesome. I will definitely spend a bit more time experimenting with this."

That splits the verdict cleanly. As an onboarding-friendly toy for hobbyist 3D prints and parametric vases, Adam lands. As a tool a mechanical engineer would trust for a part going to a manufacturer, the thread's hardware people say it's nowhere close — and the gap isn't UI polish, it's that the model can't reason about whether the pins line up. The honest read: impressive demo, real product for the shallow end, and a spatial-reasoning ceiling that no amount of OpenSCAD plumbing fixes.