For the past few months, I’ve been dabbling with Claude Code. Not in a “no one needs developers anymore, anyone can build apps now” kind of way. More in a “I have a basic understanding of this, but not enough to turn it into code I can actually use” kind of way. I don’t need to build the next vibe-coded B2B SaaS app. I don’t need to pitch you my next big AI-powered startup. Sometimes it’s just nice to code a solution to a small problem you’re having.
Last month, I wanted to give Claude something bigger to chew on. I’ve been maintaining ha-meural (a custom integration to get NETGEAR Meural Canvas digital picture frame devices working in Home Assistant) for about six years now. It started as a pandemic project: I originally bought a Canvas to display vacation photos while we were in lockdown, and I wanted to control and automate it from Home Assistant. But I’m a marketer, not a developer, so the code was definitely rough around the edges. Since then, I’ve kept the integration working, but never did any major updates. In general, it hadn’t kept pace with Home Assistant’s evolving best practices.
So I threw ha-meural at Claude Code, set it to plan mode, and gave it a simple prompt: “Modernize this integration and bring it up to date with current Home Assistant best practices.”
It came back with a pretty substantial plan. Reading through it, I arrived at an obvious conclusion: I understood the changes it was proposing and why they’d be improvements, but I could never have implemented them myself. There was a real gap between where my programming skills sat and where the integration needed to go.
So I told it to go ahead. After running out of tokens repeatedly (I should have upgraded to a proper plan before attempting this) a new, shiny version of ha-meural was waiting for me. I installed it in Home Assistant expecting it to fail spectacularly. It didn’t. It worked fine. Better than fine, actually: it had quietly fixed a few bugs that had been bothering me for years but were beyond my ability to touch. A few iterations later, and Claude had implemented every feature that had been on my wishlist for the last six years.
Still, ha-meural was something I had at least written a first version of, something I understood, something I could hand to Claude as a foundation to build on. What would happen without that?
Last week, I gave it something more demanding, or so I thought. I have a Tuneshine cover art display, a 64×64 matrix that shows lo-fi, almost abstract representations of whatever music you’re listening to. Up until now this device has relied on a remote cloud server to send it art, and there was no integration that was useful or possible. But in their latest newsletter, Tuneshine announced they’d added a local API to the device. And anything with a local API can be connected to Home Assistant.
So I dropped the API documentation into Claude and told it to write a custom Home Assistant integration from scratch. I fully expected this to get messy: I gave it no codebase to work from, nothing beyond pointing it to the Home Assistant developer docs and handing it Tuneshine’s fairly minimal API documentation.
Claude wasn’t bothered. It produced an integration that installed cleanly. It didn’t work at first, but it turned out there was an error in the API spec, the JSON responses from the Tuneshine device were formatted differently than documented. Fine. I gave Claude the IP address of my device and told it to figure it out. Minutes later, it had identified all the issues, fixed the code, and saved the actual responses it had received as sample data in a reference document for future use.
Encouraged by how smoothly that went, I gave it another challenge. The Open Home Foundation is working on Sendspin, a new standard for multiroom synchronized audio that also covers visualization and art display. Without making a big deal of it, I dropped the Sendspin spec into Claude and asked it to extend the Tuneshine integration it was working on to support the standard as well. And it just figured it out. After the update, I could group my Tuneshine with any other Sendspin client in Music Assistant, and it would display the cover art of whatever my speakers were playing.
That’s how Claude Code vibe-coded ha-tuneshine for me. I have touched exactly zero lines of its code. I have no plans to contribute it to Home Assistant or even put it on HACS. I only made it because I wanted something for myself, something that didn’t exist yet, and Claude helped me build it.
What I find interesting is how using Claude Code feels a lot like the first time I got my hands on a 3D printer, back in 2015. Suddenly, you didn’t need expertise to create physical objects. You didn’t need to first learn woodworking or welding or any other material craft. You could produce an object you needed, seemingly out of thin air. That weird connector that didn’t exist yet, that handy jig for one particular use-case nobody else had. You could spend an hour in something like TinkerCAD and have it on your desk by the afternoon.
It’s a different domain entirely, I know, but the feeling is the same. Something I couldn’t rely on anyone else to solve for me was solved by asking a machine for help. And that’s strangely empowering, even if I’m not empowering myself by actually learning the underlying skill. I recognize the irony.
For something like Home Assistant especially, I think this points to something genuinely interesting. A lot of users out there aren’t developers, but they may own devices that nobody has written support for yet: because those devices are too niche, only available in certain regions, or because they want to use them in a non-standard way. Being able to solve that yourself with help from Claude, in a very n=1 kind of way, is a real step forward for your own smart home.