AI Can Reverse-Engineer Hardware. I Can't Turn Off My Own Alarm.

My standing desk raised itself while I was writing this article. I'd been sitting for too long.

The home automation was originally supposed to be a nudge, not a lifestyle. If I sit for an hour, Home Assistant starts with a polite spoken warning, escalates through push notifications and increasingly aggressive LEDs, and at the 80-minute mark, starts the emotional manipulation ("Think of your kids..."). No match for my ADHD. After two weeks I was reflexively smacking my Nest Mini before it finished its first sentence.

A desk physically rising while you're typing is harder to dismiss.

Claude Code wrote most of that first version, which felt unremarkable in the way AI assistance now feels unremarkable: I vaguely describe what I want - it changes the template, reloads the automation, done. But the desk refused to move on command. Hardware with a proprietary protocol isn't something Claude Code can just config-file its way through.

The FlexiSpot E7 Pro Plus standing desk, despite being everywhere, does not really want to be automated. With the existing community integrations, Home Assistant can read its height, but most attempts to move it die silently. The controller expects a specific conversation with a connected keypad, and every existing integration was seemingly skipping that handshake. So I had a $7 ESP32 impersonate the keypad well enough to be trusted. About $12 in parts, an afternoon with Claude Code grinding away, and the desk obeyed.

I'd been using AI to write Home Assistant config files for months. But this was an LLM helping me reverse-engineer a hardware protocol and write working embedded firmware for a microcontroller. The coding agents are bleeding out of the terminal and into the physical world. And I wanted to see how far I could push that.

The desk was just the latest thing. Before that, Claude Code had already taken over my Home Assistant setup piece by piece. A presence sensor plus walking pad power monitor that knows whether I'm sitting, standing, or walking. Frigate camera integrations with object detection and person recognition. Leak sensors, security automations, the whole break escalation system.

At some point I realized I don't actually know how Home Assistant works. Not really. I've never manually written an automation from scratch. I don't use the dashboard. Claude Code is my interface to the physical systems in my house - that's just how it is now.

This became extremely clear one evening when our washing machine had a minor leak. The leak sensor triggered. The alarm went off. And I opened Claude Code to ask it to silence the alarm, because I genuinely did not know how to do it myself.

You could read that as a trap I walked into, or you could read it as just the next abstraction layer. Both readings are probably true at the same time. I lean toward the "just another tool" framing most days.

After the desk, I got greedy - Claude can figure out how to control a desk - what else can it figure out? What about my Plaud Note with a broken display? It's a portable "AI" voice recorder that had no real reason to be "smart". It's a microphone that records audio. The smart features are literally just two API calls: transcribe and summarize, both mediocre. I want it to be dumb and have more capable models handle the smart parts.

So Claude Code reverse engineered it - with surprising ease. Standard reverse engineering approach: analyze the app, map out the protocol, figure out how the device talks to the phone. Took about five days of casual sessions, multiple dead ends, and at one point it found the necessary key sitting in data it already captured days earlier - just didn't look at it closely enough. Now I can pull my recordings directly over Bluetooth without any app or subscription.

Three more ESP32 boards are on order. Next target is a robot lawnmower with no API.

There's a woodworking analogy I keep coming back to. Most woodworkers build their own crosscut sleds (a sled that rides the rails of a table saw to cut wood across) instead of buying one. It's almost a right of passage. Not because it's cheaper, but because a pre-made sled is necessarily generic. It doesn't know your saw, your material sizes, or how you actually work. You can't easily modify something you didn't build. I've always been this person. Long before Claude Code, I built my own voice transcription app because the built-in Windows one wasn't good enough. I press Caps Lock and talk instead of type. 90% of my computer interaction is voice now. There are probably better apps out there, but mine works exactly how I want it to.

Claude Code just made it possible to build these things faster. The barrier drops so low that experimentation becomes almost free. I rigged a classic 7-Eleven door chime to play whenever my dogs came back inside through the back door. Kept it for about two days, which was probably two days longer than my wife would have liked. Deleted the automation. Total investment: maybe five minutes.

I am extremely known for picking up hobbies and abandoning them about 80% of the way to mastery - not giving up exactly, just moving on to the next thing. Minimal sunk cost means walking away is painless. And fast enough iteration means you might actually finish before your brain moves on. That's what Claude Code changed. It handles the tedious parts, the proper syntax and debugging and configuration research, leaving me to focus on whether the thing even makes sense in my life. And picking a project back up is effortless. I literally just resume the session. All the files, docs and context is right there. I can ask "where were we?" or "what's next?" and get an immediate answer. Context switching, which is the thing that costs me the most, is basically eliminated.

The desk, the Plaud, the home automations, the voice app. They're all shop tools. Built to fit how I actually work. Mine to maintain. Mine to debug. Mine to break.

These models are about 90% accurate. Some of the failure modes you learn to recognize. Knowledge cutoffs. Time estimates are way off, every time, completely useless for planning. Whatever you discuss in the first half of a session strongly biases everything after. If you mention you're tired or it's getting late, the model will rush through the rest trying to wrap things up. These are patterns you can work around once you know they exist.

But failures are inconsistent. I've watched it look at a screenshot of something clearly wrong and say "looks great, I think we're done here." That Westworld line. "Doesn't look like anything to me." Any person would see the problem immediately. The model genuinely does not, until you point at it.

The real danger isn't the failure modes you learn to spot. It's the ones you can't, because you're out of your depth. If you don't have enough domain knowledge to recognize when the 90% has drifted into the wrong 10%, you won't even know to point at the problem. The inaccuracy just compounds quietly, and you end up somewhere very far from reality without ever feeling lost. You say: "Looks great, I think we're done here" wiring a relay to mains voltage for the first time.

It feels like increasingly every company is converging on the same playbook: subsidize the hardware, lock away the data, charge monthly for access, increase prices. What are you going to do, switch? They're all doing it. Customer support is now a Google form that goes nowhere - looking at you Anthropic. That's just how things work now, apparently.

I paid for my standing desk. The hardware is mine. If the manufacturer didn't build an integration, I'll add one. I paid for my Plaud recorder. My voice recordings don't need to route through anyone's cloud. The device is fully capable of being a dumb recorder, so that's what it is now. The OnePlus phone I bought for $80 to root and use as a Bluetooth bridge is, by any standard, obsolete. Too slow to use as a phone. But now it has a second life - a bridge for Claude Code to reverse engineer devices with.

Once you've done this just a couple times, you can stop choosing hardware based on what it can do - and instead think about what you can make it do. I'm shopping for a robot lawnmower right now. The best one for my yard has no Home Assistant support whatsoever. I'm buying it anyway and going to bend it to my will. My OXO coffee maker needs two physical button presses to start. Previously, that was the end of the conversation. Now I look at it and think: ESP32, a relay, 30 minutes of work.

Limitations you previously accepted as permanent stop being permanent. That's the actual shift.

I have some experience with microcontrollers. Arduinos years ago, a couple PCBs, comfortable with electronics. And I've fully committed to doing literally everything through Claude Code, which everyone on my team now comes to me for guidance on. But my story is not the proof that anyone can do hardware with AI. Not yet.

What I am is someone running an experiment to see where this goes, how far coding agents can push into the physical world, and what breaks along the way. Lots of people already use Claude Code to build and improve their Home Assistant setup. That's the start. What I'm saying is it doesn't have to stop there.

The barrier keeps dropping. M5stack makes modular hardware that clicks together like Legos. The extent of "hardware work" for many projects is literally connecting a few things with cables. The limitation is mostly in your head (and your wallet). And maybe this is just the new way we interact with everything. As long as the tool stays available, stays capable, and doesn't decide one day that you violated its terms of service.

Claude Code can be the breaker of walled gardens.

Assuming they don't try to make Claude itself a walled garden. Which, in almost certainty, they will try.