Cómo automatizar AutoCAD 2027 con Claude Code: qué vía usar para cada cosa

Resumen

Conclusiones

• AutoCAD 2027 tiene diez formas de programarlo. Para casi todo, te sobran tres: .NET, AutoLISP y la consola (accoreconsole).
• .NET para complementos con interfaz. AutoLISP para rutinas y prototipos. La consola para procesar cientos de dibujos sin abrir AutoCAD.
• Para que Claude programe bien AutoCAD, el lenguaje importa poco. Importan tres cosas: un inventario para comprobar cada nombre, un bucle rápido de ejecutar y ver, y conocer las rarezas del entorno.

Lo clave

• 10.000 líneas: .NET 60 ms, LISP 109 ms, COM desde otro programa 7–10 s.
• COM desde fuera, contar 100.000 entidades: 176 s recorriéndolas, 0,6 s filtrando del lado de AutoCAD. Cada llamada cuesta ~1 ms.
• 100 dibujos en la consola: 8,3 s en un solo proceso, 277 s con uno por dibujo. Con 8 consolas en paralelo, ×5,6, sin límite de licencia.
• Claude, con inventario: 0 funciones LISP inventadas, 1 error en ~230 líneas de C++ y Design Automation a la primera. Donde falló fue VBA, sin compilador ni inventario: supuso comandos que no existen.
• Sin API en ninguna vía: bloques dinámicos desde cero, restricciones geométricas (.NET y COM), cotas asociativas, RECOVER.
• Fallos silenciosos: una DLL fuera de una carpeta de confianza no carga y no avisa. En la consola, un comando inexistente termina con código 0.

Recomendaciones

1. Declara una carpeta en TRUSTEDPATHS y carga todo desde ahí.
2. Dale a Claude un inventario de la API y que compruebe cada nombre. Copia el CLAUDE.md para AutoCAD.
3. Elige la vía por la tarea, no por costumbre: la lista «qué vía para qué» está abajo.
4. Para lotes, la consola con una DLL y todos los dibujos en un proceso. Lánzala con tiempo límite y la entrada cerrada.
5. COM solo para órdenes grandes, con DispatchEx. VBA, solo para mantener lo que ya existe.

---

1. Qué vía para qué

Medido con 244 pruebas en AutoCAD 2027 (R26.0, build 26.0.118, licencia educativa), .NET 10 y Visual Studio 2026.

• Complemento con botones, paletas y comandos → .NET. Es la única vía que llega a toda la interfaz, con breakpoints de Visual Studio.
• Cientos de dibujos en tu PC → accoreconsole con una DLL que los abre con ReadDwgFile uno tras otro, en un solo proceso: 5 ms por dibujo.
• Dibujos en un servidor, sin AutoCAD instalado → Design Automation (APS). Es el mismo código que en la consola: 3,7 s en el servidor y 18 s de ciclo completo. Fuera de la cuenta de estudiante se paga en créditos.
• Rutinas del día a día y prototipos → AutoLISP. Es el ciclo más corto (~0,8 s) y es solo de 2 a 6 veces más lento que .NET.
• Controlar AutoCAD desde Python u otro programa → COM, pero solo para órdenes grandes: SelectionSet filtrado, ObjectDBX (100 dibujos en 3,3 s) o SendCommand.
• Entidades propias o lo que .NET no expone → ObjectARX (C++). Es la única vía que descarga y recarga de verdad. A cambio, un error nativo tumba AutoCAD.
• Botones y menús para usuarios → CUIx y macros, sin código compilado.
• Solo leer DWG o DXF → ACadSharp o ezdxf, sin AutoCAD.
• VBA → mantener lo que hay. No se puede guardar el proyecto por código, no funciona en la consola y una macro lanzada desde un .scr puede tumbar AutoCAD.

2. La velocidad depende de cuántas veces cruzas de un programa a otro

• 10.000 líneas: .NET 60 ms · LISP 109 ms · COM dentro de AutoCAD 163 ms · COM desde fuera 7–10 s · .scr puro 7 s.
• Contar 100.000 entidades por capa: .NET 326 ms (32 ms en una base lateral) · LISP 0,6–0,9 s · COM desde fuera 176 s recorriendo y 0,6 s con un filtro.
• Cambiar de capa 10.000 entidades: .NET 106 ms · LISP 312 ms · COM desde fuera 17,7 s.

COM desde otro proceso cuesta de 0,7 a 1 ms por llamada, entre 100 y 500 veces más que dentro. La regla: que AutoCAD haga el trabajo y devuelva el resultado, en vez de traer las entidades una por una.

3. La consola: lotes sin interfaz

accoreconsole es un AutoCAD sin ventana, oficial, que abre un dibujo, ejecuta un script y se cierra. La licencia no limita cuántas abres a la vez.

accoreconsole.exe /i dibujo.dwg /s script.scr

• Arranca en 1,5 a 5 s, y dentro el trabajo va igual de rápido que en AutoCAD normal: 10.000 líneas en 25 ms con una DLL.
• Un proceso para todos los dibujos: 100 dibujos (cambiar un atributo y guardar) en 0,5 s de trabajo más 7,8 s de arranque. Un proceso por dibujo: 277 s.
• 8 consolas en paralelo: ×5,6.
• Carga DLL de .NET, LISP y módulos .dbx/.crx de ObjectARX. No tiene COM ni VBA.

Las trampas, todas comprobadas:

• Sin /i sale con error 53.
• Si no le cierras la entrada estándar, se queda esperando teclado para siempre.
• QUIT con el dibujo modificado la cuelga.
• Un comando que no existe termina con código 0, como si todo hubiera ido bien. Hay que leer la salida.
• NETLOAD solo funciona desde una carpeta de confianza. Si no, falla sin preguntar.
• Tocar la interfaz (AcadApplication, StatusBar) tumba el proceso sin excepción. Escribe trazas a un archivo, porque la salida estándar se pierde.
• La salida es UTF-16 mezclada con ASCII.

El lanzador resuelve las tres primeras: pasa el dibujo, cierra la entrada, pone un tiempo límite y limpia la salida.

4. Prepara el entorno para Claude

1. Una carpeta de confianza. Agrégala a TRUSTEDPATHS (se puede por código con SetSystemVariable) y carga todo desde ahí. «Cargar siempre», en el aviso de seguridad, no se recuerda entre arranques. Fuera de una ruta de confianza, a veces no sale ningún aviso: el comando simplemente no existe.
2. Inventarios de la API, para que Claude compruebe cada nombre antes de usarlo:
   • .NET: por reflexión de acdbmgd, acmgd y accoremgd (2.093 tipos y 19.679 miembros).
   • LISP: con atoms-family (2.759 funciones en la interfaz y 2.608 en la consola).
   • Comandos: (getcname "_NOMBRE") antes de usarlos en un script.
3. .NET con net10.0-windows, como bundle en %APPDATA%\Autodesk\ApplicationPlugins (los de %ProgramData% se ignoran). Una DLL cargada no se puede descargar, y el Hot Reload de Visual Studio no funciona. Para iterar sin reiniciar hay que construir un cargador propio: con él, compilar y ver el resultado tarda 2,2 s, frente a 11–14 s reiniciando.
4. Pruebas peligrosas en una instancia aparte, que no importe perder.

La plantilla de CLAUDE.md junta todo esto con las trampas de cada vía.

5. Claude programando cada vía

En 34 tareas con inventario y bucle de ejecución: 151 compilaciones (11 fallidas) y 873 ejecuciones en AutoCAD (22 fallidas).

• .NET: los fallos de compilación fueron pocos y baratos, y los detectaron el compilador y el inventario. Lo caro fueron las rarezas que solo salen al ejecutar.
• AutoLISP: 0 funciones inventadas en 91 líneas y 5 de 5 rutinas a la primera.
• ObjectARX: ~230 líneas de C++ con un solo error: faltaba una cabecera. Buscar cada firma en las cabeceras del SDK hizo de inventario.
• Design Automation: todo el ciclo REST (autenticación, subida, AppBundle, Activity, WorkItem) a la primera.
• COM desde Python: el código salió bien a la primera; los problemas fueron del entorno.
• VBA: el código salió bien, pero Claude supuso que existían VBASAVE y VBProject.SaveAs, y no existen. Sin compilador ni inventario, cada suposición falsa cuesta una ejecución.

De más fácil a más difícil para Claude: .NET con cargador, LISP y Design Automation; luego ObjectARX y COM; al final VBA.

6. Lo que ninguna vía hace

• Crear un bloque dinámico con parámetros y acciones. Solo se cambian las propiedades de uno que ya existe.
• Restricciones geométricas desde .NET o COM. Solo con el comando GEOMCONSTRAINT.
• Una cota asociativa por código: queda suelta y hace falta DIMREASSOCIATE.
• Recuperar un dibujo dañado (RECOVER).
• Guardar con contraseña: ya no existe.
• Guardar un proyecto VBA: solo desde un diálogo.

APIs que fallan: Hatch.Area siempre devuelve error; IsMerged no sirve (usa IsMergedCell); DataLink no acepta CSV.

7. Las trampas de cada vía

• COM agarra el AutoCAD equivocado. GetActiveObject devuelve siempre la primera instancia, que puede ser la tuya con trabajo sin guardar. Usa DispatchEx para tener una propia, y ciérrala con Quit(): si no, queda un AutoCAD oculto.
• COM se rechaza durante minutos (RPC_E_CALL_REJECTED) sin razón visible, y pywin32 lo muestra como AttributeError.
• Las librerías chocan: gana siempre la Newtonsoft.Json de AutoCAD.
• Los complementos viejos siguen andando: DLL de 2024 (.NET Framework 4.8) y 2025 (.NET 8) cargaron en 2027.
• .NET y el contexto: desde el contexto de aplicación hay que bloquear el documento (LockDocument), y después de un await que no sea CommandAsync se pierde el contexto de comando.
• LISP: vl-catch-all-apply no atrapa funciones inexistentes, unos 20.000 niveles de recursión matan LISP en silencio y write-line escribe en ANSI.

8. Lo que tumba AutoCAD

Sin que ningún try/catch lo evite:

• una recursión infinita en .NET;
• escribir en un objeto después de cerrar su transacción;
• tocar la interfaz desde la consola;
• un puntero nulo en un módulo de C++;
• abrir una base de datos de AutoCAD fuera de AutoCAD (la geometría sí funciona fuera);
• lanzar una macro VBA desde un .scr con el proyecto sin guardar.

Después del choque, AutoCAD ofrece recuperar el dibujo. En C++, el informe de error dice qué módulo lo causó.

Cómo se midió y qué no

• 244 de 244 pruebas en 22 familias: 177 funcionan, 54 con condiciones, 8 no se pueden y 5 tumban AutoCAD. Cada afirmación del tipo «X provoca Y» lleva una prueba de control.
• No probado: los proyectos de ejemplo del SDK de ObjectARX, restricciones geométricas por ObjectARX, SECURELOAD=0 con VBA y el coste de Design Automation fuera de la cuenta de estudiante.
• Límites: un equipo, una licencia y un modelo (Claude Opus 5.5). Las medidas se repitieron pocas veces (normalmente 3): las diferencias de menos del 20 % no son concluyentes. Las cifras de Claude salen de un laboratorio largo, no de una comparación de vías con las mismas tareas en sesiones nuevas.

Material de libre uso

• CLAUDE.md para AutoCAD: la plantilla para empezar.
• Lanzador de la consola (Python), con tiempo límite y salida legible.
• Informe final de AutoCAD 2027: cada vía con lo que puede, lo que no, su velocidad y sus trampas.
• Checklist de las 244 pruebas, cada una con su resultado.