You may or may not be right, but your arguments sound like echos of what software developers were saying four or five years ago. And four or five years ago, they were right.
Don't dismiss an AI tool just because the first iterations aren't useful, it'll be iterated on faster than you can believe possible.
While LLMs are a useful tool for software development, if you try asking them the software equivalent of “Create a plastic enclosure sized to go under a desk, ok add a usb receptacle opening, ok add flanges with standard screw holes” you'll end up with the equivalent of “No the other side. No, not like that, at the bottom. Now make it 10mm from the other hole. No the other hole. No, up not sideways. Wait, which way is up? Never mind, I'll do it myself” a lot.
What works is asking them to implement micro feature that you will specify well enough at first try, not to ask them writing the entire piece of software from top to bottom. The tech is clearly not there yet for the latter.
The main difference between Code and CAD is that code is language you're writing to the machine to execute already, so it's pretty natural to just use a more abstract/natural language to ask it instead of the formal one of code, whereas CAD is a visual, almost physical task, and it's more pleasant to do a task than describe it in depth with words.
> Create a plastic enclosure sized to go under a desk, ok add a usb receptacle opening, ok add flanges with standard screw holes
With vague specifications like these, you'd get garbage from a human too.
What works for software, and I suspect for other technical fields like CAD too, is to treat it like a junior developer who has an extreme breadth of knowledge but not much depth. You will need to take care to clearly specify your requirements.
> With vague specifications like these, you'd get garbage from a human too.
You'll never have better input than this at the beginning of any project from the person that brings the use-case. That's a full job to help them define the needs more accurately. And if you always work with clear specifications it's just because there's someone in front of you that has helped write the spec starting from the loose business requirement.
> You will need to take care to clearly specify your requirements
Yes, but as I discussed above, for such tasks it's going to be very frustrating and less efficient than doing things by yourself. The only reason why you'd accept to go through this kind of effort for an intern is that because you expect him to learn and become autonomous at some point. With current tech, an LLM will forever remain as clueless as it started.
> You'll never have better input than this at the beginning of the project from the person that brings the use-case
That's as may be, but again, it's not much different to being a software developer.
Someone might ask you to create a website for their business. It's your job, as the expert, to use the available tools - including AI - to turn their requirements into working code. They might say "put a button for the shopping cart into the top right". It's then your job, as as the technical expert, to get that done. Even the laziest of devs wouldn't expect to just copy/paste that request into a AI tool and get a working result.
It takes time to learn to use these tools.
When I'm using AI to help me write code, depending on the complexity of what I'm working on, I generally write something very similar to what I'd write if I was asking other developers for help (although I can be much terser). I must specify the requirements very clearly and in technical language.
Usually I keep a basic prompt for every project that outlines the technical details, the project requirements, the tools and libraries being used, and so on. It's exactly the same information I'd need to document for another human working on the project (or for myself a year later) so there's no wasted work.
I've created (small, toy) transformers and also modeled injection molded parts in Solidworks.
There is a really big difference. It's obvious how programming languages can use tokens for an attention mechanism, which gives them excellent ability to have parallelized performance (versus RNNs, the prior way of relating tokens) with much broader ability to maintain coherence.
I don't know the parallel with brep. What are the tokens here? It's a fundamental architectural question.
But unlike four or five years ago for programming, when the attention mechanism was clear with transformers and the answer was, basically, just "scale it up", we don't even really know where to begin here. So assuming some magic is going to happen is optimistic.
It'd be exciting if we could figure it out. Maybe the answer is that we do away with brep and all tree based systems entirely (though I'm a little unclear how we maintain the mathematical precision of brep, especially with curves, which is necessary for machining -- your machinist is going to throw you out if you start giving them meshes, at least for precision work that has anything with a radius).