Why I Started Building NeuroTerm

I used MobaXterm for my boards. Opening a serial console, connecting over SSH, watching a boot log scroll by: all of it happened in that window. It was a tool my hands knew, and it had most of what I needed.

From early 2026, the rest of my development tools changed fast. Editors got LLMs that write code with you, and IDEs started reading a whole repository and explaining it. The terminal I used to look at my boards got none of that. Why does new technology reach embedded software tools so slowly? Waiting did not look like it would change anything.

The question turned into a real problem once I started using Claude Code and Codex.

An agent reads the repository, runs the build and fixes the failing test. On my own machine, it does a lot by itself. But the work that matters most in embedded development happens on the board sitting on my desk. Where the kernel stopped, what error the driver printed: that only shows up on the serial console. The agent could not see that screen.

So I carried things back and forth. When the agent asked for a log, I copied it from the console and pasted it in. When the agent suggested a command, I typed it again into the board’s window. The agent was writing the code, and I was the one moving the logs.

The developers around me were stuck in the same place. The ones who had started using Claude Code or Codex heavily moved to other terminals, like Warp or Herdr. But when they had to debug a board, they opened MobaXterm again. The agent ran in Windows Terminal or one of the new terminals, and the board lived in MobaXterm. Everyone was working with two terminals open side by side.

Either way, a person always stood between the agent and the board. I wanted the terminal to take that place. If the agent could read the board’s console itself and type into it when needed, it could develop and debug on my board too. I could not find a terminal that did this, so I decided to build one.

I borrowed the approach from Computer Use, which lets a model look at a screen and use the mouse and keyboard. For an embedded developer, that screen is mostly a terminal. So the same idea should work inside the terminal.

That became Terminal Use. The agent reads the output of serial, SSH and WSL tabs, waits for the line it is looking for, and types into the tab when I allow it. Before it types, it asks for permission right there in the tab. On a board, one wrong command can erase flash or reboot the whole thing.

Working with an agent in the same terminal needed more than that, so I filled in what was missing, one piece at a time. When NeuroTerm starts again, each tab can pick up its Claude Code or Codex conversation where it left off. When an agent finishes or waits for my input, a notification appears, the taskbar flashes and the tab is marked. Paste a screenshot or a file into an SSH tab, and NeuroTerm uploads it to the remote host and types the path, so Claude Code running there gets the image right away.

I wanted plugins to be open. Every board has its own protocols and its own log formats, and I cannot build a feature for every board. Instead, anyone can ask their agent to build a plugin for their own board: a log panel, a protocol decoder, a marker that finds the crash pattern they keep running into. The agent builds and checks it with NeuroTerm’s plugin tools, and I only have to allow it once. Plugins run in a sandbox.

So what I am building is a terminal where changes in technology show up right away. When agents learn to do more, what I can do at the board should grow with them, without the wait. Why does new technology reach embedded tools so slowly? This is the only answer I can give to the question I started with.

The starting point is my own work. I work across robotics, Linux BSP, real-time communication and edge AI integration. When I decide whether a feature goes in, I first look at whether it actually makes that work faster. Then I look at whether I can trust it in front of a real board. A feature that is convenient but cannot be trusted ends up unused at the bench.

In the end, I am building this terminal for myself. Most people are doing that these days. With an agent, building the tool you need when something gets in your way is no longer hard.

But if I was going to build it, I wanted to build it properly. I did not want it to end as a tool that only runs on my machine. It had to be a product another embedded developer could download, connect to their own board and find worth using. A product I would not be embarrassed to put out.

Moving fast and building it properly pull against each other. Hand implementation to an agent and the code arrives quickly. Leave it at that, though, and you pile up results that look plausible and feel like something you have seen before. Passing tests does not mean it has the shape I wanted, either. So alongside the terminal, I am building a system where my taste survives all the way through.

My part is to pass on intent and taste. I say what a feature is for, what should be seen first on the screen, and what it must never do. The agents do the implementation. Once a behavior is right, thousands of tests hold it in place. If adding the next feature quietly breaks something I settled earlier, the tests notice first. That is what lets me move fast and still trust what ships.

Because of that system, I could ship 1.11, 1.12 and 1.13 ten days apart this October. 1.13, released on October 28, added Work memory, which keeps a daily record per board of what I, my agents and the board did. But one problem remained: if you shut Windows down, or ended NeuroTerm from Task Manager, the open tabs were lost. What I wanted was clear. Turn the PC off without warning, turn it back on, and every tab should come back in its place, with its name, working folder and scrollback, without a dialog asking whether to restore. The agent implemented it, and it shipped the next day as 1.13.1. Now tests hold that behavior in place too.

You can get NeuroTerm at neuroterm.dev. It runs on Windows and Linux, and it is free for individuals. There was a detour on the way to what it is now, and I will write about that in a separate post.

What LLMs can do changes every few months. As long as I keep doing this work, I plan to keep updating NeuroTerm to follow those changes. I will be using it. And now that it is out there, I want it to hold up.

Comments