Using an AI assistant to program the ESP32: the workflow that works

Claude Code, Codex and Gemini do the same thing here

The three AI assistants most often used at an ESP32 workbench today are Claude Code, Codex and Gemini, and the examples in this article apply to all three equally. The limitation discussed here is not specific to one model; it applies to any assistant that talks through text.

An AI assistant reads your code, the error message you pasted and the documentation it already knows. It has no serial port, no oscilloscope and no way to know whether your board's LED is on GPIO 2 or GPIO 8 — unless you tell it.

That is not a defect; it is the nature of the tool. It is good at generating plausible code from patterns, and plausible embedded code can still fail in ways that appear only on real hardware. A platformio.ini with the wrong board compiles without a warning. An invented GPIO compiles without a warning. A race condition in loop() compiles without a warning.

While the component is silent, diagnosis is a guess

The rule applies to any diagnosis, human or AI. Asking the assistant to guess why the board rebooted by itself without pasting the serial-monitor log asks for a hypothesis, not an answer. It is valid as a first guess, but not as an accepted answer until the board confirms it.

What it is not

It is not a substitute for bench testing and not a datasheet oracle. AI assistants get register values, macro names and peripheral pins wrong with the same confidence with which they get them right. The text is fluent in both cases, and fluency is not accuracy. Any claim about hardware behavior made before you have run anything is a hypothesis, not a fact.

What it really makes easier: building, not only fixing

The same assistant can also write new firmware from a conversation without you typing the first line, and that is where it saves the most time.

The firmware in this kit was born that way: three short chat requests. First, "blink the ESP32 onboard LED every second". Then, "add two serial-monitor commands, RAPIDO and LENTO, that change the blink interval without blocking the rest of the program". Finally, "add a STATUS command that shows how long the board has been on and the current interval". Each request was compiled and tested on the board before the next one.

No line was typed by hand, and the result uses millis() instead of an unrestrained delay() because the constraint "do not block the rest of the program" already guided the answer. Asking well removes an entire class of bugs.

What would have taken an afternoon of references and trial and error became three rounds of a few minutes each. The limit is still there — compiling is not testing; testing means connecting the board and observing it — but within that limit, the assistant removes repetitive work.

Context first, code second

If the project has its own conventions — pin names, preferred library or framework version — state them before asking for the first line. Without context, an assistant fills gaps with the most common example on the internet, which may not be yours.

The smallest change that solves the current step

Replacing delay() with millis() in one function is a review you can check in thirty seconds. Asking it to rewrite the entire firmware at once is asking for a bug that will take an afternoon to find, because nobody reviews ten changes at the same time with equal attention.

Read the whole output, not just the result

The first red compiler line explains the cause; the last one almost never does. This applies to an error you read yourself and one you paste back to the assistant. Pasting only the last line means pasting the least useful part.

Flash the board before the next request

This is where most "program with AI" workflows fail: asking for the next function without confirming that the previous one did what it should on real hardware, not only in the editor. Every completed request is a checkpoint; advance only after seeing it work.

Paste the real output, not its summary

"It had a compile error" is too little information. Pasting the full terminal block, or the relevant serial-monitor excerpt, makes the assistant's next suggestion about your error instead of the most common error with that name.

A weak request and one that works

Weak: "why does my ESP32 keep rebooting?" The assistant will list the most common ESP32 reboot causes — watchdog, stack overflow, brownout and memory allocation — because that is all it has to work with. It is a generic list, not a diagnosis.

Works: paste the real serial-monitor log, including the Guru Meditation Error line or the bootloader's rst:0x... value, and say what has already been ruled out. The assistant may still be wrong, but now it is reasoning about your reboot, using the one piece of data that separates "a reboot" from "this specific reboot": what the board said before it fell.

The remaining limit

No assistant can solve alone a problem that appears only under load, in production, after hours, because no log text contains everything that happened before the failure. This still requires instrumentation: structured logs, a heap counter and a timestamp for every reconnection. The assistant helps you write that instrumentation faster. It does not replace the decision that the instrumentation needs to exist.