AI CAD automation: scripts, macros, and LLMs

Before LLMs entered the picture, CAD automation meant Python scripts, iLogic rules, VBA macros, and journal files that broke every time the vendor shipped an update. I had a SolidWorks macro that automated hole table placement on drawings. It worked perfectly for about fourteen months. Then the 2024 service pack changed something in the API, the macro threw an error on line 47, and I spent an evening debugging a tool that was supposed to save me time. My wife asked what I was doing. I said "arguing with a spreadsheet" because explaining VBA to a non-programmer is a form of cruelty.

AI CAD automation in 2026 adds a new layer to this old pattern. LLMs can write those scripts for you, often faster than you could write them yourself. But both the old scripts and the AI-generated ones share the same failure mode: nobody tests the edge cases until something breaks in production. The tools have changed. The problem hasn't.

There are now three tiers of CAD automation, and understanding when to use each one is the difference between a workflow that actually works and a workflow that works great in the demo and explodes on the third real part.

Tier 1: Traditional scripts and macros#

This is the foundation, and it's still the most reliable.

Fusion 360 has a Python API that can create geometry, modify features, export files, and automate repetitive operations. SolidWorks has VBA macros and a .NET API. Inventor has iLogic, which is Visual Basic with built-in access to part parameters. Creo has Pro/TOOLKIT and J-Link. NX has NX Open with Python and .NET bindings. FreeCAD has a Python console that can do almost anything, if you can navigate the documentation.

I've written automation scripts in most of these environments. The pattern is always the same: you identify a repetitive task (placing holes on a grid, generating variants of a part family, exporting multiple formats, populating drawing views), you write a script that does it, you test it until it works on your specific models, and then you hope nothing changes in the next software update.

The advantages of traditional scripting: complete control, deterministic output, repeatable behavior. When a script runs the same way every time, you can trust the results. You can version-control it. You can hand it to a colleague and they get the same output you did.

The disadvantages: writing scripts takes time, CAD APIs are often poorly documented, and maintenance is a real cost. I have a folder of old SolidWorks macros that I'm afraid to open because half of them probably reference API calls that no longer exist. Every CAD vendor treats their API as a second-class citizen compared to the GUI, and it shows.

For anyone starting with FreeCAD automation, the Python integration is genuinely good and the community has built libraries for common operations. It's the most approachable entry point if you're new to CAD scripting.

Tier 2: LLM-generated scripts#

This is where things got interesting about two years ago, and where most of the actual time savings are happening for me in 2026.

The idea is simple: instead of writing a CAD script from scratch, you ask an LLM to write it. "Write a Fusion 360 Python script that creates a rectangular array of M4 clearance holes on the selected face, 5 columns, 3 rows, 15mm spacing." ChatGPT, Claude, and the other major models can produce working Fusion 360 API scripts for tasks like this. Not always on the first try. Not always without bugs. But close enough that fixing the output is faster than writing the script from scratch.

I've been using this approach for about a year and a half. The practical results: LLM-generated scripts save me roughly 60 to 80 percent of the time I would have spent writing the script manually, for straightforward automation tasks. The remaining 20 to 40 percent is spent testing, debugging, and handling the edge cases the AI didn't anticipate.

OpenSCAD is the best target for LLM-generated CAD scripts because the entire model is already code. The language is small, well-documented, and shows up extensively in training data. I've had ChatGPT produce working OpenSCAD scripts on the first attempt for simple parts more often than not. The workflow feels natural because there's no translation between the AI's output and the working file: the script is the model.

For Fusion 360 and SolidWorks, the success rate drops because the APIs are more complex and less well-represented in training data. The LLM will sometimes hallucinate API calls that don't exist, or use deprecated methods from an older version. You need to know enough about the API to catch these errors, which means LLM-generated scripts work best for people who could write the scripts themselves but want to do it faster.

This is the important nuance that the "AI writes code for you" narrative misses. The LLM is a drafting tool for scripts, not an autonomous programmer. If you don't understand CAD scripting well enough to evaluate the output, you'll run code you can't debug, and that's how you end up with a macro that silently places holes in the wrong positions on every tenth part.

Tier 3: AI-native CAD features#

This is what the vendors are shipping, and it's the most limited tier in terms of what you can actually automate.

Fusion 360's Text to Command concept (still in development) lets you describe operations in natural language: "extrude this face by 10 mm," "chamfer all edges 0.5 mm." SolidWorks 2026's AURA and LEO companions can execute some operations from conversational input. The text-to-CAD workflows and tools post covers the broader set of tools that generate geometry from text.

These are automation, in a sense. You describe an operation, the software executes it. But the scope is narrow. You can automate individual commands, not sequences. You can't say "create a parametric part family with five variants based on this configuration table." You can't say "run my standard export workflow: save as STEP, export drawings as PDF, update the PLM record." The AI-native features handle atomic operations, not workflows.

The text-to-CAD API tools like Zoo.dev's API are more useful for workflow automation because they expose geometry generation as an API call you can integrate into a script. Generate a bracket from a text prompt, receive a STEP file, import it into your CAD tool, add features. That's a workflow you can script. The text-to-command approach in Fusion 360 is more interactive, designed for a human at the keyboard, not a script running in the background.

Reliability comparison#

I've been running all three tiers in parallel for the past year. Here's the honest reliability picture.

Traditional scripts: most reliable once debugged. Failure modes are predictable: API changes break the script, unusual geometry produces unexpected results, and edge cases (empty selections, zero-thickness bodies, failed features) need explicit handling. Once you handle these, the script works every time on every model that fits the expected pattern. Maintenance cost is real but manageable.

LLM-generated scripts: reliable for simple tasks, fragile for complex ones. The AI writes correct code for straightforward operations about 70 percent of the time. For complex multi-step scripts, that drops to maybe 40 percent working on the first attempt. The remaining debugging is usually small: wrong API call, missing error handling, incorrect loop logic. But "usually small" is doing a lot of work in that sentence. Occasionally the AI produces code that runs without errors and generates wrong geometry, which is the worst kind of bug because you don't know it's wrong until someone measures the part.

AI-native features: reliable for their narrow scope but limited in what they can do. Text to Command handles simple operations well. It doesn't handle complex, multi-step automation at all. It's a convenience feature, not an automation platform.

When to use which approach#

The decision tree I follow:

If the task is a one-time operation (place these specific holes, export this specific model), I use AI-native features or just do it by hand. The setup cost of writing a script isn't justified for something I'll do once.

If the task is a repeatable workflow I'll run on many parts (export routine, drawing generation, parameter-driven variant creation), I write a traditional script. Sometimes I ask an LLM to draft it, then I debug and validate it myself. The script goes into version control and becomes part of my standard toolkit.

If the task is a quick parametric model (a jig, a test fixture, a simple bracket), I use LLM-generated OpenSCAD code. The model is the script, so there's no API to worry about, no integration layer, no GUI automation. Just geometry as code.

If the task is exploring automation possibilities (what could I automate? what would the script look like?), I start by asking an LLM to draft a script. Even if the code doesn't run, it shows me the API calls I'd need, the approach I'd take, and whether the task is even scriptable in the first place. This is one of the most underrated uses of LLMs in CAD: not writing the final script, but sketching the approach.

The testing gap#

Here's where all three tiers share a common weakness, and it's the thing that trips up most people.

CAD automation scripts need testing on real, varied geometry. Not one model. Many models. Different configurations. Different sizes. Edge cases. Unusual inputs. The script that works perfectly on your test bracket might fail on a bracket with a different number of holes, or with holes on a curved surface, or with a feature tree that has a suppressed operation the script doesn't expect.

LLM-generated scripts make this problem worse because they look correct. The code is well-structured, the variable names are sensible, and the comments explain what's happening. Everything about the output suggests it was written by someone who knew what they were doing. This creates a false sense of confidence. I've caught AI-generated Fusion 360 scripts that iterated over faces in the wrong order, producing correct results on simple geometry and silently wrong results on anything with more than four planar faces.

The fix is boring and old-fashioned: test on multiple real parts. Measure the output. Compare against expected values. Run the script on a part that's slightly different from what you had in mind. Run it on a part that's very different. If it fails, fix it. If it silently produces wrong results, fix the validation logic.

Nobody does this enough. Not with traditional scripts. Not with AI-generated scripts. Not with anything. The testing gap is the most consistent failure mode in CAD automation, across all three tiers, and AI hasn't fixed it. It might have made it worse, because the scripts are easier to generate and therefore easier to trust without verification.

Building a sustainable automation strategy#

The word "strategy" makes this sound more corporate than it needs to be. What I really mean is: how do you build automation that keeps working?

Start with the repetitive tasks that cost you the most time. For most CAD users, that's export workflows, drawing generation, and parameter-driven part families. These are well-suited to traditional scripts and they pay back the development time quickly.

Use LLMs to draft scripts faster, but validate everything. The AI CAD workflow I described in detail covers where AI fits in the broader design process. For automation specifically, the LLM is a first-draft tool. You are the reviewer, the debugger, and the person responsible when the script places a hole in the wrong location.

Keep scripts in version control. I use git for everything, including my OpenSCAD library and my Fusion 360 scripts. When something breaks after a software update, the diff shows you what changed and the history shows you what used to work.

Document the expected behavior. This is the part I used to skip and now don't. Write a one-paragraph description of what the script does, what inputs it expects, and what output it produces. When you come back to the script six months later, or when a colleague tries to use it, that paragraph saves more time than you'd think.

Test on varied geometry. I said this already. I'm saying it again because it's the single most important thing and the single most frequently skipped thing in CAD automation.

Don't automate everything. Some tasks are faster to do by hand. Some tasks happen rarely enough that the script development time never pays off. Some tasks are too complex to automate reliably. The best CAD automation strategy includes knowing when not to automate. That judgment comes from experience, and it's the one thing no AI can write a script for.

Where this is heading#

Traditional scripts aren't going away. They're too reliable and too well-understood to replace. What's changing is how fast you can write them, thanks to LLMs, and how many people can write them, because the barrier to entry drops when you can describe what you want in English and get a working first draft.

AI-native features will expand. Text to Command will ship in more tools, handle more operations, and eventually support multi-step sequences. That's the natural trajectory based on what the vendors are showing.

The interesting convergence is scripts generated by AI, validated by humans, and executed inside AI-enabled CAD tools. That's a workflow where the LLM drafts the automation, the engineer reviews and tests it, and the CAD environment provides the AI infrastructure to run it. We're not there yet. We're close enough that I'm planning for it.

Until then, the state of the art in CAD automation is what it's been for twenty years: someone who understands both the CAD software and the scripting environment writes a tool that solves a specific problem. The LLM just made that person faster, not unnecessary.