Our co-founder and CTO, Sirish Munipalli, recently joined host Ronen Laviv on Wearing Flip-Flops, the hardware and semiconductor podcast, to talk about chip design and the silicon powering the AI revolution. The conversation went straight at one of the most practical questions verification leaders face in 2026: should a chip company build its own AI verification infrastructure, or buy it?
The 33-minute episode, "AI in Verification, Build vs Buy," is episode #008 of the chip design podcast. Below is a recap of what Sirish shared, and how those ideas shape the way we build products at Moores Lab AI.
Key takeaways
- Augmented, not autonomous. Chip development is too complex and a bad tapeout too expensive to take engineers out of the decision loop.
- Real AI debug is agentic. Pasting a log and a waveform snapshot into a chat window gets you a first draft at best. Engineers correlate regressions, specs, RTL and coverage, and AI debug agents have to do the same.
- Building in-house is a second product. For a large enterprise, Sirish estimates a dedicated AI infrastructure organization in the range of 50 to 100 people, and the hard part is maintenance, not the first build.
- Time, more than money, drives the decision. Customers care most about closing the project earlier.
- The future is hybrid. A vendor base framework plus the customer's own skills, scripts and flows, connected through an SDK and MCP.
Meet Sirish Munipalli, CTO and Co-Founder of Moores Lab AI
Sirish leads technology at Moores Lab AI, at the intersection of AI software and advanced semiconductor systems. He brings more than 15 years across software, silicon and artificial intelligence, with roles at Intel, Qualcomm and Microsoft as well as hardware startups. He started his career in FPGA prototyping and emulation, moved into verification, and at Microsoft focused on large-scale, production-grade hardware and system validation. Along the way he also built software applications and trained AI models from scratch, which is exactly the mix of skills an agentic verification platform demands.
Sirish holds a Master's degree in Machine Learning and Data Science from UC San Diego and a Master's degree in Computer Architecture, System-on-Chip and Embedded Systems from Portland State University. You can read more about our founders and advisors on our website.
Augmented engineering, not autonomous chip design
Ronen opened with a deliberately simple question: why does chip design and verification need a different kind of AI workflow? Sirish explained that Moores Lab AI initially set out to rethink the whole stack, then deliberately focused on verification first. The guiding principle came from experience with what a missed bug costs.
"We don't believe it's going to be fully autonomous chip development yet. We believe it's going to be augmented engineering. Semiconductor development is too complex and the cost of being wrong is too high."
Taking engineers out of the decision loop, when a respin can cost millions of dollars, is not the right move. AI belongs inside the process, working alongside the people who sign off on silicon.
Beyond chat completion: how an AI debug agent actually works
Earlier episodes of the verification podcast featured Claudio, a verification manager on Amazon's Graviton team, who described AI as great for scripting, coverage and fast environment bring-up, with debug not quite there yet. Sirish partially agreed: if all you use is a simple chat completion API, AI is a fantastic tool for documentation, scripting and coverage, and it may get you the first 80 percent. That is not how agentic debug works.
A verification engineer does not debug from one log file. They correlate failures across regression runs, compare behavior against the specification, study the RTL implementation, look for coverage holes, and only then narrow down a root cause. Our debug agent is built to follow the same path:
- Build a knowledge base. Specs and design files are parsed into a structured database, so agents don't burn cycles searching raw documents on every question.
- Use purpose-built tools. Dedicated parsers for logs and waveforms, plus mechanisms that correlate all of that information for the LLM.
- Backtrack from the failure. The agent jumps to the point of error and traces backward to understand why it happened, checking the spec along the way.
- Report with traceability. Engineers get a report they can verify step by step, with visual representation of how the agent reached its conclusion.
In practice, after a nightly regression the agent has already gone through the regression database of logs and waveforms. In the morning the team gets a full report, and can then interrogate the agent on why each failure happened and whether there is a mismatch between the design and the spec. The agent can propose and generate new testbench sequences to probe further, but it does not touch design code. That line is deliberate. Sirish noted this flow is already running on live customer projects.
What engineers need now: clear intent
Do verification engineers need to become AI experts? Sirish's answer: not to use the tools. Interaction is becoming intent-driven. Engineers who understand the spec and the design can work with AI through chat. Building the tools is a different matter, and requires deep expertise in both hardware and AI.
The most important new skill is expressing intent well. LLMs are very good at directed tasks. Ask one to "resolve all the issues in this design and fix the bugs" and you have given it a vague goal; give it a precise, scoped objective and it performs.
EDA and AI: the build vs buy question
This is where the conversation got interesting. As LLMs improve every month, some companies want an internal team building AI infrastructure for everyone. Others say infrastructure is not their core expertise and should be outsourced. Sirish laid out what building in-house really requires:
- Access to LLM endpoints, either from a model provider or through an internal GPU cluster running local models.
- Agentic workflows for verification, coverage and debug.
- Software expertise to collect design knowledge and store it where LLMs can use it.
- A team that keeps pace with the field. The patterns change constantly, from skills to agentic loops, and every prompt and skill has to be maintained as models evolve.
How big a team? Sirish was careful to say it depends on how sophisticated the workflows need to be, since it combines software engineering, AI research and hardware expertise. For a large enterprise, his estimate was somewhere between 50 and 100 people, effectively a separate organization, because this is not a one-time build. It has to be maintained and work across the entire company.
"I definitely don't think that is the advantage for a chip company. They would rather do verification work or chip design work rather than building infrastructure solutions for AI."
Ronen, who spent years on the vendor side at Cadence and AWS, pushed on the financial angle: at some price point, a large customer could decide to bring it in-house. Sirish's view from customer conversations is that the decision is driven by time more than budget. If a vendor can show a project closing six months ahead of its deadline, most teams will take that over building and maintaining their own stack. Maintenance remains the biggest bottleneck: every project mixes different design and verification tools, and the flows keep changing from one project to the next.
He also pointed to history. Many companies tried to build EDA tools internally, and most ended up standardizing on commercial tools from the major EDA vendors.
The hybrid model: a base framework plus your own skills
Many customers already have a library of skills and custom flows. Some give engineers a shared skill library and let them choose; others have a CAD or AI team building workflows for everyone. Our answer is flexibility. Moores Lab AI provides a base framework that supplies the foundation for agentic workflows, along with an SDK, documentation and a two-way MCP integration. Teams can import their own scripts as tools, plug our agents into their flows, and let us handle infrastructure issues such as scaling.
"We are not an EDA company. We want to be the intelligence layer around all these EDA tools."
Sirish expects most companies to land on this hybrid model rather than a closed, fully internal tool: vendor support from one side, an internal team building custom solutions on the other. It is the same thinking behind our post, You don't need another tool. You need to get the chip verified.
What it takes to earn trust
Asked about the challenges on the vendor side, Sirish started with trust. With semiconductor customers there is no room to get things wrong, and much of our work has been learning from customers and adapting to their requirements. In practice that means:
- An intuitive interface, so engineers can work with AI without learning a pile of new tools.
- A dedicated team that adapts to new LLM capabilities as fast as they ship.
- Support for multiple EDA tools, since most of our work happens after simulation and customers run different vendors.
- Delivering results inside the customer's evaluation timeline.
Six months out: still a human in the loop
Will verification become a closed loop, with AI debugging, fixing and re-running on its own? Not soon, in Sirish's view. He referenced Yann LeCun's argument that reliable agentic systems need to predict the consequences of their actions. Today the industry compensates with agentic loops, where one agent judges another's output. Simulation remains essential, and LLMs still need structured data to debug properly. Engineers stay in the loop.
Sirish closed with what excites him most: momentum in the open-source hardware community, more RISC-V products, and more people getting involved in hardware development. In his words, he hopes the industry gets disrupted, in a good way.
Listen to the full episode
The full conversation covers more ground than this recap. Listen to episode #008 of the Wearing Flip-Flops chip design podcast, or pick your platform: Spotify, Apple Podcasts or YouTube.
About Wearing Flip-Flops: Wearing Flip-Flops is a semiconductor and verification podcast hosted by Ronen Laviv, a chip design and EDA veteran with 25 years in the industry. Episodes go deep on EDA and AI, verification, emulation, formal, and the geopolitics of the chip supply chain, with guests from hyperscalers, EDA vendors and startups.
About Moores Lab AI: Moores Lab AI builds agentic AI for silicon engineering, helping teams accelerate verification, debug and coverage closure inside their existing EDA flows. To see how our agents could fit your verification flow, get in touch with the Moores Lab AI team.
Frequently asked questions
Is AI ready to fully automate chip verification?
Not yet. Moores Lab AI CTO Sirish Munipalli describes today's approach as augmented engineering: AI agents handle analysis, debug and testbench work, while engineers remain in the decision loop because a missed bug at tapeout can cost millions.
What does an AI debug agent do after a nightly regression?
It parses the regression logs and waveforms, backtracks from each failure, checks behavior against the specification and produces a traceable root-cause report in the morning. It can generate new testbench sequences but does not modify design RTL.
Should a chip company build or buy AI verification infrastructure?
Building in-house means owning LLM access, agentic workflows, a knowledge infrastructure and constant maintenance as models change. Sirish estimates 50 to 100 people for a large enterprise and expects most teams to adopt a hybrid model: a vendor base framework extended with their own skills and flows.
Where can I listen to the episode?
The episode is "AI in Verification, Build vs Buy," episode #008 of Wearing Flip-Flops, a chip design podcast available on the Wearing Flip-Flops website, Spotify, Apple Podcasts and YouTube.
