what I work on

hactl is a command-line tool that makes the world’s largest home automation framework, Home Assistant, directly accessible to AIs. The problem: there are AI interfaces for Home Assistant, but they burn a lot of tokens. That is because the interfaces are only partly available and do not work consistently. Sometimes there is no interface at all, and then the AI agents have to log in through a terminal and edit the files or the database directly. That is dangerous in principle. Other solutions try it with MCP, the Model Context Protocol. That is a big JSON battle that burns a lot of tokens.

hactl solves the problem with a command-line tool: clear, consistent commands for every part of Home Assistant, with which everything can be modified. Before every change a backup is made automatically, and Home Assistant itself checks consistency. That way you can work with Home Assistant quickly and safely.

It started as classic vibe coding, but very test-driven. A good test concept was developed: a real Home Assistant was set up in a Docker container and tested there. That seemed to come very, very close to the real Home Assistant.

But implementation and tester sat in one session. So a great many tests only proved that what the code set out to do actually comes out. Whether it really works in practice was, unfortunately, never tested. On top of that, separate agents were started for the different parts of Home Assistant. As a result, the commands were anything but consistent. The biggest problem was that a real Home Assistant instance behaves very differently from a freshly created Docker container with generated sample files. That led to many iterations and improvements in the test concept. You can read all of it on GitHub.

In the end there was a specification after all. The approach was specified from the top, then implemented, and tested last. That was incredibly expensive, because it was done after the fact. But it led to a good result very quickly, where before every round of testing and fixing had ended in inconsistencies and bugs again and again.

Tests belong in their own session, independent of the code (Rule t.1Rule t.1Never let the same agent write the test and the implementation.). A test system is only as good as its closeness to the real system. A spec from the start saves the expensive rework.

The project started because I was looking for a digital picture frame that changes when the source album changes. No extra cloud, no monthly fees. What was out there was either expensive or bad. So I had wanted this app for a long time.

This app was built spec-driven from the start. That worked really well, even though in-app purchases added an unbelievable amount of complexity. A simple onboarding with the camera and the app’s security features were hard to build. But in the end, the specification produced a test concept that tests almost completely on simulators and real hardware. My own manual tests took four hours at most in total, and the rest was automated. That was really very elegant.

Specifying from the start is ultra efficient. Regressions or useless code hardly ever happened. And: the tech is fast, customers and marketing are the value.

ESPCars is a GitHub repository for using ESPHome, a fantastic base for microcontroller projects, to build automotive controllers that process and log data in real time.

Here an extra layer comes in: the microcontroller. Agents usually like to program databases or websites, where they see the result right away. Here one more stage is built in, a hurdle: after the unit test, testing has to happen on the processor, which means uploading, flashing, trying it out, and downloading the logs again. And all of that as efficiently as possible. If one agent has to understand how to flash a processor, start and evaluate the logging, and master the program code at the same time, it all drowns in context soup in the end.

So the question here is: how do you do agentic programming on microcontrollers efficiently? The project documents that too. The main trick is to use several agents at the same time: a lead that splits up the work, a spec owner, an engineer, coders and testers, analysts for research, and an agent for the test bench.

This produced very capable drivers very quickly. On a single-core RISC-V at 160 MHz, for example, they deliver a web frontend, a CAN gateway with two CAN buses and data manipulation, UDS diagnostics, a data logger on SD card, and LIN, all at the same time: around 3,500 frames per second per bus at 62 to 75 percent CPU load. That is fairly efficient for a control unit like this.

This book itself consists of two repositories, which are not public, though. One is the book itself, the data. Firm resolution: always keep code and data separate. The other holds the delivery website, which provides, delivers, and updates the data, all of it GDPR-compliant. Here too it helped enormously to write a specification first, adjust and refine it together, and only then roll it out. GDPR-compliant data processing raises the bar considerably for a service that delivers mails and websites.

The idea is to do software development the way frontier models allow it today, but locally. For that, an M3 Ultra with 96 GB RAM currently runs Qwen 3.8 with 27 billion parameters in Q8 quantization, with Pi and OpenCode. For single software updates this works very well. For complex embedded projects it was an exciting experiment, written up on LinkedIn (in German). As of September 2026: not the way to go. The local language model, on the other hand, is excellent for agentic tasks, GDPR-compliant.

The next step in agentic development moves away from software-only toward hardware. The PCB Hero project lets you develop circuit boards spec-driven, end to end. The goal is to get from specification through simulation, schematic, routing, and manufacturing to testing the board in four weeks, even for more complex projects. That would be a bit faster than usual.