Spent the weekend letting AI write my STM32 firmware, and here's what happened

I've been writing firmware for about twelve years, mostly on ARM Cortex parts, and my expirience lines up with yours but with a twist. I use one of the AI tools daily now, and the biggest win for me has never been generating driver code. It's asking it to summarize a 900 page datasheet or explain a weird errata sheet while I keep working. That part actually saves me real time every week.

Where it falls apart for me is anything involving timing or hardware quirks. Last year I had an I2C sensor that kept NACKing reads, and the AI kept suggesting the same pull-up resistor fix over and over. Turned out the chip needed a repeated start condition for that paticular register, somethig buried in a Chinese forum post from 2016. The tool had no shot at that.

I also think the job risk is diferent from what people assume. The typing part was never the hard part anyway, and juniors have always learned by fixing broken code. If anything, someone coming up now who debugs AI-generated garbage on real hardware might end up with sharper instincts than I got from copy-pasting app notes.

That said, your point about silent failure modes is the one that keeps me up at night. A web app throws an error you can read. A motor controller that miscounts steps just quietly ruins someone's day three months later.

I come at this from the contract side. Small companies hire me to finish products that a previous team half finished, and over the last two years those handoffs have gotten messier, not cleaner. Someone generates a big pile of code with an assistant, it sort of works on the bench, then the client builds a hundred units and they act up when the motor kicks on or the enclosure gets warm. Fixing that means putting a scope on the lines, staring at the board layout, knowing how a cheap power supply misbehaves under load. Typing speed does nothing for you there. The other thing I notice is the juniors. The ones who lean on the assistant for everything can't sit through an afternoon of reflashing and watching nothing happen on screen. The ones who treat it like a search engine with a personality do fine. The tool isn't the problem, the shortcut mindset is. And honestly a big chunk of my billing has nothing to do with code. It's talking the client through part availability and what testing they need before they can sell the thing. That part was never going to be automated anyway.

Kinda the same boat here, hobbyist level though. I asked an assistant to write me a simple blinky-to-logger thing on a cheap dev board and it gave me code assuming a different crystal frequency. Nothing crashed, it just ran at half speed and my timestamps were quietly garbage for two days. A web dev would've caught that in a second, but I didn't even know what to suspect untill I scoped it. What worries me more than the code is the setup stuff, linker scripts, flash settings, boot config. That's the layer where a wrong guess just bricks your morning with zero error message. Wonder if training data will ever cover that, since half of it lives in people's heads.

Similar story on my bench last month. I had the assistant write a state machine for reading a rotary encoder and it looked fine, but it fell apart the second I actually spun the knob fast. No way it could've known my cheap encoder bounces like crazy. Ended up staring at a scope for an afternoon and adding my own debounce, which took ten minutes once I saw the waveform. My rule now is let it write the boring setup code I've written a hundred times, but I don't trust anything that touches hardware behavior until I've watched it on a scope with my own eyes. That habit has saved me way more grief than any tool.