What it means is that a good CAD model is not just sticking stuff together in 3D space. Parametric flow means that a small number of measurements ripple through the design, and sketches and solids adapt. To do this right, it's easier to just understand the purpose and intent of the model, how it was manufactured, and draw from there.
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)
Astra does that. I've fed it STLs, told it to inspect, make a model for it, derive 'conceptual' measurements (e.g. - there were USB type A sized slots in one design, it recognized those, and knew not to change that, but only let it be swapped out for type C slots), and make parameters for everything that is relevant (that's pretty much the level of detail I gave it). It distinguishes 'implementation detail' from 'conceptual measurement' and implements the model in terms of those 'conceptual measurements'. As always, with OpenSCAD (well CSG in general) the problem is bevels/chamfers/fillets, so it needed some instructions to look for those and not mistake geometry stemming from them for 'real' measurements. It does that too, now.
And yes, telling it 'add draft angles to make this castable' works.
Then you are not actually getting a model with a constraint system at all. Which is the point of the thing I'm replying to.
CAD constraints are more powerful and flexible than OpenSCAD, and the power comes from analysis of what the part is actually for, not merely what it looks like.
You can't even compel OpenSCAD to keep a line and an arc tangent. If hull() can't do it, you're making it up yourself with maths.
Wait.. Al this started with you saying Ai can't design cad that is useful. Does that mean you consider openscad not capable of doing anything that is "useful"?
It's a slight overstatement, maybe. But in the general case the answer to your question is yes. I believe OpenSCAD is absolutely not the right tool for functional parts. It has fundamental weaknesses.
You can use it for basic shapes and very simple geometry. But you can use Tinkercad for that too.
Should you use it for CAD generally: I think not. Because complexity balloons out of control. An AI is going to struggle as much as a human does with a complex part in OpenSCAD.
All the text-to-CAD packages are relying on it because there's lots of simple examples in the training set, and because it is declarative — there's a belief that there is a mapping from text to declarative spec and from declarative spec to an object.
But it is the wrong choice for flexible designs that adapt correctly when measurements are changed.
It's clear to me that "AI CAD" developers who think OpenSCAD is adequate to the task have a fundamental misapprehension of the capabilities of the technologies they are actually seeking to replace. OpenSCAD is not representative of the nature or capabilities of modern CAD.
I think that if you are trying to make an adaptable functional part you would be better to start from CAD drawings, with proper constraints on them, and that an AI CAD package should be interacting with those (there are some attempts to do just that).
It's just not that difficult in a modern CAD package, it's not arcane or obscure.
But if you're going to be using code-CAD, you want a programming package that can represent fundamental aspects properly. OpenSCAD cannot.
CadQuery, to be fair to the authors of this post, does now have an experimental 2D constraint solver:
And it has a proper bRep kernel, so it can represent vertexes, edges, arcs and faces in mathematically abstracted (not mesh approximated) forms, and do operations on those (including fillets, though it has its weaknesses there inherited from OpenCascade).
I think an AI that could operate properly on CadQuery models and implement appropriate sketch constraints with an awareness of their implications, choose the right operations, make use of libraries, etc., would be a lot more capable. But it's so much further down the line than people think based on these OpenSCAD toys that produce trivial parts.
I'm a Onshape person myself, and try to contsain every thing in a way you describe. Including variables to quickly change important parts of the drawing.
But I also 100% believe half my designs could be done with tinkercad. And this be useful for me.
Last thing I designed and printed was a vacuum hose adapter. Ai cad could have done that. Including variables with sliders for size in both ends.
The Spark feature's UI isn't as good as the others.
For example, I'm not sure if it should prominently show recent workload, and unless I use MCP to manipulate files on my computer, local file manipulation isn't possible. Personally, I don't think it's going to be that useful.
Works correctly in opencode, but seems like they inject a system prompt:
Thinking:
> The user is asking what model I am. According to my system prompt, I'm powered by "deepseek-flash" with model ID "opencode-go/deepseek-flash".
>I'm powered by the model opencode-go/deepseek-flash.
The new meta model is fast and very cheap as well, and when used through OpenCode you get quite a lot of free tokens. But meta is also THE surveillance company, so probably also not a good choice in your case.
Is it? You're still putting a lot of thought and guidance into the agent's harness, the final code is just a tiny bit of that. It's like giving a junior developer final code vs explaining the whys and nuance. Which I'm not sure I want to give Meta
If someone shows me a picture of a haircut, or a dress and asked me if it would look good on them, I can't imagine it. My mind does not work like that. I just can't visually see it.
There's no way to win in that situation anyway - if you said "yes I think it'd look great!" and then they went and got their hair cut to match your suggestion but didn't like it, is it your fault for saying "yes"?
reply