Reviewing an AI-written SOLIDWORKS macro before it runs

Tue, 03 Nov 2026 · 7 min read · Written with an AI assistant

SOLIDWORKS 2027 can turn a plain-language request into a VBA macro. A macro that runs without an error has proved nothing. Here is how to read, test and control generated code before it touches production CAD files.

SOLIDWORKS 2027 lets an engineer describe an automation in plain English and get a VBA macro back. The code now arrives faster than most teams can review it, and a macro that runs to the end without an error message has proved nothing about what it did to your files.

This piece is about the gap between those two facts: how to read, test and control a generated macro before it goes anywhere near production CAD data.

What changed in 2027

Dassault Systèmes describes the release as adding “hundreds of enhancements across the portfolio, including AI capabilities that accelerate design and documentation” on its What’s New in SOLIDWORKS 2027 page. One of those listed enhancements is Natural Language Macro Generation, which sits alongside In-Context Design and Performance Assistants, Automated Assembly Instructions and BREP-to-Parametric Conversion on the SOLIDWORKS product page.

The mechanism, according to Dassault’s AI flyer, is simple. You describe the automation you want, LEO generates “working macro logic instantly”, and you refine it by chatting with LEO inside the editor. The stated benefit is automating repetitive tasks “without writing a single line of code.” One small oddity: the flyer’s own title reads R2026x FD01, FD02, FD03, even though the file is named for 2027, so check which release your installation actually matches.

In a SOLIDWORKS blog interview dated 7 October 2026, CEO and VP of R&D Manish Kumar puts it plainly: users can “ask LEO to create a macro for your workflow.”

That is a real change. People who never opened the VBA editor can now produce automation. But not having to write code is not the same as not having to read it.

A finished run is not a correct result

GoEngineer, a SOLIDWORKS reseller, makes the point directly. LEO can generate a VBA macro, open it in the editor and revise it through conversation, but this “does not remove the risks of generated code”. They advise reviewing the macro and testing it on non-production data first. The same article adds that a successful response “only confirms that the system produced an output; it does not confirm that the output is correct.”

You do not need to write VBA to review a macro. You need to read for verbs and scope. Before running anything, answer these:

Scope. Which documents does it touch? The active document, every open document, every file in a folder, or every file in every subfolder?
Writes. Does it save, save as, rename or delete? VBA’s Kill statement deletes files outright. Where does any output go?
Error suppression. A line such as On Error Resume Next near the top means the macro will carry on through every failure and still appear to succeed.
Hard-coded values. Paths, units, property names, configuration names. Are they yours, or plausible guesses?
Assumptions. Does it assume a property exists, a material is assigned, or a part has one configuration?

If a block is unclear, asking in the editor chat is reasonable. Treat the answer as another generated output to check, not as a verdict.

Worked example: a material property macro

A familiar request: “For every part in the project folder, write the assigned material into the Material custom property and save the part.” It is repetitive, low on judgement and exactly the kind of job people will hand to a generated macro.

Now read it as a reviewer. Several things can go wrong without a single error message:

The folder contains released parts. The macro saves over them.
Some parts have no material assigned. The property is written blank, or with whatever placeholder text the macro picks up.
Parts with several configurations need configuration-specific values. The macro writes one file-level value, and the drawing BOM reads the wrong one.
A file fails to open. Error suppression skips it silently, and you assume it was done.
Parts last saved in an older release are re-saved in 2027, and colleagues on older installations can no longer open them.

A test routine that catches these:

Copy a small set of parts into a scratch folder outside the vault.
Deliberately include awkward cases: no material, multiple configurations, a read-only file, an older-release file.
Ask, in the prompt itself, for the macro to write a log of every file it opened, changed or skipped.
Run it. Then open each file and compare the property against the material in the model. Check the model, not the log.
Store the prompt that worked next to the reviewed macro, so the next person knows what it was meant to do.

This follows GoEngineer’s advice to start with low-risk tasks that are easy to check, and to agree review rules before AI output goes into production or customer deliverables.

It is worth writing those rules down now, as a team. What should a macro never do unattended? A reasonable starting list: save over released files, delete anything, check files in, or change dimensions in a part that other assemblies reference. Your list may differ. The point is that it exists before the first generated macro does.

Where the AI runs and where the data goes

GoEngineer separates two kinds of AI in SOLIDWORKS. Built-in intelligence runs on the local installation with no internet, cloud services or tokens. The Virtual Companions, AURA and LEO, use Cloud Services through the 3DEXPERIENCE platform, need an internet connection and consume tokens.

Two further points from the same source matter for production use. Virtual Companion skills are Early Access, “intended primarily for evaluation, testing, and feedback – not for production reliance”, and may give inconsistent results or change in a future release. And while many AURA and LEO skills work with locally opened files, some workflows need data stored on the platform, including BREP-to-parametric conversion, PLM insights and platform-based where-used analysis.

GoEngineer’s article was updated for 2026 SP4 / 2026x FD04, so read it as a description of current Virtual Companion behaviour and confirm the details for 2027 yourself. Then take these questions to IT and whoever owns data security:

Is our licence connected to 3DEXPERIENCE Cloud Services, and who manages token use?
When an engineer sends a prompt, what leaves the workstation: the prompt alone, or file names, properties and geometry as well?
Which of the workflows we want need files stored on the platform, and is that permitted for customer data?
Does Early Access status fit our policy for production work and customer deliverables?

If nobody can answer the second question, that is your answer for now.

Who owns the macro

GoEngineer is clear that the engineer remains responsible for design intent, calculations, validation, compliance and approval. A macro that writes properties feeding a BOM is a change to design data. It should be reviewed, approved and traceable like any other change, whoever or whatever wrote it.

The same applies to the other AI features. Dassault’s flyer describes Change Impact Analysis, where LEO flags which components and subassemblies a change affects before it is made. That is useful input to a review. It is not the review.

What this means for CAD tooling

Generation has become cheap. Review has not, and it is now the bottleneck. In my view, the tooling that earns trust will be the tooling that makes review cheap: a dry run that shows exactly which files and values would change, a log by default, scope limited to what the engineer selected, and write permission tied to PDM state so released data cannot be overwritten by accident.

That principle shapes what we are building at Bluecoderhub. AI-CAD, currently a prototype, has specialist agents plan a change, SOLIDWORKS build it, and an engineer approve every decision. Whatever tool you use, the approval step is the part worth designing carefully.

Closing

Natural-language macros will save real time on repetitive work, and they will also make it easy to damage a folder of parts very quickly. Read the verbs, test on copies, check against the model, and agree the rules before the first macro runs on anything that matters. If you have a review checklist that works for your team, get in touch, or follow the journal for more on SOLIDWORKS automation.