Say it, Print it

I want to be upfront, I went into this experiment with low expectations. Not because I doubt AI tools — I use them all the time — but because what I was trying to do felt like a weird edge case.

I wanted to use Claude Code to write OpenSCAD, a programming language for building 3D objects in code. No drag-and-drop, no visual modeling. Just pure, parametric geometry defined in text. Would Claude even understand it well enough to be useful? Could I describe a physical object in plain words and end up with something printable?

Five prompts later, I had a soap holder ready to print. A couple of sessions later, I had something I'd genuinely be happy to keep in the office shower. And I hadn't typed a single line of OpenSCAD myself.

Here's how it went.

The "Challenge"

Our office has a small shower with a narrow ledge around the pan — just wide enough for a soap holder. I wanted something simple: a tray that sits on the ledge, holds a bar of soap, drains properly, and survives daily humidity.

Straightforward enough. The interesting constraint I gave myself: I'd design the whole thing in OpenSCAD, using Claude Code, and I wouldn't touch the code myself. Not to edit it, not to fix a typo, not even to adjust a number. Everything would go through natural language conversation with Claude Code.

Why OpenSCAD specifically? A few reasons. It's free and open-source. It produces clean, parametric models that are easy to modify — if you want to change the width of something, you change a variable, not drag a handle around. And honestly, I was curious whether an AI assistant would be comfortable in a relatively niche programming environment that isn't Python or JavaScript.

Session One: Five Prompts to a Printable Object

I started simple. I described the ledge, gave rough dimensions — 100×70mm, about 20mm tall — and asked Claude to build a basic tray. The first result wasn't perfect, but it was a valid OpenSCAD file that rendered correctly. That alone was more than I expected.

From there it was a conversation. The second prompt was about drainage holes — I wanted them centered between the ribs automatically, not just scattered across the base. Small thing, but it showed the code was actually structured, not just hacked together.

The third prompt is where it got interesting. I asked for a double bottom — a sealed channel under the perforated floor, with a side opening so water drains out rather than pools. Claude redesigned the base as three distinct layers and adjusted the overall height to keep a full soap cavity above the drainage chamber.

Then I asked for a slope. The channel floor should tilt slightly toward the drain opening so water actually flows out instead of sitting there. Claude added a wedge module — a hull ramp that rises 4mm from the drain side to the far end. Simple idea, clean implementation. That's what impressed me the most!

By prompt five I had something genuinely interesting. Not just a box — a tray with a real drainage system, raised ribs to keep the soap out of the water, and a sloped internal floor. I exported the STL and sent it to my Prusa.

A few days later, it was in the shower. It worked.

Session Two: Iteration, Bugs, and a Drain Spout

A few weeks of use pointed to two obvious improvements. First, a holder for a small shampoo bottle on the back side of the tray. Second, a proper spout so water draining out of the channel doesn't just run down the outside of the holder and onto the floor.

I opened a new Claude Code session, pointed it at the existing file, and started describing what I wanted.

The bottle holder came together quickly — a new compartment attached to the back wall, full length of the tray, open at the top. But then came the first real bump. There was a gap between the bottle holder floor and the soap tray's drainage ramp. The two sections weren't connected — water would drop down at the junction instead of flowing through. I described the problem, Claude extended the ramp geometry to span both sections continuously, and the gap closed. One extra prompt.

The spout needed a few passes — a stray geometry artifact, a floor gap, a wall angle — the usual friction of translating a mental picture into 3D. Each fix was a sentence. That's the difference.

The final session ended with a cleanup pass: I asked Claude to reorganize the parameters section, group variables by module, and add proper comments. The code went from functional-but-scrappy to something I'd actually want to share.

What This Actually Tells Us

I want to be careful here, because it's easy to turn a small experiment like this into a sweeping claim about AI replacing engineers or whatever. That's not what happened, and it's not what I think.

What I observed is more specific: Claude Code has a genuinely solid grasp of OpenSCAD's syntax and design patterns. It knows how to structure parametric models. It handles iterative modification well — it doesn't just rewrite everything from scratch each time, it makes surgical changes. And it communicates clearly about what it's doing, which makes it easy to catch mistakes before they become wasted print time.

The limiting factor isn't the AI. It's me. I still had to know what I wanted. I had to describe proportions and constraints clearly enough to be actionable. When something came out slightly wrong, I had to look at the preview and diagnose what needed to change. The AI is a very fast, very capable pair of hands — but the thinking about what to build, and why, and whether the result is actually right for the context, that's still entirely human.

There were a couple of moments where Claude produced something syntactically valid but geometrically a bit off — an angle that looked fine in the abstract but would have made the holder tip forward on the ledge. I caught it, described the issue, it fixed it. That back-and-forth is normal and expected. The workflow handles it gracefully.

What's Next

I've put the whole project on GitHub — both OpenSCAD files, and the actual Claude Code chat transcripts from both sessions. If you're curious what the conversation looked like, or you want to adapt the design for your own shower ledge, it's all there.

The obvious next step is to try something more complex. The soap holder was a good first test because it's forgiving — if the proportions are slightly off, you just describe the fix and reprint. I want to try something where the tolerances matter more: an enclosure for electronics, maybe, or a clip-on mount for something specific. Cases where the geometry has to be right within a millimeter or two, not just approximately right.

I'm also curious about the limits of description. With the soap holder, I could visualize what I wanted and describe it fairly precisely. With more complex geometries — internal threads, interlocking parts, living hinges — I wonder how much you need to understand the underlying math to describe it well enough. That's the experiment I want to run next.

If you've tried Claude Code (or any AI assistant) for parametric CAD work, I'd love to hear how it went. The comment section exists, allegedly.