When CAD Becomes an Implementation Detail

SolidWorks users love SolidWorks.

I don’t mean they simply prefer it. They know how it thinks. They’ve spent years building muscle memory around it. Their companies have templates, part libraries, integrations, deployment processes, and entire teams organized around it.

People sometimes describe that loyalty as cult-like. That gets at the emotion, but it misses some of the machinery underneath it. A CAD system is rarely just a piece of software. It carries years of habits, infrastructure, supplier relationships, and organizational memory.

That’s part of what keeps incumbent CAD platforms so durable. It isn’t necessarily that one of them has the perfect feature set. Even newer products like Onshape, which fundamentally changed the deployment model by moving CAD into the cloud, haven’t made that history disappear. Engineers still love SolidWorks. They still love NX. A new generation of engineers is learning to love tools like Onshape. They still use the systems their companies have trusted and deployed for years.

Today, that human attachment matters enormously.

I’m not sure it will matter nearly as much when the primary CAD operator is an agent.

At Tandem, we often talk about being the harness or the context layer. We integrate into the systems that engineering companies already use, along with the documentation, design reviews, and manufacturing feedback surrounding the work. We don’t necessarily care which CAD system ultimately wins, and we aren’t betting that the most important opportunity is to build another CAD tool from scratch.

That position comes from a fairly simple observation: agents are going to do more design work.

They’re not good enough yet.

Even before asking whether an agent can make a good engineering decision, the basic action layer is still unreliable. Agents struggle to execute long sequences of precise CAD operations, recover from failures, understand feature dependencies, and make changes without breaking something downstream. Models are improving quickly, but today an engineer is still far better at operating these systems.

That limitation is real, but it doesn’t feel permanent.

There probably won’t be a single moment when agents suddenly become “good at CAD.” They’ll become useful gradually. Repetitive edits, drawing updates, configuration changes, and variant generation will come before novel product architecture or safety-critical design. The amount of work we’re comfortable delegating will increase as the actions become more reliable, reviewable, and reversible.

Eventually, constructing geometry won’t be the scarce capability.

Knowing what geometry should be constructed will be.

That distinction is important because CAD execution is only one part of design. An agent might be perfectly capable of changing a dimension or rebuilding a part and still produce something completely wrong for the company.

It may not know which requirements take priority. It may not know why a previous design failed testing, which materials have been approved, what a supplier can manufacture, or which internal standard applies. It may not understand that a decision that looks inefficient on paper exists because of a problem the team encountered three years ago.

That is company context, and honestly, it may be the harder problem.

The information exists, but it is spread across requirements tools, PLM systems, test results, manufacturing systems, supplier documentation, conversations, and the memories of individual engineers. Some of it is outdated. Some of it conflicts. Some of it is permissioned. Often, the reasoning behind a decision is more important than the decision itself.

Teaching an agent how to perform a CAD action is one problem. Giving it enough context to know whether that action is appropriate for this product, at this company, right now, is another.

As agents become better at the first problem, the engineer’s role begins to move up a level.

That doesn’t mean engineers stop designing. It means they spend less time manually constructing every feature and more time defining intent, resolving tradeoffs, reviewing decisions, and validating outcomes.

The interaction moves from:

Build this sketch, add this feature, and change this dimension.

Toward something closer to:

Satisfy this objective under these constraints, then show me what you changed, why you changed it, and how you verified it.

At that point, the engineer may care less about which interface the agent used or which file representation it created. The engineer cares that the objective was met and that the result can be trusted.

The CAD system doesn’t disappear. It recedes into the infrastructure.

File formats, geometry kernels, model structure, simulation, certification, and downstream manufacturing workflows will still matter. Different CAD systems will still have different capabilities. Deep, tool-specific integrations will still be necessary.

But those differences may become less visible to the person directing the work. The CAD environment becomes an execution layer behind an abstraction.

That could put the incumbents in a strong position. SolidWorks, Siemens, PTC, Autodesk, and Onshape already have mature modeling environments and decades of engineering capability embedded in their products. If they can make those systems reliable and legible to agents, allowing an agent to take actions, understand failures, inspect model structure, and verify results, they may be well-positioned for this transition.

Or perhaps the execution layer will be open source. Maybe a new CAD system will be built specifically for agents. We don’t necessarily know what that future looks like.

More importantly, we don’t think we need to predict it.

Tandem’s bet is that the durable layer sits above any individual CAD tool.

Company context doesn’t begin or end in CAD. It spans requirements, prior decisions, approved components, testing, manufacturing, suppliers, change history, and the rest of the engineering workflow. No single design tool naturally sees all of it.

If we can connect those systems and build a useful context layer around them, then increasingly capable agents can take that context into whichever CAD environment is right for the job.

Our job isn’t necessarily to own the geometry engine. It is to make sure the agent operating that engine understands what the company is trying to build, the constraints it has to respect, and the reasoning it needs to preserve.

Today, the CAD moat is built largely around human operators: their preferences, their muscle memory, and the infrastructure their organizations have created around them.

Agents won’t inherit that loyalty.

They will care about capabilities, reliability, and access. Engineers will care about the quality of the result. The particular CAD system used to produce it may become an implementation detail. It won’t be irrelevant, but it will be increasingly abstracted away.

We don’t know which CAD tool wins that future.

Our bet is that the context layer matters regardless.

-Arjun