A FIRST STEP FOR GENERATIVE MCAD

There are many companies exploring AI in mechanical design in 2026. Before we jump into generative design, let’s first acknowledge that AI can help with many aspects of the design process. Generative design is just one, albeit a very important, aspect of the design process. AI can add value across the full design workflow —research and literature review, design review, part sourcing, tolerance analysis, and more. That said, generative MCAD (Mechanical Computer-Aided Design, as opposed to Electrical CAD or other computer design tools) is the biggest potential change to the design workflow, and there are different approaches to getting there.

The Code-First Approach

As I noted in my post on AI trends in hardware development, several companies are tackling generative geometry by using programming languages for CAD generation. This allows them to leverage the proven strengths of LLM’s in the 3D geometry generation process. Companies like Zoo and Component AI are doing genuinely impressive work in this space, and I don’t want to dismiss it.

I’m not yet bought in that Mechanical Engineers writing part specifications to feed a code generation LLM is the right approach from the engineer’s perspective —at least not as the primary interaction model. Consider the distribution of brain function: roughly 30% of the human brain is devoted to visual processing, compared to a far smaller share for language. Visual-spatial reasoning tends to be a core competency that self-selects into mechanical engineering. MEs tend to have strong 3D visualization skills — it’s part of what makes them good at their jobs.

Now think about a complex injection-molded part like the image below: organic curves, draft angles, ribs, bosses, snap fits. I don’t know how I would write a precise textual description of that geometry from scratch.

Figure 1: Automotive Dashboard

The population’s visual-spatial skills and comfort with language interfaces will likely shift over time due to the prevalence of 3D gaming, AR and VR. In additional, the generation of engineers currently in college are growing up with conversational AI. This will likely change things in the future, but for now tool providers are selling to a generation of engineers that didn’t grow up in that world.

The First Step: Autocomplete for CAD

On May 27, 2026, I had the opportunity to speak with Sohrab Haghighat, CEO of Hestus, a company taking a different approach to generated MCAD. Rather than trying to generate geometry from a prompt, Hestus is focused on what Sohrab described as “autocomplete for CAD” — specifically, predicting the next likely actions as an engineer constructs a 2D sketch in a parametric MCAD tool.

If you’ve spent time using a parametric MCAD tool like SOLIDWORKS, Onshape by PTC, Fusion 360, or Creo, a PTC Technology, you know the amount of work required to fully constraining a 2D sketch. This work can be time-consuming and tedious. It’s also exactly the kind of repetitive, pattern-heavy work at which ML models tend to excel.

Why This Approach Makes Sense

There are several reasons I think the autocomplete approach is will be a commercial success, both for user adoption and for extensibility into more advanced geometric data generation.

It addresses a real pain point for engineers. A tool that meaningfully reduces friction in the design process has a clear value proposition. Doing so without requiring anyone to rethink their workflow removes a significant barrier to adoption. Engineers can start using the tool right away, and see benefits immediately.

It follows a proven playbook. GitHub Copilot didn’t start with trying to generate entire applications. It started with line and code block completion, built trust incrementally, and expanded from there. The autocomplete model worked in software because it kept the engineer in the loop and built confidence in the tool.

It generates its own training data. By observing which suggestions engineers accept, modify, or reject, the system can continuously generate labeled training data at scale. That’s a significant competitive moat. The model can get better the more it’s used, and the usage data is uniquely valuable because it reflects real engineering judgment, not synthetic generation.

There’s a credible path to expanded capabilities. Sohrab outlined a natural progression: from 2D sketch constraint prediction to feature prediction, then to part-level suggestions, and ultimately to assembly-level intelligence. Each step builds on the last and the training data collected. These are not trivial engineering problems, but the path is plausible.

Text Input as a Complement

While autocomplete is the current interaction focus, Sohrab was clear that text based input has a role in Hestus’s vision — just not as the primary driver. He described how text is appropriate for describing aspects of the design that should impact the geometry generation: target manufacturing process (machining, injection molding, etc.), a list of mating parts and design standards are all easily provided through text input.

The combination of direct geometric interaction and natural language context seem to me to be a powerful architecture.

Looking Ahead

Hestus isn’t trying to replace the mechanical engineer. It’s trying to remove the friction that keeps engineers from spending their time on the work that actually requires engineering judgment. If you’re an engineering manager thinking about where AI fits in your design workflow, I’d keep an eye on what Hestus is building.

Thanks to Sohrab for taking the time to walk me through the Hestus vision. I’m looking forward to having my mechanical engineering team try it out when it’s released.