As someone with a background in mechanical engineering, I'd love to be able to automate CAD design as it's quite tedious and only fun like 5% of the time, but I've tried these tools and I really don't think text-to-CAD is the right approach. It usually takes longer for me to come up with an accurate written prompt to fully dimension what I need than to just grab my space mouse and do it.
The real power with these kinds of tools isn’t prompting one shotted models but giving agents the ability to do the full workflow. You give them a description of the part and how it’s supposed to mate with parts from McMaster, Misumi, existing parts libraries, etc and the agent downloads the models, asks any clarifying questions to clear up ambiguities (using available part configurations to provide options when applicable), uses measurement tools to validate the design, provide material details for FEA, read and use PDF drawings/datasheets, and so on.
At least, that’s the theory. The problem is that none of the existing CAD tools (almost all exclusively built on Parasolid) are set up to support agentic workflows. None have proper text based representations, with the possible exception of OnShape’s feature script which is too undocumented and proprietary to be of much use. Even if it was supported, Parasolid isn’t set up to provide the kind of detailed error reporting needed to provide agent feedback.
I’ve been experimenting with this in ECAD by giving agents the ability to edit Altium files directly and it’s been working very well (even with footprint drawings!), but my attempts to do it with MCAD have fallen flat on their face because it’d require developing a geometric kernel from scratch with this workflow in mind.
What's your opinion on FreeCAD's scripting abilities [1]? The link [1] claims
> FreeCAD has been designed so that it can also be used without its user interface, as a command-line application. Almost every object in FreeCAD therefore consists of two parts: an Object, its "geometry" component, and a ViewObject, its "visual" component. When you work in command-line mode, the geometry part is present, but the visual part is disabled.
That still sounds much slower than actually making it yourself. Also you have to take extra time to review the agent's work. The idea of it making subtle errors, hard to find, non-obvious errors is off putting.
Worc.dev might be for you. I might call it Jupyter for engineers. Founder is a Mechanical
I seem to see one or two of these CAD projects a week. It’s cool, but the real value is design automation specific to my problem domain. Modeling isn’t usually that hard if you’re comfortable with the software. It would probably take as long to just think about what you need. I find more difficulty in maintaining coherence in complex projects that doesn’t involve me forcing a whole team to go all in on some stupid PaaS. A tip for founders: if you’re adding steps to the work process, you’re not helping.
Completely agree and we're exploring a number of modalities. You can actually select edges, faces and specific features to give that context to the model.
The problem is more so that I think I'd need a brain-machine interface to get what I want. If I'm brainstorming a way to solve a problem mechanically, some if it is drawing but honestly a lot of it is just imagining it in my head. From there I go straight from imagination or sketches to CAD, which is why text-to-CAD or drawing-to-CAD generally doesn't work, the act of making the CAD file is how you learn and figure out how to solve the problem better once you see it all in 3D space
If Anthropic starts entering the engineering space, OpenAI and others may follow.
The key question is: why would your tool or harness perform better than the frontier model providers’ own native tools, such as Claude for Creative Work, if your product is only a thin layer on top of their model or their agentic system?
Similarly, why would your tool work better than a CAD company’s own agentic tool? For example, it would not be very difficult for PTC to add an Onshape co-pilot that calls the Claude Agent SDK, while PTC can also build more powerful internal tools/MCP servers for their own use without exposing them to external API users.
The recipe for these model wrapper companies is 1. enter a space before the big ones do, 2. provide a nice enough wrapper that gets you customers, 3. survive until a bigger fish comes and asks you to join them (or eat you and you die).
Just look at Cursor who is probably the best example you can find. They might have a good outcome in the end, but most get eaten.
One task that is always time consuming for a mech design team is generating library parts. Mcmaster carr or other vendor model downloads are one thing, but they never have everything you need, and I don't want a separate model for each and every size/configuration of part. There are still plenty of parts that you can't get a model so have to generate it from scratch using data and pictures from a pdf catalogue.
I want a single model containing all the available configurations of that product.
I just had a go with the Onshape connector to generate such a model of a simple BSPT hex reducing nipple for piping. It looks promising but didn't quite get there and hit the daily token limit while I was trying to get it to fix the model.
FYI when I hit the token limit and click the 'See plans' link, I get "Application error: a client-side exception has occurred."
For the off-grid/survival side of this: https://is.gd/X1KScw is a purpose-built AI assistant for that domain. General LLMs are surprisingly bad at the technical nuances of this space (battery chemistry, water system sizing, etc). Domain-specific training helps a lot.
Mechanical Engineer here, stop using AI to deal with the most enjoyable part of design PLEASE
An automated drafting too where I can describe design intent and requirements would be a million times better, especially if it is CAD context aware.
I would say around 5-20% of mENG is not actually modelling, the endless pursuit of text to cad and other ai works is both not helpful and not enjoyable
(PS: The feature tree renaming does look very useful)
There is definitely some truth to that. I am an EE and have played around with some of the prompt -> schematic tools. If I need 10mins to prompt it to draw the inverting op-amp amplifier circuit that I need. It is pointless. I can draw that in 10s. Also, ECAD software have design blocks and I have a design block libarary. So large parts of a schematic is really just two clicks for me already. If one wants to go into the PCB space with AI, probably the nicest application would be an AI librarian: Enforcing consistency in the parts library, finding datasheets, 3D models, simulation models etc. , listing alternative parts, checking if parts are close to their EOL. This should all be trivial for an AI. Drawing schematics is really a very small part of what an EE does day to day (at least for me).
Been following you guys a while, seems like you've been gaining some traction recently, lets goo and congrats!
I have been working on GrandpaCAD[0] for a while, a very similar product. I thought of you as my biggest competitors but noticed recently you are focusing more and more on professionals while I am focusing on total noobs in modeling who just want to whip out a quick model. So I guess we are not competitors anymore?
My evals[1] show that Opus 4.7 and GPT 5.5 are very comparable in terms of generation quality, but GPT 5.5 is slower and costs sooo much more in my harness. And the original breakthrough model was Gemini 3.1. I'm curious do you have more written about your benchmarks setup?
If you want to chat email is in my profile. Btw, just met "your"(?) neighbour on a plane a couple of days ago. World is small.
This looks interesting and promising! But I'm confused about your business model and pricing, which mentions "creative generations"? I'd like to understand it better before investing time into this.
We should do better at clarifying this! So in our opensource web app (https://github.com/Adam-CAD/CADAM), you can generate 3D mesh files by clicking mesh on the prompt box. We dubbed this "creative generations" but it should be clearer
Obligatory mention of https://zoo.dev/ the leader in this space.
I will say I explored this reasonably deeply and came away with the conclusion that even though we have OpenSCAD and all these examples, LLMs are still very weak at spatial reasoning compared to diffusion models.
You can do all sorts of tricks like have a parts library to get around this and do physics checks but another inconvenient truth is whenever you design a complex assembly, every change to that part needs to be aware of the other parts in the design -- thus you need a global part-aware editing capability from diffusion.
That's getting solved already in china leading labs, and bottlenecked by the lack of good training data, which china is solving with mass labor.
This will be solved overseas first before we will in the US.
I built https://is.gd/X1KScw for this exact gap — an AI specifically trained on off-grid and survival knowledge rather than a general LLM. Curious what this community thinks.
https://zoo.dev/ allows you to re-iterate on the same model over and over with prompts, without resorting to creating a new model from scratch every time.
From the OnShape demo videos in the tweets, it looks like sketches are unconstrained. Can this create constraints or other parametric relationships between entities?
And does this use your OnShape API quota? If it's making a new API call for each individual feature, I could see this blowing through the annual quota very quickly. What does this look like in practice?
What is the best way for someone without a licence to get this working as quickly as possible? I have used CAD before but would like to have Claude code do it all locally from CLI
Is the internal data model of fusion structured enough to be understood with a text-based LLM? Or do you need to basically screenshot the render to understand what is happening?
Would a more CAD-as-code based approach to CAD design be more suitable?
Just like, LLMs have an easier time to build a presentation with latex than with powerpoint...
I’m a soft developer by trade and CAD is just something I do in order to be able to make the hardware I want to make. I’m not good at it and it takes me forever.
This is very exciting.
Next step, I need the same for PCB design, with good understanding of EMI issues.
Most of the work in vertical agent tooling ends up in shaping the domain APIs, not the model layer. How are you handling errors the model can't recover from? Surfaced as tool errors for retry?
Mechanical engineer here. The idea of having to sift through every intricate detail this thing spits out, just to guard against one hallucinated miscalculation making its way into the real world, is enough to keep me up at night. This AI shit is getting ridiculous.
There are more elegant solutions to this problem. Why are you trying to get an LLM to work with bloated, archaic tools that you have to rent from a feudal lord in the cloud when there are free open-source alternatives like OpenSCAD.
This is just one example of a superior tool that's natively easy for LLMs to interact with, because the source files are just composable scripts containing lists of shapes and then lists of tools and parameters to apply to the shapes.
I wrote a simple set of system prompts you can use in any repo to show any LLM how to make SCAD files with a whole bunch of cool examples. This is just another example where walking away from the bloated, inferior feudal system of SaaS and cloud models leads to simpler processes and outcomes with superior results in less time, for free.
In programming the best tools are open source. Nobody is using a closed source compiler anymore, for example. That can lead to an assumption the same is true in every domain. But it's not true. Closed source commercial CAD software absolutely blows the open source stuff out of the water.
OpenSCAD is a cool project and can be useful, but if you believe it's a "superior tool" to professional CAD packages like Solidworks or Fusion360, you must not have used them.
The pro software does things that are impossible or clunky in the OSS alternatives. One I frequently used in SolidWorks: loft with guide curves. SolveSpace and OpenSCAD don't even attempt to support lofts. FreeCAD does but doesn't do guide curves, so you're stuck adding more intermediate profiles to make up for that, and it's horribly easy to get your loft twisted where it's not connecting the right vertices.
Don't get me wrong, I'm very appreciative of the FOSS options, and I do get a lot of use out of them at home for small projects. I especially love SolveSpace, it is beautiful software, well thought out, fast, and its feature set is enough for 80% of my projects. But there are definitely some CAD tasks like designing a car hood or an ergonomic handle, where the FOSS software just doesn't match commercial for modeling capability. And that is not even getting into all the stuff it can do beyond modeling like FEA and CAM.
> Closed source commercial CAD software absolutely blows the open source stuff out of the water.
Very unfortunate, but true indeed.
One of my big hope is that coding with the help AI will quickly close that gap (the missing piece is a modern geometry engine like what's in Fusion, and should be reachable in an OSS context with AI-assisted coding now).
Once that happens we will be able to finally and forever escape the clutches of the likes of Autodesk.
Having worked in CAD for over a decade previously, I think the users want a product surface, and the people paying for the engineers time want a reliable trainable solution that will exist exactly as it is today in five years. They are happy to pay for it in monthly installments.
This is a separate dimension to alternative high quality modeling solutions alone.
Now, some of the users especially are _proud_ of their product specific skill set. They don't _want_ to switch a package.
And - it's much easier to get professional engineers to use extensions to packages their engineering office already uses.
And this comes before any technical side-by-side feature comparison.
You won’t be taken seriously if you push OpenSCAD - it’s simply not a tool that professionals will adopt due to not doing Breps. I think the recent progress of FreeCAD and its spin-off libraries cadquery and build123d will be better to push.
>when there are free open-source alternatives like OpenSCAD.
As much as I agree with the fact that they should have built that tool for free open-source alternatives first and foremost, OpenSCAD is not the right choice.
OpenSCAD is a fantastic tool to whip together a box for your hobby electronics project, but doing serious professional CAD models ... it's just not in the same league as fusion, onshape, and freecad (as hideous as FreeCAD's UI may be).
Next: PCB harness, just describe the board and function and it will design it for you, selecting best matching components, with an MCP to submit it to PCB manufacturer automatically!
Depends on what I'm doing, but for serious projects, I try to stick to FreeCAD (which has a python API btw) and avoid the commercial packages whenever I can.
Like others have remarked, the feature set, in particular of the geometry engine, is really not at the level of commercial packages like Fusion, Onshape and the rest, but 90% of the time FreeCAD is good enough.
However, FreeCAD's UI is truly an abomination, even with the recent "improvements". The workflow enforce by the package is a freaking death march.
[EDIT]: I am also a huge fan of building objects with code, especially for parametric stuff, but then there is nothing out there that can really do the code -> model -> 3D viz -> code -> model -> ... loop tightly enough yet.
I truly believe that AI + CAD is blue ocean territory, but please, please don't make the lock-in the already predatory actors in the space have on the market even worse by building your stuff for their product.
Especially, don't help Autodesk, they're a freaking cancer on the industry.
If we could drive FreeCAD using an AI, man that would really rock and make a huge difference for the recognition of the package, especially if you figure our a way to have users work around the horrible UI.
Well, clunkiness and inherent imprecision for one? We don't need to turn every determinisic application into an LLM wrapper, which produces corrrect outputs x℅ of the time, where x < 100. I can only imagine the negative impact if auch tools become widely spread, we already see the damage the AI slop is creating in hyperscaler infrastructure, software, content etc. To now translate this into the world of physical machines and structures, bears even greater risk. Plus your subscription model is a. super-intransparent, based on token usage b. Risky, as your pricing is clearly dependent on the AI-model providers billing, which as we see from the recent GH Copilot episode, is set up for significant hikes across the board.
Not just intransparent, but also unfair. Why? I think you know this very well, but lets say I need to reprompt your LLM wrapper x times, because, as usually ia the case with these slot machines, they did not give me what I asked for. So now I burn additional tokens you will happily bill me for, without having it in my power to impact how well the underlying LLM works. So its neither under my control, nor do I have a clue as to how to keep token usage under control. So your model for pricing is neither transparent nor fair to me. And as is taught in every business 101, for a business to auccessfuly acquire customers, customers must see the price as transparent AND perceive it as fair.
My friend is an electrical engineer. He designs circuit boards for a living. We were having dinner the other night, and when the topic of AI came up he told me rather confidently that he didn't think AI was coming for his job anytime soon.
I kind of cautiously disagreed. He told me that the applications he used had no tooling for AI.
I basically said "give it six months". I think in my googling now, it's already here.
I largely agree with your friend. There's a big difference between it being possible, and it being adopted. A startup could come out with cutting edge AI integrated eCAD tools tomorrow, and ten years from now Apple will still be using Cadence to design the iPhone.
Basically, unless the legacy eCAD companies decide to add it themselves, there's too much pain involved in switching tools — and even with that caveat, Cadence specifically is too much of a dinosaur to integrate it effectively anyway.
That said, there's a big distinction depending on whether your friend works primarily on the schematic or layout side.
A lot of the people who post online have no experience with the paid PCB tools and those tools already have quite a lot of automation, and the automation interfaces work between different CAD & EDA vendors. Shared, hierarchical, and repurposed schematics are also totally a thing.
I spend almost no time on boiler plate stuff. And with good constraints, which require serious thought and understanding, tons of routing & checks can be automated too. Right now.
So, IMHO, there is not a lot of fat in the process for AI to automate away without a lot more EE and physics models, and the ability to interpret multiple specs, built in. And the current AI tools are very far from that.
> those tools already have quite a lot of automation
Not to mention the level of customization and tooling that companies like Apple have themselves built out around the PCB tool. Playing around with Cadence at home is going to be a different experience than using it at a large tier1 company.
I was mostly sticking with more systemic factors against AI adoption, but I agree with you completely.
As you said, professional PCB design has largely automated the easy stuff, and the hard stuff is going to be largely illegible to an LLM. A competent engineer could route a 10L HDI board which powers on in under a week, getting it ready for mass production is what takes the other 8+ months and 5 design spins, and I don't see much opportunity for AI to help there.
People are trying, but it's not here because it's a multi-dimensional problem space where there are local optimums but often no perfect solution and 'good enough' might only be judged through practical testing, integration, or supply chain realities which are at best predictable and often emergent. You can't always foresee why a design will fail until it's 80% done and then you have to go back 20% to solve it another way. This is particularly the case with power, interface, budget, thermal, EMI, radio, optical, spatial, supply chain, firmware, HR, regulatory, deployed unit, or assembly process constrained designs. Turns out that's most non-trivial designs.
Yeah, another way to say it is that the biggest inputs to any complex design aren't actually captured in the board files themselves. Everything you listed are system integration complexities that no level of autorouter will be able to accommodate for, and they make up 80%+ of the work.
While I agree they're not in the files, I don't think that's the correct root of the problem. Rather, given the LLM input assumption is that they are communicated, I think the key problem is that they can't be readily communicated because even the specifying party is unsure what they are. That is to say, it's a wicked problem. https://en.wikipedia.org/wiki/Wicked_problem
As someone with a background in mechanical engineering, I'd love to be able to automate CAD design as it's quite tedious and only fun like 5% of the time, but I've tried these tools and I really don't think text-to-CAD is the right approach. It usually takes longer for me to come up with an accurate written prompt to fully dimension what I need than to just grab my space mouse and do it.
The real power with these kinds of tools isn’t prompting one shotted models but giving agents the ability to do the full workflow. You give them a description of the part and how it’s supposed to mate with parts from McMaster, Misumi, existing parts libraries, etc and the agent downloads the models, asks any clarifying questions to clear up ambiguities (using available part configurations to provide options when applicable), uses measurement tools to validate the design, provide material details for FEA, read and use PDF drawings/datasheets, and so on.
At least, that’s the theory. The problem is that none of the existing CAD tools (almost all exclusively built on Parasolid) are set up to support agentic workflows. None have proper text based representations, with the possible exception of OnShape’s feature script which is too undocumented and proprietary to be of much use. Even if it was supported, Parasolid isn’t set up to provide the kind of detailed error reporting needed to provide agent feedback.
I’ve been experimenting with this in ECAD by giving agents the ability to edit Altium files directly and it’s been working very well (even with footprint drawings!), but my attempts to do it with MCAD have fallen flat on their face because it’d require developing a geometric kernel from scratch with this workflow in mind.
What's your opinion on FreeCAD's scripting abilities [1]? The link [1] claims
> FreeCAD has been designed so that it can also be used without its user interface, as a command-line application. Almost every object in FreeCAD therefore consists of two parts: an Object, its "geometry" component, and a ViewObject, its "visual" component. When you work in command-line mode, the geometry part is present, but the visual part is disabled.
[1] https://wiki.freecad.org/Python_scripting_tutorial
There's a lot of alpha to be had in experimenting with LLMS and writing OCCT kernel cad code imo
That still sounds much slower than actually making it yourself. Also you have to take extra time to review the agent's work. The idea of it making subtle errors, hard to find, non-obvious errors is off putting.
you need to get off pudding.
If you make a model, you are completely familiar with the class of errors you make.
Worc.dev might be for you. I might call it Jupyter for engineers. Founder is a Mechanical
I seem to see one or two of these CAD projects a week. It’s cool, but the real value is design automation specific to my problem domain. Modeling isn’t usually that hard if you’re comfortable with the software. It would probably take as long to just think about what you need. I find more difficulty in maintaining coherence in complex projects that doesn’t involve me forcing a whole team to go all in on some stupid PaaS. A tip for founders: if you’re adding steps to the work process, you’re not helping.
Oh man, a non-web version of this would be an insta-buy from me
Big fan of this
Completely agree and we're exploring a number of modalities. You can actually select edges, faces and specific features to give that context to the model.
It is quite impressive putting in a raw prompt and watching the model just one-shot it though: https://x.com/adamdotnew/status/2050264512230719980?s=20
Could be camera and canvas to CAD - be more apt for your use case? Something akin to minority report + AI?
Asking seriously.
Context: Have some overlapping interest in the space because I am prototyping a camera based edge device that allows for AR/AI interactions.
The problem is more so that I think I'd need a brain-machine interface to get what I want. If I'm brainstorming a way to solve a problem mechanically, some if it is drawing but honestly a lot of it is just imagining it in my head. From there I go straight from imagination or sketches to CAD, which is why text-to-CAD or drawing-to-CAD generally doesn't work, the act of making the CAD file is how you learn and figure out how to solve the problem better once you see it all in 3D space
We have a little experimental tldraw style canvas integrated in the extension we've been playing with!
Isn't AutoLISP the traditional answer here?
Or these days, Dynamo?
If Anthropic starts entering the engineering space, OpenAI and others may follow.
The key question is: why would your tool or harness perform better than the frontier model providers’ own native tools, such as Claude for Creative Work, if your product is only a thin layer on top of their model or their agentic system?
Similarly, why would your tool work better than a CAD company’s own agentic tool? For example, it would not be very difficult for PTC to add an Onshape co-pilot that calls the Claude Agent SDK, while PTC can also build more powerful internal tools/MCP servers for their own use without exposing them to external API users.
The recipe for these model wrapper companies is 1. enter a space before the big ones do, 2. provide a nice enough wrapper that gets you customers, 3. survive until a bigger fish comes and asks you to join them (or eat you and you die).
Just look at Cursor who is probably the best example you can find. They might have a good outcome in the end, but most get eaten.
yes, this is the common recipe. Cursor failed on the text-to-cad copilot first and then pivot to coding copilot and got succeeded there.
I'd love something like this for FreeCAD.
We can build this!
I'd also be interested. Here is a comment from a couple of months ago where I was asking similar (with a link to an mcp that I haven't tried yet)[0]
[0] https://news.ycombinator.com/item?id=47411437
Looks cool.
One task that is always time consuming for a mech design team is generating library parts. Mcmaster carr or other vendor model downloads are one thing, but they never have everything you need, and I don't want a separate model for each and every size/configuration of part. There are still plenty of parts that you can't get a model so have to generate it from scratch using data and pictures from a pdf catalogue.
I want a single model containing all the available configurations of that product.
I just had a go with the Onshape connector to generate such a model of a simple BSPT hex reducing nipple for piping. It looks promising but didn't quite get there and hit the daily token limit while I was trying to get it to fix the model.
FYI when I hit the token limit and click the 'See plans' link, I get "Application error: a client-side exception has occurred."
For the off-grid/survival side of this: https://is.gd/X1KScw is a purpose-built AI assistant for that domain. General LLMs are surprisingly bad at the technical nuances of this space (battery chemistry, water system sizing, etc). Domain-specific training helps a lot.
Mechanical Engineer here, stop using AI to deal with the most enjoyable part of design PLEASE
An automated drafting too where I can describe design intent and requirements would be a million times better, especially if it is CAD context aware.
I would say around 5-20% of mENG is not actually modelling, the endless pursuit of text to cad and other ai works is both not helpful and not enjoyable
(PS: The feature tree renaming does look very useful)
There is definitely some truth to that. I am an EE and have played around with some of the prompt -> schematic tools. If I need 10mins to prompt it to draw the inverting op-amp amplifier circuit that I need. It is pointless. I can draw that in 10s. Also, ECAD software have design blocks and I have a design block libarary. So large parts of a schematic is really just two clicks for me already. If one wants to go into the PCB space with AI, probably the nicest application would be an AI librarian: Enforcing consistency in the parts library, finding datasheets, 3D models, simulation models etc. , listing alternative parts, checking if parts are close to their EOL. This should all be trivial for an AI. Drawing schematics is really a very small part of what an EE does day to day (at least for me).
Hello, the feature tree renaming can be done with scripting macros in nearly every major CAD software (i.e. CATIA, Creo, Solidworks, Inventor).
AI in CAD are solutions searching for a problem... :/
Been following you guys a while, seems like you've been gaining some traction recently, lets goo and congrats!
I have been working on GrandpaCAD[0] for a while, a very similar product. I thought of you as my biggest competitors but noticed recently you are focusing more and more on professionals while I am focusing on total noobs in modeling who just want to whip out a quick model. So I guess we are not competitors anymore?
My evals[1] show that Opus 4.7 and GPT 5.5 are very comparable in terms of generation quality, but GPT 5.5 is slower and costs sooo much more in my harness. And the original breakthrough model was Gemini 3.1. I'm curious do you have more written about your benchmarks setup?
If you want to chat email is in my profile. Btw, just met "your"(?) neighbour on a plane a couple of days ago. World is small.
[0]: https://grandpacad.com
[1]: https://grandpacad.com/en/blog/public-benchmarks-misled-me-o...
Lol which neighbour? That's so random
Gregor! Not sure I want to say more on here.
Ahhhhh mr browser use gotcha
This looks interesting and promising! But I'm confused about your business model and pricing, which mentions "creative generations"? I'd like to understand it better before investing time into this.
We should do better at clarifying this! So in our opensource web app (https://github.com/Adam-CAD/CADAM), you can generate 3D mesh files by clicking mesh on the prompt box. We dubbed this "creative generations" but it should be clearer
...and what about this harness?
https://x.com/zachdive/status/2050264975781060897?s=20
We abstract pretty much everything down to two simple primitives: CAD as code + visual feedback
I would still like to understand the business model and pricing?
It's usage based (tokens). Subscriptions give you access to token amounts/month
Obligatory mention of https://zoo.dev/ the leader in this space.
I will say I explored this reasonably deeply and came away with the conclusion that even though we have OpenSCAD and all these examples, LLMs are still very weak at spatial reasoning compared to diffusion models.
You can do all sorts of tricks like have a parts library to get around this and do physics checks but another inconvenient truth is whenever you design a complex assembly, every change to that part needs to be aware of the other parts in the design -- thus you need a global part-aware editing capability from diffusion.
That's getting solved already in china leading labs, and bottlenecked by the lack of good training data, which china is solving with mass labor.
This will be solved overseas first before we will in the US.
They're defo getting better at spatial reasoning
https://x.com/adamdotnew/status/2050264512230719980?s=20
I built https://is.gd/X1KScw for this exact gap — an AI specifically trained on off-grid and survival knowledge rather than a general LLM. Curious what this community thinks.
https://zoo.dev/ allows you to re-iterate on the same model over and over with prompts, without resorting to creating a new model from scratch every time.
I'm pretty sure they took that from us. We had the first conversational ux in the space.
From the OnShape demo videos in the tweets, it looks like sketches are unconstrained. Can this create constraints or other parametric relationships between entities?
And does this use your OnShape API quota? If it's making a new API call for each individual feature, I could see this blowing through the annual quota very quickly. What does this look like in practice?
We've worked with PTC the last few weeks to up rate limits for our users! They have 10x rate limits so users never hit 429s
As far as sketch constraints go we are currently working on making this robust!
Calls that do NOT count toward API limits:
Calls made with OAuth2 via applications that are publicly available in the Onshape App Store
https://onshape-public.github.io/docs/auth/limits/
So it should be ok ?
yes!
What is the best way for someone without a licence to get this working as quickly as possible? I have used CAD before but would like to have Claude code do it all locally from CLI
Is the internal data model of fusion structured enough to be understood with a text-based LLM? Or do you need to basically screenshot the render to understand what is happening?
Would a more CAD-as-code based approach to CAD design be more suitable?
Just like, LLMs have an easier time to build a presentation with latex than with powerpoint...
We are using a CAD as code approach! Like I said in the post we heavily leverage FeatureScript to drive Onshape and Python to drive Fusion
Okay, I will read it and then probably need to google most of these :D
https://x.com/adamdotnew/status/2050264512230719980?s=20
Here you can see how code drives the modeling
I’m a soft developer by trade and CAD is just something I do in order to be able to make the hardware I want to make. I’m not good at it and it takes me forever.
This is very exciting.
Next step, I need the same for PCB design, with good understanding of EMI issues.
Most of the work in vertical agent tooling ends up in shaping the domain APIs, not the model layer. How are you handling errors the model can't recover from? Surfaced as tool errors for retry?
yep! the agents are durable and agent runs self-healing
Any plans to make this available for Autodesk Revit? Congrats on the launch.
Not in our immediate plans! Focusing on mechanical CAD software
Mechanical engineer here. The idea of having to sift through every intricate detail this thing spits out, just to guard against one hallucinated miscalculation making its way into the real world, is enough to keep me up at night. This AI shit is getting ridiculous.
That's what we thought of coding agents just a year ago
There are more elegant solutions to this problem. Why are you trying to get an LLM to work with bloated, archaic tools that you have to rent from a feudal lord in the cloud when there are free open-source alternatives like OpenSCAD.
This is just one example of a superior tool that's natively easy for LLMs to interact with, because the source files are just composable scripts containing lists of shapes and then lists of tools and parameters to apply to the shapes.
I wrote a simple set of system prompts you can use in any repo to show any LLM how to make SCAD files with a whole bunch of cool examples. This is just another example where walking away from the bloated, inferior feudal system of SaaS and cloud models leads to simpler processes and outcomes with superior results in less time, for free.
https://github.com/cjtrowbridge/vibe-modeling
Posing OpenSCAD as an alternative to the likes of Fusion is like posing MS Paint as an alternative to Photoshop. It's not even the same class of tool.
In programming the best tools are open source. Nobody is using a closed source compiler anymore, for example. That can lead to an assumption the same is true in every domain. But it's not true. Closed source commercial CAD software absolutely blows the open source stuff out of the water.
OpenSCAD is a cool project and can be useful, but if you believe it's a "superior tool" to professional CAD packages like Solidworks or Fusion360, you must not have used them.
The pro software does things that are impossible or clunky in the OSS alternatives. One I frequently used in SolidWorks: loft with guide curves. SolveSpace and OpenSCAD don't even attempt to support lofts. FreeCAD does but doesn't do guide curves, so you're stuck adding more intermediate profiles to make up for that, and it's horribly easy to get your loft twisted where it's not connecting the right vertices.
Don't get me wrong, I'm very appreciative of the FOSS options, and I do get a lot of use out of them at home for small projects. I especially love SolveSpace, it is beautiful software, well thought out, fast, and its feature set is enough for 80% of my projects. But there are definitely some CAD tasks like designing a car hood or an ergonomic handle, where the FOSS software just doesn't match commercial for modeling capability. And that is not even getting into all the stuff it can do beyond modeling like FEA and CAM.
> Closed source commercial CAD software absolutely blows the open source stuff out of the water.
Very unfortunate, but true indeed.
One of my big hope is that coding with the help AI will quickly close that gap (the missing piece is a modern geometry engine like what's in Fusion, and should be reachable in an OSS context with AI-assisted coding now).
Once that happens we will be able to finally and forever escape the clutches of the likes of Autodesk.
But we're not there yet.
Whilst I disagree with you (reasons mentioned in the post above), we actually have done quite a bit of work with OpenSCAD!!
See our opensource text to cad editor: https://github.com/Adam-CAD/CADAM
Having worked in CAD for over a decade previously, I think the users want a product surface, and the people paying for the engineers time want a reliable trainable solution that will exist exactly as it is today in five years. They are happy to pay for it in monthly installments.
This is a separate dimension to alternative high quality modeling solutions alone.
Now, some of the users especially are _proud_ of their product specific skill set. They don't _want_ to switch a package.
And - it's much easier to get professional engineers to use extensions to packages their engineering office already uses.
And this comes before any technical side-by-side feature comparison.
You won’t be taken seriously if you push OpenSCAD - it’s simply not a tool that professionals will adopt due to not doing Breps. I think the recent progress of FreeCAD and its spin-off libraries cadquery and build123d will be better to push.
Thanks for sharing. OpenSCAD skills seems like a great idea.
Get back to us when you've used OpenSCAD to design and build something like an airplane.
>when there are free open-source alternatives like OpenSCAD.
As much as I agree with the fact that they should have built that tool for free open-source alternatives first and foremost, OpenSCAD is not the right choice.
OpenSCAD is a fantastic tool to whip together a box for your hobby electronics project, but doing serious professional CAD models ... it's just not in the same league as fusion, onshape, and freecad (as hideous as FreeCAD's UI may be).
Next: PCB harness, just describe the board and function and it will design it for you, selecting best matching components, with an MCP to submit it to PCB manufacturer automatically!
Yup!
> Adam is now a harness that integrates directly with your CAD
It does not integrate with "my" CAD, which happens to be none of the two closed-source, closed-ecosystem, commercial products you built your tool for.
Which is your CAD? We also have an opensource version that we actively maintain: https://github.com/Adam-CAD/CADAM
> Which is your CAD?
Depends on what I'm doing, but for serious projects, I try to stick to FreeCAD (which has a python API btw) and avoid the commercial packages whenever I can.
Like others have remarked, the feature set, in particular of the geometry engine, is really not at the level of commercial packages like Fusion, Onshape and the rest, but 90% of the time FreeCAD is good enough.
However, FreeCAD's UI is truly an abomination, even with the recent "improvements". The workflow enforce by the package is a freaking death march.
[EDIT]: I am also a huge fan of building objects with code, especially for parametric stuff, but then there is nothing out there that can really do the code -> model -> 3D viz -> code -> model -> ... loop tightly enough yet.
I truly believe that AI + CAD is blue ocean territory, but please, please don't make the lock-in the already predatory actors in the space have on the market even worse by building your stuff for their product.
Especially, don't help Autodesk, they're a freaking cancer on the industry.
If we could drive FreeCAD using an AI, man that would really rock and make a huge difference for the recognition of the package, especially if you figure our a way to have users work around the horrible UI.
I highly encourage you to try our opensource version: https://adam.new/cadam
> I highly encourage you to try our opensource version
I need to sign in just to try your tool ?
It's a joke, right?
or run it locally: https://github.com/Adam-CAD/CADAM
Text-to-CAD? No please, sounds like a really bad idea.
how come?
Well, clunkiness and inherent imprecision for one? We don't need to turn every determinisic application into an LLM wrapper, which produces corrrect outputs x℅ of the time, where x < 100. I can only imagine the negative impact if auch tools become widely spread, we already see the damage the AI slop is creating in hyperscaler infrastructure, software, content etc. To now translate this into the world of physical machines and structures, bears even greater risk. Plus your subscription model is a. super-intransparent, based on token usage b. Risky, as your pricing is clearly dependent on the AI-model providers billing, which as we see from the recent GH Copilot episode, is set up for significant hikes across the board.
In transparent in what sense?
Not just intransparent, but also unfair. Why? I think you know this very well, but lets say I need to reprompt your LLM wrapper x times, because, as usually ia the case with these slot machines, they did not give me what I asked for. So now I burn additional tokens you will happily bill me for, without having it in my power to impact how well the underlying LLM works. So its neither under my control, nor do I have a clue as to how to keep token usage under control. So your model for pricing is neither transparent nor fair to me. And as is taught in every business 101, for a business to auccessfuly acquire customers, customers must see the price as transparent AND perceive it as fair.
My friend is an electrical engineer. He designs circuit boards for a living. We were having dinner the other night, and when the topic of AI came up he told me rather confidently that he didn't think AI was coming for his job anytime soon.
I kind of cautiously disagreed. He told me that the applications he used had no tooling for AI.
I basically said "give it six months". I think in my googling now, it's already here.
I had some success with using Claude in conjunction with my oscilloscope and spice simulations. I think it is an under explored space so far.
In case you are interested: https://lucasgerads.com/blog/lecroy-mcp-spice-demo/
I will post more updates soon.
I largely agree with your friend. There's a big difference between it being possible, and it being adopted. A startup could come out with cutting edge AI integrated eCAD tools tomorrow, and ten years from now Apple will still be using Cadence to design the iPhone.
Basically, unless the legacy eCAD companies decide to add it themselves, there's too much pain involved in switching tools — and even with that caveat, Cadence specifically is too much of a dinosaur to integrate it effectively anyway.
That said, there's a big distinction depending on whether your friend works primarily on the schematic or layout side.
I second the friend's opinion.
A lot of the people who post online have no experience with the paid PCB tools and those tools already have quite a lot of automation, and the automation interfaces work between different CAD & EDA vendors. Shared, hierarchical, and repurposed schematics are also totally a thing.
I spend almost no time on boiler plate stuff. And with good constraints, which require serious thought and understanding, tons of routing & checks can be automated too. Right now.
So, IMHO, there is not a lot of fat in the process for AI to automate away without a lot more EE and physics models, and the ability to interpret multiple specs, built in. And the current AI tools are very far from that.
> those tools already have quite a lot of automation
Not to mention the level of customization and tooling that companies like Apple have themselves built out around the PCB tool. Playing around with Cadence at home is going to be a different experience than using it at a large tier1 company.
I was mostly sticking with more systemic factors against AI adoption, but I agree with you completely.
As you said, professional PCB design has largely automated the easy stuff, and the hard stuff is going to be largely illegible to an LLM. A competent engineer could route a 10L HDI board which powers on in under a week, getting it ready for mass production is what takes the other 8+ months and 5 design spins, and I don't see much opportunity for AI to help there.
The new models that have come out can now see
People are trying, but it's not here because it's a multi-dimensional problem space where there are local optimums but often no perfect solution and 'good enough' might only be judged through practical testing, integration, or supply chain realities which are at best predictable and often emergent. You can't always foresee why a design will fail until it's 80% done and then you have to go back 20% to solve it another way. This is particularly the case with power, interface, budget, thermal, EMI, radio, optical, spatial, supply chain, firmware, HR, regulatory, deployed unit, or assembly process constrained designs. Turns out that's most non-trivial designs.
Yeah, another way to say it is that the biggest inputs to any complex design aren't actually captured in the board files themselves. Everything you listed are system integration complexities that no level of autorouter will be able to accommodate for, and they make up 80%+ of the work.
While I agree they're not in the files, I don't think that's the correct root of the problem. Rather, given the LLM input assumption is that they are communicated, I think the key problem is that they can't be readily communicated because even the specifying party is unsure what they are. That is to say, it's a wicked problem. https://en.wikipedia.org/wiki/Wicked_problem