Claude Code for pcb design?

[Mickelin]

After successfully using Claude Code for firmware development, I decided to give pcb design a try. I set up an agent team with a hardware agent using the kicad-happy skill. Very slow and not impressive, but clearly a lot of potential. Who has tried kicad-happy? Are there any other good Claude skills for hardware development out there?

[negativ3]

When you say PCB design, did you feed it a schematic?

[Unixon]

To me it's faster to do it by hand than to explain to LLM what I want to do.
And often I don't really know what I want to do until I do it so I can't tell an LLM anything sensible.
And when I can present it with a task I decide not to, so that LLM could not learn it from me and then do it in my place.

[Mickelin]

No, I am letting the agent do everything from scratch, also the schematic.

[negativ3]

Try feeding an LLM a component datasheet. Ask it to stick to an example schematic & PCB layout guidelines.
That's as straightforward as it gets, really, and if it can't do that, there's not much hope for "intelligent" design capabilities based on "I want a circuit board that does X" prompts.

None of that assumes the LLM has any electronics knowledge tho which is just one worrying aspect of Ai.

You'll need an md file with reams of design constraints, at which time it becomes much easier to do the work yourself.

[twospoons]

Considering specialised PCB routing software designed for the task usually does a piss poor job on anything of more than moderate complexity, unless fed a ton of constraints, I hold very little hope that a generalised LLM is ever going to be useful for board layout.

[Unixon]

Considering specialised PCB routing software designed for the task usually does a piss poor job on anything of more than moderate complexity, unless fed a ton of constraints, I hold very little hope that a generalised LLM is ever going to be useful for board layout.

This is what people don't understand and always asking why don't I use autorouter when it is much faster.
It takes a lot time to explain about constraints and that even an advanced autorouter simply has no way of defining a significant part of these constraints.
Many consideration are informally and implicitly taken into account by wetware, and it is not obvious to those who don't do PCB layout and routing by hand.
A giant LLM may mimic how things look but it has no way of 'understanding' what the hell it is doing.

[Mickelin]

Considering specialised PCB routing software designed for the task usually does a piss poor job on anything of more than moderate complexity, unless fed a ton of constraints, I hold very little hope that a generalised LLM is ever going to be useful for board layout.

Have you seen flux.ai? It is an AI specifically developed for board design. To think that AI will not have a massive impact on EE over the next couple of years, just like for lawyers and doctors, is wishful thinking. The question is how far along are they today? Anyone with actual experience?

[leo938]

I've recently used a combination of KiCAD & Claude to create a 4 layer board of moderate complexity (a Linux system with high speed components such as SD card, Ethernet, DSI etc). While it didn't create the schematic or layout components I found Claude very useful for checking off TODO lists, checking for errors or omissions etc. Also as I was using the JLCPCB I found it useful for optimizing BOM (basic v extended parts) & checking on stock levels. I also used it to create parts (mine were based on existing footprints). While its certainly not a silver bullet I found, because the KiCAD files are plain text & not proprietary, it significantly sped up development. It might help prevent a respin or two by reviewing your board for errors.

As with software its probably better to run Claude in a VM (with dangerously skip permissions) so you don't have to keep approving changes & all changes tracked by git to allow easy rollback.

[AndyC_772]

I think one major hurdle to overcome will be determining how to calculate a figure of merit for an attempt at a PCB, which is a necessary step in reinforcement learning.

Pretty looking tracks mean almost nothing when it comes to whether or not a PCB layout is fit for purpose. They are, however, the most visually obvious thing that professionally routed boards tend to have.

Mathematically we might define "looks good" as necessary, but not sufficient.

A fit for purpose PCB requires knowledge of placement and design rules, which probably don't exist in the net list. Simple things like 'which end of the track does this terminating resistor go' would be fairly obvious to the actual design engineer responsible for routing the board manually, but an AI place/route engine would need both technical information and design intent. On a link between two pins, both of which are capable of being bidirectional, the 'right' place for that resistor cannot be known without being aware of how the parts each end will be programmed.

More esoteric designs only get harder, of course. Are these pins a differential pair? What's their max length / max skew / impedance requirement? Is this signal a likely emitter of noise, or sensitive to it? Which gets to go nearer the star point, the ADC or the DAC? How much current flows in this trace?

I predict we'll see AI developers claiming to have "solved" PCB layout quite soon. Just like SPECCTRA "solved" it 20 years ago.

Eventually they'll learn that they solved the easy part, not the important part, because they're rushing to develop something new without stopping to really understand what already exists.

[twospoons]

I found Claude very useful for checking off TODO lists, checking for errors or omissions etc. Also as I was using the JLCPCB I found it useful for optimizing BOM (basic v extended parts) & checking on stock levels. I also used it to create parts (mine were based on existing footprints).

These are functions already built into professional tools like Altium. No need for AI.

AI is a solution looking for a problem, in a desperate attempt to justify its cost.

[Smokey]

You need reference training data in order for a model like this to know how to optimize anything.  So you need to feed it a TON of known good designs, along with their specification documents, design guidelines, and all the other requirements and such.  Power electronics have vastly different requirements and layout than small signal stuff for example. 

The volume of reference data just doesn't exist to train a model like they have now to make circuit boards in the same way that they could train it to write code.

Now I'm not saying that all open source hardware is of poor quality, but can you imagine an AI model trained only on open source hardware projects? 

[Simmed]

 you can "use it" to find Z-diff trace width
(and create some ULP https://www.eevblog.com/forum/eagle/ulp-for-finding-total-milling-length/)

[kripton2035]

Claude is now able to draw schematics in svg, instead of previous pure ascii drawings...
the schematics are really more pertinent. but it was very slow to obtain. still need more work and power.
may be next year or so.

[BadeBhaiya]

Making schematics symbols or footprints is about 1% of the job of a design engineer. Making the schematics and doing the layout combined is maybe 20%. This is the part that we can do on paper, we don't need EDA software at all.

The rest 80% of the job of electronics design is decision making around constraints, and looking at as many variables and perspectives as possible. Do not mistake symbol or footprint creation of even schematics as the end goal. The end goal always way making things work the first time by being as thorough as possible.

I think people's expectations have been misguided by LLMs. I can sort of understand, in software engineering the code is largely the end "product" but in other field like electronics design or mechanical CAD, the process is more important, basically how you reach to a particular design or design decisions matters more than "this is a schematic+gerbers for a board, let's see if it works" just doesn't stick

[Siwastaja]

I think one major hurdle to overcome will be determining how to calculate a figure of merit for an attempt at a PCB, which is a necessary step in reinforcement learning.

It needs to do the same AI does on software development - have a way of verifying results. It needs to use circuit simulators like SPICE, and even EM modeling tools for layout. This is all doable, just we are not there yet. AI for software development got a huge boost from having absolutely massive archives of known-good, battle-tested software, and the existing infrastructure and concepts of testing and verification.

For PCB design, even we human designers still rarely simulate much, especially not the layout - we handwave it. And even when we simulate, that's all closed work in corporate setting, so no freely available learning material - not for humans, not for AI.

I don't see this changing quickly. Because easy, free source for training does not exist like it did for software, those developing EE design / PCB AIs will need to put a lot of their own money.

But maybe I'm wrong again and maybe it will happen quickly anyway.

[BadeBhaiya]

We must not forget, even for code, images and text, it took multiple years of expensive top end GPUs, titanic amounts of freely available training data (even if we disregard the massive amounts of illegally acquired data on top of it, paid works, copyrighted stuff etc etc), armies of lowly paid workers in third world countries to sort, categorise and label the training data, and a lot, lot, lot of funding to get to this stage.

I doubt the model can be replicated for hardware. A few simple points

1. Training data is non existent. You can find kicad projects on github but they range in quality, quantity and most of them have non existent reasoning or engineering documentation. Professional level training data is proprietary and in company servers. You COULD reverse engineer circuit boards but that is just unreasonable. I also doubt you could get armies of similar EEs to categorise and label data in sweatshops, like you could do for text, images and code. Gerbers and the schematics PDF don't tell you anything.
2. Text, images and code are largely self explanatory, or at least the intent behind them is easily understandable from their existence. Hardware is much more ambiguous. I could use a diode as a bad quality voltage reference. Nobody does it normally, so this data point would be underrepresented in the model, or worse, confuse the model. Also I don't see how chatgpt and its ilk can understand and co-relate hardware tolerances, stackups, keepout zones, drill sizes etc etc etc. Fab sent an email their capabilities PDF is out of date, stuff like that. But then again, I have no idea about how these LLM things work behind the scenes, maybe they can do it?
3. Economics. Software engineering market is massive, so there is a lot of potential to earn money, if you can automate stuff or even write basic code. Compare that to the hardware design market, its small, much smaller. ChatGPT and its cousins would need to spend many more times more compute to earn anything

[paulca]

So I have spent far too many hours on this problem and gave up.

In terms of Kicad, the problems start with the file format.  KiCAD uses a redo of some old 1970s lisp S-Expression format.  It's a delimiter swamp with positional/sequencial dependencies.

The second is the hardest one to get around.  A schematic is a VISUAL communication medium.  The LLM has no eyes and very little concept of "spatial relationships".  It doesn't understand what "clean layout" looks like.  It' s never seen one and has no "attention awareness" of it.

It does better with "web layouts" as the markup and languages being used there are far more explicit and far more commonly "out there".   Those markups and languages have elvoled to be human editable from the beginning. It still doesn't see your webpage, if it looks good it's likely just that it picked a very basic "tabular" layout and grids like 90% of websites.

You can get it to do a netlist.  You can get it to read/write/edit the netlist and even make an attempt at a BOM.  You will need to review it though.

As an example as to why you need to review it, or take other techniques....  try one of these techniques yourself.

Open an empty chat and ask claude about decoupling capacitors on ICs.  Tell it you were thinking that "3 decades in paralell" sounds like your best approach.  Read the response.

Open a new empty chat context and ask claude exactly the same thing, but suggest your best approach is a single 1uF on the ICs.  Read the response.

Both will be confirmatory, affirming your strategy either one.  It would seem that both are valid answer.  That is because they are both valid answers with almost equal weighting out there on formuns and in schematic/netlist examples.

It highlights something though.  Your prompt can be seen as an "observer".  The LLMs response will be from that view point.  If there is someone obvious on the "back side" of the idea it might be completely blind to it.  So, reprompting it with a flip on something key, like "undo a previous design decision" and ask it to present something different, or you approach the original problem from a new direction, maybe if you were very "pro" the idea, as it's yours, try being negative about the idea and see if it gives you a different insight.

So applied to electronics, if you want something that "you" would have produced yourself you have two options.  1.  Let it decide and pick which every style was closest in it's context or 2.  Go through every single detail with it and ask / chat with it to direct it to what you want. 

As someone said...  at a point it becomes faster to just do it yourself.

Where I did get some use out of it for PCB design, was converting a verilog file to 74HCxx logic gates.  There I was driving the schematic.  I had claude grepping the yosys synthesiser output and helping me go through the verilog bit by bit converting different sections to schematic sections.  The yosys idea was mine.  I was looking at a sequence with multiple inverters and could see it might have few chips if it was completely "inverted".  After looking at a few Claude outputs and not being convinced it was seeing the same thing, I asked it "What did yosys do?" and off it went.  Brought back the LUTs and whatnot yosys has placed for the circuit, translated those back to 74HC discretes.  This helped.

Schematics.  My approach to fix this is a bit too much for me to do myself.

OpenSchematic format.  Split into several layers.  "functional" - the netlist basically.  What the PCB editor and electrical constraints see.  It may include the BOM so that a simulation can run with just the "functional" input.  Then the visual layer.  This is where components get "symbols" and "nets" get "wires" etc.  Things get "places" and orientations etc.  Finally is the documentation layer.  From the normal stuff, to datasheets for components to labels, to tooltips to pop outs.

The functional layer is intented to be easily used by human and machines.  It is technically all you need to make the circuit.... just a bit of visual layout ,  "just" LOL.

To make this even slightly viable... it would need to be created and trans-parsers written for at very least KICAD.  However even there changes would be required to KiCAD beyond just import/export.  Not a one man band project, unless I only want one project for the next 5 years.

The other problem is acceptance.  There have been other such endeavours and they just failed into obscurity.  Most people just pick one EDA application and assume they are stuck with it.

[paulca]

As with software its probably better to run Claude in a VM (with dangerously skip permissions) so you don't have to keep approving changes & all changes tracked by git to allow easy rollback.

You seem to have figured out the right approach.

Too often you will see: "I gave AI this one question and it failed.  AI is useless."

I mean if I want to sit down and have Claude produce garbage, I can.  Instead, like you did, I just gave claude the bits it CAN do well.  Those are then offloaded from me, so I can spend more time on the bits where I am faster.  Even doing admin etc.    Learning new things I can offload to it is good fun too.

It's "cognitive offload", but that is not the same as "thinking offload".  The LLM cannot 'think' in the same way we can.  It's "modelling abilities" are a micro-fraction of what humans do almost constantly.  Model, compare, predict, assess, loop. 

This brings me to your suggestion of "dangerously skip permission" and ignore it's prompts.  This is taking you out of the loop.  Without you in the loop the LLM is piss poor.  So for that strategy to work you need to do all the thinking up front and document it prior to prompting.  This is what most "Prompt engineering" guides would be telling you before 2025.  Prior to 2025 it was more efficient to just "clear context" and run the same prompt over and over again with small modifications until you get what you want.  Chatting back and forth with them tended to cause confusion with the "Pro" point being almost equally weighted to the correcting prompt.  Later the two would compact to be exactly equal weight and it would return etc.  This is not the best way in 2026 though.  The context size has expanded dramatically.  To "pre-load" and "single shot prompt" it with a full 200k ... from manually created specs and docs ... will take you a massive amount of effort.

So I would suggests staying in the loop with it.  Task it with small tasks that you choose, small enough that you can rapidly verify the output is correct.

When it makes stupid suggestions, and this is important, I do not labour the point.  I use "positive direction" instead of "negating".  If claude says, "X is Y" and it's not.  Then saying, "No, X is not equal to Y", to an LLM is risky.  It may not actually see the gravity of the "not" there.  It's just one token.  Changes everything, but it is a known limitation that they do not take the "not" as significantly as they should.  You are better to reframe it with something like, "I believe X is actually Z" and resteer it.

Contray to your approach, the strategy I take on the day job is the opposite.  I tell it to interview me for all decisions.  So the prompt will always have ambiquity to it.  That's why we write software in code and not english.  So with "silent mode" engaged it will just make something up statistically based on how it landed in training data.  With the opposite, it will prompt the "human" when there is more than one possibly direction to take.

In fact I am considering extending this into a PoC called "AI Assistant Compliance".  The LLMs in use by a team are pre-prompted to be always prompting the user and asking for decisions.  So when the software blows up, deletes people accounts and the team says, "The AI did it!", the answer from compliance is... "Actually you answered 'Yes' to 47 of claudes questions, the AI policy does state that YOU are responsible for it's output, these interview logs show you "decided" at each key point.  There for you are accountable."

Further.  If you hit "Yes" too quickly, it knows this too, logs this and instead "punishes" you with a reverse prompt.  Instead of telling you the "good points" of each of the 3 options it presented.  It shows you the "Now here's what blows up and gets destroyed if you choose these options.", just an "Oww!  Human!  Do your job!" caution.


Claude emits:
...."Should I delete the master branch?"
and the user just auto-pilot hits "Enter" for Yes.

"WARNING!  You have failed an AI Assistant compliance and vigilance test.  You have been enrolled on mandatory AI Compliance Policy training.  An invite will be in your calendar."

Just like they do with phishing email tests.

[BadeBhaiya]

Claude emits:
...."Should I delete the master branch?"
and the user just auto-pilot hits "Enter" for Yes.

"WARNING!  You have failed an AI Assistant compliance and vigilance test.  You have been enrolled on mandatory AI Compliance Policy training.  An invite will be in your calendar."

This is sadism. I don't want my tools to test me. My manager does it already

[temperance]

It highlights something though.  Your prompt can be seen as an "observer".  The LLMs response will be from that view point.

Indeed, and then people with whom you work come to beat you on your head with something made up by an AI based on their own biased the input. The best part: they don't believe what you say about the matter... Look at me, I have a confirmation from an AI that what you did can't work.

That is only the start of the problem. I now have to demonstrate how to fool around with AI and I can make it output anything I want to by biasing the input. After such a demonstration some bystanders are baffled and sometimes confused 

I wonder when this AI thing will collapse. Sure, you can make it do something. But its capabilities are two and half solar systems away from what most people seem to think it can do.

[paulca]

I wonder when this AI thing will collapse. Sure, you can make it do something. But its capabilities are two and half solar systems away from what most people seem to think it can do.

I don't think the technology is going to "collapse" unless the power infra collapses or something.  Bubbles ... I expect at least one burst, probably more.

However, your point about what "many" people see current AI as is disturbing.  At the same time, I would take the AI answer over the answer given by about 50% of people.  The AI's information is more reliable than 50% of people.  As a comedian once said, "If you consider just how stupid the average person is, now consider that approximately half of people are dumber than that!  This is what you gotta deal with."

It's an issue because those ~50%, it would seem from pop-culture, do not have the critical or second order thinking required to not suffocate in a wet paper bag.

[temperance]

I could show you what an engineer pulled out of chat GTP to beat me on the head. He even kept his foot in the ground because chat GTP confirmed his flawed reasoning.

I would think that someone with a master degree would know better. Apparently not.

[negativ3]

An aspect of Ai taking over barely discussed is liability. The boilerplate answer to mistakes seems to be "oh yea sorry" whereas that will not wash in most serious endeavours. The can of worms widens and deepens the more credential authority you give it.

[AndyC_772]

I don't think that's such a big question really. If I deliver a board to a customer or employer and it doesn't work, I still have to fix it. Whether I routed it one track at a time by hand, or just gave the whole job to an Ai, doesn't change anything in terms of responsibility.

A more important question is about ownership. Many contracts include clauses along the lines of:

a) I represent that I am the sole beneficial owner of all materials produced, with clear, uncontested right and title to them, and
b) in exchange for consideration (money!), I hereby agree to transfer said rights to whoever is paying me.

That doesn't work if the output of the AI isn't owned, completely and outright, by the person using it. A company might easily find out, quite late in the day, that it doesn't actually own the bank of IP that it thought it did.

That's why I'm happy to use AI to advise on methods and to help track down bugs, but not to actually write any code that gets incorporated into a finished product.