The Strawman Critique of “Text-to-CAD”

Many people today criticize Text-to-CAD by making some variation of the following arguments:

• Describing complex geometry with natural language is difficult.
• AI tools are not good enough to generate an entire jet engine, car, or aircraft in a single prompt.
• Design intent is not preserved in common formats like STL or STEP, which are the primary formats used to store 3D models.

The issue is not whether these arguments are true or false. In fact, most of them are true.

The real problem is that they criticize the wrong idea.

This is a classic strawman argument: simplifying or misrepresenting a position so that it becomes easier to attack. The current debate around “Text-to-CAD” often focuses on an unrealistic interpretation of what the technology is meant to do.

The Name Is Misleading

The phrase Text-to-CAD itself is part of the problem. It is a vague label that does not accurately describe the intended use case.

If the expectation is that engineers will sit down and type a paragraph describing every detail of a complex structure, for example:

a tapered wing with twist, internal ribs, spars, mounting interfaces, and aerodynamic constraints

then the skepticism is justified. That is not a practical way to design complex systems.

But this framing misunderstands where the information in a design actually comes from.

Regardless of whether geometry is created by a human designer or generated by an AI tool, the information defining that geometry must exist somewhere. Engineers already specify constraints, parameters, interfaces, and requirements throughout the design process.

The real question is not whether natural language can fully describe a design, but how these sources of information can be integrated into an automated design pipeline.

The Position of the Tool in the Design Pipeline

The biggest misunderstanding concerns where such tools sit within the design workflow.

Yes, these tools will ultimately be used by engineers and designers. But not in the way many critics assume.

The future workflow is unlikely to involve engineers manually prompting a system to tweak individual geometric parameters:

“increase wall thickness by 2 mm”
“move this hole by 3 mm”

Instead, the tool becomes part of a larger automated pipeline.

Engineers will spend their time:

• defining constraints
• specifying requirements
• configuring design rules
• integrating the system into their engineering workflow

Once this infrastructure exists, the system can generate and refine the geometry automatically.

The human effort shifts away from manually editing geometry and toward building the system that produces the geometry.

From Manual Modeling to Automated Design

The key shift is not about replacing CAD with text prompts.

It is about automating the generation of functional geometry.

In this paradigm:

• engineers define intent and constraints
• the system generates the geometry
• the engineer evaluates and adjusts the system, not the individual surfaces and edges

In other words, the real transition is not:

CAD modeling → text prompts

but rather:

manual geometry creation → automated design pipelines

The debate around Text-to-CAD often misses this distinction entirely.

A Reality Check

We're still at the beginning of the journey toward building a real-life Jarvis, a system that can automate the entire engineering pipeline for a complex assembly. But we're improving at a pace that only keeps accelerating.

The goal is to focus on use cases where we can deliver value today so we can learn in which direction to improve, rather than living in a wonderland of what's theoretically possible but disconnected from reality.