AI for hardware is having a moment. Even compared to just a few years ago, it’s never been more exciting to be working at the intersection of bits and atoms, shipping real products. Every week brings a new wave of demos promising to design your board, route traces, or collapse half your workflow into a prompt. Some of it is genuinely impressive and will stick, but most companies are still largely unproven and it’s not yet clear what these tools will actually deliver in practice.
To cut through the noise, we recently spoke with Kyle Dumont, Co-Founder & CTO of AllSpice, about what his team is building with DRCY and how they’re applying AI to real hardware workflows.
A bit of context: the problem space AllSpice is exploring is design reviews. Traditionally, these are the quarterly checkpoints where teams pressure-test a design against specs and constraints. Design reviews are a non-negotiable part of hardware development because the cost of being wrong compounds with every step toward production. Unlike software, mistakes aren’t easily reversible with a new commit; being wrong means rework, scrapped boards, and the inevitable schedule slip.
(History has plenty of reminders of what happens when teams aren’t aligned — the Airbus A380 wiring fiasco cost $6.1B in project delays).
With that in mind, it’s useful to look at how modern teams are trying to close the gap between design intent, documentation, and build reality in day-to-day workflows.
The Current Reality of Design Reviews
Design reviews are still handled the same way they have for the last few decades: schedule a meeting, export a PDF, redline through it on a call, and collect comments from the meeting with information scattered across Slack, email, and shared folders. For those unfamiliar, version control is often just a copied folder on a network drive (hardly sophisticated, but functional). It works for slow cycles and ends up as a single checkpoint before the design moves forward to build or release.
That model worked when the main challenge was simply getting everyone in the same room. The real purpose of a design review isn’t the meeting itself though; it’s making sure the design intent, supporting documentation, and actual implementation all line up. Most issues surface in the gaps between those sources: specs living in one place, datasheets in another, design files exported into PDFs, and decisions scattered across messages and folders.
For all the advances in tools and software, much of hardware development still looks exactly the same to a team from twenty years ago, nowhere more so than in design reviews.
Origins of AllSpice
That gap between modern design complexity and legacy review workflows is the problem space AllSpice set out to tackle. To address it, their approach starts from a fairly grounded premise: engineers still have to do the hard part with architecture, product definition, and making the tradeoffs that shape a design. That judgment isn’t going away, and no software tool is going to replace it. The opportunity they saw was in everything around it: the tedious, error-prone work of reconciling specs, tracing signals, and digging through hundred-page datasheets to confirm that the design actually matches the intent.
Early on, the first product was a diff engine for ECAD files like schematics, PCB layouts, and related metadata. In simpler terms, it compares two revisions and highlights changes in components, nets, parameters, and layout; not just file differences, but the actual design database.
That solved a basic and persistent problem where most hardware teams couldn’t easily see what had actually changed between versions of a design. By making changes explicit, the diff engine turned revisions into something reviewers could understand incrementally instead of starting from scratch each time.
Once the diff engine could interpret schematic, PCB, and BOM changes at the design-database level, it naturally became the basis for the core platform: central repository revision control for ECAD data. Instead of storing revisions as entire project folders, edits could be represented as structured changes to objects in the design database (components, nets, parameters, geometry, metadata) which can be committed, branched, and merged.
That model made it possible to build reviews directly on top of those commits. A hardware revision becomes a defined change set with a clear before/after state, rather than another exported file. Reviewers inspect the semantic diff, comment on specific objects or regions, and the discussion remains attached to the change history.
In practice, this was a core bet that hardware projects should behave like software repositories, with revisions that are incremental, traceable, and reviewable in context, not static snapshots passed around as folders or PDFs.
Once hardware revisions were represented as structured commits with a reproducible design state, automation became possible at the repository level. Their third product is called AllSpice Actions, essentially a CI system for ECAD repositories — meaning checks and workflows that run automatically whenever the design changes, like software test pipelines triggered by a code commit.
Typical uses are deterministic checks tied to repository events like running design-rule checks, validating part numbers against approved libraries, verifying BOM properties, generating manufacturing outputs, or flagging rule violations before a review is approved. The results attach to that specific revision, so reviewers see both the human discussion and the automated findings in the same context.
The DRCY Review Layer
What we’ve described so far compresses roughly five years of development into a few paragraphs. In practice, this meant building the platform piece by piece, almost like adding spokes to a wheel around a common data model that could parse schematic, PCB, and BOM data consistently.
Diff made changes visible. Actions made checks automatic and deterministic. DRCY is the next layer on top of that stack: an AI design review agent operating on the same structured design data.
The name is a play on traditional DRC (Design Rule Check), but the distinction matters. Traditional DRC runs fixed tests against predefined constraints. DRCY is meant to reason more broadly about the design during review, using the actual circuit data rather than exported PDFs or screenshots.
Because it works on native ECAD objects, it can trace signals, interpret part relationships, and cross-reference requirements directly from the design database. That avoids the information loss that normally happens when designs are flattened into images or documents for external analysis, where an agent has to infer intent from pixels instead of working from the circuit structure itself.
Under the hood, the system follows an agent-style approach. Instead of running a fixed checklist, it analyzes the circuit and decides what areas warrant closer inspection, using the schematic data, component information, and supporting documentation available in the repository.
For example, if a section of the design involves a power regulator, the review might include pulling relevant datasheet constraints, checking that surrounding components match recommended configurations, and flagging inconsistencies for the reviewer to examine. The goal isn’t to replace deterministic rule checks, but to provide a first-pass investigation that surfaces issues or questions a human reviewer would otherwise have to track down manually.
DRCY is one part of the broader automation stack inside AllSpice, alongside automated checks from Actions and the design history stored in the repository. Because it runs on the same system of record, its findings stay attached to the actual design context, so reviews remain traceable and grounded in the source data rather than separate reports.
In practice, that means flagging incorrect pin connections (required power or decoupling pins left unconnected or not tied together as mandated), out-of-spec power supply connections like under-voltage on required rails, and unconventional but datasheet-allowed pin reuse (for example, special-function pins repurposed as GPIO).
It can also confirm proper handling of NC/DNU pins, power rails, clocks, buses, and interfaces, surface incompatible component configurations or implementations, and catch higher-level logic errors — the sort of issues that usually only show up after someone manually traces the schematic.
Moving Toward Iterative Design Reviews
What all of this adds up to is a shift in how often designs can realistically be reviewed. On a traditional program, a design review might happen a few times per quarter, usually when the team feels the design is “ready.” Changes accumulate in the meantime, and the review becomes a large, high-stakes checkpoint where many issues surface at once.
What’s been interesting to learn about customers using their workflow is how quickly that pattern starts to change. Instead of long stretches between major revisions, you might see dozens of commits over a short window — sometimes 60 commits across a phase, with 10 or more design updates landing in a single day. Each change carries its validation results and discussion, so review happens incrementally as the design evolves rather than in one large batch at the end.
Over time, that compresses the review cycle itself. A process that might previously have meant preparing for a major review every couple of months starts to shift toward smaller, more continuous checkpoints. The formal review doesn’t disappear, but it increasingly reflects a history of incremental decisions instead of being the first time the design is examined closely.
Every hardware team wants the same outcome: ship faster, with confidence. Iterative design review is the mechanism that enables it.
Special thanks to Kyle and the team at AllSpice for the behind-the-scenes look at DRCY. See DRCY in action: https://www.allspice.io/drcy-demo
