Ask an AI to make you a 3D model and, depending on the service you use, the results can be genuinely decent at best and utterly awful at worst. The tools made to turn text into 3D models that have floated around for a few years often make a vaguely correct sculpture that looks fine in a preview but doesn't actually work on a geometric level. It may not have clean dimensions, it might not be editable, and half the time it might not even be a geometrically valid object.

The better way to do this doesn't involve generating a shape at all, as language models are bad at picturing objects in space. However, they're quite good at writing code, so instead of asking for a model, you ask for a program that builds one. The model writes a script, the script produces the geometry, and you get a part with real measurements that you can actually change.

I spent some time doing exactly that, designing 3D printable parts with Claude Opus 4.8 and GPT-5.5. I had both models create OpenSCAD files, comparing the outputs at the end to see what was accurate, what wasn't accurate, and if the model would even theoretically print. It works surprisingly well... but it's also wrong a lot, and sometimes in ways that look mostly fine until you stop and think about them.

LLMs can't picture a 3D shape, but they can write the code for one

It gets you started

OpenSCAD is a programming language for 3D shapes. You describe a part in code, with variables like wall = 2 or angle = 65, and it compiles that into a 3D object. That suits a language model perfectly, because a design becomes a text file it can write, read, and edit like any other program.

The beauty of it is that everything stays parametric. You can change a number near the top of the file and the part resizes around it, which means you can hand the model a real measurement and have the design rebuild itself to match. If you design a holder for a 66mm device, it becomes a holder for a 90mm one by editing a single line.

What makes this work is an actual loop: Claude Code writes a .scad file, runs OpenSCAD from the command line to render it to a PNG, and then looks at that image. It can see its own output, notice that a wall is in the wrong place or a hole missed its mark, rewrite the code, and render again. The same command exports a finished STL once the picture looks right.

If you ask for a one-shot model, you get a confident guess, but if you force the write, render, look, fix cycle, you get something that's at least verified somewhat. It won't be perfect, as we'll get to, but it's surprisingly powerful. In all three instances, GPT-5.5 was much faster, but the actual results were pretty close.

Asking both models to build a phone stand

A pretty hilarious failure from GPT-5.5 to kick things off

I started with a simple request: both models were told to make a parametric desk phone stand for an 8 to 12mm cased phone, reclined 65 to 70 degrees, stable, with a cable channel to the bottom port, and printable flat without supports. Both were told to render, look, fix, and export an STL.

In this instance, Claude did less but still got it right. It drew a single 2D side profile, extruded it, cut the cable channel, and crucially stood the part upright with an explicit rotation, leaving a comment noting which axis was which. Its renders showed exactly what you would want to see, with an upright wedge, a flat base sitting on the plate, a triangular buttress behind it, and the cable channel running cleanly through the lip. The exported STL was tidy too, at 42 vertices and 84 faces.

GPT-5.5 did far more and, well, built the wrong object. It wrote genuine centre-of-mass maths with mass estimates and printed a stability check to the console. It even built a separate verification rig, a translucent "ghost phone" and a red "ghost cable", to prove to me that the phone seated properly when I pointed it out. Its profile was arguably the more sophisticated of the two, with chamfered edges and a rear heel buttress. However, the phone was... not seated properly at all.

GPT-5.5 never rotated the part upright, so the whole stand was extruded lying on its side, with the 88mm height running flat across the plate. It cut the cable channel in the wrong plane, put the USB-C cutout on the wrong side of the lip, and its ghost phone floated up and to the left, passing straight through the back support without ever touching the rest face. It rendered that image, its own proof that everything lined up, and confidently stated that it was correct.

A case for an ESP32-based board turned it into a test of research

A good starting point for your own build

The phone stand was free-form, so nothing stopped the models inventing their own measurements. The next job had to fit something real, so I pointed both at a ReSpeaker XVF3800, a circular USB microphone array, and asked for a two-part enclosure. This time I made the brief force each model to research the board itself, finding its real diameter, the four microphone positions, and the port locations, and to state them with sources before modelling anything. That way, a failure could be pinned on either bad research or bad geometry.

They failed in opposite directions, which was the interesting part. Claude got the outline right at 99mm, matching the published spec, but invented the microphone ring, placing the acoustic holes at a 35mm radius when the real one is 46.67mm. Its holes would have ended up around 12mm too far in, sitting over the PCB instead of the mics. GPT-5.5 did the reverse, as it pulled the real microphone coordinates straight out of the board's own beamformer config, placing every hole at the correct radius and angle, and it even downloaded the official STEP CAD file.

Unfortunately, OpenSCAD can't read STEP, so GPT-5.5 ended up scraping the numbers out of a Python snippet from the Seeed wiki, and then it sized the whole shell to 108mm. For reference, the board has a 99mm diameter, though this goes to 103mm from the ESP32's USB-C port to the bottom. Still, the 46.67mm radius for the microphones appear to be accurate (if not close to accurate), and the reasoning to get to that was pretty clever. From the OpenSCAD file:

AEC_MIC_ARRAY_GEO: [0.033,-0.033,0], [0.033,0.033,0], [-0.033,0.033,0], [-0.033,-0.033,0]. Used mic radius sqrt(33^2+33^2)=46.67 mm at angles 315, 45, 135, 225 degrees.

Overall, it was pretty good research, it's just that GPT-5.5 started with the wrong base number for the dimensions. To be fair, Seeed's own store page also says 108mm x 108mm, so it's not totally the fault of the model.

The buttons are worth a mention, too. Left to their own devices, both models put the buttons on top, when the real ones are pressed from the sides. Claude's were the worse of the two, with both on the same side and set too far in, while GPT-5.5 at least had them on the correct opposite edges. I then asked GPT-5.5 how you would reach the buttons from the side, and mentioned they looked like they should sit flush to the edge. I didn't show it a photo or tell it what to build, and it worked out the side-window fix on its own. I didn't try the same test with Claude, but it's a good sign that if you wanted to design a model through iteration using an LLM, you absolutely could.

The desk holder passed every check, except for one problem

"It should not tip under normal button presses"

The last job was a desk cradle for a Zooz ZEN37, a small Z-Wave remote, and it's a similar angled cradle to the phone holder. Again, GPT-5.5 won the research element, but it lost when it came to actually designing the part. It found the real published dimensions, 66mm x 35.6mm x 12.7mm, in Zooz's own FAQ, and sensibly ignored the larger mounting-plate and wall-plate figures listed next to them.

Then it built a cradle the remote would fall straight out the back of.

The rails meant to hold the device sat just outside its width, so there was nothing behind the remote's back face, and a unit leaning at 65 degrees would simply rotate backward and drop between them. Its anti-tip rib, the one feature meant to keep things steady, was modelled floating 2mm above the base as a separate, disconnected piece that would have fallen off the print bed. Best of all, the export reported a clean manifold solid with no errors, because each of the two disconnected lumps were watertight on their own.

Claude completely failed at the research part, but it built a working part with placeholder values. It insisted, flatly, that Zooz doesn't publish dimensions at all, when they're sitting in that same FAQ, and built around a guessed 90mm x 40mm x 16mm, roughly 24mm too long. However, the geometry at least held up, with a single connected body and a solid full-width backrest for the remote to lean into. It's the right structure at the wrong size, against the other model's right size in the wrong structure.

All three builds suffered from similar issues: a model can write valid code, render a preview that looks perfectly seated, pass a manifold check, and still hand you a part that ignores gravity... or euclidean geometry in general.

Each model produced a good starting point

Nobody would actually design a model completely hands off like this

What I found most interesting about this test was that it proved a hypothesis I've had for a while: models aren't typically going to one-shot a CAD design, but with more interactive guidance, they can probably do a lot more than you'd expect. I could have used my callipers to collect all of the measurements myself, and I could have even made a basic sketch of the dimensions in Onshape or something, but I gave a very barebones prompt to both Opus 4.8 and GPT-5.5. Even still, across all three rounds, both managed to be decently impressive. What I did here was not what a normal person would do, and it was artificially limiting, but that's why it was arguably more impressive.

For example, GPT-5.5 consistently did the more impressive research, gathering real coordinates, even downloading an official CAD file, and writing notes as it went. I had thought that the harness may play a part when it comes to research, as I'm using GPT-5.5 in Pi with my own SearXNG instance, yet it still did better on research than Claude did. Unfortunately, it kept producing parts that didn't physically work. On the opposite side, Claude tended to write cleaner geometry that held together, and seemed to understand the actual geometry better than GPT-5.5 did, but it also didn't research the actual dimensions effectively. Neither managed to do the research and the physical reasoning well in the same pass.

What would get every part over the line was a more proactive human in the loop; for example, the ReSpeaker buttons were fixed because I noticed they were incorrect, and it only took a light prompt to GPT-5.5 where I stated that the buttons should be flush to the side that it figured out they were oriented incorrectly and put in the wrong place. For simple parametric parts, this is genuinely good, and faster than learning a CAD package from scratch. I went from a prompt to printable STLs of a phone stand, a mic-array case, and a remote cradle in just a few minutes, and they're not far off of being parts that I'd happily send to my 3D printer.

Like with anything else and LLMs, the output is only as good as the human making the judgment. You need to know the real dimensions, read every render as if you're trying to break it, and keep in mind that "no errors" and "won't fall over" aren't quite the same thing.