The input layer

In the first post I wrote that the factory is the product and that my job is to make myself unnecessary in it. Two posts later I am still needed, and I now have a better idea of where exactly.

Where the time goes

Something about how I work has inverted, and it took me a while to name it. For as long as I have done this job, the best work I could do came out of long, deeply focused sessions: the whole codebase in my head, no interruptions, no multitasking. There was nothing to gain from switching more often. You wanted the opposite.

With agents it is the reverse. The codebase does not need to be in my head anymore, because it is in the agent’s context, and the agent is far better than I am at holding a few hundred files together and finding the links between them. Focus stopped being the scarce resource. What I have instead is waiting: a session working through something complex is not instant, and a person sitting in front of one is a person doing nothing.

At the beginning I filled that time by reviewing. Every change, read line by line, because a mistake could be an expensive one. Somewhere around December last year, that stopped making sense. The models got good enough that I stopped reading every non-critical diff and started caring about outcomes instead: the interface, the performance, the behaviour a user actually sees. If something needs a second look, another agent can review it. Reading everything was clearly not the best use of my time.

So the time went into parallelism. More projects at once, each with a few agents: usually two on features, and one or two on process, such as a session that only does commits and releases through dedicated skills. I could go wider inside a single project with worktrees, and sometimes do, but spreading across projects has been a better use of both my time and my tokens. Many worktrees on one codebase move faster and multiply the ways it can get messy, while a dozen projects each moving in one direction do not step on each other.

And that is where the bottleneck shows up again. Each of those sessions is waiting on a sentence from me, and the sentence goes through a window switch and a keyboard. Access is mostly solved, that was the last two posts. With a dozen projects open, switching and typing is now the slow part of the whole factory. Not the model, not the tooling. Me, at the input layer.

Voice

First, the input itself. I have always liked typing, in a quiet room or with music on, and I never took voice seriously. Part of it is that I work in English all day but do not speak it all day, and dictating in a second language you rarely say out loud is not an obvious move. Then a minor neck injury made long typing sessions painful, and that settled it.

It turns out the open models are already there. Parakeet, running on the Mac, is good enough for daily work, and the audio never leaves the machine, which after the last post is not negotiable for me.

I already had a place to put it. Cadence is the app I built to transcribe my meetings on-device, so that every conversation leaves a record my agents can work from. Dictation into any app was the natural next step, and I built it for agentic use: one shortcut dictates, a second one dictates and then sends, so a sentence to a session is press, speak, done. Say “slash commit” and it types the command.

The mouse

Once sending a message no longer needed the keyboard, I wanted to see how far I could go without touching it at all. The answer was on the side of my mouse, in its two thumb buttons.

Pressed together, they start dictation with auto-send. Hold one and click the other, and I walk through my VS Code windows one session per click, then let go to land on one. That is the whole loop: switch, listen, speak, release. The goal is to get through a day of driving sessions without touching the keyboard, and that loop already covers most of it.

It sounds like a gimmick until you count the switches. A dozen projects, a few agents each, every one of them needing a sentence every few minutes. Two buttons and a microphone take more friction out of that than any prompt I have written.

Limits

Once the input is faster, the next thing that runs out is the plan, and not wasting it is a discipline I did not have a year ago. Weekly limits that reset unused are lost inference, and there is always something worth spending them on, a market check, a skill to sharpen, a review pass on last week’s work. So a new part of the job is triage: what has to ship, what inference it needs, and what to do with whatever is left. That deserves its own post.

The one thing it needed was seeing every account at once. I run several, and there are short windows where one of them has to be filled before it resets. That is what Armada started as: a menu bar app that shows the five-hour and seven-day windows of every account side by side, with the sessions behind each number.

What comes next

None of this changes the shape of the problem, it only makes me a faster bottleneck. The shape is that a person is polling a dozen windows to find out which one needs them, and that is not a job for a person.

So the thing I am building in Armada now is a supervisor. Armada already watches every session on the Mac, across accounts and across Claude Code, Codex and Grok Build, so it exposes what it knows as an MCP server, and a Claude session attached to it becomes the chat. Which sessions need me, what one of them is doing, what it last said, how much of each plan is left. It can start a session in a project, put a message in front of one, close one. Ask out loud and it answers out loud.

It is a prototype, nowhere near fluent, and Armada itself is a week old. But the shape is right: instead of me switching to a window to find out what it wants, the question comes to me, and I answer it. That is the interface I want to be working in a few months from now, and it is where most of my time goes next.

This is the setup as of this week. If you drive a fleet of sessions with something else, I would like to hear how.