Engineers are feeding SolidWorks tasks to ChatGPT, Copilot, and Claude and getting working VBA macros back — sometimes. A Reddit post showing a ChatGPT-generated STL export macro pulled 26 upvotes. A separate thread about building an MCP server for the SolidWorks API drew 15 comments. The interest is real, and for good reason: writing a SolidWorks VBA macro from scratch means wrestling with a COM API that has methods taking 23 parameters and returns boolean values that aren’t actually booleans.

But the failure rate is also real. On the CADmunity forum, experienced API developer josh put it bluntly: “ChatGPT cannot write SolidWorks macros. It consistently and frequently just hallucinates functions that do not exist, or supplies completely spurious arguments to ones that do. Everything looks quite reasonable, but it’s garbage.”

This post breaks down exactly what AI gets right, what it gets wrong, and what the actual failure modes look like — with real code and real API signatures.

What AI Gets Right: Simple, Single-Document Operations

AI handles the shallow end of the SolidWorks API reasonably well. Renaming files, exporting a single part to STL or STEP, toggling visibility of features, reading custom properties — these involve a small API surface with patterns that appear frequently in training data.

A typical success looks like this: you ask for a macro that exports the active part as STEP, and AI produces something close to correct:

Dim swApp As SldWorks.SldWorks
Dim swModel As ModelDoc2
Dim swExt As ModelDocExtension
Dim errors As Long
Dim warnings As Long

Set swApp = Application.SldWorks
Set swModel = swApp.ActiveDoc
Set swExt = swModel.Extension

swExt.SaveAs3 "C:\output\part.step", 0, 0, Nothing, Nothing, errors, warnings

This works. The API surface is small, the method signature is straightforward, and there’s enough training data for AI to get the parameter order right.

User Bradfordzzz on CADmunity (January 2026) reported success with Microsoft Copilot: “I have had quite a lot of success with Microsoft Copilot writing SolidWorks 2022 macros. I find you just need to be very specific… My macros aren’t super complex, but they are still saving me quite a bit of time.”

The key qualifier: “aren’t super complex.”

Where It Falls Apart: The Five Failure Modes

1. The Boolean Trap — SolidWorks Returns 1, VBA Expects -1

This is the most insidious failure because the code compiles, runs, and produces wrong results silently.

In standard VBA, True = -1 and False = 0. SolidWorks API functions sometimes return 1 for True instead of -1. This means:

' All three of these FAIL when swResult = 1
If swResult Then              ' Works for -1, fails for 1 in some contexts
If swResult = True Then       ' 1 <> -1, evaluates False
If Not swResult Then          ' Not 1 = -2, which is truthy — inverted logic

The safe pattern, documented by josh on CADmunity:

If False = swResult Then
    ' This catches both -1 and 1 as "not false"
End If

AI never generates this pattern. It produces standard VBA boolean comparisons that break on specific SolidWorks API calls. Forum user mihkov noted: “I’ve repeatedly told AI models to avoid Not in VBA with If and even tried to save this as a permanent rule in their memory. Yet, they still slip up and use it.”

2. GetMassProperties — The Type Mismatch Chain

The CADmunity “AI vs. SolidWorks API” challenge thread documented a Gemini session attempting to analyze overlapping body volumes. The failure chain is instructive:

Round 1: Gemini generated bodyA.GetVolume — a method that does not exist on IBody2.

Round 2: Replaced with GetMassProperties("") — passing a string where the API expects a Double (density value).

Round 3: Tried bodyA.GetMassProperties("")(3) — direct array indexing from a function return, still with the wrong parameter type.

Round 4: Corrected to bodyA.GetMassProperties(1) with a Variant. Compiled and ran — but the downstream Operations2() call never returned intersection bodies, so nothing was colored.

Four rounds of correction. Still broken. The real signature from decompiling SolidWorks.Interop.sldworks.dll:

instance object marshal(struct) GetMassProperties([in] float64 Density)

The return is a 12-element array: [CenterX, CenterY, CenterZ, Volume, Area, Mass, MomXX, MomYY, MomZZ, MomXY, MomZX, MomYZ]. AI often confuses this with IModelDocExtension::GetMassProperties, which is a different method on a different interface with different return semantics.

3. Assembly Traversal — Where Training Data Runs Out

The official API docs for IAssemblyDoc::GetComponents state: “The components returned by this method can be in any order. You should not rely on the order to indicate anything about children or parents.”

AI ignores this. Every AI-generated assembly traversal macro assumes top-down ordering that doesn’t exist. The correct approach uses GetRootComponent3 with recursive GetChildren():

Sub TraverseComponent(swComp As SldWorks.Component2, level As Long)
    Dim vChildComp As Variant
    Dim swChildComp As SldWorks.Component2
    Dim i As Long

    vChildComp = swComp.GetChildren()
    If IsEmpty(vChildComp) Then Exit Sub

    For i = 0 To UBound(vChildComp)
        Set swChildComp = vChildComp(i)
        ' Process component...
        TraverseComponent swChildComp, level + 1
    Next i
End Sub

Three things AI gets wrong here:

  • IsEmpty() check: GetChildren() returns VBA Empty when there are no children — not Nothing, not an empty array. UBound() on Empty crashes. AI generates If Not vChildComp Is Nothing which is the wrong test.

  • Transform context: IBody2::GetMassProperties returns coordinates relative to the part origin, not the assembly origin. You must multiply by IComponent2::Transform2 to get assembly-space coordinates. The official docs bury this in Remarks. AI never generates the transform step.

  • GetModelDoc vs GetModelDoc2: The older variant returns ModelDoc, not ModelDoc2. AI mixes these up because both appear in training data. GetModelDoc2 is the correct call for modern API work.

4. SelectByID2 — The 9-Parameter Minefield

SelectByID2 takes 9 parameters:

SelectByID2(Name, Type, X, Y, Z, Append, Mark, Callout, SelectOption)

The Callout parameter is a COM object pointer. In VBA, you pass Nothing. In Python via win32com, you must construct win32com.client.VARIANT(pythoncom.VT_DISPATCH, None) — passing Python None directly causes a COM type mismatch. The SolidworksMCP-TS project (97 stars on GitHub) documents this as the root cause of their SelectByID2 failures.

But the deeper problem is that SelectByID2 itself is fragile. The SolidWorks forum has a thread titled literally “Don’t use SelectByID2.” The Type parameter uses uppercase string literals ("SKETCHPOINT", "EXTSKETCHPOINT", "COORDSYS") and the correct string depends on context — whether a sketch is active, whether the point was created in the current sketch, and whether you’re selecting in a part or assembly context.

A cadoverflow.com thread documents a user trying every type string — "sketchpoint", "extsketchpoint", "datumpoint", "coordsys" — and none working for selecting a coordinate system origin point.

The recommended alternative: FeatureByPositionReverse() combined with GetTypeName2() for finding features in the tree. Both the SolidworksMCP-TS project and experienced API developers independently converged on this pattern.

5. Operations2 and Empty Results

IBody2::Operations2(OperationType, ToolBody, Error) returns Empty when two bodies don’t overlap — not Nothing, not an empty array, not a zero-length array. AI generates code that calls UBound() on the result or tests Is Nothing, both of which crash:

' AI generates this — crashes on non-overlapping bodies
Dim vResult As Variant
vResult = bodyA.Operations2(swBodyOperationType_e.swBodyAdd, bodyB, nError)
If Not vResult Is Nothing Then   ' WRONG — vResult is Empty, not Nothing
    ' process results
End If

' Correct approach
If Not IsEmpty(vResult) Then
    ' process results
End If

This is the same Empty vs Nothing distinction that breaks assembly traversal. It’s a SolidWorks COM API pattern that appears nowhere in general VBA training data.

The MCP Server Approach — Five Projects, Same Problem

At least five independent projects now exist to bridge AI and the SolidWorks API:

swapi-pilot provides a remote MCP server with tools like search_solidworks_api and get_api_detail that feed correct method signatures to AI at the moment of the call. Their README states the core problem: “SolidWorks API documentation is massive, and LLMs almost never have the right methods and parameters in their training data.”

SolidworksMCP-TS (97 stars) discovered a fundamental COM constraint: SolidWorks methods like FeatureExtrusion3 take 23 parameters. Node.js COM bridges choke above 12-13 parameters. Their workaround: route by parameter count — under 12 goes through direct COM, 13+ auto-generates a VBA macro that SolidWorks executes internally.

SolidPilot (79 stars) layers Python over a C# COM adapter via PythonNET, adding another translation layer that introduces its own failure modes.

The architectural lesson: even with a working bridge to the API documentation, complex modeling operations still require generating VBA that SolidWorks executes — adding a second layer of potential failure on top of the API hallucination problem.

What Actually Works: The Incremental Approach

The most successful pattern reported by users is not “ask AI to write the whole macro.” It’s incremental construction with human verification at each step.

User TK.421 on CADmunity describes the working pattern: “I muddled through it knowing exactly what I wanted, and 3/4 sure of which particular API page everything was found on. Then the bot and I wrote the code in increments so I could test it along the way. Every so often I would feed it the working macro & say ‘don’t change any of this.’”

This mirrors what experienced developers already know about AI code generation: it works as a drafting assistant when you already understand the domain, and fails as an autonomous agent when you don’t.

User loeb summarized it: “It is not a replacement for an understanding of coding, VBA, and the SW API interfaces.”

The practical approach:

  1. Know which API page you need. If you can’t point to the method in the API help, AI can’t reliably find it either.
  2. Build incrementally. Get one API call working before adding the next. Test after every addition.
  3. Feed AI the working code before each iteration. Explicitly tell it “don’t change any of this” for the parts that work.
  4. Never trust boolean returns. Always compare against False, never against True.
  5. Always test for IsEmpty() before UBound(). COM methods return Empty, not Nothing.

For a worked example of this incremental approach applied to drawing automation — view placement, title-block property linking, and where Task Scheduler hands off — see how to automate SolidWorks drawing creation with a macro.

When AI Isn’t Worth the Iteration Cycles

For batch DXF export from assemblies, the API chain involves assembly traversal, flat pattern feature detection, suppressed component handling, bend line layer mapping, metadata embedding, and file naming logic. This is exactly the class of problem where AI macros fail — multi-step workflows crossing several API interfaces with SolidWorks-specific edge cases at each step.

The gap between what AI can generate (single-document, shallow API calls) and what manufacturing teams actually need (assembly-wide batch operations with metadata preservation) is precisely where purpose-built tools operate. CadShift handles the assembly traversal, flat pattern detection, and metadata embedding as an in-process add-in — avoiding the COM bridge failures that plague external AI-to-SolidWorks connections entirely.

The honest assessment: AI will keep getting better at SolidWorks macros. The training data will grow, the MCP servers will mature, and the 23-parameter methods will get proper documentation coverage. But right now, for anything beyond single-part operations, you still need either deep API knowledge or a tool that already has it.