Skip to content

How an AI-Native CAD Tool Actually Competes With 30 Years of Incumbent Software

A common reaction to the "AI-native CAD will win" argument is the obvious one: how do you compete with thirty years of software and millions of lines of code?

It is a fair question. The answer is that you do not — at least not by trying to replicate it.

You compete by picking the workflow the incumbent does structurally badly, and owning that workflow so thoroughly the user stops caring about the rest.

The pattern across professional software

The reflexive way to evaluate an AI-native CAD tool is to put it next to the incumbent's feature checklist. That comparison always loses. The incumbent has 30 years of features and will continue to have 30 years of features. Matching them feature-for-feature is the slowest, most expensive, and most predictable way to lose.

The same lesson has played out in every other category of professional software:

  • Figma vs Photoshop / Illustrator. Figma did not try to match Photoshop's brush engine or Illustrator's vector tooling. It picked one workflow — collaborative UI design in a browser — and made it 10× better than the desktop incumbents could ship from their architecture. Adobe had every advantage: brand, distribution, capital, decades of tooling. They lost the wedge anyway, then attempted to acquire the winner.
  • Slack vs Outlook. Email was already the universal communication tool. Slack did not try to replace email; it owned a different workflow — high-frequency team chat with channels and integrations — that email handled poorly. Microsoft eventually shipped Teams, but only after Slack defined the category.
  • Notion vs Confluence / Word. Notion did not match Word's document features or Confluence's enterprise hierarchy. It owned the block-based, mixed-content workspace that neither incumbent could ship without breaking their data model.
  • Linear vs Jira. Linear did not try to be a configurable enterprise PM platform. It owned opinionated, fast issue tracking for teams that found Jira's flexibility a liability rather than a feature.

In every case the wedge looks small at the start and obvious in retrospect. The right question for an AI-native CAD challenger is the same: which workflow does the incumbent structurally do badly, and can it be owned end to end?

Candidate wedges in engineering CAD

A handful of workflows in engineering CAD look like wedges in the same sense — small entry points where the incumbent's architecture is the constraint, not the team.

Intent-driven design. Today's CAD captures geometry. The reasoning behind that geometry — target impedance, loss budget, thermal margin, cost ceiling — lives outside the file, in slides, emails, and the senior engineer's head. A tool whose data model captures intent alongside geometry can answer questions the incumbent's file format cannot represent: "what changes if I move to a 6-layer board," "which constraints are at risk," "why was Rogers picked over MEGTRON here." Incumbents cannot retrofit this without breaking 30 years of file-format compatibility and the plugin ecosystem built on it.

AI-assisted component selection across thousands of parts. Selecting a PA, VCO, filter, or LNA against a frequency band, power target, and cost ceiling is a search-and-ranking problem with tens of thousands of candidates and noisy datasheets. Incumbents ship parts libraries; they do not ship reasoning over them. An AI-native tool ships the reasoning as a first-class workflow, with the library as backing data.

Multi-domain co-design. RF chain, stackup, impedance, thermal, and compliance are typically five tools today, with manual handoff between them. A unified model where a stackup change instantly recomputes RF performance, thermal margin, and compliance status is a workflow incumbents cannot ship without unifying products that were built and acquired over decades — each with its own data model, license server, and customer base.

Outcome-aware design. When a board fabricates and tests, the results should feed back into the tool's selection and constraint logic. Incumbents do not see customer outcomes — files are confidential and on-prem, and the commercial model assumes air-gapped use. AI-native tools designed for opt-in cloud telemetry close the loop in a way the incumbents architecturally cannot match without re-architecting their deployment model.

Agentic workflows. "Design a 5W X-band PA chain with these constraints; show me three options ranked on cost and DC efficiency." That is a goal, not a click sequence. A tool whose primitives are goals and constraints can serve this request directly. A tool whose primitives are GUI operations needs translation glue between intent and execution — and that glue is exactly the layer that breaks when the user's request gets ambitious.

Why "structurally" is the load-bearing word

Note what each of these wedges has in common. The barrier for the incumbent is not engineering effort. It is architectural commitment. File formats, plugin contracts, license-server assumptions, on-prem deployment models, and the way decades of acquisitions glued separate products into a suite — these are the things that take years to change and break customers when they do.

A challenger that does not carry those commitments can ship a different default in months. That is the actual asymmetry. It is not "AI startups move fast." It is "incumbents are anchored, and the anchor is exactly the layer the new workflow needs to change."

This is also why feature-count comparisons mislead. Most of an incumbent's millions of lines of code address legacy formats, niche industries, and regulatory edge cases that any given user does not touch. A typical user lives in 5–10% of the surface area. Owning that 5–10% with a structurally better workflow is a winnable game. Replicating the other 90% is not — and is not necessary.

The wedge is the entry point, not the product

The wedge alone is not the win. It is the foothold.

Once a wedge is owned, breadth follows. Figma added prototyping, design systems, dev handoff. Slack added voice, video, automation. Notion added databases, AI, projects. Linear added cycles, projects, customer requests. In each case the tool that started as "the small one" ended up larger than the incumbent it replaced — but only after winning the wedge first.

Breadth on top of a structurally better core compounds. Breadth on top of a structurally older core does not. That is the entire bet.

The interesting question for engineering teams is not whether AI-native CAD can match the incumbent's feature list in 2026. It cannot, and trying would be a strategic mistake. The interesting question is which wedge an AI-native tool will own first — and whether the workflows you depend on are inside that wedge or outside it.

If your work lives in a wedge an AI-native tool is going to own, the transition will feel sudden. If it lives in the long tail of legacy features, the incumbents will keep serving you well for years.

Both can be true at the same time. That is what the next five years of CAD will look like.

Which workflow in your day-to-day CAD use feels structurally broken — the one where the tool's architecture, not the team, is the limit? Curious what other engineers see as the obvious wedge in their domain.