Vibe Coding Hardware: Build an ESP32 Project From One Sentence
Vibe Coding Hardware: Build an ESP32 Project From One Sentence
Quick answer: vibe coding hardware means describing the device you want in one plain sentence and letting AI produce the parts list, the wiring and the firmware, while you build, upload and test it. It works when the AI knows your exact parts: their pins, voltages and libraries. Most AI-written Arduino code that “compiles but does nothing” fails because the code and the wiring were never written for the same physical parts.
What is vibe coding for hardware?
In software, vibe coding means describing what you want and letting an AI write the program, then steering it with follow-up prompts. Hardware adds a physical layer that software never has: a sensor with fixed pins, a board with a fixed header, a supply voltage that can damage a part, and libraries that must match the chip. You cannot retry your way out of a 5 V signal on a 3.3 V pin.
So vibe coding hardware is really three outputs from one sentence: a parts list you can buy, a wiring map you can follow wire by wire, and code that compiles for that exact board. If any one of the three is generated without the other two, they drift apart, and the project fails on the bench even though each piece looks right on its own.
Why does AI-written Arduino code fail on real hardware?
A general chatbot writes plausible code for a plausible board. It rarely knows which ESP32 board you have, which pins that board actually exposes, or which revision of a sensor arrived in your parcel. The code compiles, the upload succeeds, and then the Serial Monitor shows nothing useful. Here are common mismatches on the ESP32:
| Failure | Typical cause | What is actually wrong |
|---|---|---|
| Pin not on the board | Code uses GPIO0 for a sensor | On the 30-pin ESP32 DevKit, GPIO0 goes to the BOOT button, not the header |
| Analog pin dies with Wi-Fi | Sensor on GPIO4 or GPIO25–27 | These are ADC2 pins, which cannot be read while Wi-Fi runs |
| Wrong voltage | 5 V sensor output into a GPIO | ESP32 pins are 3.3 V only and are not 5 V tolerant |
| Board may not boot | Sensor on GPIO2, 5, 12 or 15 | Strapping pins set the boot mode at reset |
| Library or core mismatch | Code written for an older library or ESP32 core | APIs change between versions (the 3.x core replaced the I2S API); some changes fail to compile, others compile and behave differently |
| Wrong part variant | Code declares DHT11, you own a DHT22 | Different data format, so every read fails |
Most of these never show up as a compile error. They come from a mismatch between the code and the hardware, which is why pasting the error back into a chatbot often goes nowhere: there is no error to paste.
How does a parts-aware flow fix it?
The fix is to make the parts list the single source of truth and generate everything else from it:
- Start from real, stocked parts. Each part brings its own pin names, supply range and interface from its datasheet and listing.
- Pick pins from the real board header. Skip flash pins, strapping pins and pins the board does not expose, and use ADC1 for analog when Wi-Fi is on.
- Write the wiring and the code from the same pin map. If the wiring says GPIO35, the code says GPIO35.
- Compile before handing it over. Syntax slips and library mismatches are caught before you plug anything in.
- Leave the bench test to you, and say so. Calibration and a first power-up are still physical steps.
Soldr is built around this loop: one prompt in, and out come the exact parts, the wiring and code that compiles, all from one parts list. Compoden, the store, stocks those parts and delivers across India.
Worked example: a plant thirst alarm from one sentence
Here is the whole flow for a small, real build that uses parts Compoden stocks: an ESP32 30-pin development board and a capacitive soil moisture sensor. We wrote and compile-checked this example ourselves to show the shape of output you should expect from any parts-aware tool. It is not a transcript of a Soldr session.
| Step | What you do or get | Why it matters |
|---|---|---|
| 1. Describe it | “I want to build a plant thirst alarm with an ESP32.” | One sentence; name the board if you already own one |
| 2. Check the parts | ESP32 30-pin board, capacitive soil moisture sensor, 3 jumper wires, USB data cable | Tick off what you own; the board ships without a cable |
| 3. Wire it | VCC to 3V3, GND to GND, AOUT to GPIO35 | Every pin comes from the board's real header |
| 4. Upload | Paste the sketch, select ESP32 Dev Module, upload | We compiled this sketch before publishing it |
| 5. Calibrate | Note the reading in air and in water, edit two numbers | Real sensors need real reference points |
| 6. Iterate | “Now send me a Wi-Fi alert when it is dry.” | Change one thing at a time and retest |
The wiring, and why each pin was chosen
| Sensor pin | ESP32 pin | Reason |
|---|---|---|
| VCC | 3V3 | Keeps the analog output inside the ESP32's 3.3 V input range |
| GND | GND | Common ground |
| AOUT | GPIO35 | ADC1 and input-only: keeps reading when Wi-Fi is added later, and cannot be driven by mistake |
A plausible-looking alternative, AOUT on GPIO4, would compile and even work, until step 6 adds Wi-Fi. GPIO4 is an ADC2 pin, and the readings stop. Choosing GPIO35 up front is the difference between code that compiles and a build that keeps working as it grows.
The code
// "I want to build a plant thirst alarm" - ESP32 DevKit + capacitive soil moisture sensor v2.0
// Wiring: sensor VCC -> 3V3, GND -> GND, AOUT -> GPIO35 (ADC1, so it still works with Wi-Fi on)
const int SOIL_PIN = 35;
const int DRY_RAW = 3000; // placeholder: your reading with the probe in air
const int WET_RAW = 1300; // placeholder: your reading with the probe in water
const int THIRSTY_PCT = 30; // alarm below this moisture percentage
void setup() {
Serial.begin(115200);
analogReadResolution(12);
}
void loop() {
int raw = analogRead(SOIL_PIN);
long pct = constrain(map(raw, DRY_RAW, WET_RAW, 0, 100), 0, 100);
Serial.printf("Soil moisture %ld %% (raw %d)%s\n", pct, raw,
pct < THIRSTY_PCT ? " -> WATER ME" : "");
delay(2000);
}Compile check: this sketch compiled for esp32:esp32:esp32 (ESP32 Dev Module, ESP32 Arduino core 3.3.10) on 5 October 2026. Calibrate DRY_RAW and WET_RAW with your own probe before trusting the percentage; the numbers in the sketch are placeholders.
When is vibe coding hardware not enough?
One sentence is a good start for sensors, displays, small motors and Wi-Fi dashboards on USB power. Bring in an experienced engineer, or at least a careful review, before you build anything that switches mains voltage, charges lithium cells, drives large motors or protects people or property. Those failures cause damage, not just a blank Serial Monitor.
Where should you start?
Pick one sensor and one board and get a reading on the Serial Monitor first. The guides below give the exact pins, wiring and compile-checked code for the sensors Compoden customers buy most. When you are ready for a whole device, describe it in one sentence at app.soldr.ai and get the parts from compoden.com.
| Item | Role | Link |
|---|---|---|
| ESP32 30-pin CP2102 development board | Controller with Wi-Fi and Bluetooth | View ESP32 board |
| Capacitive soil moisture sensor v2.0 | Relative soil moisture, analog output | View soil moisture sensor |
ESP32 sensor wiring guides
- TCS34725 colour sensor + ESP32: pinout, wiring and code
- DHT22 temperature and humidity + ESP32: pinout, wiring and code
- XKC-Y25-V non-contact liquid level + ESP32: pinout, wiring and code
- INMP441 I2S microphone + ESP32: pinout, wiring and code
- 5 mm LDR light sensor + ESP32: pinout, wiring and code
- Capacitive soil moisture sensor v2.0 + ESP32: pinout, wiring and code
- HX711 and 5 kg load cell + ESP32: pinout, wiring and code
- Water level sensor + ESP32: pinout, wiring and code
- AS5600 magnetic angle sensor + ESP32: pinout, wiring and code
- AHT21B temperature and humidity + ESP32: pinout, wiring and code
Sources
ESP32 pin rules (flash, strapping, input-only and ADC2-with-Wi-Fi limits): Espressif ESP32 GPIO reference. Pins exposed on the 30-pin DevKit, including GPIO0 going only to the BOOT button: Compoden’s board pinout verification of 2 October 2026 against Espressif documentation and the board’s published header layout. Sensor supply and output range: the Compoden soil sensor listing.
Frequently asked questions
How do I build an ESP32 project without knowing how to code?
Describe the device in one plain sentence to a parts-aware AI build tool, then follow the parts list, wiring table and code it returns. You still wire the parts, upload the sketch from the Arduino IDE and test it, but you do not have to write the code yourself. Start with one sensor and one output so a fault is easy to find.
Can AI write Arduino code, and why does AI-generated Arduino code often not work?
Yes, AI chatbots can write Arduino code that compiles. It often fails on the bench because the code was written without your exact parts: a pin that is not on your board, an analog pin that stops working with Wi-Fi, a 5 V sensor on a 3.3 V pin, or a library version with a different API. Generating the wiring and the code from the same parts list removes most of these mismatches.
What is vibe coding for hardware, and can you vibe code an Arduino or ESP32?
Vibe coding for hardware means describing the device you want in plain language and letting AI produce the parts list, wiring and firmware, while you build, upload and test. You can do it with Arduino and ESP32 boards today. It works best when the AI knows the exact parts and board, because physical pins and voltages cannot be fixed by retrying a prompt.
Do I still need to test an AI-built circuit?
Yes. A clean compile proves the code and libraries agree, not that the wiring is right or the sensor is calibrated. Check every wire against the table, power it from USB first and watch the Serial Monitor before adding motors, pumps or mains loads.