NX Design Automation & Legacy Code

Your best automation was written by someone who left in 2019. Nobody has dared to touch it since.

Almost every NX shop with history has them: the VB journals that fill title blocks, the C# NXOpen macros that generate the standard housings, sometimes a GRIP program that has quietly outlived three CAD generations since the Unigraphics days. They were once the department’s productivity edge. Then the author moved on, NX kept shipping releases, and today the automation runs “somehow” — undocumented, untested, on an NX version you dare not upgrade, doing something nobody can fully explain.

That state has a price you pay twice. Once in fear: every NX upgrade becomes a gamble against your own tooling, so upgrades get postponed and the whole installation ages. And once in loss: the design logic encoded in that macro — real, hard-won engineering knowledge — is one broken API call away from being gone.

This is precisely the gap that Siemens’ copilots don’t touch: they assist inside NX generically, but they don’t know your custom code, your undocumented APIs, your works logic. We do this for a living — and large language models have fundamentally changed the economics of it. Code archaeology that took weeks of reverse engineering now takes days: understand, port to supported NXOpen APIs, test against real models. And on the same foundation, we build the new automation you never had capacity for.

// Orphaned automation, in numbers

0+ yrs

age of the oldest automation still in production at typical NX shops — some of it GRIP

0 / yr

NX releases per year — each one a potential breaking change for undocumented custom code

0 docs

lines of documentation on the macro your order flow depends on — be honest

wks → days

what LLM-assisted code archaeology did to the effort of understanding and porting legacy automation

Frozen upgrades, hostage knowledge

Ask an NX administrator why the installation is still two releases behind, and somewhere in the answer you will find a macro. Not the CAD system, not the users — the custom automation nobody can safely test, because nobody knows exactly what it does. So the upgrade waits, then waits again, and the gap between your installation and current NX grows: missing features your competitors use, security patches unapplied, support windows closing.

The deeper problem is what that code contains. A macro that generates your standard components correctly isn’t just tooling — it is the executable form of design decisions: which clearances, which naming logic, which drawing conventions. When its author left, the department lost the ability to change it; when it finally breaks, the department loses the knowledge itself. Rewriting from scratch means re-deriving rules that were already solved once.

The way out is neither “never touch it” nor “rewrite everything”. It is systematic rescue: make the code understandable again, document what it actually does, port it to supported NXOpen APIs, put it under version control and tests — and then, on that healthy foundation, extend it. Two years ago that was a luxury project. With LLM assistance doing the reading, drafting and translation while engineers review and verify, it is now routine work with a fixed price.

// Rescue in practice — the same routine, before and after

Found — journal, last edited 2016, author gone

Sub M3()  Dim s As Session = Session.GetSession()  Dim wp As Part = s.Parts.Work  ' no comments, magic numbers ahead  Dim h As Double = 12.5 * f1 + 3  Call DoIt(wp, h, 4, True, False, 2)  uf.Modl.CreateFixedDplane(...)  ' old UF callEnd Sub

Rescued — NXOpen C#, documented, current API

/// Generates the mounting-flange blank for/// housing family H3. Height rule per works/// standard: h = 12.5·sizeFactor + 3.public void CreateFlangeBlank(Part work,    H3Config cfg){  var height = FlangeRules.Height(cfg);  FlangeRules.CreateDatum(work, cfg);  // via DatumPlaneBuilder}

AI analysis (engineer-verified): this macro builds flange blanks for housing family H3; the magic constant 12.5 implements a works standard — now named, documented and unit-tested against 14 reference models.

Rescue. Build. Enable.

The offer has three layers, and they build on each other — most clients start with Rescue because that is where the fear lives, then use the healthy foundation to build what was never possible before:

01 — RESCUE

Orphaned code, back under control

Inventory of your macro landscape — what exists, what runs, what the business depends on. LLM-assisted analysis shows what each routine actually does (verified by engineers against real models), then the critical ones are ported to supported NXOpen APIs, put under version control and tested. The next NX upgrade stops being a gamble.

Code archaeologyAPI migrationJournals · GRIP · KF

02 — BUILD

New automation, at LLM speed

Modeling automation, drawing derivation, batch processing, Teamcenter-integrated workflows — described in your language, drafted by LLM, engineered and tested by us. Development that used to price itself out of reach now fits mid-sized budgets, and everything ships deterministic: the same input produces the same released result, every time.

NXOpen C# / C++ / PythonDrafting automationBatch & TC workflows

03 — ENABLE

Your team keeps the keys

The point of the rescue is that it never happens again. The code is versioned, and your power users learn to read and extend it with LLM assistance — a skill that no longer requires a dedicated developer — and maintenance guidelines define how changes are tested and released. We stay available for the hard cases; we refuse to become the next single point of failure.

TrainingVersion controlLLM-assisted maintenance

When does this pay off?

You are a candidate if most of these sound familiar:

Custom NX automation exists — journals, NXOpen macros, Knowledge Fusion rules — and its authors are gone or going.
NX upgrades are postponed out of fear for the custom code, and the installation is aging with them.
Nobody can say what exactly the critical macros do — there is no documentation, no tests, no version control.
Repetitive modeling and drawing work is done by hand because new automation was always too expensive to commission.
Variant-intensive product families beg for automation — the case our variant design offer covers end-to-end.
You run Siemens NX (any recent version — that’s rather the point) and want tooling on supported extension points.

Our NX automation stack

Full-stack NX development across the technologies your automation runs on — old and new.

NXOpen (C# / C++ / Python) Journals (VB) GRIP analysis & migration Knowledge Fusion Product Template Studio Drafting Automation Batch / headless NX Teamcenter integration (SOA/ITK) Version control · CI · tests LLM-assisted development (on-prem)

Before and after: NX upgrade day

The clearest test of your automation’s health is the day a new NX release lands. Here is that day, on both sides of the change:

Before — the gamble

Upgrade postponed twice — "because of the macros"
Test plan: run everything once and hope
Title-block journal fails silently — found by a customer
The one colleague who "sort of knows" the code is on vacation
Rollback. Next attempt: next year

After — the routine

Automation runs against the new release in a test environment — before rollout
Test suite reports two API deprecations — fixed in an afternoon
Every routine documented — no colleague is a single point of failure
Upgrade ships on schedule — users get current NX, IT gets its weekend
The macros are an asset again — and a foundation to build on

Why inteliScience — and how we use AI without gambling

This page describes our home discipline. We build NX and Teamcenter customizations every day, on Siemens’ supported extension points — the same upgrade-safe philosophy behind our Teamcenter programming practice applies to every line of NXOpen we touch. And we speak both languages the job needs: the code and the construction. An engineer who has never sat next to a designer will port your macro’s syntax and miss its intent; our people recognize that the magic number 12.5 is a works standard, not a whim.

On AI, the division of labour is strict, because production CAD tooling is no place for improvisation. LLMs read, draft, translate and explain — they are spectacular at digesting an undocumented codebase and proposing a modern equivalent. Engineers review, test and release — every ported routine is verified against real reference models before it goes anywhere near production, and everything ships deterministic and version-controlled. The LLM does not run in your NX; its output does, after it has earned the right to.

One honest note on GRIP and the truly ancient: not everything ports one-to-one, and pretending otherwise would be selling you archaeology as magic. Where direct migration doesn’t make sense, we extract the logic — the rules the code encodes — and rebuild it cleanly on NXOpen. The knowledge survives; the technical debt doesn’t.

Fixed price — no day rates, no surprises

Automation Rescue Pilot

€9,900 fixed

Full inventory of your automation landscape — what exists, what runs, what's critical
LLM-assisted analysis of the top routines — engineer-verified
Your most business-critical macro modernized, ported and tested on current NX
Version control, test setup and release process established as the template
Modernization roadmap for the rest — prioritized by business risk

Start the pilot conversation

2–3 weeks · on your NX installation · all code, docs and the roadmap are yours, whatever you decide afterwards.

For comparison

The cost of the frozen state

Rewriting the critical macros from scratch when they finally break — under time pressure
Years of NX features and fixes your users don't get while upgrades wait
And the un-priced risk: design knowledge that exists only as unreadable code

Frequently asked questions

LLM-generated code in production CAD tooling — is that safe?

Not by itself — which is why that's not what we do. The LLM reads, drafts and translates; engineers review every line, and nothing ships without passing tests against real reference models from your production. What lands in your NX is deterministic, version-controlled, human-released code that happens to have been developed several times faster than it used to be. The AI accelerates the work; it never becomes the release authority.

We still run GRIP programs. Can those really be migrated?

Case by case — and we'll tell you honestly which case yours is. Some GRIP ports cleanly; much of it shouldn't be ported at all but translated: we extract the logic the program encodes — the rules, the conventions, the calculations — and rebuild it on supported NXOpen APIs. The distinction matters: you are preserving thirty years of design knowledge, not thirty years of syntax. The inventory phase of the pilot classifies every routine into port, rebuild, or retire.

Our macro author is still here. Do we even need this?

That is the best possible moment — genuinely. Documentation written while the author can still verify it is worth double, and the step from "knowledge in one head" to "versioned code your team can test" is fast and cheap now, expensive and lossy after the farewell party. Several rescue projects start exactly this way: as structured knowledge preservation twelve months before a retirement.

Can our own people maintain the automation afterwards?

Rights are agreed in the contract. And maintainability is a design goal, not a promise — code is written to be read, and the Enable layer trains your power users to extend it with LLM assistance, which has genuinely lowered that bar: reading and adapting NXOpen code no longer requires a career developer. We stay available for the hard cases, but the everyday changes stop needing us. We refuse to become the next single point of failure — that would just repeat the story this page starts with.

Isn't this what Siemens' NX copilots will do anyway?

No — different layer. Siemens' copilots assist users inside NX with generic knowledge: commands, best practices, standard workflows. They don't know your macro landscape, your works standards encoded in twenty-year-old code, or your Teamcenter integration — and they don't port, test or release anything. Custom automation on your own logic is exactly the layer that stays works-specific, which is why it's ours to build and yours to own.

How does this relate to your variant design automation offer?

This page is the capability; that page is its biggest payoff. Variant design automation (see our energy offer for transformer manufacturers) is what you build once the foundation is healthy: rules that turn order parameters into models and drawing sets. Many clients sequence it exactly so — Rescue first, because the old macros usually contain half the rules already, then Build the variant automation on top. If your pain is variants rather than legacy code, start on that page; the technology underneath is the same.

Somewhere in your NX runs a macro nobody understands. Let's make it yours again.

Send us your scariest routine — the one nobody dares to touch — and we'll show you what the LLM-assisted analysis finds in it, verified by an engineer who speaks NXOpen.

Talk to an NX Automation Engineer

Always here to support you – reach out to us with your questions, and we’ll guide you every step of the way.

Phone: +40 774 463 429
Our Location: Str. Ploiești 9, 400157
Cluj-Napoca, Romania
Email: info@inteliscience.net
LinkedIn: inteliScience on LinkedIn
YouTube: inteliScience on YouTube