What would you build for DraftSight if writing the code were no longer the first hurdle?
Maybe your team runs a drawing check repeatedly. Or you have a repetitive process involving hundreds of files. Or you wish a tool existed for a workflow unique to your company. Or perhaps there is information trapped in one system that you would rather bring directly into your CAD workflow.
For years, APIs have helped tackle problems like these. The challenge was getting from an idea to working software. You needed to understand the API, write and compile code, and troubleshoot errors before you had something that worked. Without programming experience or access to a developer, a useful idea could stop there.
AI is beginning to change that part of the equation.
In the on-demand webinar Build Custom DraftSight Add-Ins with AI, DraftSight Technical Sales Manager Brian Vanasse explores what happens when someone who understands DraftSight and the workflow they want to improve uses AI to help navigate the software development process.
Brian is not a professional software developer. He knows DraftSight. He understands 2D CAD. Most importantly, he knows what he wants the software to do. His expertise remains central to every example in the webinar.
The API Is the Doorway
To understand where AI fits, it helps to understand what makes these customizations possible: the DraftSight API.
An application programming interface, or API, provides a structured way for software to interact with other software. In DraftSight, the API provides capabilities developers can use to automate tasks, create custom functionality, and connect DraftSight to other applications and business systems.
Consider a repetitive CAD task. Perhaps hundreds of drawings need to be opened, inspected, modified, printed, or exported. If the workflow follows predictable rules and the API provides the required capabilities, an application could perform those operations automatically, rather than requiring someone to process every drawing manually.
Customization opens another set of possibilities. A company might have specific layer standards, required blocks, title block conventions, or drawing checks that must be completed before release. Using the DraftSight API, developers can build add-ins around workflows like these and integrate them into the DraftSight user experience.
The same principle applies to integration. Drawing numbers, revisions, materials, attributes, part numbers, and project information may need to move between CAD and other systems. APIs provide a mechanism for software to exchange that information rather than relying entirely on manual transfer.
None of this is new simply because AI has entered the picture. The DraftSight API already provides the underlying capabilities.
What is changing is how someone can approach using them.
AI Can Help Bridge the Gap Between an Idea and the API
Traditional API development requires the developer to translate a requirement into a series of technical decisions: which API objects and methods to use, what parameters they expect, and how to structure the code.
In the webinar, Brian uses Claude Co-work to assist with that process.
Rather than beginning with code, he begins with a problem or an idea. AI helps him work through the DraftSight API documentation, generate code, and troubleshoot errors as he builds working add-ins.
AI does not remove the human part of development. Brian defines what he wants to accomplish. He decides what the user experience should be. He tests what the AI produces inside DraftSight. When something fails, he reports what happened and continues iterating.
The process is not one prompt followed by a perfect application. It is a collaboration built around domain knowledge, testing, feedback, and refinement.
The webinar shows what that process looks like through several very different DraftSight add-ins.
Bringing an AI Assistant Into DraftSight
Brian’s first idea sounds simple: instead of continually switching between DraftSight and a browser to use an AI assistant, why not put the AI experience directly alongside the drawing?
The result is a custom DraftSight add-in with a dockable AI chat palette.
The palette gives users access to different AI providers while they continue working in DraftSight. In the demonstration, Brian asks questions about DraftSight workflows and uses AI for design guidance, all within the CAD environment.
The example has an important boundary. The AI assistant does not directly read or modify the drawing through this add-in. It is there as a resource for the person doing the work.
This boundary is useful when thinking about AI’s role in design. AI doesn’t replace the designer’s judgment or take control of the design process. It can augment the person doing the work by making information, guidance, and troubleshooting help more readily available while that person remains responsible for the drawing and the decisions behind it.
The finished palette is interesting, but the development story behind it is arguably more important.
Brian didn’t know how to architect the add-in, write its C++ and C# components, build the browser integration, register the application correctly, or package it for installation. Working with Claude Co-work, he went through architecture, coding, and testing before deployment.
When an early version produced an error, he sent it back to Claude. When the add-in failed to appear in DraftSight, he reported the result and continued troubleshooting. Eventually, the add-in loaded successfully and was packaged with a simplified installation process.
Then the Experiments Get More Ambitious
Once the first architecture was working, Brian began testing what else he could build. One experiment tackles a file interoperability problem: bringing geometry from a Rhino 3DM file into DraftSight through a custom add-in.
This example also shows why understanding an API’s limitations matters. The resulting tool is not presented as a perfect 3DM importer. During development, Claude checked what the DraftSight API could support. When the team explored native import of solids and surfaces, the available API did not provide the path needed to create the required BREP geometry.
The resulting add-in creates a usable representation of supported geometry inside DraftSight that you can view, reference, navigate, and incorporate into the drawing workflow. This is an example of something that becomes important whenever AI is used for technical work: the goal is not simply to generate an answer. The result still needs to be checked against what the underlying software and API can do.
Rethinking an Existing G-Code Workflow
Not every AI-assisted development project needs to start from scratch. For another example, Brian takes an existing DraftSight G-code generator add-in and asks Claude to help redesign it. The objective is partly visual, but it goes deeper than changing the interface.
The workflow has been reorganized into clearer sections for export, import, and profiles. The project also adds multiple G-code profiles, color-coded toolpath visualization inside DraftSight, and the ability to import existing G-code into a drawing for visualization and troubleshooting.
In the demonstration, you can select DraftSight geometry and convert it into machining operations before generating G-code. In the other direction, users can import existing G-code and reconstruct it as DraftSight geometry, providing a visual representation of the code’s description.
The example also includes unfinished work. The toolpath visualization does not yet display exactly as Brian wants. AI-assisted development still involves iteration. Test it, figure out what’s wrong, describe the problem, and revise. Then test again.
A Smaller Idea Can Still Solve a Real Problem
The final example turns from file translation and manufacturing workflows to something more familiar: learning how to use CAD commands.
Brian creates a Command Advisor that displays information in a dockable DraftSight palette when a supported ribbon command is selected. The palette provides command syntax, available option keys, and practical tips before the user launches the command and returns to the drawing.
The library covers roughly 80 commands across nine ribbon tabs.
It is a simple idea compared with translating 3DM geometry or generating G-code, but that is precisely why it is useful. Custom development does not always have to solve a large engineering problem. Sometimes it can simply remove friction from an everyday task.
Start With the Problem, Not the Code
Across all four examples, the starting point is an understanding of the work. What are you doing repeatedly today? Where are people manually transferring information that could move automatically instead? Those are questions a CAD user, designer, engineer, or organization may be better positioned to answer than an AI system.
AI can also assist with another part of the process: navigating API documentation, generating code, and diagnosing errors. The DraftSight API provides the mechanisms for interacting with the application. The person provides the problem, context, testing, judgment, and definition of a useful result.
The webinar brings those pieces together through demonstrations, including parts that required troubleshooting and places where the API imposed limits.
If you have ever looked at a repetitive DraftSight workflow and thought, “There should be a better way to do this,” the on-demand session is worth watching. The examples offer a practical look at how ideas can move from a CAD user’s experience into custom DraftSight functionality with AI.
Watch the on-demand webinar, Build Custom DraftSight Add-Ins with AI, to see the add-ins in action and follow the development process behind them.
Try DraftSight for Free for 30 days.