QAD Dev Log — a technical drawing is more abstract than it seems

We are building QAD as a CAD created from the start as an AI-first solution, based on MCP.

In practice, the idea is that you can design by talking to a chat and giving it the data it should work on.

We are still at an early prototype stage, and one of the areas we are working on a lot right now is technical drawings.

It is an interesting problem, because at first glance it can look very concrete, almost mechanical.

We have a 3D model. The geometry already exists. It has to be turned into a drawing.

In practice, between those two points there is a surprising number of decisions.

A 3D model does not tell you what the drawing should look like

The model gives very concrete information about geometry.

What it does not answer on its own is a few basic questions:

• which views should appear on the drawing,
• how many views we need,
• how they should be arranged on the sheet,
• which dimensions need to be added,
• where those dimensions should go.

And this is exactly where the problem starts to become much more abstract.

The geometry itself is unambiguous. A hole has a specific diameter and position. A part has a defined shape. A dimension has a specific value.

But the decision about how best to present that information on a drawing is no longer so obvious.

Every drawing can be completely different

On top of that comes the sheer variety of the cases themselves.

A drawing may show a simple plate with a few holes.

It may also show a far more complicated part, or a whole assembly.

So you cannot simply find one arrangement of views, one set of dimensions, and apply it everywhere.

What is legible and sensible in one case may not make much sense in another.

A very concrete and a very abstract problem at the same time

This is probably the most interesting thing we see while working on this part of QAD.

The AI works on something very concrete: the 3D model, the geometry, the dimensions and the positions of parts.

At the same time it has to make far more abstract decisions:

what to show and how to show it, so that a sensible drawing comes out.

Creating a view of the model is only part of the problem.

Much harder is deciding which view makes sense, where to put it, and what information should appear on it.

For now we are testing

QAD is still an early prototype.

The screenshot in this post shows one of our current tests related to producing drawings.

We are not showing a finished solution here. Examples like this are exactly how we check where the approach works, where problems appear, and which decisions are the hardest.

And that is what we are working on now.