Geometry as Code.

When you set out to build agents for hardware design, the first question is not which model to use or how to train it. It is how a model perceives a part and acts on it. What is the equivalent, for an agent, of drawing and manipulating geometry?

For a human engineer, the answer is the interface. You orbit a model, click a face, drag a dimension, pick a feature out of a tree, and the design takes shape under your hands. Almost none of that transfers to a machine. A click carries no meaning outside the session in which it happened, and a viewport is a picture rather than a handle. Whatever an agent does to a part, it has to do somewhere else.

There is one place where a part is written down in a form a machine can read, write and check, and that is code. Which means the paradigm has to come before the agent. This article is about that paradigm: an old idea, confined for thirty years to the edges of mechanical engineering, and one we think is now moving to the centre.

Two ways to describe a part

Mainstream CAD is feature-based, sometimes called history-based. You sketch a profile, extrude it, cut a pocket, add a fillet, and the system records that sequence as a tree. Change a dimension near the top and the whole sequence replays underneath it. SolidWorks, Fusion, Creo and CATIA are all built this way, and very nearly every mechanical part in the world is made of one of these trees.

The alternative is code-based modelling, or geometry as code. The part is a program: you write a function, it returns a solid. OpenSCAD, CadQuery, build123d and KCL all work like this, with different languages and different kernels underneath, but the same premise. The program is the model, and the geometry is what you get when you run it.

It is tempting to treat these as two different kinds of object, but a feature tree is already a program. It has statements, an order of execution, parameters, and dependencies between them. What separates the two paradigms is not that one is procedural and the other is not. It is two other things.

The first is access. A feature tree is written in a language you cannot read and cannot write, stored in a proprietary binary file, and producible only by the interface that produced it. You cannot diff it, search it, import half of one into another design, or generate one from anything else. A program is text, and everything that is true of text is true of it.

The second is what you can express. Feature-based modelling gives you a fixed vocabulary of operations and a narrow way of relating them: equations between dimensions, a handful of configurations, a suppression rule here and there. Anything an engineer meant that does not fit in that vocabulary has to be flattened into numbers before it can be stored. Code has no such ceiling. A dependency can be a function, a rule can be a conditional, a family of parts can be a loop, and a requirement can be written as the thing that computes a dimension rather than as the dimension it happened to produce. Intent survives at the level of abstraction it was thought at, which is also the level at which it stays valid when something upstream moves.

Why it never took off

Code-based CAD is not a new idea, and it has not been for want of trying. Companies have been founded on it, repeatedly, over the last thirty years, and none of them displaced the feature tree. The tools that survived did so in narrow places: lattice structures, additive manufacturing, generative work, hobbyist parts. Anywhere, in other words, that the geometry is more repetitive than a mechanical assembly and the person at the keyboard already writes software.

The main reason is not subtle. You had to be able to program. A mechanical engineer is not a developer, and an engineer who wants a flange is not going to learn a language to get one when a competing tool lets them click. Every code-based CAD tool paid that cost at its front door, and it was enough to keep the market at a few percent.

Two secondary reasons are real and less often stated. The first is constraints. Much of what an engineer means when they design is a constraint rather than a computation: this face stays tangent to that one, these two holes stay concentric, this wall stays at least 2 mm thick. Constraint solving is native to sketch-based CAD and awkward in most code-based tools, several of which support it barely or not at all. The second is the sketch itself. A 2D profile is a visual act. Drawing one with a mouse takes seconds, writing it out in coordinates takes minutes, and no amount of language design has made that trade attractive.

What changed

The barrier was writing the code, and that barrier is gone.

It is worth being precise about what this claim is and is not. It is not that language models write good CAD. They do not, yet, and anyone who has watched one try to place a fillet on an imported part knows how far there is to go. The claim is narrower and more solid than that: the cost of producing code, any code, has collapsed. The single argument that kept code-based CAD out of the mainstream for thirty years was that its users would have to program, and that argument no longer holds. It did not stop holding because CAD changed. It stopped holding because programming did.

Once that happens, the trade reverses. The property that made this paradigm hard for humans is exactly the property that makes it workable for machines. A textual, executable, inspectable representation was a barrier at the entrance, and it is a handle everywhere else.

What code gives you

Once a part is a program, a set of things that were difficult or impossible become ordinary.

Parameters become explicit. A function signature states what governs the design. In a feature tree, the same knowledge is a set of dimensions buried at various depths, some meaningful and some left over from an afternoon three revisions ago, with nothing in the file to tell them apart.

Version control works. Not a document management system bolted onto a binary format, but the real thing: diffs, branches, blame, review. You can see what changed between two revisions of a part and who changed it. On a binary CAD file, you can see that the file changed.

Reuse works. A library of parts is imported rather than copied, so when the library improves, everything downstream inherits the improvement instead of drifting into fourteen slightly different versions of the same bracket.

Testing becomes possible. You can write down what must remain true of a design and check it automatically after every change: mass below a threshold, no interference in the assembly, minimum draft angle, wall thickness above the process limit. This is design driven by tests, and today it exists in mechanical engineering only as a manual review that someone occasionally remembers to run.

Intent has somewhere to live. This is the deepest one. The knowledge behind a design, why this dimension follows from that one, which requirement forced this shape, is almost never in the CAD file. It sits in a spreadsheet, in an analysis someone ran once, in a message thread, or in the head of the engineer who drew it. Code is the first CAD representation with room for it, because a dependency can be written as a dependency instead of being baked into a number.

And this is where it lands. Everything in that list is ordinary software engineering practice, and an agent that writes code already knows how to use all of it. It can write an operation, run it, read the error, fix it, run the test suite, and open a diff that a human can review. An agent working on a part does not need a new theory of how to act; geometry as code hands it one that has been under industrial load for decades.

What code does not solve

None of this makes the hard problems go away, and an honest version of the argument has to say which ones remain.

Persistent topology. This is the deepest unsolved problem in the paradigm. When geometry changes, faces and edges are renumbered, merged, or destroyed. Code that says fillet edge 47 is code that breaks on the next modification, and it breaks quietly, producing a valid part that is not the part you meant. The way out is to select by intent rather than by identity: every edge between a drafted face and an undrafted one, rather than a list of indices. That is harder than it sounds, and no system does it well across the board.

The kernel underneath. Boolean operations fail. Fillets fail. Offsets produce self-intersecting geometry. Writing an operation as text does not make the operation robust, and the failure costs more in an automated pipeline than at a workstation, because at a workstation someone is looking at the screen.

The parts that already exist. The installed base of mechanical geometry is STEP files, and a STEP file has no program. It is boundary geometry with no history, no parameters and no intent. For a part that arrives this way the agent's grip is gone, and most industrial work starts from a part that arrived this way. Getting an agent to understand geometry it did not write is a problem of its own, and it is the one our research with the DFKI is aimed at. It deserves its own article, and it will get one.

Ergonomics. Nobody wants a CAD system in which you cannot click. Sketching is visual, inspection is visual, and a product that forces text on both will lose to one that does not. The interesting design problem is not code instead of a user interface. It is code and a user interface over the same model, with neither one lying about the other, and as a product question that is still open.

Where this leaves us

The idea is old, the objection that buried it has been removed, and the reason to care about it now is not the reason people cared before. Code-based CAD used to be argued for on elegance, on reuse, on the discipline it imposes. Those arguments were and still are correct. What is different is that geometry as code is the only representation an autonomous system can actually operate on, and autonomous systems are now the thing everyone is trying to build.

That is why our agents write code. It is the only real handle on a part.