What TexoCAD means, and why we built it

The 3D printer showed up in a big brown box and immediately made the room feel more ambitious than it had any right to. Fresh plastic smell, foam inserts all over the floor, that thin little scraper they always include like you're about to become a manufacturing powerhouse with one piece of stamped metal and a prayer. We set it up, leveled the bed, ran the usual first print, and spent the next hour watching a small piece of plastic appear out of nowhere. It felt a bit like cheating. In a good way.

Then we hit the obvious problem.

None of us could really design for it.

We could download parts. Everyone can download parts. There is an entire internet full of phone stands, cable clips, headphone hooks, oddly aggressive drawer organizers, and replacement knobs for appliances you do not even own. But the moment you want a part that fits your thing, your desk, your enclosure, your weird little prototype, the fun stops. You are no longer browsing. You are modeling. And modeling is where a lot of people discover that "I have a 3D printer" and "I can make objects" are not remotely the same sentence.

That was the moment TexoCAD started, even if the name came a little later.

We bought a 3D printer before we knew how to design#

What bothered me was not that CAD was hard. Of course it was hard. Every serious tool worth using is hard in some specific, slightly insulting way. What bothered me was the shape of the bottleneck. We had a machine that could turn bits into plastic on a table in front of us, and yet the actual path from idea to object still ran through a long detour of sketches, commands, menus, constraints, broken feature trees, and the kind of beginner frustration that makes you stare at a toolbar like it personally betrayed you.

The printer was ready. The physical world was ready. We were the slow part.

That felt backwards.

The more I thought about it, the stranger it seemed. Software had already made ridiculous progress in every other expressive medium. If you want to write, you type. If you want to edit a photo, you have a hundred tools. If you want to compose music, there is software for that too. But if you want to describe a bracket, a housing, a mount, a jig, or some ugly little adapter that exists only because two standards refuse to get along, you still need to learn a full modeling environment before the machine will listen to you.

That gap is what we cared about. Not "AI" in the abstract. Not futuristic demo fluff. The simple fact that a person can know exactly what they need, be perfectly capable of describing it, and still be blocked because geometry has historically been trapped behind specialist tooling.

We were not world-class CAD experts at the time. What we did have was a background in software. We could code. We understood structured systems, abstractions, parameters, syntax, iteration, and the very familiar ritual of getting something 80 percent right, testing it, cursing softly, then fixing it. That mattered more than I realized at first.

Because once you look at CAD through a programmer's eyes, a lot of it stops looking mystical and starts looking like something else: a language problem.

And once it looked like a language problem, the name stopped feeling like branding and started feeling like a way to describe the whole idea.

Why the name is TexoCAD#

The name came from two pieces, but also from that shift in perspective. It was my attempt to name the problem the way it actually felt.

CAD is the easy half. Computer-aided design. Everybody in this space knows that one, and if they do not, they will about five minutes after their first bad export.

Texo is the more interesting half. It comes from the Latin verb texo, usually glossed as "to weave," with extended senses around composing, constructing, and joining things together. I like that meaning because it gets closer to what design actually feels like when you are doing it honestly. You are not summoning finished objects from the void. You are weaving constraints together. You are composing form, function, dimensions, material limits, manufacturing reality, and whatever dumb requirement showed up in the last message from a supplier.

That is design. Not pure invention. Structured composition.

So TexoCAD, at least in my head, meant something like woven CAD, composed CAD, constructed CAD. CAD that starts from language and intent, not just clicks. CAD that treats geometry less like a priesthood and more like something you can write, inspect, revise, and reason about.

I also liked that texo sits close to "text" without pretending to literally be the same word. That mattered because the deeper idea here was always that text, code, and geometry are closer cousins than most CAD software has historically admitted.

If that sounds slightly philosophical, fair enough. A lot of naming is philosophy with a domain check.

But that question does have a practical answer. If geometry really is something you can compose, then what is the best digital form for carrying that composition? For me, the answer kept circling back to code.

Code is the closest digital version of a physical thing#

That is the view that kept getting stronger for me as we worked on this.

Code is not just instructions for computers. In a lot of cases, it is the cleanest digital representation of intent we have. It says what something is, how it behaves, what can vary, what must stay fixed, and which constraints matter. Good code is not merely output. It is structure with reasons attached.

That is also what a well-built CAD model is supposed to be.

A physical object is made of atoms. A digital object is made of bits. That part is obvious. The more useful analogy is one layer up. Atoms combine into parts, surfaces, edges, tolerances, fit, motion. Bits combine into parameters, operations, relationships, and rules. In both cases, the thing only becomes useful when structure appears. A pile of atoms is not a hinge. A pile of bits is not a model.

The job is to arrange the building blocks so they hold together.

That is why code matters here so much. Code can express relationships directly. Width equals board width plus clearance. Hole spacing matches the mounting pattern. Wall thickness stays constant. Corner radius changes, and the rest of the model updates with it. If you have ever used OpenSCAD, this already feels obvious, which is part of why I wrote about OpenSCAD + AI. It has been quietly proving for years that geometry becomes much easier to reason about when the representation is textual and explicit.

Traditional CAD systems can absolutely represent intent, sometimes beautifully. But they often hide that intent inside a feature tree, a proprietary format, or a click history that makes sense right up until it doesn't. You change one sketch dimension and the whole thing turns red like you have offended its ancestors. Every CAD user has been there. Usually with cold coffee nearby.

Code has its own failure modes, obviously. It can be ugly, brittle, overcomplicated, and written by someone who should have gone for a walk before opening the editor. But when code is the representation, you can inspect it. Diff it. Version it. Generate it. Refactor it. Ask an agent to explain it. Ask an agent to change one parameter without touching the rest. That gives you a very different kind of control from click-based geometry creation. It gives you room to work.

Once we started treating geometry as something closer to code, the path forward got much clearer. And once that clicked, coding agents stopped sounding like a side topic and started sounding central.

Why coding agents change the whole equation#

That is where my opinion gets stronger.

I think coding agents matter enormously for CAD, not because they make engineers obsolete, and not because every prompt should become a printable part, but because they are unusually well matched to the structure of the problem. They work best when there is a formal language, a clear objective, feedback from execution, and a loop where each attempt can be inspected and improved. That description fits programming. It also fits a surprising amount of design work.

If you ask a coding agent to build a login form, it writes code, runs it, sees what broke, and tries again. If you ask a coding agent to build a bracket in a textual CAD system, or through a CAD API, the loop is not all that different. Define geometry. Run it. Render it. Measure it. Notice the hole is wrong. Change the parameter. Try again. The agent is not guessing in the dark. It is operating inside a structured environment with syntax, state, and feedback.

That matters because most of the pain in early-stage CAD is not deep geometric genius. It is translation. You know what you want. The software does not. So you spend time converting intent into operations. Sketch here. Constrain that. Offset this face. Add that fillet. Move the hole 3 mm because of course it intersects now. A coding agent is good at exactly this kind of translation work when the underlying system is exposed in a way it can manipulate.

This is also why I do not think the important question is "Will AI replace CAD designers?" That question gets asked because people enjoy drama and because LinkedIn would collapse without fake civilizational panic. The more useful question is: which parts of CAD are fundamentally authoring problems, and which parts are judgment problems?

Authoring is where agents help first. Generating first drafts. Converting a verbal description into geometry. Wiring up parameters. Producing several variations quickly. Cleaning up repetitive modeling chores. Working through the boring parts without getting bored, which is one of the computer's few truly admirable qualities.

Judgment is different. Deciding whether the part is manufacturable. Deciding whether a snap fit will actually survive use. Deciding whether the tolerance stack makes sense, whether the material choice is stupid, whether the mounting location guarantees a future service headache. That remains human territory for quite a while, and honestly I am fine with that. I have seen too many parts that were technically valid and practically idiotic.

But once you separate authoring from judgment, a lot of the noise falls away. Of course coding agents can help with CAD. CAD contains a huge amount of authoring work. Structured, repetitive, explicit, revisable authoring work. That is exactly the sort of terrain where software has always done its best work.

And that is the final step in the chain from the printer on the desk to the product itself. The printer exposed the bottleneck. The name gave the bottleneck a shape. Code suggested a better representation. Agents made that representation feel operational.

Why we built TexoCAD#

TexoCAD came out of that entire chain of reasoning. We had a machine that could make physical things, and the main obstacle was still the interface between intention and geometry.

We did not want that interface to stay reserved for people who had already paid their dues to traditional CAD. Those tools matter. CAD expertise matters. Manufacturing knowledge matters even more. But there should also be a better path from "I know what I need" to "here is the model."

That is the bet.

Not that text replaces CAD.

Not that agents replace designers.

Not that physical reality becomes easy, because it does not. Physical reality is rude, dimensional, and unimpressed by your prompt.

The bet is that code, text, and agents can compress the distance between thought and object. And once that distance gets smaller, a lot more people can build useful things.

That is what the name means to me. Texo plus CAD. Weaving intent into geometry. Composing something digital that can survive contact with the physical world. Taking the machine on the desk seriously enough to admit that the real bottleneck was never the nozzle. It was the translation layer in front of it.

Now that we have coding agents, that layer looks a lot less permanent than it used to.