There’s been some activity on this forum about using new AI tools to create KiCad plugins, so I thought I’d share my experience.
I wrote kipart back in 2015. It’s not actually a plugin. It’s a Python script that will turn tabular data on part pins into a schematic symbol. It’s very useful for large parts with 100 or more pins. It’s been used for generating libraries of FPGAs with thousands of pins.
But kipart was written for the old-style symbol library format before the switch to S-expressions. I looked at updating it but it was too much work and I had too little interest.
Last year I tried giving the code base to a few of the AI tools and asking “Convert this code to output symbol libraries using the KiCad S-expression format described at this [URL].” The tools would grind away for a while and then give up, usually reporting an overflow on the context window.
Last month, I decided to retry it using a more incremental approach. I asked Grok to create a CSV file with the pin data for a hypothetical part. Then I ran that CSV through the old kipart and got a library symbol. I used KiCad 8 to convert that symbol into the S-expression format. Then I passed the S-expression back to Grok and said “write a program that will create S-expression libraries from CSV files using this as an example.” (I’m heavily paraphrasing here.) And it came up with something that kinda-sorta worked.
From there, it was a matter of iteratively testing the code → reporting errors → getting fixes → requesting new features (incrementally) → repeat. For example, I asked for the ability to work with spreadsheet files and Grok added the option and supporting code. I tested it, found that it worked, and then moved on to the next feature. A large part of the development time was just waiting several minutes for Grok to regenerate up to 700 lines of code.
Throughout the process, Grok was providing unit tests for the code so I could always check that features were not failing as modifications were made. At the end I also had Grok write the comments and docstrings to document the code.
You can see the entire set of interactions between me and Grok here. It’s LONG because Grok prints out all the code for each iteration and then it likes to talk about what it did. It’s more informative, initially, to look at my prompts which are a tiny fraction of the thread.
I didn’t get to a final working version of kipart. Grok had some difficulties with aligning pins along all four sides of a symbol, but the code for that is relatively small and well-contained so I could manually handle it. And I may do that and release it, or I may not. It doesn’t really matter to me. It took so little effort to create the code that discarding it isn’t a big deal. See this for more about this issue.
This has some big implications for KiCad. There may soon be many plugins. It may become easier to make a plugin than it is to search for an existing one that does what you want.
