TLDR; I set out to make asynchronous programming on microcontrollers easier. Along the way, I accidentally built somewhere that humans and AI’s can work together comfortably.

This is the first in a short series of posts about learnings and insights I’ve got during the making of Thingstudio, leading up to a proper introduction.

For now, all you need to know is that Thingstudio is a low-code programming environment for microcontrollers, inspired by Nick O’Leary’s brilliant Node-RED. You drag nodes onto a canvas and wire them together, and the result, called a flow, is the program that runs on the board. Its main goal is to take the pain out of asynchronous programming on small devices. More on all of that in later posts.

The accidental discovery

Each time I added a feature to Thingstudio, I made a flow to test it. Out of curiosity, I started asking an LLM to write some of those test flows for me.

They were perfectly good. The first flows the LLM wrote were fine, but looked a bit of a mess because it had no idea of what a neat diagram looked like. A few pointers later, it was producing correct, neatly laid out flows that were easy to modify.

(By the way, they were also very good at the grunt work. Every board Thingstudio supports needs a definition: which pins exist, which are reserved for flash or USB, which are input only, which ones to avoid because the manufacturer hung an LED off them. Every processor needs one too. It’s tedious, datasheet-squinting work, and the LLM’s munched through it happily.)

But the interesting thing wasn’t that the AI could write flows. It was what kind of thing it was writing.

Fences

Thingstudio is a fairly small playground with fairly high fences.

There is a fixed set of nodes. Each one has named properties and typed inputs and outputs. You can’t wire a boolean into something that wants bytes, or use a pin the board doesn’t have. All of this is checked by a compiler, and there’s a command line version of it, so an AI can write a flow, run the check, and get back errors that say exactly which node is wrong and why. It fixes them and runs it again, until it gets the magic word: OK.

The constraints are only half of it, though. Each node wraps up quite a big chunk of functionality, a display, an MQTT connection, a debounced button, and the interfaces between nodes are well defined. You can’t easily write spaghetti, because there’s nowhere to put it. Good practice gets enforced without getting in the way.

Think of it as LEGO for programming. LEGO has (or used to have) a pretty restricted set of bricks, but people build huge, elaborate things with it, and you can always see how they were put together.

The real bonus

Here’s the part that actually surprised me.

AI generated code these days is often perfectly good. The trouble is that reviewing it is hard work. It tends to be long, and it’s written by something that doesn’t much care whether you understand it.

A flow is different. Open an AI written flow in the editor, and it’s just a picture. Here’s the timer, here’s the sensor, here’s the display, here’s where it goes off to MQTT. You can see what it does in a few seconds, and if it’s not what you wanted, you drag a wire or change a property. No archaeology required.

So, without meaning to, I’ve made a shared space. The AI is comfortable because the rules are tight and the feedback is immediate. The human is comfortable because the result is small, visible, and easy to change. Each can pick up where the other left off.

And notice that humans like it for exactly the same reasons the AI does: a small vocabulary, a visible structure, and something that tells you quickly when you’ve got it wrong. I didn’t design Thingstudio for AI’s at all. I designed it for people, and it turns out to suit both.

Beyond microcontrollers

I suspect this applies well beyond blinking LEDs.

When we think about humans and AI’s working together, the conversation is usually about the AI: how capable it is, how far to trust it, how much to check. Thingstudio suggests another angle, which is to think about the environment they share.

Give both parties a set of well defined building blocks, clear interfaces between them, a checker that gives precise feedback, and a result that can be read at a glance, and the collaboration gets a lot easier. The AI works more reliably, the human can see and change what it’s done, and neither has to take the other on trust. That’s a policy that could be applied to all sorts of systems and domains, from business workflows to data pipelines.

In the next few posts, I’ll get into some of the other things I’ve learnt on the way, including designing for supply chain attacks, AI agents and technical debt, and the curious usefulness of telling an AI what not to do.

Good fences make good neighbours. It seems that goes for AI’s too.

PS: Before Thingstudio goes public, I’m looking for testers to try getting started with it. All you need is an ESP32 or a Raspberry Pi Pico. Details at www.thingstudio.net.