Software and hardware are fundamentally different in the ability of the engineer to isolate working segments. You can take a piece of code and set up unit tests for it, and if you feel good about your test suite, you can be fairly certain that it will serve your engineering and product goals.

In hardware engineering, that kind of isolation is a liability. As a billing electrical design engineer, you should be working tightly with your mechanical and SW/FW/GW teams to optimize what you're building. The massive context and knowledge base you collectively synthesize a design from is a huge benefit, and things like your phone or laptop, or any piece of spaceflight hardware, would not be possible without it.

Example - you can take something like a motor controller. Easy peasy, you say. Grab the best stocked and reasonably priced TI IC off of Digikey and slap its reference design into your copy of Altium Designer. If you give it its own power, thermal, and packaging solution, you can absolutely silo that component and hand it off to an AI agent that builds that piece for you.

Congrats, you've built a standalone motor control module, which you can also buy off of Digikey for a reasonable price that is much cheaper than the time you spent thinking about this.

Also congrats, systems engineering wants your head on a pike and mechanical engineering has taped a picture of your face to a football and is kicking it around in the parking lot.

If you're designing into a product, you're working with the mech and systems teams to create an integrated product that meets the systems/module requirements. The context for this includes not just circuit function, thermal performance, what the EMI situation is, whether there's some room to push back on systems and product as you weigh thermal performance and device longevity against module volume, global industrial geopolitics and the effect on part availability (there's a tariff tickbox in Digi-key now, and during COVID I had to redesign parts several times before being able to actually build them because parts became unavailable overnight due to panic buying).... the list is huge.

The cost of "compiling and running against the test suite" is also huge, because it involves typically weeks of answering questions/issues from the fab/assy, waiting for them to build and ship it, doing electrical bring up, actually running the tests you care about...

It is also hard to catch design issues in schematic or layout reviews. We don't have comprehensive and ubiquitous models for electronic devices, so we can't economically simulate this stuff.

This huge cost means "mashing GO until LLM spits out the right code" can't work, at all.

If you really do want to apply AI to EDA software, I think there's actually a really good use case in being able to catch small issues in a board, things that are too small to address in design reviews but have a meaningful impact on bring-up timelines for R&D test articles - stupid things like having a footprint flipped, or drawing the schematic symbol for a slightly different version of the part that has subtly different power pin configurations (my latest fuck-up). That is a fairly tightly containable problem, because our schematics all have links to vendor data and PDF datasheets that should be easily ingestible, and in practice there's often a lot of EDA users copying pins configs into their tools. I think AI would actually be good at catching the "dumb" errors that are sort of hard to see for humans.