Notes · Ideas × AI
I Had an Idea. Claude Built It. We Both Learned Something.
On building a working smart moisture monitor from scratch — and what it says about the new relationship between human curiosity and AI.
Let me be honest with you before we get started: I am not an electrical engineer. I don’t write firmware for a living. I have never soldered a production PCB. I’m a network and security leader who occasionally takes apart things he probably shouldn’t.
But I had a problem, a box of random parts, and a curious mind. And it turns out that’s enough — if you know how to use the tools now available to you.
The Problem
Hiking gloves in the rain. ATV gloves after a long day in the mud on my Honda Foreman Rubicon. If you spend time outdoors doing either of those things, you already know the problem. Gloves that come back soaking wet and stay that way — and if you leave them in your gear bag overnight, they develop a personality you really do not want.
The obvious solution is some version of “blow air into them until dry.” But how do you actually know when they’re dry? You guess. You check. You probably over-dry them or give up too early because there’s no signal, just hope.
I started thinking: what if you measured the humidity in the exhaust air coming out of the gloves? When they’re wet, that exhaust humidity would be noticeably higher than the intake air. As they dried out, the delta between the two would shrink toward zero. That delta is the signal — objective, measurable, and automatic.
Simple idea. But turning that idea into a working circuit with firmware and a display — that’s the kind of thing that would have stopped me cold a few years ago.
What I Had
Rattling around in a parts drawer: an ESP32C3 microcontroller board, two Adafruit I2C humidity and temperature sensors, a couple of low-wattage Noctua fans (the kind built for silent operation), a small OLED display, some resistors, a handful of MOSFETs, a perfboard, and various connectors.
No pre-designed circuit. No kit. Just components and an idea. And eventually — a 3D-printed enclosure to house it all.
What Claude Did
I described what I wanted — the concept, the components I had, the power constraints — and asked Claude to help me design a circuit and write the firmware. What happened next genuinely surprised me.
It didn’t just answer my question. It walked me through power budgeting to confirm everything would fit on USB power. It designed the full pin mapping for the microcontroller. It wrote firmware that monitored the humidity delta between intake and exhaust sensors, controlled fan speed via PWM, tracked elapsed drying time, and drove the OLED display — showing cycle state, real-time humidity readings, and the delta in a format I’d actually find useful.
When I hit a bug — an inverted humidity delta calculation that caused the fans to stop immediately when the gloves were wet — it diagnosed the logic error from my description alone. When my perfboard wiring was wrong and I described the symptom (pins turning on in the right sequence when I disconnected the board and tested with a test LED), it correctly identified that the issue was in my wiring, not the firmware.
When I added a fan tachometer and ran into PWM interference noise in the RPM readings, it explained the electrical reason and suggested a practical fix. When I decided I wanted an OLED display to show cycle status without being connected to a laptop, it integrated the display driver in a few iterations.
The day it worked as intended — button pressed, cycle running, delta ticking down from 13% toward 3.4%, then “COMPLETE!” appearing on the OLED with the total elapsed time and final humidity readings — was genuinely one of the more satisfying moments I’ve had with a personal project. Worth noting: this prototype uses a swatch of wet fabric sandwiched between the intake and exhaust fans. The glove holder and airflow manifold are the next mechanical design challenge. The hard part — the control system, the sensing logic, the firmware — is already proven out.
What I Brought
The idea. The problem framing. The curiosity to keep going when things got confusing. The willingness to describe what I was observing precisely enough for the AI to reason about it. And the judgment to know when the output was right and when something felt off.
That last part matters more than people realize. At one point I noticed the display was showing a drying cycle screen that didn’t look right. I didn’t know exactly what was wrong with the code — I couldn’t have written that fix myself — but I knew it was wrong, and I knew how to describe it. That’s a skill. It’s not engineering. But it’s not nothing, either.
What This Actually Means
There’s a category of thing that used to be simply out of reach for most people. Embedded systems. Custom firmware. Electronic circuits designed from scratch. These weren’t locked away by intelligence — they were locked away by years of specialized training and practice that most people don’t have the time or path to acquire.
AI doesn’t give you those years of experience. But it does give you a collaborator who has them, available at any hour, patient with every question, and capable of meeting you exactly where you are.
The thing you still need to bring is the idea, the genuine curiosity, and the willingness to stay in the problem. You can’t just type “make me a glove dryer” and walk away. You need to show up, pay attention, describe what you’re seeing, and iterate. The people who will get the most out of these tools are not the ones who treat them as vending machines. They’re the ones who treat them as genuine collaborators — with something to offer, and something to learn.
My gloves are dry. The firmware is on GitHub. The OLED says “Ready.” And I keep thinking about what else I could build with a box of parts and a good conversation.
Carlton D. Houston is a Senior Infrastructure & Security Leader based in Roswell, GA. This is his personal site — a place to write things down when they seem worth writing.