Benchmark: CadQuery vs. OpenSCAD for agentic CAD work

One of the things you get from studying CAD diagrams — like the Solidworks exercises everyone works through — is that real world parts often have surprisingly few dimensioned constraints. A lot more emerges from geometry.

So you can look at a diagram and initially think "where the heck does it define this radius!?" and find that it never needs to, because that radius emerges from tangency, parallelism, perpendicularity etc., combined with fewer measurement constraints.

Specifying it as a measurement would therefore be overconstraint; it might lead to solids that are difficult/impossible to manufacture or erroneous when another measurement is changed.

The diagram will specify the actual driving measurements that come from the part's purpose, with the intent to adapt to different real-world requirements.

Any CAD tool that works from images is going to have to approximate, which will create over-complex models with to many measurements that are more fragile with respect to changes, whereas a design that has geometrical constraints in place that are logical will be simpler and more adaptable.

With functional parts, roughly, form follows function first, and manufacturability second. But you have to understand why, to be able to make a good part. Even (perhaps especially) with 3D printing. But not uniquely. For example, would this tool be able to understand why the draft angles on a plastic part were important, what determines the bend radius of a part that was made from pressed metal, etc.?

I must stress that I am an amateur. But my amateur skills have come from reading and learning about CAD and learning what makes a viable design.

(Sorry… this was a stupidly long answer but I am hungry and I figured I should try to blurt it out before I have to get up from my desk and cook. I've edited it a lot and cut out a bit that I will probably put in another comment later)

If a non-CAD person imagines a part that they need, the chances are very high indeed that either it isn't what they need, can't be made robustly or sensibly, or if it is, it already exists in some meaningful way that can be adapted, because one of tens of millions of other people already wanted it.

This scenario — needing something very specific that can be described only in words and nobody else has ever needed before — is almost imaginary. Most stuff just isn't like that.

Now… if someone were to design an AI CAD package that could remix objects that exist and combine them, perhaps with a GUI tool that allowed a user to identify attachment points, maybe that would be interesting. But a lot of that has been solved in non-AI GUIs already.

Text-to-CAD just isn't as good an idea as it seems. You are not going to be able to magic up some novel invention from a text description without a significant amount of domain knowledge of the words needed to describe a part, and that domain knowledge usually comes from learning CAD!

(Bit like getting a coding agent to write really good code)

And simple parts, sorry, just don't need much CAD skill. Get a CAD package on a free plan, learn enough to make your thing. You will get so much more out of that and it will be easier to make changes. It'll probably have standard tools for adding threads, even.

Even image-to-CAD for a functional part requires a significant amount of understanding of what to photograph and from which angles, etc.

Could you do meaningful things without domain language you learned the long way?

I don't doubt it is coming along. But as with all of these things, this one is painted into a corner from the very start by using OpenSCAD.

And a mechanical engineer's job isn't just fiddling away in CAD, is it? If it was I would be on the way to being one by now, and I am not.