Since 2024, the coding capabilities of Large Language Models like GPT and Claude have, in my opinion, been far more interesting than the “word producing” side of the technology. Chatbots are predictable, sycophantic, hallucinating slop-machines, but the LLMs sitting just underneath them are capable of “speaking code” fluently enough to turn them into digital Swiss Army Knives.
And it’s this capability – the ability to speak machine – that I think will carry LLMs into the future. I’ve written extensively in the past about computer-using AI Agents, and I think that there’s a deceptively simple premise that will come to define how we interact with AI in our digital lives:
Everything that happens on a computer happens in code and through software. GenAI is proficient at writing and manipulating code. Therefore, it follows that many operations a computer can carry out can be carried out by GenAI.
From: Practical AI Strategies 2
But step away from the screens for a second, and this logic suddenly explodes into the real, physical world. Because it’s not just computers that are controlled by code in our modern lives, it’s everything.
Dabbling with hardware
Because an AI model like Claude is proficient at reading and writing code, it’s able to produce any number of small pieces of software. Put that AI into an environment like a computer, and it can use its coding talents to write scripts and even entire applications that interact with other parts of the computer.
But physical devices also run code. From tiny single board computers (SBCs) like ESP32s and Raspberry Pis, through to serious, industry-grade hardware (some of which is basically run on those SBCs anyway), millions of devices in our day-to-day work and personal lives run on code.
I’ve always been a dabbler myself. I taught STEM with Raspberry Pis and Arduinos, and used Python to control simple robotics like the Dobot Magician. At home, I’ve got a drawer full of Pi Zeros and ESP32 boards, all in various states of disarray from start-stop experiments over the years. With the help of Claude Code, I’ve resurrected many of those devices and played around with new features.
Recently, I bought an M5 Stack Cardputer ADV, and used Claude Code to make, variously, a musical instrument, a notetaker, and a fully functional voice assistant.
And a few weeks ago, I decided to tackle a more serious, real-world problem out here on the farm.
Claude in the real world
We live on an off-grid property on a farm in regional Victoria. There are several… interesting… challenges associated with off-grid life, but of course one of the main ones is a consistent power supply so that you don’t spend half of winter in the dark. We have a large solar array, and a backup diesel generator, and the solar is connected to the house via a data cable which allows us to look at the usage via the app. It’s not incredibly exciting, but how else are you going to pass time on the farm?
One issue we’ve had since installation is that the diesel fuel gauge is horribly inaccurate. The generator data is also not connected to the solar, so doesn’t directly show up on the dashboard. Both problems could definitely be fixed by a diesel mechanic, but why bother doing something properly if you can over-engineer a solution for yourself by spending several hours attacking the problem sideways using Claude Code?
I posted about it on LinkedIn, explaining that essentially I set up a system which uses a combination of the auto start/stop data from the battery and the generator’s fuel consumption rate to reverse engineer a more accurate, digital fuel gauge.
Because the solar data cable is connected to my home internet router, and because Claude Code is running on a device connected to the same network, it was relatively straightforward to find the incoming data and build a new, more comprehensive dashboard around it. Claude Code added a few extra features while building the dashboard, including sunlight hours, weather, and a price-comparison based on typical Victorian household energy consumption.
This dashboard is exclusively read-only. I don’t want to hand the reins over to the entire setup just yet, but theoretically the data can go two ways: I have read/write access from the house. In theory, then, I could also use Claude Code to manually start the generator, override the default battery settings, or anything else that it’s possible to do via the panel on the battery cabinet itself.
Instead of throwing caution to the wind and handing my solar power entirely to an LLM, I decided to build a simulator. I collected data for a few weeks and then used that to build a model of the whole system, this time adding the write access to see how it would work.
It was successful, and I now have a playground where I can test out the read/write features of the solar system without risking any damage to the actual setup. Using the simulator I can see that it would be entirely possible, for example, to DM the Discord bot I have set up with Claude access and get it to turn on my generator from anywhere in the world.
I wouldn’t actually do that… probably… but the thought experiment was interesting.
The Model Hardware Standard
As I was working on these things, Anthropic released a post that immediately caught my eye. The company behind Claude is also largely responsible for the Model Context Protocol, which is an open standard that allows AI models to talk to other applications. MCP has been incredibly successful, and widely adopted across the software industry. Chances are, if you use an app that already has an API, it now has an MCP server that can be accessed by an LLM.
For their next trick, Anthropic has been trialling the Model Hardware Standard – a sort of MCP for physical devices. In their preview post, they describe early research using medical technologies like lab microscopes and robotic arms.
Something like the MHS could actually solve a lot of the problems I had with the solar/diesel setup. A common standard for hardware would mean that it doesn’t matter if the battery doesn’t speak the same language as the generator, or if neither of them translate neatly into a user interface. MHS would be capable of connecting AI across those various pieces of hardware.
My solar array is just a small feature of life out here on the farm. It’s a working farm, and like many family-owned farms across Australia it isn’t particularly hi-tech. But it could be… Enabling farmers to “speak to” their hardware in natural language could, much like the digital Swiss Army Knife of computer-using agents, change agritech enormously.
I’m just a dabbler, but even so, I’m already able to build capable and useful artefacts that bridge the gap between software and hardware. The next few years are going to prove very interesting, as more people start to realise that the future of AI has very little to do with chatbots.
Want to learn more about GenAI professional development and advisory services, or just have questions or comments? Get in touch:
Leave a Reply