Foreword

I didn't set out to write this piece as a polished argument. It started as a frustration.

A frustration I've been carrying quietly for a while sitting in program reviews, hiring conversations, and tool evaluation meetings, watching the same disconnect play out repeatedly. Extraordinary technology being adopted by organisations that haven't asked what the technology demands of them in return.

I've spent over 27 years working in semiconductors. 

Not as an observer. As someone who has been inside the machine making product decisions, building teams, running programs, living through respins, and navigating the particular kind of pressure that comes with knowing that a mistake made today won't surface until silicon comes back months from now, if it surfaces at all.

That experience gives me a specific vantage point. Not the vantage point of someone watching the AI wave from a distance and writing about its implications in the abstract. The vantage point of someone who is standing in the middle of it, making real decisions, on real programs, with real consequences.

What I've written here is not a celebration of AI in chip design. Nor is it a warning against it. It is something more uncomfortable than either of those: an honest assessment of the gap between where the technology is and where the organisations deploying it actually are.

That gap is not a technology problem. The tools are working. The gap is a people problem, a leadership problem, and an organisational design problem and it is the kind of problem that the semiconductor industry has historically been slow to name, because naming it requires acknowledging that technical excellence alone is not enough.

I believe it is enough. Not sufficient on its own but enough to start an honest conversation.

That is what this article is intended to be. A conversation starter. One practitioner's perspective, offered in the hope that it resonates with others who are seeing the same things from their own vantage points and that together, we can move the industry's thinking forward faster than it would move on its own.

If something in here makes you uncomfortable, good. That's usually where the useful conversations begin.

— Murugavel Ganesan
Product Director | Semiconductor Technologist | Industry Commentator
Intelligence Is Software. Supremacy Is Silicon.

Main article

I've spent over 27 years in semiconductors. 

I've watched EDA tools evolve from green-screen terminals to cloud-native platforms. 

I've seen synthesis runtimes collapse from weeks to hours. 

I've lived through the shift from schematic capture to HDL, from manual floorplanning to constraint-driven automation, from tape-based delivery to cloud PDKs.

And now I'm watching AI weave itself into every layer of chip design — RTL generation, functional verification, DRC closure, power estimation, timing signoff, test pattern synthesis, even documentation.

The technology is genuinely moving. 

The organisations building with it largely are not.

The AI-assisted design revolution is real. The talent strategy to match it is not.

Let me be specific about what's actually happening in design flows today not the marketing version, the real version.

AI-assisted RTL tools are catching logic bugs before simulation runs. ML-guided place-and-route is reaching timing closure faster than experienced physical design engineers with multiple tapeout cycles behind them. LLM-powered verification assistants are generating testbench scaffolding, suggesting corner cases, and flagging specification ambiguities that human reviewers missed. Power integrity analysis that once required specialised expertise and days of runtime is being compressed into hours with AI-in-the-loop solvers.

These are not demos. These are production flows at leading semiconductor companies right now.

And yet when I look at how teams are being hired, structured, and developed to work alongside these tools, I see a profound mismatch. Hiring managers are still writing job descriptions built around individual tool proficiency and years of HDL experience. Performance frameworks still measure engineers on outputs that AI is increasingly producing faster and more accurately. Onboarding programs haven't been rewritten. Training budgets haven't shifted. The organisational model hasn't moved.

We are deploying 2026 tools inside 2015 team structures. That gap is where expensive mistakes live.

The new semiconductor team is a hybrid organism.

The best chip teams forming right now don't look like traditional functional hierarchies. They look more like high-performance production crews a small, experienced nucleus surrounded by a larger, more fluid execution layer, with AI woven into both.

The nucleus still matters enormously. These are the engineers who understand why a constraint exists, not just what it says. Who can read a failing simulation waveform and know intuitively where in the architecture the bug lives. Who have lived through a respin and carry the scar tissue that no training dataset captures. Who understand the full stack from physics to protocol to product well enough to know when an AI-generated output is confidently, dangerously wrong.

Their value is not decreasing. If anything, it's increasing. Because AI tools need direction, and bad direction produces bad silicon at accelerated speed.

Around that nucleus, you need a new engineer profile that the industry hasn't fully defined yet. Engineers who are fluent in prompt engineering for EDA contexts. Who can evaluate AI-generated design quality rather than just producing design manually. Who treat the model as a capable but unreliable collaborator faster than any human, but without physical intuition, without stakes, and without the capacity to know what it doesn't know.

The mental model shift required here is significant. This is not "use AI to go faster." It is "manage AI as a member of the team" which requires judgment, oversight, and domain depth, not just tool access.

The staffing crisis no one is naming.

The semiconductor industry is in simultaneous expansion across compute, automotive, defence, and communications. Fab capacity is being built on multiple continents. Government policy is pulling investment into new geographies. Demand for silicon is structurally higher than it has been in a generation.

And underneath all of that is a mid-career talent gap that is quietly becoming a structural problem.

Entry-level engineers entering the workforce today are learning AI-assisted flows from day one. They are native to these tools in the same way that a generation of engineers were native to EDA GUIs while their predecessors were still writing SPICE by hand. They are fast, adaptive, and comfortable with ambiguity in AI outputs.

Senior engineers who have spent a decade or more in deep specialisation physical implementation, mixed-signal design, DFT, custom layout are being asked to adapt their workflows overnight. With no training budget. No time carved out. No organisational permission to experiment, fail, and learn on non-critical work before being expected to use AI tools on tapeout-critical programs. And often, a leadership layer that isn't modelling the transition either.

The result is predictable and I've seen it on real programs:

Experienced engineers dismiss AI tools as unreliable because the first output they saw was wrong and they weren't given the context to understand that prompting quality drives output quality. Junior engineers over-trust AI-generated constraints, timing budgets, or verification coverage metrics because they don't yet have the intuition to interrogate them. Neither failure mode is a people problem. Both are leadership and process failures.

And underneath both, there is a more corrosive dynamic: senior engineers who feel their expertise is being devalued, and junior engineers who feel unguided in how to use powerful tools responsibly. That combination quietly destroys team cohesion and team cohesion is what gets silicon to tapeout on schedule.

The organisational redesign that needs to happen.

This is not a tools procurement conversation. It is an organisational design conversation. And most semiconductor companies haven't started having it seriously.

Job architectures need to evolve. The functional boundaries between design, verification, and physical implementation were already blurring with shift-left methodologies. AI is accelerating that blur. More importantly, new questions have appeared that no existing job family owns: Who on the team governs AI tool usage? Who defines which AI-generated outputs require human review, at which stage, under which sign-off authority? Who is responsible when an AI-assisted flow produces a bug that escapes to silicon? These are not edge cases. They are daily workflow decisions that teams are currently making ad hoc, without policy, without accountability structures, and without any institutional learning loop.

Psychological safety for experimentation is not optional. The semiconductor industry has a deeply ingrained culture of caution for good reason. Silicon is expensive, schedules are long, and mistakes compound. But that same culture has consistently underinvested in the kind of low-stakes experimentation that allows engineers to develop genuine fluency with new tools. Teams need protected space to use AI on non-critical paths internal studies, prototype blocks, re-implementation of already-closed designs before they are expected to make consequential decisions with AI-assisted outputs on live programs.

The talent pipeline institutions are lagging. Universities, professional certification bodies, and corporate training programs are still largely teaching the manual-first curriculum. The graduate entering the semiconductor workforce today will spend a substantial portion of their career directing AI agents, evaluating AI outputs, and making judgment calls about when to trust the model and when to override it. We are not teaching that. Not systematically. Not at scale. The curriculum gap will produce a competency gap within five years if it isn't addressed now.

Metrics need to change. If you are still measuring an engineer's contribution primarily by lines of RTL written or number of verification tests authored, you are measuring the wrong thing. The right question is the quality of judgment applied to AI-assisted work the ability to scope a problem correctly, prompt effectively, evaluate outputs critically, and escalate appropriately. That is significantly harder to measure than throughput. It also significantly better predicts who will perform well in the design environment that is actually emerging.