Lab Notes: The AI Electronics Gap

Welcome to a new series where I take elements of what I get up to day to day in the R&D process and put the spotlight on things that might be interesting to a general engineering audience, maybe outside of the world of pinball machine development. This is absolutely not an authoritative article, just a taste of some real world, behind the scenes experience that some may find interesting.

I’ve been using AI tools for code work for the past few years. The companies producing them noticed a great market fit for the use case. There’s loads of source data on which to train the models, software engineers are likely to be early adopters due to overlap with the domain, and they are likely to pay for the efficiency gains because they are real.

The quality of output, if properly constrained and managed, has come along leaps and bounds. Agentic coding tools with local file access helped reduce the friction even further. The plethora of Model Context Protocol (MCP) servers augmented the abilities of the Large Language Models (LLMs) in this space even more.

Heck, even for this website, I barely use the code editor now apart from tweaks or to help the LLM out of the occasional hole. I use a folder out of the source tree to provide assets and copy and use that to manage most of what ends up in the build. Maybe I don’t trust it so much on more performant code, at least from an architectural standpoint, but then maybe that’s just more my jam and I like to keep a closer eye on precisely what’s going on there. An ego problem more than anything?

In electronics, things aren’t quite as refined, and I think this comes down to a couple of reasons that I can speculate about.

1. The LLMs just aren’t as optimised for hardware as they are for software because the product market interface is a bit more jagged. The result is an LLM that, to me at least, seems far less impressive and capable in this field in general. This is just down to the prioritisation of training data from the companies that make these. To my understanding, there is nothing intelligent about artificial intelligence in the way it is implemented in LLMs (read more).
2. The canonical use cases just aren’t as well embedded in the way things are done in electronics either. There’s component comparison, schematic design, PCB layout, system-level thinking, cost optimisation of BOM, EMI compliance, and trading all of that off against ultimate performance. Electronics is inherently more multimodal. Even if we take something like a PCB layout, where many common Electronic Design Automation (EDA) packages define everything in a human-readable (well, within limits) plain text file, it is still harder for a generic LLM to replicate the rendering of the PCB engine to assess where traces are going (among many other factors) and begin to be useful. It’s a universe where the tools are just not up to the debugging and introspection available in the software world.

Of course that’s not to say it’s not useful. It’s becoming very good at component comparison, discovery, and sourcing, and creatively suggesting alternatives I wouldn’t have thought of. It’s great for pasting in complex datasheets and bouncing ideas about register maps and bit fields on more complex integrated circuits. Everything just feels a few years behind the curve compared to the software world. You need to be more granular and strategic about the application of AI in electronics. Here, it’s still the precocious intern.

Using it in a granular way isn’t necessarily bad for the mindset though.

So if it’s weak for the core electronics work, the natural next thought is to throw it at all the management overhead of a complicated engineering effort. I came from a world where bloated and opinionated project management tools and methods were the norm, and thought I’d attempt to look with fresh eyes. You quickly realise that for a lot of business tasks, the basic LLM can replace a lot of SaaS (Software as a Service) junk that puts a user-in-yer-face over your data. For many, many tasks you can have a directory of plaintext markdown files all synced using a git repository, a tool like Obsidian if you (optionally) want to render it nicely, and then LLMs on webhooks or as cron jobs (think OpenClaw, or simpler). Your whole human and AI team interact through the repo, solving the multi-user challenge elegantly. Then you have something incredibly flexible and easily updatable to your needs. Git and the LLM are the the real technologies, the rest is fluff.

But it’s far too easy to go down the rabbit hole of optimising the workflow rather than doing the work. I nearly did exactly that. “Premature optimisation is the root of all evil”, but sometimes it is a fun thought experiment.

Start with the lowest friction workflow for a specific contained challenge.

For instance, humble note taking. There are note taking apps galore, but did you ever consider just opening the web interface of your LLM of choice and using that as a note taker? All it takes is a simple prompt at the start of the chat to prevent the LLM rotting its own context with “helpful” junk. This is a bit of a crummy prompt, but it’s a real one I used:

I then just hit it with a load of hastily typed snags straight into the web chat. Some are longer notes, some are simple three word notes. The LLM just automatically started responding “Got it” or “Noted”. Simple as that. No overthinking.

The LLM is sophisticated enough to flag blatantly duplicated items or snags that sound very close to another.

You can then at any point ask for a simplified table of results, a nicely formatted pdf, or even slide deck for sharing. The point here is you’re using the LLM as a second brain for a contained task with limited scope and they absolutely rock for this, irrespective of the discipline or niche.

Following on from this concept, at any point in the conversation, you can ask your LLM to produce a markdown-formatted list of the snags and bring that into the working directory of your EDA data. From there, fire up an AI coding agent with local file access to co-work with you. This can work exceptionally well for automated tasks where the snag maps directly to its plaintext representation in the EDA file. But otherwise you can work manually and at least flag to the agent that the modification you last made was in relation to a particular snag. As LLMs become more capable, they’ll bridge the gap between the item in the list, the solution, and the file format more completely by themselves. It’s an exciting time to be alive.

Some may say this workflow seems clunky, but it solves a number of problems without requiring additional services. The web interface chat is easily accessed on mobile wherever you go, and it’s cloud stored. At any point you can pull a markdown representation of it into your workstation for the real work, or you can keep all the note taking and progress in the web chat.

It can be far too easy to be blinded by the automagical tools available in the world today that incorporate AI in some form or another and to become bewildered by the options. But if you dumb this down to simple interactions with LLMs and get them to do grunt work, you can free up a lot of mental capacity.

Working with AI in the modern world, to me, is about balancing what you want to be very much in control of and what is safe or inconsequential to delegate to a lesser expert. Or conversely, what you need to delegate to an entity with greater expertise. In that way, it’s just like building anything complex as part of a team has always been. It’s just trying to shift the mindset to realise AI is always there as an option for more work tasks than you may think. I guess nothing I’ve written here is new or particularly revelatory, but maybe it’s planted a seed to think differently about how you work.

Share this post

Like this post? Share it with your friends!

• Share on Facebook, opens in a new tab
• Share on Twitter, opens in a new tab
• Share on LinkedIn, opens in a new tab