AutoCAD Automation: How I Choose Between LISP, .NET, and AI
There are three routes on the AutoCAD side: AutoLISP, .NET/ObjectARX, and AI-assisted generation. Here is when each is the right call, with a decision table based on team size and maintenance load.
In This Article
The AutoCAD automation question is almost always asked the wrong way round: "should I write LISP or .NET?" The right question is: who will maintain this, and how long will it live?
Those two answers pick the tool.
The honest profile of each route
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".
Decision table
The thresholds I use in practice:
| Situation | Choice | Reason |
|---|---|---|
| One person, runs a few times | AutoLISP | Don't let setup cost eat the gain |
| A team will use it, contains rules | .NET | Testing and version control are essential |
| External data / ERP connection | .NET | LISP does not carry that load |
| Scope still unclear | AI + LISP | Explore first, build the durable version after |
| Produces output that goes to production | .NET + validation | Silent faults are the expensive ones |
The last row matters most. In automation that produces manufacturing output, tool choice comes second; verifying the output comes first.
The common mistake: picking the tool before the problem
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.
Summary
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.