Writing SolidWorks Add-ins with AI: Where It Speeds You Up, Where It Slows You Down

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:

1. Scaffolding and mechanical conversion — generate it, review quickly.
2. Any code containing an API call — generate it, but add return-value checks and object release by hand.
3. The rule and validation layer — written by hand. Code that decides whether the product is correct is not entrusted to generated code.
4. 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:

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.