In embedded and electronics circles, AI is no longer something abstract that lives in research papers. We run small neural networks on ESP32, deploy keyword-spotting models on Cortex-M4 with a few hundred kilobytes of RAM, and even let code assistants sketch out HAL boilerplate for our STM32 projects.
The question quietly creeping into every lab, hackerspace and factory floor is not “Can AI do this?” anymore. It is: If the model can do this, what is left that is genuinely human?
Arduino Uno SMD Edition microcontroller board. — Image: SparkFun Electronics from Boulder, USA / Wikimedia Commons, CC BY 2.0
Throughput vs. intention
Take a mid-range Cortex-M7 MCU running at 400 MHz. Using DSP instructions, it can perform on the order of hundreds of millions of MACs per second. A modern desktop GPU goes many orders of magnitude higher, into trillions of operations per second on large language or diffusion models.
That computational throughput translates into impressively fluent behavior:
- Code assistants that complete entire
while(1)loops withHAL_GPIO_TogglePin()andMX_ADC1_Init()calls. - Generative tools that propose schematics for a buck converter or a simple sensor front-end.
- Image models that “imagine” what your 3D-printed robot chassis could look like.
But inside all this, there is something conspicuously absent: intention.
The model does not want your motor driver to be efficient. It does not care whether your watchdog resets at the right time. It simply predicts the next token, the next pixel, the next activation value based on statistics of data it has seen.
We, on the other hand, walk into the lab with goals:
- “I need this device to run for a year on a CR2032 cell.”
- “This robot must not injure a child even if a sensor fails.”
- “This firmware must be maintainable by someone else in three years.”
Maybe the real frontier between humans and machines is not capability but direction: we supply the why, the model supplies more and more of the how.
Is AI actually creative, or just combinatorial?
In embedded work, creativity rarely looks like painting or poetry. It looks like:
- squeezing a PID controller and a small neural net into 64 KB of RAM;
- choosing a clever oversampling strategy to turn a noisy 10‑bit ADC into something that behaves like 12 bits;
- abusing a timer peripheral to generate an extra PWM channel you “officially” don’t have.
An AI assistant can absolutely suggest code for all of these. It can even propose exotic filter topologies or RTOS task layouts it has seen in other projects. But note what is happening:
- The model recombines existing patterns in a very high-dimensional space.
- The engineer navigates constraints in the real world: BOM cost, PCB area, certification, user behavior, and occasionally, Murphy’s law.
So perhaps AI’s “creativity” is high-dimensional remix, while human creativity in engineering is constraint-driven invention. The more the model helps us explore the combinatorial space, the more our job shifts toward defining, prioritizing and questioning constraints.
Robot arm and engineer working together on a PCB assembly line — AI-generated illustration
From human-in-the-loop to AI-in-the-loop
We like to say we are building human-in-the-loop systems: the AI proposes, and the human approves. Yet if you look at your own workflow as an engineer, the picture is often the opposite.
You decide:
- the system architecture and safety boundaries;
- which peripherals to trust and which to guard with redundancy;
- what “acceptable failure” means in your application.
Within that architecture, the AI model is just one block in the diagram:
- input from sensors (
ADC,I2C,SPI), - some opaque vector math inside,
- output to actuators (
PWM,GPIO,UART).
In practice we are living in an AI-in-the-loop world: the human carries the overarching responsibility; the model is a powerful, but narrow, component.
What happens if we push this further? Imagine a toolchain where a generative model:
- drafts your entire firmware project structure,
- chooses HAL vs. bare-metal based on your power budget,
- writes unit tests and even generates simulated sensor logs for them.
Your role might gradually tilt toward specifying high-level intents: “Design a motor control firmware for a 3-phase BLDC, 24 V, with maximum efficiency, under 64 KB flash, MISRA-compliant.” You become, in a sense, a programmer of goals rather than a programmer of loops.
Oscilloscope screen blending signal traces with a neural network visualization — AI-generated illustration
Creativity and responsibility: an inseparable pair?
The more AI participates in design, the harder the ethical questions become. Take a connected door lock:
- The encryption scheme is proposed by an AI assistant (
AES-256,TLSover Wi‑Fi). - The OTA update mechanism and rollback logic are generated from examples.
- You review the code, run tests, ship the product.
A year later, a subtle implementation bug allows remote unlocking. Thousands of homes are affected.
Where does responsibility live?
- With the model that suggested the vulnerable pattern?
- With the company that trained it on unvetted code?
- With you, who signed off on the design and merged the PR?
Today’s legal and professional frameworks still place accountability squarely on the human engineer and their organization. That means we may end up in a world where creativity is shared, but responsibility is not.
As AI pervades our IDEs, simulators and even low-power MCUs, perhaps the deepest question for embedded engineers is no longer “What can this chip do?” but “What do we choose to do with this much leverage?”
When you imagine yourself ten years from now, surrounded by smarter tools and denser silicon, what part of your work do you hope will still feel unmistakably, irreducibly human?
