AutoCAD Automation: LISP, .NET, or AI? A Decision Table

AutoLISP

Fastest start. One file, no build step, runs immediately inside the drawing environment. For small, local jobs — layer cleanup, batch plotting, attribute extraction — it is still the most practical route.

Its limit arrives with complexity: weak error handling, no practical unit testing, and a large LISP file that grows harder to maintain over time. There is also a quiet cost — when the person who knew LISP leaves, the code is orphaned in most companies.

.NET / ObjectARX

Compiled, testable code that lives in version control. The right call when you need complex rule layers, external data sources, or enterprise deployment.

The price is setup cost: project structure, references, signing, deployment. For a small job that overhead is not worth paying.

AI-assisted generation

This needs care, because two different things travel under one name:

• A code-writing assistant. It writes the LISP routine or .NET add-in for you. This does not replace the two routes above — it accelerates them.
• A command-understanding assistant. It turns a plain-language description into a macro. Useful for exploration and one-off work, but it does not belong in a production flow without a validation layer.

Miss that distinction and you replace a sustainable solution with a one-off output while telling yourself "AI does this now".

The thresholds I use in practice:

The last row matters most. In automation that produces manufacturing output, tool choice comes second; verifying the output comes first.

A company arrives saying "we have these LISP routines in AutoCAD, let's have AI rewrite them." That is not the first question to ask.

First you measure: what job do these routines do, how often does that job repeat, and where is time actually being lost right now? The answer is often that half the existing routines are no longer used, and the real loss is somewhere else entirely.

I walked through that sequence in how I start an automation project — the same order applies on the AutoCAD side.

Should I choose AutoLISP or .NET for AutoCAD automation? The decision is not about technical superiority but sustainability: who will maintain the code, and how long will it live? AutoLISP for single-person, short-lived, drawing-editing work; .NET when a team will use it, when it carries rules, or when it connects to external data.

Is AutoLISP still used, or is it a dead technology? Very much alive. It has stayed almost unchanged since the 1980s and is supported in every AutoCAD release. For small, fast automations close to the drawing environment it is still the most practical route.

What is the difference between ObjectARX and .NET? ObjectARX is the C++-based, lowest-level and most powerful extension route; .NET reaches the same API through managed code. For most enterprise needs .NET is sufficient and markedly cheaper to develop.

Will AI replace LISP and .NET in AutoCAD automation? No — it accelerates both. Code assistants shorten the time to write a routine, but verifying the generated code is still on you; nothing should run in a production flow without a verification layer.

Should I migrate my existing LISP routines to .NET? Not all of them. Migrate only the ones a team uses, that carry rules, and whose maintenance has become heavy. In most companies a large share of existing routines is no longer used at all; measure what actually runs before migrating.

What matters most in automation that produces production output? Tool choice comes second; verifying the output comes first. Automation that silently produces wrong output is far more expensive than automation that crashes, because the error is caught on the shop floor.

LISP is not dead, .NET is not always right, and AI does not replace either. What decides the choice is not technical superiority but sustainability: who will read the code, who will change it, and how long it will live.

Next in the series: how to measure automation gains honestly.