Anyone else finding embedded work less fun since leaning on AI?

Oct 23, 2026 Last reply: 9 hours ago 5 Replies

First reply

kit.vance

Honestly, I've crossed the threshold into full automation for the basic peripheral setup. I’m using AI to generate the foundational layer for all my STM32 projects now. For instance, if I need to set up a specific timer for a polling routine, I just tell the tool the required…

Read the full reply

Been thinking about this a lot lately. I do firmware on STM32 parts and over the past year I've gotten into the habit of just describing what I need, say a timer setup or a DMA buffer scheme, and letting the tool generate the init code. It works. It honestly works well. But I've noticed I don't get that little buzz anymore when the board finally blinks or the sensor data comes through clean. Part of me wonders if that's just nostalgia. When I was younger I'd spend a whole evening squinting at a reference manual to figure out one register, and that struggle was kind of the point. Now the struggle is gone and somthing feels missing. The other part of me thinks maybe the real enjoyment was never in the typing anyway, and I should be pushing myself toward the design and architecture side where I still have to think hard. Curious how others land on this. Do you hand-write stuff on purpose to keep the skills sharp, or have you fully handed over the boring bits and moved on? Genuinely torn here.


Honestly, I've crossed the threshold into full automation for the basic peripheral setup. I’m using AI to generate the foundational layer for all my STM32 projects now. For instance, if I need to set up a specific timer for a polling routine, I just tell the tool the required frequency and interrupt flags, and it handles the register writes. It’s unbelievably fast. I used this approach recently when configuring a data acquisition system. Instead of spending three hours meticulously setting up the ADC conversion sequence and the DMA buffer pointers, the code generates the initial structure in minutes. This isn't me skipping the work, though. The real effort has shifted entirely. My focus is now on the system architecture and the data flow logic. For example, I'm currently working on a remote monitoring unit where power efficiency is critical. The challenge isn't making the sensor read; it's making sure the entire chip spends 99% of its life in sleep mode, waking up only for the neccesary acquisition cycle. That power management and state machine design is where the actual satisfaction is. It’s much bigger than just watching an LED blink.

It feels less like a coding chore and more like high-level systems engineering now. The AI takes care of the drudgery, letting me focus on the interesting design problems.

I land on the hand-write side, but not out of nostalgia. I let the tool draft code, but I won't ship a line I can't explain. Last spring it generated a comms setup for one of my boards, compiled clean, looked fine. Then the link would randomly drop after a few hours. Turned out there was a subtle mistake in the config that I would have caught instantly if I'd typed it myself. Instead I burned two evenings with a logic analyzer before I understood the code well enough to even suspect it. That's my issue with handing over all the boring parts. The boring parts are where the intuition lives. When something breaks the night before a demo, the tool gives you plausible-sounding guesses, and if you've never wrestled with the manual yourself you can't tell a good guess from a bad one.

So my rule now is simple: the tool can type, I have to read. Every generated line gets reviewed like it came from an intern I don't fully trust yet. It's slower than full automation, way faster than my old pace, and the buzz is still there when the board comes up because I actually know why it works. Am I just being slow here, or do other people review generated code line by line too?

Here's my take after a few decades of this stuff. The buzz never came from typing the setup code anyway. Back when I was doing this on paper datasheets and burning EPROMs, the fun part was the hunt, the wierd bug at 2am where the thing works til you touch the enclosure. That hunt is still there, it just moved up a level. If anything I'd worry the other direction: if the tool hands you clean peripheral code every time, and you never have to trace why a timing went sideways, you lose the instincts that make you good at the top level too. I let the machine draft it, then I read every line like a suspicious editor before it goes near a board.

I'm pretty new to this so take it with a grain of salt, but I started learning microcontrollers last year and I catch myself asking the tool for everythign before I even try. Then a few weeks ago I had to debug something with no internet access and realised I couldn't even read the config without help. Kind of embarrassing. Now I force myself to write the first attempt by hand and only check after. I still use it afterwards, but at least the manual part sticks a bit better. Maybe worth trying if you're worried about losing the knack?

With the guy who won't ship code he can't explain. Had the same thing last year, tool spat out an SPI init for a flash chip and everything looked right, but the reads came back garbage on one board only. Turned out the clock polarity was set for a mode the chip didn't actually support, something I'd have caught in thirty seconds if I'd written it out myself. Now I still let it draft, but I read every register line before it goes anywhere. Slower, but the weird bugs are way fewer.

Join the Discussion

Have something to add? Share your thoughts — no account required.

Didn't find your answer?

Ask the community — no account required