The semiconductor industry is adopting AI-assisted design tools faster than it is changing the teams that use them. The tools now help with RTL, verification, physical design, power and test, but hiring, job roles, training and performance metrics still reflect how chips were built a decade ago. That gap between 2026 tools and 2015 team structures is where expensive mistakes happen, and closing it is a leadership and organisational design task, not a procurement one.
The chip we are building is smarter than the team we are building it with. That needs to change.
Key takeaways
- AI is already part of production chip design flows, from RTL checks and verification to place and route and power analysis.
- Team structures, job descriptions, onboarding and training budgets have not moved at the same pace.
- Experienced engineers matter more, not less, because AI tools need direction and bad direction produces bad silicon faster.
- Two failure modes are common: senior engineers who dismiss AI after one bad output, and junior engineers who trust it too much. Both are leadership and process failures.
- Four changes are needed: new job architectures and AI governance, protected space to experiment, an updated talent pipeline, and metrics that reward judgement over throughput.
Foreword
I did not set out to write this piece as a polished argument. It started as a frustration.
It is a frustration I have 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 have not asked what the technology demands of them in return.
I have spent over 27 years working in semiconductors, not as an observer, but as someone who has been inside the machine: making product decisions, building teams, running programs, living through respins, and dealing with the particular kind of pressure that comes with knowing that a mistake made today will not 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, but that of someone standing in the middle of it, making real decisions, on real programs, with real consequences.
What I have 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: 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 naming 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 is usually where the useful conversations begin.
Murugavel Ganesan
Product Director | Semiconductor Technologist | Industry Commentator
Intelligence Is Software. Supremacy Is Silicon.
Main article
I have spent over 27 years in semiconductors.
I have watched EDA tools evolve from green-screen terminals to cloud-native platforms.
I have seen synthesis runtimes collapse from weeks to hours.
I have 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 am watching AI work its way into every layer of chip design: RTL generation, functional verification, DRC closure, power estimation, timing sign-off, 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 is 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. The major EDA vendors market AI-driven optimisation for production use, for example Synopsys with its DSO.ai design space optimisation and Cadence with Cerebrus for implementation.
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 have not been rewritten. Training budgets have not shifted. The organisational model has not 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 do not 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 is 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 has not 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 does not 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 judgement, oversight and domain depth, not just tool access.
| Role in the hybrid team | What it contributes | What it must guard against |
|---|---|---|
| Experienced nucleus | Architecture intent, constraint rationale, debug intuition, respin experience | Dismissing AI output without understanding why it failed |
| AI-fluent execution layer | Fast iteration, prompt and flow skills, evaluation of generated work | Accepting plausible output that lacks physical or system grounding |
| AI tools | Speed, breadth of search, tireless repetition | No physical intuition, no stakes, no awareness of their own limits |
The staffing crisis no one is naming.
The semiconductor industry is expanding at the same time 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 joining 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 is not modelling the transition either.
The result is predictable, and I have seen it on real programs.
Experienced engineers dismiss AI tools as unreliable because the first output they saw was wrong and they were not 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 do not 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 have not 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 a manual-first curriculum. The graduate entering the semiconductor workforce today will spend a substantial part of their career directing AI agents, evaluating AI outputs, and making judgement calls about when to trust the model and when to override it. We are not teaching that. Not systematically. Not at scale. In my view, the curriculum gap will produce a competency gap within five years if it is not 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 judgement 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 is also a much better predictor of who will perform well in the design environment that is actually emerging.
Where to start: first steps for each change
| Change | A practical first step |
|---|---|
| Job architectures and AI governance | Name an owner for AI tool usage on each program and write down which AI outputs need human review, at which milestone and by whom. |
| Safe experimentation | Set aside time and compute for teams to rerun an already-closed block with AI-assisted flows and compare the results. |
| Talent pipeline | Add evaluation of AI-generated RTL, constraints and tests to onboarding and university partnership programs. |
| Metrics | Review engineers on the quality of their decisions and escalations, such as bugs caught in AI output, alongside throughput. |
Frequently asked questions
Is AI replacing chip design engineers?
Not in the view set out here. It changes what engineers spend their time on. Experienced engineers become more valuable as the people who direct the tools and catch confident but wrong output, while routine production work is increasingly automated.
What skills should a chip engineer build now?
Deep domain knowledge remains the foundation. On top of it: scoping problems clearly for AI tools, prompting within EDA contexts, critically reviewing generated designs, constraints and tests, and knowing when to escalate.
Who should own AI governance in a design team?
There is no standard answer yet, which is the point of the article. Each organisation needs to assign it explicitly, with clear review rules and sign-off authority, rather than leaving it to ad hoc decisions on each program.
Your comments will be moderated before it appears here.