How I Learned to Stop Worrying and Love the LLM

2026-09-28 · Lew Palm

In the world of free software, there are huge controversies around the use of LLMs, especially generative AI, for producing program code. Big emotions, holy wars. I don't want to take part in that, because everything has already been said. For me, the point of a debate is that everyone walks away having learned something, not in a foul mood (I know, crazy idea). And the odds of a foul mood are high on this topic right now. Still, I'm telling the story of AI's involvement in Leviculum here, so that anyone interested can make up their own mind. By the way, fun fact: back in 2010 I released LEvoSim, neural networks written in C++ and optimized by evolution. Sadly, I stuck with neither university nor the topic, otherwise the current hype might have made me rich and famous (or not ...)!

How I Learned to Stop Worrying and Love the LLM

It came to pass in the cold winter of the year 2026 (the beginning of the year, not the end) that three things were bothering me: The lead developer of Reticulum seemed to have thrown in the towel, the Python code wasn't the right technological foundation for my application projects, and there was no community around the project that wrote code together and set its direction together.

I decided to build a compatible stack the way I wanted it, preferably in C. As a foundation for embedded projects, Android development, and classic server applications, all at once. People advised me: Use Rust instead, it's cool, it's modern, it'll get more acceptance. I let myself be convinced, partly because Rust makes it fairly simple to offer a lightweight C API, so almost any other programming language can build on top of it. For me, languages are tools, not religions, and besides, I like trying new things.

I wrote the core functions of the network stack by hand, completely LLM-free, and learned Rust along the way. The manual and the Python reference implementation served as my map, and I still test against the latter to this day. It was exciting. And, that's part of Reticulum's charm, the basics are relatively simple on their own. The encryption, the routing, the packet structure, it all fits on the back of a beer mat. Almost. Good protocol design. Hats off, Mark.

But in real-world use, when I wanted to write a complete daemon, my day job reminded me that there isn't enough time in my life for my grand networking plans. The rescue: Surely I can just have AI generate the code! Or so I thought.

You know how it is: Sometimes it's mind-blowing how good the code is that the LLM spits out. Sometimes it builds in hair-raising bugs that are a pain to find. More of a pain than writing the code yourself. And let's be honest: Nobody enjoys reviewing code, least of all generated code. It's detention homework. But I stuck with it, because the alternative would have been not reaching my goals for lack of time. And I don't like that one bit. I soon found out: Code generation with an LLM works quite well when the result can be rigorously checked, when there's feedback. But not with unit tests alone. They cheerfully stay green while the network is completely broken. So I spent most of the summer building a testing framework called Periculum.

Under my desk sits a USB rig with, by now, 8 embedded devices that can talk LoRa and Bluetooth. Periculum uses it to run hordes of tests, for which the devices are flashed either as an LNode (with the Leviculum firmware, which turns the things into a router and message propagation node) or as an RNode (Reticulum's firmware, which turns the devices into a radio modem). On top of that, there are various Docker containers in a virtual network, home to lnsd instances (Leviculum's daemon) and rnsd instances (Reticulum's daemon). Everything gets mixed together, and all sorts of network topologies are built and tested. A full run of all tests takes a few hours. Only with this framework do I get stable, working code, whether handwritten or LLM-generated. Complex topologies keep surfacing unexpected bugs, but over the last few months they've become rarer and less and less relevant for real-world operation.

So my strategy was: don't code myself, don't review, put all the energy into testing. Why? I don't want to have to follow the result line by line. I hate reviewing machine-generated code. The code should damn well meet my standards, meaning low on bugs, maintainable, readable, functional, without me having to touch it. I don't want to chew through the damn code line by line! I want to go hiking while the code gets written.

And that goal is extremely ambitious. Experience shows: If you unleash AI on complex projects, it makes the most annoying mistakes. So I started a daring experiment with a very uncertain outcome: Can I put the AI on a leash, fence it in, catch its mistakes with automated tests? And to such a degree that I have to intervene as little as possible and the overall quality of the code gets better over time, not worse?

I wanted to take myself out of the loop more and more. At first I had to review and manually test everything the AI built. Better tests made that less and less necessary. There were setbacks. I kept extending and rebuilding the testing framework and adding more and more automated checks. The process took half a year, but it moved in the right direction: In field tests with the embedded devices, more and more things ran smoothly, and bit by bit I could withdraw from steering the AI.

And now? I think I've found it, the holy grail. Since around mid-September, after months of groundwork, I can let the AI work for days on end, and no garbage comes out. No more OMG-what-is-this-absurd-nonsense moments. The whole web of checks and tests holds. For now, it looks like the experiment has succeeded. The LLM itself has probably gotten better, too. Finally I'm free, the effort paid off, I no longer have to babysit a brilliant but insane and drunk artificial programmer with severe dementia; programs do that for me now. I can turn to what I actually wanted: designing beautiful new applications that are genuinely useful to users. That are easy to use. That work out of the box. That offer truly useful features that didn't exist before. And having fun with Leviculum networks that I build while hiking in the woods, by hanging up small hidden devices.

By now, the Leviculum firmware runs on a SolarNode and various handheld devices that cheerfully share their positions and pass messages along, storing them in between. So I send off my position and messages from my phone, and they get stored on inconspicuous alders and firs and passed along whenever the chance arises, and all of it wanders through the forest. And sooner or later it reaches other wanderers I'm in touch with. That's the whole point in the end, isn't it: having a tool that helps you find your friends' campfire instead of getting lost in the undergrowth.

In that spirit: Stop worrying and go walk in the woods, I tell myself. And I wish the same to all of you who spend your time with mesh networks. Warm greetings to you all.