If you have heard that "AI can now design CAD" and filed it under hype, CADAM is worth a real look. It is an open-source Text-to-CAD tool that turns plain English into OpenSCAD code and a 3D model you can actually open, slice, and 3D-print. The thing that decides whether it works for your team is not the demo video — it is whether the OpenSCAD it emits is code your team can read and edit.
This page is for the engineer or maker who is evaluating an AI CAD tool and needs to know, before committing a workflow to it, what CADAM produces, where it fits, and how to check the output without trusting a slick render. The short answer: treat the generated .scad file as the deliverable, not the picture, and judge the tool by how editable that file is.
What CADAM actually is
CADAM is an open-source project from Adam (YC W25), launched on Hacker News as "Open-Source AI CAD." It is a React app (TanStack Start) with a Supabase backend for auth, database, and file storage, and you can run the hosted version at adam.new/cadam or read the source at github.com/Adam-CAD/CADAM. The founders frame it around two bets: that AI becomes the primary medium for mechanical design the way it already is in software, and that the right paradigm for CAD generation is CAD as code — text becomes code, code becomes geometry.
That "as code" detail is the whole point. Many AI design tools hand you a mesh or a proprietary file and call it done. CADAM instead generates OpenSCAD, a scripting language where a model is described by a program. Per the project description, it produces parametric 3D models from natural-language prompts (and image references), automatically extracts parameters that surface as interactive sliders for instant dimension tweaks, and exports to .STL or .SCAD plus OBJ, GLB/GLTF, FBX, and DXF.
If you have never touched OpenSCAD: it is a free, code-driven CAD modeler. Instead of dragging shapes, you write something like cube([20,20,5]) and the geometry follows. That matters here because a program is diffable, reviewable, and version-controllable — three things a binary mesh is not.
The direct answer: editability is the real test
The demo will look great. AI demos always do. The question that actually predicts your outcome is narrower: can a human on your team open the generated OpenSCAD and change it correctly?
This is the same lesson the AI-assisted UI world already learned. A generated React screen is only useful if a developer can drop into the component, understand it, and modify it without rewriting from scratch. The screenshot is not the deliverable — the editable source is. CADAM applies that exact frame to mechanical design: the render is the demo, the .scad file is the deliverable.
So when you evaluate it, do not score the 3D preview. Score the code behind it.
| What you are tempted to judge | What you should judge instead |
|---|---|
| The 3D render looks right | The .scad source is readable by your team |
| It exported an STL | The parameters are named and adjustable |
| The prompt "just worked" | A wrong dimension is fixable in code, not re-prompted |
| It looks parametric | Changing one slider doesn't break unrelated geometry |
The left column is what a demo optimizes for. The right column is what a workflow survives on. In practice, the gap between them is where AI CAD either becomes a tool or stays a toy — if the only way to fix a 2mm error is to re-roll the whole prompt and hope, you do not have a CAD tool, you have a slot machine.
This checklist turns AI UI 작업은 수정 가능한 코드에서 갈린다 into visible pass/fail points, but the evidence in the article remains the source of truth.
Worked example: reproduce it on a small input
Here is a small, reversible test you can run to judge editability rather than vibes. The goal is not a complex part — it is to see whether the generated code is something you would let into a repo.
Scenario. You need a simple parametric spacer: a flat washer-like disc with a center hole, where the outer diameter and hole diameter must be adjustable later.
Input prompt.
A flat circular spacer, 30 mm outer diameter, 5 mm thick,
with a 10 mm diameter hole through the center.
Command / config. Generate in CADAM at adam.new/cadam, then export the .SCAD file. To verify it locally, install OpenSCAD and render headlessly:
# macOS
brew install --cask openscad
# Render the generated file to an STL without opening the GUI
openscad -o spacer.stl spacer.scad
Expected output. A .scad file whose structure makes the dimensions obvious and editable — something close to this in spirit:
outer_d = 30; // outer diameter (mm)
hole_d = 10; // center hole diameter (mm)
height = 5; // thickness (mm)
difference() {
cylinder(h = height, d = outer_d, $fn = 64);
cylinder(h = height + 1, d = hole_d, $fn = 64);
}
Common failure. Watch for code that hard-codes magic numbers inline (cylinder(h=5, d=30) with no named variable), a center hole that does not fully pierce the body because the cutting cylinder is the exact same height (a classic OpenSCAD z-fighting artifact — note the height + 1 above that avoids it), or "parameters" that exist as sliders in the UI but are not actually wired into the geometry.
How to verify. Change outer_d from 30 to 40 directly in the file, re-run the openscad -o command, and confirm the disc grows while the hole stays put. If editing one named variable produces the change you expect, the tool passed the only test that matters. If you have to go back and re-prompt to resize a hole, it failed — regardless of how good the first render looked.
These are reproduction steps, not measured benchmarks; the point is the editability check, and the exact generated code will vary per run.
Where it fits, and where it does not
CADAM is a strong fit when the part is geometrically describable in words and you want a parametric starting point you can refine in code: brackets, spacers, enclosures, mounting plates, simple fixtures. The OpenSCAD output drops naturally into a Git-backed workflow, and the slider-extracted parameters give non-coders a safe surface to tweak dimensions.
It is a weaker fit when the design depends on tolerances, fits, and constraints that a sentence cannot capture — press-fit bearings, threaded interfaces, sealing surfaces, or anything where a 0.1mm error means the part is scrap. For those, the generated code is a first draft to be corrected by an engineer, not a final part. And because OpenSCAD is constructive-solid-geometry by nature, organic or freeform surfaces (ergonomic grips, swept aero shapes) are not its strength.
A quick comparison of the export formats helps you decide what to do with the result:
| Format | Editable as code | Best use |
|---|---|---|
.SCAD |
Yes | Keep the source, edit, version-control |
.STL |
No (mesh) | Send to a slicer / 3D printer |
OBJ / GLB / GLTF / FBX |
No (mesh) | Visualization, rendering, game/AR pipelines |
DXF |
Partial (2D) | 2D profiles for laser cutting / CAD import |
The takeaway from the table is simple: only the .SCAD is a living source. Everything else is a snapshot. If your plan is to iterate, the .scad file is the one you commit; the meshes are throwaway outputs you regenerate.
Production caveats before you commit a workflow
A few things to check before you let an AI CAD tool into a real pipeline. First, review the code, not the picture— geometry that renders fine can still be structurally wrong (non-manifold edges, walls thinner than your printer can produce). Second, minddata and auth boundaries: the hosted version uses a Supabase backend, so confirm where your prompts and files live before you upload anything proprietary; running the open-source repo yourself keeps designs local. Third, treat the first generation as areversible draft — keep it in a branch, render it, physically test or simulate a fit before trusting it. The verification points are the same as any AI-assisted output: check the source, run a small reversible test, and separate what you proved from what you are assuming.
FAQ
When should I use CADAM? When you want a parametric, code-based starting point for a mechanical part that is describable in words — brackets, spacers, enclosures, plates — and you intend to refine the OpenSCAD afterward. It is less suited to high-tolerance assemblies or organic freeform shapes.
What should I check before applying it in production? Whether the generated OpenSCAD is readable and editable by your team, where your prompts and files are stored (hosted Supabase vs. self-hosted repo), and whether the part's real tolerances can survive a description-only first draft. Always keep the first generation reversible.
What is the easiest way to verify the result? Export the .SCAD, change one named parameter directly in the file, re-render with openscad -o out.stl file.scad, and confirm the change is correct and localized. If editing code produces the expected geometry, the tool is doing its job; if you must re-prompt to make a small fix, it is not.
Sources and checks
Verified on: 2026-06-19
| Claim | Evidence | How to verify | Limit |
|---|---|---|---|
| AI UI 작업은 수정 가능한 코드에서 갈린다 should be checked against the original source before reuse. | github.com | Check the source page, version, date, and setup notes. | Source content can change after this article is published. |
| AI UI 작업은 수정 가능한 코드에서 갈린다 should be checked against the original source before reuse. | adam.new | Check the source page, version, date, and setup notes. | Source content can change after this article is published. |
| AI UI 작업은 수정 가능한 코드에서 갈린다 should be checked against the original source before reuse. | youtube.com | Check the source page, version, date, and setup notes. | Source content can change after this article is published. |
| AI UI 작업은 수정 가능한 코드에서 갈린다 should be checked against the original source before reuse. | adam.new | Check the source page, version, date, and setup notes. | Source content can change after this article is published. |
| Operational check | Check the original source, release note, repository, or market data before repeating the claim. | Reproduce on a small input and record input, output, and environment. | A local test does not prove every production path. |
| Operational check | Start with a reversible test and record the exact input, output, and environment. | Reproduce on a small input and record input, output, and environment. | A local test does not prove every production path. |
| Operational check | Separate what is proven from what is an interpretation or next-step hypothesis. | Reproduce on a small input and record input, output, and environment. | A local test does not prove every production path. |
🐦 Faster updates on X: @baegseungh7061
📚 More in this series: All posts
💌 Subscribe: Follow on X or grab the RSS
댓글
댓글 쓰기