All the dimensions are in mm by default, so 39 mm radius on a mug is about right. For all their flaws, the LLMs do usually provide reasonable dimensions.
That's fair, it just bothers me when examples are like "a block with two holes in it" and sure the result is a block with two holes, but when are you going to want that without having those two holes in very specific spots at a specific size? lol
The conversation itself is sent to the LLM in regular text, and in addition it sees the feature tree (also text) and often a screenshot of whatever the current model looks like. This is usually enough for the model to know what's going on.
Yes - we're likely looking into other 3D systems in the future.
Every time you put in a query, LAD takes a snapshot of the current model and stores it, so you can revert whatever changes the LLM makes if it messes up.
I think that would make a lot of sense for non-CAD images, but the particular task you described there is do-able in just a few clicks in most CAD systems already. I think the AI would almost always take a longer time to do those kinds of actions than if you did it yourself.
Would you use something like this if it worked well in Fusion 360? We chose to start with SolidWorks because when talking with people in mechanical engineering, almost everyone was using SolidWorks and no one even mentioned Fusion (despite online surveys saying it's like 45/45).
The people who use Solidworks buy Solidworks to use Solidworks. You'll go up to one of them and they'll have the whole model done in like 8 key presses before you even finish typing in your prompt.
All the people who aren't professional CAD users have Fusion, which they can get for free. They would probably benefit the most from text to model AI, but would probably also be the least willing to pay.
Fusion doesn't have the needed tools to large machine designs with multiple components. They have only just added the ability to have assemblies where the parts are separately defined in their own files. Without that, it is only suitable for small, low parts count, one off projects.
Thanks for the input! Haven't done much with Altium but it seems like you get at least somewhat of a boost for it being slightly more about the logic and less about the spatial reasoning.
2 things related to what you said I hadn't put in the original post:
1. In our experience, the LLMs were awful at taking actions directly with any of the SolidWorks API scripting formats (C#, VBA, etc.). Probably 75% of what they wrote just failed to run, and even when they had access to browse the documentation it wasn't much better. If you're getting Opus or anything else to interact with SolidWorks from the CLI, can you say more about how you're getting it to interface effectively?
2. The LLMs are indeed surprisingly bad at spatial reasoning unless prompted specifically and individually. The most notable case of this is when they need to choose the right plane to sketch on. When creating revolve features, they'll often choose the face that would've only worked if they were going to extrude rather than revolve, and when creating sweeps they'll often try to put the sketch that's going to be swept on the same plane as the path that's being swept. If you go back and ask them why they did that and point out that it's wrong, they can fix it pretty fast, but when left to their own devices they often get quite stuck on this.
> If you're getting Opus or anything else to interact with SolidWorks from the CLI, can you say more about how you're getting it to interface effectively?
I just have a Solidworks plugin that translates CLI calls to JSON to Solidworks API calls and back again.
What really started working was creating a bunch of high level CLI commands so that Claude Code could query the part/assembly by asking stuff like "What is the closest distance between the southmost surface of Extrusion1 and the surface of Cylinder2" which would then be translated to a specific high level command or a bunch of lower level commands by Gemini 3 Flash. Those would then be translated to Solidworks API calls, as would any editing commands. It also really helps to give it the ability to parametrize the queries so instead of "all features smaller than 2mm" it can say "all features smaller than $MinFeatureSize", with some logic and a downstream LLM to translate that parameter into values in the design and review it with the human in the loop before committing it to the project.
The key is to absolutely minimize how often the LLMs think about numbers and have them think in relationships instead. The hard part is translating those relationships back to the CAD API calls but LLMs are much better at hot hallucinating if you resolve all the parametrized equations last.
Curious what you think is the best interface for it? We thought about this ourselves and talked to some folks but it didn't seem there was a clear alternative to chat.
Solidworks's current controls are the best interface for it. "Draw a picture" is something you're going to find really difficult to beat. Most of the other parametric CADs work the same way, and Solidworks is widely known as one of the best interfaces on top of that. They've spent decades building one that is both unambiguous and fast.
Haha yes, I've never heard any engineer discribe any CAD package as anything other than slow and full of bugs. But of the alternatives, I think most would still pick Solidworks.
I wonder how many of these bugs are actually situations where the underlying algorithms are simply confronted with situations outside their valid input domains. This can happen easily with 3d surface representations of geometries.
Modelling isn't the slow part. If one is copying a drawing and have exact dimensions its pretty straightforward in most software even if the software is bloated.
The clear alternative is VR. You put on hand trackers and then physical describe the part to the machine. It should be rid m this wide, gestures, and moves hands that wide.
maybe some combination of visual representation with text. For example it's not easy to come up intuitive with names of operations which could be applied to some surface. But if you could say something like 'select top side of cylinder' and it will show you some possible names of operations (with illustrations/animations) which could be applied to it then it's easy to say back what it need to do without actually knowing what actually possible. So as result it maybe just much quicker way to interact with CAD that we are using currently.
Honestly, the out-of-the-box models aren't great at CAD. We were mostly trying to figure out (1) how well it could do with the best harness we could give it and (2) whether people would want and use this if it worked well.
Nothing R specific. In my experience, Claude is pretty good about using tidyverse for everything. What was is flopping on for you? Our thought on not fine tuning models is that whatever comes out in 6 months is just going to be better than whatever we fine tuned.
Admittedly this was probably ~2 years ago, previous gig used a lot more R and the earlier models were (in my memory) worse in R than in Python. But makes sense that this would've come a long way. Love this!
reply