Writing SolidWorks Add-ins with AI: What It Gets Wrong
AI speeds up add-in scaffolding and API discovery, then gets COM lifetimes, version signatures and silent failures confidently wrong. Where I draw the line.
In This Article
I use AI tools as controlled leverage when building add-ins. "Controlled" is not decoration there: the SolidWorks API is one of the areas where language models go wrong most often.
For flows still in the exploration phase — connecting over COM, testing parameters, validating export paths — SolidWorks Python scripting is usually faster before you commit to add-in architecture.
This post separates where it helps from where it does not.
Scaffolding. Add-in registration, the ISwAddin implementation, the CommandManager tab, button wiring — near-identical in every add-in. Half a day by hand, a few minutes to generate. The gain is real and the risk is low, because mistakes surface at compile time.
API discovery. The SolidWorks API is broad and its documentation is scattered. Asking "how do I reach the bend table of a sheet metal part" usually gets to the right interface name faster than searching for it. But I do not use the answer without verifying it — for the reason below.
Repetitive conversions. If a VBA macro exists and needs porting to C#, that is mechanical translation. AI is good at it.
Test data and edge-case lists. Asked "what inputs break this function", the list that comes back is usually longer than the one I had in my head.
The danger here is not that it makes mistakes — it is that the mistakes do not announce themselves.
COM object lifetimes. The SolidWorks API runs over COM. Generated code often skips releasing objects, or releases them in the wrong order. Nothing visible happens immediately: the application runs, but memory grows over long sessions or SolidWorks hangs on shutdown. These faults show up in the field three weeks later, not in testing.
Version differences. If an API method changed between releases, the model usually emits the older signature. It compiles, it runs, it returns the wrong result.
Silent failure. Many SolidWorks API calls do not throw; they return null or false. Generated code frequently skips checking those returns. The automation looks like it worked and quietly produces incomplete output.
The most expensive automation fault is not code that crashes — it is code that silently produces wrong output. You notice a crash; wrong output goes to the shop floor.
I turned that separation into a rule:
- Scaffolding and mechanical conversion — generate it, review quickly.
- Any code containing an API call — generate it, but add return-value checks and object release by hand.
- The rule and validation layer — written by hand. Code that decides whether the product is correct is not entrusted to generated code.
- Tests — AI suggests edge cases, I write the tests.
This is the code-side counterpart of drawing the automation boundary: rule-shaped work is delegated, judgement-shaped work is not.
Answering "did AI speed up development" with a single number would be wrong. There are two separate things worth measuring:
| Measurement | What I observe |
|---|---|
| Time to first working version | Noticeably shorter |
| Time to field-reliable version | No clear difference |
The gap between them shows where the verification load moved: from writing time to reading time. Your total gain is only as good as your verification discipline.
AI accelerates scaffolding and discovery in SolidWorks add-in work; it does not know the API's traps. Protecting the gain comes down to deciding upfront where generated code is allowed to live.
Next in the series: the AutoCAD options, and how to measure the gain honestly.
Does AI genuinely speed up SolidWorks add-in development? It speeds up scaffolding and API discovery markedly. Add-in registration, lifecycle implementation and command UI setup are nearly identical in every add-in; generating them takes minutes and the risk is low because mistakes surface at compile time.
Where is AI most often wrong about the SolidWorks API? Three areas: COM object lifetime (release order), method signatures that changed between versions, and silent failure — calls that do not throw but return null or false and go unchecked.
How should generated code be verified? Split the code into three groups: scaffolding and mechanical conversion can be generated and reviewed quickly; any code containing API calls gets return-value checks and object release added by hand; the rule and verification layer is written by hand.
Why is silent failure the most expensive kind of bug? You notice code that crashes; code that quietly produces wrong output goes to the shop floor. The error surfaces weeks later, when the wrong part has been made, and costs many times more than rewriting the code would have.
Does AI shorten total development time? Time to a first working version drops clearly; time to a version that is reliable in the field showed no clear difference in my experience. The load moves from writing to reading — total gain equals your verification discipline.
Which code should never be delegated to AI? The code that decides whether the product is correct. The rule and verification layer is written by hand; you write the tests too, and the model only suggests edge cases.