‍AI is changing engineering exponentially faster than other technology shifts

Hardware engineering has gone through major technology shifts before, but none have happened as quickly or so fundamentally changed how engineers work as AI. To understand why this moment is different, it helps to look back at the last major transformation: the shift from paper-based design to ECAD.

The transition from paper to ECAD happened over the course of decades. If you didn’t live through this transition, here’s a great article that rewinds the clock to the 80s when schema drawings looked like this:

A 1981 paper on VLSI layout says these chips typically contained more than 50,000 transistors, and that a complete IC design cycle could take more than a year. It identifies layout as one of the most time-consuming parts of the process. The paper provides a snapshot of how hardware complexity was already pushing against the limits of manual engineering processes. ECAD emerged when hardware complexity overwhelmed manual design processes. 

This transition wasn't just about replacing pencils with computers. It was the beginning of turning hardware engineering into a digital, connected discipline. We're reaching another point where the complexity of the design process is exceeding what humans can efficiently manage manually. AI is the next step in that same evolution.

But this next transition in hardware engineering with AI agents is dramatically different. The transition to agents is measured in months.

Take, for example, Anthropic and Claude. Within a year of Claude Code's launch, Anthropic engineers had shifted from using AI as a coding assistant to delegating most of the execution itself. By early 2026, some Anthropic teams reported that Claude Code was writing 70–90% of their code. Anthropic’s research provides a look at how quickly this shift is happening.

A week, a month and a year is a huge difference in AI. The competitive advantage isn't simply deciding whether to adopt AI. It's understanding where it can create value and building the right foundation to use it effectively. We see this shift firsthand in our conversations with Fortune 500 engineering teams. AI is moving from experiments to real workflows, with teams actively figuring out where it fits, what it can do, and how to integrate it into their existing processes.

The speed of this transition creates an interesting paradox with AI and hardware engineering. We're using AI to build increasingly complex products, while still using largely human-driven engineering processes to build the AI-powered systems themselves. How do we accelerate balancing that equation? Let’s look at why software had the early advantage.

Why software was ready for AI

Software development has already solved many of the infrastructure problems that AI agents need to operate effectively.

• A system of record: Git gives every change a complete, queryable history. Engineers can see what changed, compare versions, branch, merge, and roll back. The history of the work is part of the system.‍
• Perfect information flow: Open APIs mean data can move between tools without being trapped inside them. Systems across the stack can connect, exchange information, and trigger actions.‍
• A language machines understand: Code is text. LLMs can read, reason about, search, modify, and generate it natively. There is no translation layer between the agent and the fundamental engineering artifact.‍
• Built to be extended: Open ecosystems, robust revision control, CI/CD pipelines, and APIs give software teams the ability to build on top of their tools, automate workflows, and connect systems together.

The hardware infrastructure gap

Hardware engineering has a fundamentally different starting point. Much of the infrastructure that makes software accessible to AI simply doesn't exist in hardware or exists in fragmented, proprietary, and difficult-to-access areas.

• No system of record: Design files live in folders, inboxes, and people's heads. There is no authoritative history, no single source of truth, and no easy way to know what changed or why.‍
• Powerful tools that don't talk to each other: Legacy ECAD vendors built powerful solutions, but those systems weren't designed to work together. Data gets exported, truncated, translated, or manually re-entered as it moves between tools.‍
• Proprietary binary formats: Schematic and layout data is often locked inside proprietary formats that AI can't easily read, reason over, or manipulate without a translation layer.‍
• Tools you can't extend or automate: If you want to add a capability, you often have to go through the vendor and request a feature or develop custom scripting. Without an API or extensible architecture, there's no way to build on top of the tool, you work within the walls it provides.

Shifting to an extensive system creates the connective infrastructure that allows existing tools and the AI agents operating across them to work together.

Hardware engineering is fundamentally different than software

Hardware engineering is a discipline with short timelines, small budgets, and high expectations. What you are doing is really hard and you're doing it with tools that are generations old. You can only do as much as the tools you have. If you want to build the next generation of autonomous vehicles, you need to give engineering teams the tools they need to deliver in today’s reality.

Critical engineering with real-world consequences

Engineering teams are building products across aerospace, energy, medical devices, defense, industrial systems, and more; mistakes can be expensive, dangerous, or impossible to reverse.

The cost of a hardware mistake is also exponentially higher than a software mistake. You have to pay for prototypes. There are timeline costs, schedule risk, and strategic impacts. There are also environmental and sustainability impacts from wasted products. The impact is real and tangible.

That makes the quality and accessibility of engineering data even more important. Your data is only as good as your lowest denominator. The system with the lowest-quality data ends up winning. This is why you can’t just drop an agent into a hardware design and expect it to work.

For AI to deliver, the foundation comes first

The difference between software and hardware isn't simply that one has more AI tools than the other. As we covered earlier, software was already built on an infrastructure that made it relatively easy for AI to access, understand, modify, test, and create. Hardware largely wasn't.

But that doesn't mean hardware engineering can't get there. An extensible system can provide a path to changing that reality.

Why closed engineering systems hold AI back

If an extensible system is the path forward, the first thing to understand is what stands in its way: closed engineering systems.

The opposite of closed is open. But we’re not talking about open source software. In the hardware engineering space an extensive system means open within the bounds of our enterprise's ecosystem. Teams can adopt the tools they need and build the workflows that work best for them.

In an extensible system, data can “flow” between systems, customers own their information, and AI tools can access the data they need to accelerate the work. An extensible system lets organizations choose the best solution for each part of the engineering process from a large ecosystem rather than being locked into a single vendor.

And that matters for AI. If engineering data is fragmented across disconnected systems, AI has an incomplete picture of the design. The more fragmented the data, the harder it becomes for an agent to understand the full context and support critical engineering decisions.

How the extensible system approach helps AI work

Since AI agents need access to the full engineering context, the goal isn’t necessarily to replace all of the tools the hardware teams rely on. The goal is make the tools and the data they generate more accessible, connectable, and extensible.

There are two ways to get there.

1. Build with AI-ready systems: Use tools that are already optimized for AI and build around open, accessible formats. This gives teams a foundation where data can move more freely and AI can work with it more efficiently.
2. Connect the systems you already have: Create an infrastructure that optimizes conversion and translation across existing engineering tools. This allows teams to keep their tools and workflows while you work to create a more consistent foundation for AI.

This second approach is not as tight as an API-based system, but it helps to create a stronger foundation for the data AI agents need. Switching engineering systems carry long timelines and massive business risk.The key thing is to make the engineering data accessible and structured in the right way that AI can actually use it. 

That’s where an extensible system really becomes important. You don’t know what tools, models, or agents might be the best for you in the future. You need a foundation that allows you to adopt whatever works best for your teams.

Why we built Allspice for extensibility instead of lock-in

We want a world where people can bring best-in-class tools to their processes and also where they can truly customize their workflow to their particular needs.

Think of Allspice as a Lego set. It comes assembled, but at the end of the day, it's a bunch of little pieces that you can take from one place and put in another and truly make it fit. In the world of agents, the right answer is very context dependent. 

But what's the right or wrong answer about which component to use for two different business outcomes? Take for example two aerospace companies with very different goals. The company that is designing for low-income countries and is optimizing for cost is going to make different decisions than one that is optimizing for weight because they're shipping to space with a very expensive payload.

The right answer may be very different based on the particular context and circumstances. This is one of the areas where agents can truly shine. But that also means that you have to have the ability to make it your own.

When do you want an all-in-one platform?

It’s a great question that we get from engineering teams. What we typically hear from our customers is that when a team is of a certain size and is optimizing for simplicity, a cookie-cutter approach might work. It's easier to get started. It's faster, but that means that you're capping your potential.

Depending on what you want to optimize for and what the trade-off is, the extensible system approach is best when you don't fit the out-of-the-box experience and you want to be able to make it your own. When you have a lot of internal tooling or other teams that you want to integrate or build around, or when you have teams with sophisticated users and engineers that want to extend their own tools beyond what the UI allows them to click through.

Those are the teams where we see they get a lot of value with Allspice.

What does a winning with AI formula look like

The teams that will win aren't necessarily the ones using the best model or the best AI tool today. They're the ones building a strong foundation to adapt as those tools evolve.

What’s best today is likely to change tomorrow. The advantage comes from having an extensible foundation that lets you keep up.

Allspice is that foundation. Yes we have our own AI, but our role is broader. We give teams the data, structure, and tools they need to build AI into their engineering workflows. Teams can build their own deterministic automations, use our AI agent DRCY, leverage their own AIor adopt whatever comes next. The foundation stays the same.

Ultimately, the value of AI depends on the quality of the data it can access, the structure around that data, and the ability to connect it to the tools and workflows where engineering happens. That’s the value of an extensible approach: you can keep evolving your AI stack without having to rebuild the foundation underneath it.

FAQs

What is an extensible systems approach in hardware engineering?

‍
It’s a way of building your engineering toolchain so data can move freely between tools, teams own their information, and new capabilities can be added through APIs and automation. Teams choose the best tool for each part of the process instead of relying on a single vendor.

Why do closed engineering systems hold AI back?

‍
AI needs the full engineering context to be useful. When design data is locked in proprietary formats or scattered across disconnected tools, AI works from an incomplete picture of the design and can’t support critical decisions.

When is an all-in-one platform the better choice?

‍
An all-in-one platform can work for smaller teams that want simplicity and a fast start. An extensible approach fits better when a team has internal tooling to connect, other teams to integrate with, or engineers who want to go beyond what the user interface allows.

‍

‍