How I Keep Speed, Quality and Intent with AI Agents

NeuroTerm is a terminal for embedded developers who work with AI agents. You open a board’s serial console and SSH as tabs, and an agent like Claude Code or Codex reads those tabs directly and, when I allow it, types into them. I started building it so that a person no longer has to carry logs between the console and the agent. I wrote about that in the first post.

What agents can do changes every few months. A terminal that cannot keep up with that has no reason to exist. But I build NeuroTerm alone, and I decided that the days I work on it by hand are weekends. That is not a generous setup.

Under that constraint there are three things I do not want to lose: development speed, quality, and the product’s philosophy. Holding on to one of them is not hard. Go fast and quality slips. Hand more to the agents and it gets blurry what the product is for. To hold all three at once, I set up two things.

One is intent-driven development. I write down my intents, and the agents pick ideas and build features to match them. The other is a release train. It leaves every two weeks, it does not wait for work that is not ready, and when it arrives the next train leaves right away. The intents decide what goes on the train, and the train takes those intents around once every two weeks. The first train left today, November 1.

In October I shipped NeuroTerm 1.11, 1.12 and 1.13 ten days apart. The speed was there. But those ten days were not a cadence I had set. I built whatever was ready and shipped whenever it was. Living like that for a while, two things bothered me.

The first was that the speed could not last. I was the one hunting for the changes to follow. Nothing brought me what the agent tools had changed, what similar tools had shipped, or where users were getting stuck.

The bigger problem was intent. What a feature is for, and what it must never do, I told the agents in the moment, and the agents remembered it only inside that conversation. My judgment was scattered across the Claude memory of a single computer. The more implementation I hand to agents, the more dangerous that gets. The code keeps coming out fine, while the product drifts, a little at a time, away from what I wanted.

It weighed on me more because NeuroTerm, so far, is a product I filled with my own taste and intent. Getting each piece right took a lot of time, and I grew attached to it in the process. As the agents take on more of the work, I did not want what I had shaped so carefully to fade.

So I started writing my intents down as sentences. There are several now. Here are two.

One is that an agent’s hands must be trustworthy. Leaving the work of watching and touching a board to an agent should not feel uneasy. When something is about to be written to the board, the tab asks first, and anything automatic runs only inside a boundary the person has set. A feature that is convenient but cannot be trusted ends up unused at the bench.

The other is that someone who just downloaded NeuroTerm can connect their own board that same day. An embedded developer who has just installed it should be able to plug in their board, put an agent beside it, and find it worth using, all on the first day. I wrote this one because I did not want NeuroTerm to end up as a tool that only works on my machine.

Each intent says what it is for and also what must never happen. Sensibilities like “no emoji on the screen” or “before adding a button, remove the one it overlaps” live in the same place. Whatever the agents build, they build inside these sentences. As the written intents pile up and get refined, they become NeuroTerm’s philosophy as a product.

The train carries these intents through two weeks.

At dawn on the first day, an agent reads what changed over the past two weeks. It reads changes in agent tools and similar tools, embedded news, and the issues and mail users left, and it also looks at NeuroTerm itself, searching for places where the current features fall short of a written intent. Only what touches an intent comes to me, as a card. Each card shows how the screen will change once the feature is done, and who would use it at what moment.

Not every card comes from outside. The thoughts, worries, and new intents and taste that come up while I use the build for two weeks, I write as cards myself. The changes outside and my own two weeks ride the same path.

In the morning I decide, card by card, whether to adopt it, and I write one line of reason. Even the reasons for saying no are not thrown away. On one card I wrote that too much automation is not good, and that automation has to respect its boundary. That line went into the intent about an agent’s hands, as something that must never happen, and the next train’s agent brings cards from inside that boundary. Choosing becomes a way of writing intent.

Adopted cards are turned into features by the agents. They write down what to build, write the tests first from that, write the code, and go through review. They do not ask me anything along the way, because adopting the card counts as approving what to build and why. They stop and hand it to me only when a new decision comes up that would be hard to undo. When the work is done I see a short result, and it goes in only when I say yes.

The tab Timeline that landed today was built that way. When you open several tabs for one job, it places the lines from those tabs on a single time axis, in the order they were received. The agent reads that time axis, and I see the same screen. All I did was add a few lines of note when I adopted the card: easy for the user to set up, visible to the user, and usable by the agent.

For the next week I use the dev build myself. On the night of day 8 I cut a release candidate, the RC, and after that only fixes go in; new features take the next train. In the second week I, and any user who wants to, run the RC, and on the night of day 14, a Saturday, it ships. I do not keep track of the dates. Which day of the train it is, and whether a feature can still go in, is decided by code. Even in a busy week, the train leaves on time and arrives on time.

Speed comes out of this structure. The agents do the hunting for changes and the implementing, and I choose and answer. That is how a feature can land in a single weekend day. But the train is the rhythm for features, not for bugs. When a user reports a bug, an agent reproduces it, writes a failing test first, fixes it and puts it on that train. A bug that crashes the app, loses tabs or logs, writes something to a board without permission, or touches security does not wait for the train; it ships as a patch as soon as it is fixed. When an agent tool changes and breaks the integration, only the plugin that holds the fix gets updated first.

Quality is guarded by the dates. When you push for speed, quality is the first thing to slip. Hand work to agents and code comes out fast, but ship it as it is and what piles up is work that only looks right. The train puts a date between the two. Until that date things go in; after it, only fixes.

So whatever goes out is something I have used myself for at least a week. Before that it passes thousands of tests, a number that keeps growing, and goes through several rounds of code review. Once a behavior is right, those tests guard it, so adding the next feature quickly does not quietly break an old one. Every night the full test suite runs again on main, and the e2e tests that launch the real release build run on both Windows and Linux.

Nothing ships on the strength of agents building it and agents checking it alone. What a machine cannot judge, like how a screen looks or what happens when you actually power the PC off and on, I look at myself and close. If even one of those checks is open, there is no RC. Something that is only fine on my own machine is not quality.

Quality also includes what users go through. The train running should not mean the users get shaken every two weeks. So features are built as plugins whenever possible. People who need one download it when they need it, and for everyone else the screen stays as it was. Every train carries one headline, but it does not have to be a new button. A feature made clearly better, something taken out, or a new plugin can be the headline too. A new screen goes into the base app only when a plugin cannot do the job.

Philosophy gets checked when the train arrives. Each time, I answer one question per intent. For the agent’s hands, I ask: in this train, was there any moment when leaving the board to an agent made me uneasy? So as not to rely on memory alone, I write down such moments in a line as they happen, and I answer with those lines and the user issues from that train laid beside them. If an intent was not kept, the reason becomes the first thing the next train fixes.

If I put in a lot, fast, and the answer to that question is no, the train failed.

I have written down a goal too. Whether it is an important change on the agent side, something a user ran into, or an intent NeuroTerm has not yet kept, it should reach users within one train. The release notes, the website copy and the demo video are drafted from the features on that train. That is how the time I spend on release work stays under two hours per train. All I need to hold on to is the intent.

This post only sketches the train as I picture it. The first one has just left. After it has run a few times, I plan to write in more detail in Methods: what I handed to Claude and the other agents and what I kept in my own hands, and where the two-week train actually held up and where it did not.

In this structure, I do not do much. I answer each card with a line, write my own cards when something comes to mind, use the build, say yes, and when the train arrives, answer one question per intent. The agents take care of the rest.

But those few lines keep riding the train. Every two weeks the changes outside and my own thoughts come in together, I choose against the intents, and the reasons I give become intent again. However many times the train goes around, the loop does not stop. Each time, NeuroTerm changes quickly, and what it is for gets a little clearer.

The first train arrives on the night of Saturday, November 14. The next morning, before dawn, the second train leaves.

Comments