All opinions are my own.

Back in 2024, interviewing at a company that was very much the name of the moment, someone senior asked me: would you be willing to work on verification? My answer was an immediate, unhesitating no. Two years later, verification is one of the things I discuss most with other teams. In the age of AI, I’ve come to think it’s the hardest part to replace — and the most underrated.

What is architecture? It’s the art of trade-offs. Put more concretely: design space exploration. The design space of a chip is enormous, which is why architects usually need ten or twenty years to fully mature. What accumulates over that time is a feel for design — the instinct that lets you rule out infeasible options quickly and find the local, if not global, optimum for your company and your product.

Can AI replace that? Yes and no. AI can run design space exploration extremely fast. But from first principles, when the design space has no bound at all, search is inefficient — and may never converge.

So how do we draw a boundary and let AI explore freely inside it? I think verification is the answer. When I’ve designed an architecture and I want AI to search around it, I need to draw that boundary precisely — and I need to be able to check whether AI stayed inside it. That boundary isn’t just functional verification: performance-related checks and test vectors have to be expressed just as precisely. Only when the tests and assertions are complete enough can I comfortably hand the design over to be automated.

A lot of chip designers today are thinking about handing verification over to AI. I’d flip the question around. AI can absolutely help you write a verification plan faster and fill in assertions faster — but if one of the two, design or verification, has to go to AI first, I’d hand over design. Not because design is the easier job — it isn’t, and getting a design right takes every bit of the skill it always did. The difference is where the responsibility lands. Verification is the gate a human has to review and sign off on, because it defines what correct even means. And when verification is complete enough, the correctness of the design is underwritten by it — nobody has to read the design line by line to believe it.

Picture two scenarios:

  1. You hand-wrote the design, handed it to AI to test, and AI cheerfully reports that everything passed — but you have no idea what it tested, or how.
  2. The tests are layered and rigorous, coverage is very high, AI wrote the design, and every test passes.

Which one lets you sleep at night? I’ll take the second one. The hand-written design in the first may well be the better design — but I have no way to know whether it’s right, and the second gives me confidence I can actually check.

That’s what I mean by verification being an architect’s love language. What an architect actually needs to communicate — what must hold, what must never happen, where the performance boundaries sit — doesn’t survive documents and verbal description, least of all with an AI that won’t read between your lines. Tests and assertions are executable intent: you’re not describing what you want, you’re stating it in a form a machine can check. Every assertion you write down is a way of saying I care about this.

My advisor once told me: if you need to look at a waveform to debug a design, then you are doomed. It means the design doesn’t have enough debug infrastructure, and staring at waveforms is where efficiency goes to die.

In the age of AI, that line rewrites almost word for word: if you need to read AI’s design line by line, and you have no fast way to verify its correctness and its performance, then you are doomed.