Use AI to write firmware for physical computing — sensors, actuators, timing, and state. Describe the physical behavior you want. AI translates it to code. You test it, feel it, and iterate.
The same principle as vibe coding — but with hardware in the loop. Your job is to specify what should happen physically: what triggers it, what responds, how it feels. AI handles `digitalWrite`, timing, and state machines.
"When the PIR sensor detects motion, the servo sweeps to 90° and holds for 3 seconds, then returns slowly." That's a spec AI can act on. "Use a for loop to sweep the servo" is an implementation choice you haven't earned yet.
Board model, component names, pin numbers. Ambiguity in hardware descriptions produces firmware that almost works — which is the hardest possible thing to debug. "A sensor" can mean fifty things. "DHT22 on GPIO 4" means one.
Test your firmware logic in a browser simulator before connecting real hardware. A logic error found in simulation costs seconds. The same error found after soldering costs an hour and possibly a component. Simulation is not optional — it's the cheapest test you'll ever run.
Paste a hardware specification like this at the top of every firmware prompt. Precision here removes an entire category of AI error.
AI generates your firmware. Development environments upload it. Simulators let you test it before touching hardware. Know which tool belongs at which stage.
Hardware adds a constraint vibe coding doesn't have: the physical world doesn't forgive logic errors gracefully. Simulation and serial monitoring are non-negotiable steps, not shortcuts you skip when you're in a hurry.
AI assigns pins confidently and incorrectly more often than any other firmware error. It may use a pin that doesn't exist on your board, is reserved, or conflicts with a library. Always verify against your board's actual pinout diagram.
Most firmware problems are invisible without Serial output. If you're debugging by observation alone — watching what the hardware does — you're missing the most important diagnostic tool you have. AI can't help you either without it.
Uploading untested firmware directly to hardware and then debugging the result is the slowest possible workflow. Wiring, power, and hardware introduce variables. Simulation isolates the code. Find logic errors there, not on the bench.
"A sensor" or "an LED strip" leaves AI guessing at component models, communication protocols, and library choices. The result is code that almost works — which requires a full debugging session to fix what a precise description would have prevented.
Adding three sensors and two new outputs in a single code update makes it impossible to know which change caused a problem when something breaks. Hardware debugging is already hard enough without entangled variables.