AI can review your PCB. The datasheet still decides.
How I use Python, MCP-connected tools and AI assistants to speed up schematic reviews, routing checks and firmware tests — and the verification rules I never skip.
AI-assisted engineering is real, and it's useful. It's also confidently wrong often enough that you need a system around it. This is the system I use for hardware work.
Where AI actually helps on hardware
First-pass schematic reviews
I export netlists and BOMs and let an assistant look for the boring-but-costly stuff: a pin with no connection, a pull-up missing on an I²C bus, a regulator whose input range doesn't cover the supply, a part used outside its rated voltage. It's a tireless junior reviewer that never gets bored of checklists.
Consistency checks with scripts
Many of my checks aren't "AI" at all — they're Python scripts that the AI helped me write faster:
- Every net named
*_3V3actually connects to the 3.3 V rail. - No user-facing signal lands on an ESP32 strapping pin.
- Every connector pin in the schematic matches the pinout table in the docs.
- Trace widths on power nets meet a minimum.
Scripts are deterministic. Run them on every revision and they never forget.
Firmware test generation
Given a module's interface, an assistant can draft unit tests and edge cases far faster than I can type them. For SolveBlock's statistics code that meant dozens of nasty test sessions (DNFs, penalties, ties) in minutes.
Documentation
Bring-up notes, pinout tables, assembly instructions: AI drafts them from my notes, and I correct them. The docs exist now, instead of "later."
MCP: giving the assistant real tools
The Model Context Protocol lets an assistant call tools instead of guessing. In my setup, MCP servers expose things like:
- Reading project files (netlists, BOMs, firmware source).
- Running the check scripts and returning results.
- Querying a parts database for specs.
That changes the conversation from "what do you think this pin does?" to "run the strapping-pin check and tell me what failed." Answers grounded in tool output are dramatically more reliable than answers from memory.
The rules I don't break
1. The datasheet wins. If the assistant says a pin supports something, I find the line in the datasheet that says so. No line, no trust.
2. Physical hardware is the final reviewer. A check that passes on screen but fails on the bench failed.
3. AI suggestions are proposals, not commits. Every change to a schematic or layout gets reviewed like a pull request from someone new.
4. Deterministic checks beat clever prompts. If I find myself asking the same question twice, it becomes a script.
A real failure mode
Language models are very good at producing plausible pinouts. "Plausible" is the problem. Pin numbering varies across packages of the same part; alternate functions vary across chip revisions. An assistant that blends two datasheets in its memory will hand you a pinout that's 90% right — the most dangerous kind of wrong.
The fix is structural: the assistant never gets to be the source of a pin assignment. It can check assignments against a datasheet I provide, and it can flag things for me to verify. The source of truth stays a document.
Why this matters beyond hardware
This is the same lesson from years of enterprise change management: speed is great, and controlled change is how you keep it. AI made my design reviews faster. Verification is what made them safe.
Some links in these notes are affiliate links. If you buy through one, I may earn a commission at no extra cost to you. I only link to tools I use or would recommend.