From CAD Screens to Text-to-STEP: Building VayuAI CAD

About 12 to 15 years ago, I saw serious CAD tools for the first time: SolidWorks, AutoCAD, Inventor, and the world of sketches, constraints, assemblies, drawings, and tolerances.

At that time, I thought CAD was mainly a software skill.

Industry taught me otherwise.

A CAD model is never just geometry.

It is a compressed engineering argument.

Every hole, flange, wall thickness, bore, bolt pattern, chamfer, shaft step, and drawing note carries design intent, manufacturing constraints, cost, lead time, and lessons learned from the physical world.

That is the world I came from.

Now I am exploring the next interface to that world: describing a mechanical part in plain English and turning it into real parametric CAD code, valid solid geometry, STEP files, STL/GLB exports, and ASME-style drawings.

That experiment is called VayuAI CAD, and it is live now: Try it → cad.vayuai.ai

The starting point is intentionally simple: describe a mechanical part in plain English, or begin from a known-good reference part.

From a sentence to a solid

The idea is simple on the surface.

You write something like:

Create a circular flange, 110 mm OD, 14 mm thick, 50 mm bore, with 6 bolt holes on an 85 mm bolt circle.

The system turns that sentence into a real CAD model.

But the important part is not that it creates a 3D shape. The important part is what kind of 3D shape it creates.

VayuAI CAD does not aim to generate a frozen mesh as the primary output. It generates an editable parametric CAD program, which is then executed through a real CAD kernel. From that, the system exports the engineering package: STEP, STL, GLB, and a 2D ASME Y14.5-style drawing.

That distinction matters.

A mesh is usually the end of a workflow.

Parametric CAD code is the beginning of one.

If the model is code, it can be inspected, edited, versioned, regenerated, and improved. A dimension can become a named parameter. A flange thickness can be changed. A bore can be updated. A bolt circle can be resized. The model can move forward into actual CAD software instead of staying trapped as a visual demo.

That was the first principle behind the prototype:

AI should generate engineering structure, not just visual output.

A generated part shown in the browser viewer, with inspection controls rather than just a static render.

The browser is only the surface

The frontend is intentionally thin.

The browser gives the user a clean engineering workspace: a 3D viewer, view presets, sectioning, measurement, parameter editing, chat refinement, and downloads. But the browser is not doing the CAD work. The geometry is created, validated, and exported server-side on top of OpenCascade, a production-grade CAD kernel. The browser is the interface. The CAD kernel does the geometry.

Once a part is generated, the user can:

• rotate, zoom, and pan the model;
• switch between isometric, top, front, and right views;
• section the model along X/Y/Z;
• measure distances in millimeters;
• edit named dimensions;
• refine the design in plain English;
• download STEP, STL, GLB, DXF, and PNG outputs.

The goal is not to make a pretty 3D toy.

The goal is to create a small but complete engineering loop:

prompt → generate → inspect → edit → export

The editor is built around inspection and iteration: viewer in the center, parameters on one side, refinement on the other.

You can run this whole loop yourself in the browser: Try it → cad.vayuai.ai

Why code, not meshes

One of the biggest design decisions was to make the generated model a source program.

The system outputs parametric CAD code. That code becomes the feature history. It is readable. It is versionable. It can be rerun. It can be modified without asking the model again for every small change.

This is where I think AI CAD becomes more interesting.

If AI only generates a mesh, it may be useful for visualization, concept art, or rough geometry. But mechanical engineering usually needs more than shape. It needs intent.

A bracket is not just a bracket. It has a mounting face, hole spacing, thickness, load path, manufacturing process, and design assumptions.

A flange is not just a cylinder with holes. It has an OD, ID, bolt circle, thickness, pattern count, clearance assumptions, and downstream mating requirements.

A shaft is not just a revolved form. It has shoulders, diameters, chamfers, bearing seats, and assembly logic.

The closer the output stays to editable structure, the more useful it becomes to an engineer.

That is why VayuAI CAD treats code as the primary artifact and STEP as the main engineering deliverable.

The model exists as parametric code first, which makes editing and regeneration possible.

The actual generation loop

The hardest part is not asking a language model to write CAD code.

The harder part is not trusting it blindly.

LLMs can produce invalid code. They can miss a hole. They can misunderstand a dimension. They can generate something that looks plausible but does not match the prompt.

So the system has to close the loop.

VayuAI CAD follows a generate-execute-verify-repair workflow. A request goes to the backend, multiple candidate CAD programs are generated in parallel, each candidate is executed in an isolated subprocess, the resulting solid is checked, and the best verified result is promoted. If a candidate fails, the error is fed back into the model for repair.

That architecture matters because CAD is not forgiving.

A broken model is not a minor UI issue. An invalid solid, missing feature, wrong hole count, or wrong scale can make the output useless.

The system therefore treats generation as a closed-loop process, not a single model response.

There is one more deliberate constraint: the whole thing runs on free model tiers. Code generation does not depend on one provider. A request walks down a fallback chain, and as soon as one provider returns usable code, the rest are skipped.

This is the technical spine of the project:

Generate → execute → verify → repair → promote.

What the system currently outputs

Every successful generation produces a small engineering package.

STEP is the main CAD interchange file, intended to open in tools like SolidWorks, Fusion, or other MCAD systems.

STL provides a mesh export for 3D printing or quick downstream use.

GLB supports lightweight browser-based 3D viewing.

DXF + PNG provide an ASME-style drawing output and proof image.

Named parameters allow dimensions to be edited and rerun.

The current reference examples include mechanical parts such as L-brackets, pipe flanges, stepped shafts, pulleys, spur gears, gusset brackets, electronics enclosures, cap screws, vented plates, funnel adapters, clevis brackets, radial cylinders, impellers, spiral staircases, and planetary gears.

That scope is intentional.

This prototype is focused on standard mechanical and industrial geometry: prismatic parts, turned parts, holes, bolt circles, flanges, shafts, brackets, and simple feature assemblies.

Not organic surfacing.

Not large production assemblies.

Not simulation.

Not released-for-manufacturing authority.

At least not today.

The gallery acts as both a user starting point and a reference library for the kinds of mechanical geometry the system targets.

An honest prototype

I would describe VayuAI CAD as a functional prototype / early engineering tool.

It genuinely generates valid solids and real STEP files for a meaningful class of mechanical parts. It has a working browser viewer, parametric editing, chat refinement, export, and drawing generation.

But it is not production-ready.

The current system runs on free model tiers, so latency and provider availability can vary. Generation can take around 90 to 120 seconds. Hosted backend storage is ephemeral. Some verification is still soft. The 2D drawing step can fail or time out. Generated parts still need engineering review before any real use.

That honesty is important.

I do not think useful AI tools need to pretend they are finished.

In engineering, credibility comes from knowing what works, what does not, and where the boundary is.

This project is not claiming that AI has solved CAD.

It is exploring a new interface for engineering design.

Drawing generation is part of the pipeline, but still prototype-grade and treated honestly as such.

What I learned building it

Three things stand out.

First, the output primitive matters.

For mechanical design, editable code is more valuable than a static shape. If the model can be inspected, parameterized, regenerated, and exported, it can enter an engineering workflow. If it is only a mesh, its usefulness is limited.

Second, reliability requires a loop.

A single LLM call is not enough for CAD. The system has to run the code, check the solid, compare the result to the prompt, and repair failures. Verification is not a bonus feature. It is the difference between a demo and a tool.

Third, AI engineering tools need to respect engineering judgment.

The value is not in bypassing the engineer. The value is in reducing the distance between intent and first structured model, while keeping the human in control of review, correction, and decision-making.

That is the line I care about.

Not AI instead of engineering.

AI as a new interface to engineering.

Why I built this

I work at the intersection of mechanical engineering, manufacturing, industrial systems, sourcing, automation, and applied AI.

That intersection is where I think a lot of real-world AI value still lives.

Many industrial workflows are not blocked by lack of intelligence. They are blocked by translation.

A requirement has to become a sketch.

A sketch has to become a model.

A model has to become a drawing.

A drawing has to become a supplier conversation.

A supplier conversation has to become a manufacturable part.

A manufacturable part has to survive cost, quality, lead time, and field reality.

Every step loses context.

VayuAI CAD is a small experiment in reducing that loss.

It starts with one narrow question:

Can a sentence become editable parametric CAD, and can that CAD move toward real engineering deliverables?

The current answer is early, imperfect, but promising. It can generate parametric CAD code, produce valid solids, export STEP, show the part in the browser, expose parameters, attempt drawings, repair failures, and keep the workflow moving.

That is enough to make the direction worth exploring.

Where this goes next

The future of AI CAD should not be random shape generation.

It should be design-intent-aware engineering assistance.

The next layer is not just more geometry. It is more context: manufacturability, material selection, tolerance logic, supplier capability, cost and lead-time impact, standards, simulation, design history, drawing automation, and lifecycle documentation.

That is where this becomes serious.

A useful engineering AI system should help answer: What did the user intend? What geometry represents that intent? Is the solid valid? Are the requested features present? Can the model be edited? Can it be exported? Can an engineer inspect and continue the work?

That is the direction I am building toward with VayuAI CAD.

It is early. It is imperfect.

But it is real enough to show a full loop from plain English to parametric CAD code, valid solid geometry, browser inspection, STEP export, and drawing output.

For someone who started years ago learning CAD through sketches, constraints, drawings, and real manufacturing problems, this feels like a meaningful step.

Not away from engineering judgment.

Toward a new interface for it.

The future belongs to those who design systems not just with intelligence, but with intention.

Try VayuAI CAD live →