I Have No Idea What the Ones and Zeros Are Doing, but I Made Them an Elm House

AI did not make me a programmer. It did let me bother some open-source Bitcoin code until a real bug got fixed. Then I put the whole thing in a piece of elm, because that part I understand.

I have always been pretty comfortable with physical things.

Wires have ends. Boards have plugs. Wood has grain. If you make a mistake, you usually get smoke, sawdust or a new piece for the scrap pile. The feedback is immediate and occasionally smells expensive.

Software is different. Software is invisible electricity arranged by people who apparently looked at ones and zeros and thought, "Yes, I would like several million more of those."

I have no fucking clue how they do it.

I can read enough to become dangerous. I can understand what a program is supposed to do, notice when it does something stupid and ask increasingly annoying questions. But if you sat me down with a blank C file and told me to build a Bitcoin signing device, I would probably create a calculator that only displays an error message.

AI changed the distance between that ignorance and actually doing something useful.

It did not magically turn me into a software engineer. What it gave me was a patient crew of agents that can trace code, explain what a function is doing, build tests, argue with each other and keep working long after a normal human would have stopped answering my calls.

That is how I ended up messing around with Kern.

A Bitcoin signer on a little blue board

Kern is an open-source research project built around the ESP32-P4. It is not pretending to be a finished consumer wallet. It is an experimental, air-gapped Bitcoin signing device where transactions move by QR code or SD card instead of sending private keys anywhere near the internet.

The board on my desk is a Waveshare ESP32-P4-WIFI6-Touch-LCD-4.3. That mouthful buys you a 4.3-inch, 480-by-800 touchscreen, a camera connection, a microSD slot and enough exposed circuitry on the back to remind me that I am operating above my pay grade.

The ESP32-P4 itself has no radio. This particular Waveshare board also carries a secondary ESP32-C6 radio chip, which Kern holds in reset as part of the air-gap design. That is exactly the sort of sentence I can now understand well enough to worry about, while still needing an agent to show me where the relevant code lives.

Rear view of the blue Waveshare ESP32-P4 touchscreen development board, showing its chips, connectors and printed labels. — The side of the project that looks like it escaped from a very organized laboratory.

From the front, though, it is surprisingly polished. Kern boots into a clean dark interface with orange accents and an on-screen keyboard. It asks for a PIN. You tap the glass. It looks like a product.

Then you turn it over and see the development board covered in chips, ribbon cables and labels.

Perfect. Exactly my kind of project.

We found a bug that had its priorities backward

Amy VPS and I started looking through the code as part of an audit. The agents found a nasty little ordering problem in the PIN logic.

Kern's default policy allows ten PIN attempts before wiping sensitive storage. The failure counter is deliberately updated before the expensive PIN check so somebody cannot keep cutting power to avoid having a failed attempt recorded. That part makes sense.

The problem was what happened at the boundary. After nine wrong attempts, you could enter the correct PIN on attempt ten and the device would wipe itself before it compared your entry with the stored PIN hash.

In normal-person language, the bouncer burned down the building and then checked your ID.

We opened the issue, built regression tests around the final-attempt behavior and submitted a focused fix. The new order preserves the power-cut-safe failure counter, compares the PIN, unlocks if the final attempt is correct and still wipes if it is wrong. The project maintainer merged it after all eleven checks passed, then added another safeguard for a corrupted attempt-limit value.

That is an actual contribution to an actual open-source Bitcoin project. I am still not sure I could explain PBKDF2 at a dinner party without getting asked to leave, but the code is better than it was before we showed up.

I like that.

The CNC part I actually understand

Once the software was alive on the screen, I fired up my CNC machine and gave the electronics a home.

I used elm because I like elm. Technically it is a hardwood, but it lives on the softer, friendlier side of that family compared with something like hard maple. It machines nicely, has warm color and enough grain to make a plain rectangle look like somebody cared. The interlocked grain also gives the end walls some character after milling.

A freshly CNC-milled single-device elm tray beside the bare Kern touchscreen device. — Before assembly: one touchscreen, one pocket, and a USB-C notch where I hoped it would be.

The Kern touchscreen running inside the finished elm tray with a USB-C cable attached. — The electronics got an elm house. Building inspectors were not consulted.

I carved a recessed tray for the display so the black glass sits inside a narrow wooden border. There is a small notch for the USB-C cable, radiused inside corners from the cutter and just enough material around the edge that it feels solid without looking like I built a cutting board around an iPad.

I might not put any finish on it.

I know. Somewhere a woodworker just dropped his oil rag. But the bare elm looks good, it feels good and this is a test device, not Queen Anne furniture. If it picks up a little color from being handled, fine. That is called character when you like the object and damage when you don't.

The funniest part is that I had some scrap elm left and accidentally made enough room for two trays side by side. It was not the grand plan. It was the sort of happy accident that happens when the CNC is already running and throwing away useful wood suddenly feels offensive.

A wide piece of elm CNC-milled with two side-by-side pockets for two touchscreen devices. — The accidental dual-device tray. Either a gift for another curious Bitcoiner or A/B testing that smells faintly like a tree.

Now I can give the second tray to another curious Bitcoiner, or set up two Kern devices next to each other and compare UI tweaks without flashing one board back and forth.

So what is the risk?

The electronics cost about forty bucks. The elm was scrap. I have already spent more money on router bits I immediately broke and steaks I overcooked.

If this experiment goes wrong, I lose a cheap development board, a hunk of wood and whatever dignity remained after admitting publicly that my programming department is mostly artificial intelligence supervised by a construction guy.

That seems manageable.

To be clear, I am not putting serious Bitcoin on it. Kern says plainly that it is an unaudited research platform for experimentation and testnet use, with no security guarantees and secure boot not enabled by default. I may be ignorant, but I am not interested in turning ignorance into an expensive teaching aid.

That distinction matters. AI makes it possible for me to participate, but it does not make every answer correct. The agents still need tests. The code still needs review. Hardware claims still need verification. Open-source maintainers still get the final say about what belongs in their project.

What AI has done is let me cross a line I could never cross before. I can start with, "Wouldn't it be cool if..." and end with firmware running on a real board, a bug fixed upstream and a custom elm enclosure sitting on my desk.

I do not need to understand every one and zero to contribute something useful. I need to understand the goal, recognize the risks, ask dumb questions without pretending they are smart ones and connect the right wires, tools, agents and people.

Apparently that is a kind of programming now.

Good. I can do that.

— FF2K