NX Open Code Generation: The Short Version
NX Open code generation means using a language model to write the Python or C# that automates Siemens NX. Models handle the scaffolding reliably and invent API calls that do not exist. inteliScience grounds them on the NX Open reference and verifies every journal headless before it reaches an engineer’s seat, which roughly halves the time to a reviewed automation.
| Ungrounded LLM output | Grounded and verified pipeline | |
|---|---|---|
| First draft speed | Minutes | Minutes |
| API calls that compile | Often wrong | Checked against the reference |
| Safe on a production seat | No | Yes, after a headless run |
The Problem: Why NX Open Trips Up Language Models
Code assistants are only as good as the amount of public code they were trained on, and NX Open is a thin corpus. Compare the volume of React or pandas code on GitHub with what exists for NXOpen: the most-starred community tutorial collection, Foadsf/NXOpen_Python_tutorials, sits at 97 stars and 12 forks, last pushed February 19, 2026 (retrieved July 28, 2026). That is the public training signal for an API surface of several thousand classes.
The result is a specific failure mode. A model asked for an NX Open journal will produce something that reads like correct NX Open — right imports, right session pattern, plausible method names — and then call a method that Siemens never shipped.
This is measurable. A 2026 replication study across five frontier code models — Claude Sonnet 4.6, Claude Haiku 4.5, GPT-5.4-mini, Gemini 2.5 Pro and DeepSeek V3.2 — found package-name hallucination rates between 4.62% and 6.10% over 199,845 prompts, down from the 5.2%–21.7% spread reported by Spracklen et al. at USENIX Security ’25 but far from solved (arXiv:2605.17062). Those numbers are for PyPI and npm — registries the models have seen millions of times. For a proprietary CAD API, the miss rate on specific method signatures is considerably worse.
Engineers feel this as wasted time rather than as a security issue. You get code that looks finished, spend forty minutes debugging it inside NX, and discover the model needed a completely different object hierarchy.
What AI Gets Right, and Where It Invents API Calls
Models are good at structure and bad at recall. The scaffolding of an NX Open journal — session handle, work part, listing window, iteration, error handling — is stable across the whole API and well represented in what public examples exist. This kind of thing comes out clean:
import NXOpen
def main():
session = NXOpen.Session.GetSession()
work_part = session.Parts.Work
lw = session.ListingWindow
lw.Open()
for body in work_part.Bodies:
lw.WriteLine(f"{body.JournalIdentifier} solid={body.IsSolidBody}")
if __name__ == "__main__":
main()Now ask the same model for the mass of a body. Variants like the three below show up again and again across current assistants, and none of them exists in NX Open:
# Invented — none of these are real NX Open calls
mass = work_part.GetMass()
mass = body.Mass
mass = NXOpen.MeasureManager.GetMass(body)
# What NX Open actually requires: a unit array, an accuracy, the part's MeasureManager
session = NXOpen.Session.GetSession()
work_part = session.Parts.Work
uc = work_part.UnitCollection
units = [uc.FindObject("SquareCentiMeter"), uc.FindObject("CubicCentiMeter"),
uc.FindObject("Gram"), uc.FindObject("CentiMeter"), uc.FindObject("Newton")]
props = work_part.MeasureManager.NewMassProperties(units, 0.999, [body])
mass = props.Mass # in grams, the mass unit in the array
props.Dispose()The real path needs a unit array assembled from the part’s own unit collection, an accuracy tolerance, and disposal of the measurement object afterwards. No amount of prompting gets a model there reliably, because this is recall, not reasoning — a point the hallucination literature makes explicitly: reasoning-distilled models hallucinate library APIs at the same rate as their non-reasoning siblings.
Where the pattern holds
Anything that reads the part is easy to fix when wrong. Anything that writes geometry, edits assemblies, or touches Teamcenter is where a wrong call gets expensive, because the failure may not surface until someone opens the part three weeks later.
Grounding and Verification: The Loop That Makes It Usable
Two changes turn NX Open code generation from a party trick into a working method.
Ground the model on the actual reference
Retrieval over the NX Open documentation for your exact NX version, plus your own existing journal library, plus your naming and attribute standards. The model stops guessing at signatures because the correct ones are in its context. This is the same architecture behind the NX knowledge assistants we build for engineering teams, pointed at code instead of at documentation questions — inteliScience runs these on-premise where GDPR or IP constraints rule out sending part data to a public API.
Verify by running, not by reading
Every generated journal goes through NX in batch mode against a set of representative test parts before a human ever sees it. Compile errors and invented methods die immediately. What survives gets a real review.
This runs as a POC. What’s missing for production: version pinning across two NX releases a year, batch execution and error handling on part-load failures, Teamcenter session context, rollout to hundreds of seats, and a regression suite that tells you when a Siemens update broke your journal. We close the gap from “runs on my machine” to “runs in the enterprise” — talk to our engineers about NX Open programming.
Our clear recommendation: no generated NX Open code reaches a production seat without a headless run against test parts. Teams that skip this step do not save time, they move the debugging to the engineer who trusted the script.
Where NX Open Code Generation Pays Off First
Start where the task is repetitive, the output is checkable, and a mistake is cheap. That ordering matters more than the choice of model.
| Task | AI leverage | What still needs an engineer |
|---|---|---|
| Batch drawing and PDF export across an assembly | High | Naming rules, revision logic |
| Attribute clean-up and Teamcenter sync | High | Mapping to your PLM schema |
| Report and BOM extraction from part data | High | Output format, edge cases |
| Parametric family creation | Medium | Design intent, tolerancing |
| CAM operation setup | Medium | Machine limits, fixturing |
| Geometry creation from scratch | Low | Nearly all of it |
Why geometry generation is the wrong pilot
We would advise against starting with geometry creation, which is where most pilots begin and most pilots stall. The gap between “a block appears” and “a manufacturable feature that respects your design rules” is the entire job.
For teams still mapping out which workflows to automate at all, our 2026 guide to NX AI and NX Open automation works through the ROI side of that decision.
Designcenter Copilot Is Not a Code Generator
Siemens renamed NX CAD to Designcenter with the June 2026 release, version 2606 (Siemens Designcenter blog); NX for Manufacturing 2606 shipped June 19, 2026. The headline AI feature is Designcenter Copilot, a conversational assistant grounded in Siemens documentation and your current context. The release notes say nothing about changes to the NX Open API itself.
That distinction gets confused in almost every conversation we have. Copilot answers questions. It does not write your automation.
| Designcenter Copilot | IDE assistant | Grounded NX Open pipeline | |
|---|---|---|---|
| Answers “how do I…” from Siemens docs | Yes | Partly | Yes |
| Writes NX Open journals | No | Yes, unverified | Yes, verified |
| Knows your standards and naming | No | No | Yes |
| Runs and tests the result | No | No | Yes, headless |
| Deployable across hundreds of seats | n/a | No | Yes |
The assistant layer sits next to your automation, not on top of it
Siemens is pushing hard here, and the numbers they quote are real: Michael Taesch, senior director of product management for NX CAM, estimates NX CAM Copilot saves 80% or more of CAM programming time. Teamcenter 2606, also June 2026, shipped the first AI BOM agent that proposes and executes multi-step changes. None of that replaces the automation you own.
In practice, the IDE-assistant-only approach rarely survives contact with an NX upgrade. Nobody owns the script, no test tells you it broke, and the engineer who generated it has moved on.
If your own engineers are to own that code, they need the API knowledge behind it. The Siemens NX training courses from inteliScience include an NXOpen course on your own parts, in-house or live online.
Frequently Asked Questions
Can ChatGPT or Claude write working NX Open code?
For scaffolding and read-only journals, often yes on the first try. For anything involving specific method signatures — measurement, assembly editing, Teamcenter access — expect invented API calls. The fix is retrieval over the NX Open reference for your NX version plus a headless test run, not a better prompt.
How much does an AI-assisted NX Open automation project cost?
A single well-scoped automation, such as batch drawing export with your naming rules, sits in the low five figures including the verification harness. The harness is the part teams underestimate: it is usually 40–60% of the effort and the reason the automation still works after the next NX release.
NX Open Python or C#?
Python for journals, exploration, and anything a small team maintains. C# when you are shipping a compiled add-in with a UI, need performance on large assemblies, or have to integrate into an existing .NET toolchain. Models are noticeably better at the Python variant, simply because more of it exists publicly.
Does Designcenter Copilot replace custom NX Open automation?
No. Copilot is a documentation and guidance assistant inside the application; it answers questions about how to do something. Custom NX Open code executes the work unattended, across an assembly or a whole release, according to your rules. They solve different problems.
How do we stop generated code from breaking on the next NX release?
Pin the NX version in your build, keep a regression suite of representative test parts, and run it against every new release in a staging environment. Siemens ships roughly twice a year, so this is a scheduled task, not a surprise.
Next Step
Bring one repetitive NX workflow to a 60-minute call. We will tell you whether AI-assisted NX Open automation is the right tool for it, and what the verification harness would need to look like. inteliScience delivers this with senior NX Open engineers from Romania, just one hour ahead of our DACH clients.