Kickoff
By early January 2026 my agentic setup had given me a brand-new problem: I was too productive to know what I was doing.
Ten-plus terminals open at once, most of them running agents on different tasks in different repos. Alt-tabbing between identical black rectangles, trying to remember which one was migrating a database and which one was allowed to touch main. My velocity had outrun my own ability to track it — a problem I had never once had in twenty years of being slower, and one no amount of shouting at a terminal was going to fix, though believe me, in month one, I tried.
The Run
A Kanban board for terminals
The idea arrived one evening while I was eating dinner: terminals shouldn’t be tabs, they should be cards on a Kanban board. Each terminal carrying its own context — name, purpose, working directory, what to run on open — and moving across columns like any other work: to do, doing, done. I put the thought to Claude and went back to my plate. By the time I’d finished eating, there was a basic working version on my screen. The plate, for the record, was pasta. I finished it. First commit: January 8th. “Initial 0.0.1 version.”
e2dd35b0feat(mcp): Add MCP Server for LLM Integration (#17)⋮ four days of commits ⋮34290564 feat: initial 0.0.1 version
I wish I could tell you I then paused for a considered architecture review. What actually happened is the thing sprinted — 169 commits that January. And the pivotal moment came just five days in, when I gave the app an MCP server. Suddenly the agents could see the board too. Read it, update it, queue actions on cards that would run when a terminal opened. The board stopped being my tidy view of the work and became shared memory between me and the machines — a persistent, structured answer to “what’s in flight?” that survived every session. That’s the day it stopped being a terminal manager and started being an agentic IDE, though it took me months to say those words out loud, mostly because they sounded ridiculous.
The scar
Now the scar, because this post has one. Dinner-speed building meant dinner-speed decisions. Claude and I reached for Swift and SwiftUI — native, lovely, fast to demo — and that choice quietly welded TermQ to macOS. Eighteen months and 572 commits later, that’s not a refactor; that’s a rewrite I’ll probably never do. Nobody made the decision. The velocity made it. When building is nearly free, the irreversible choices — platform, language, data model — happen before you notice you’re making them, dressed up as defaults.
And I can’t even claim it surprised me, because it had already happened a month earlier. That forty-eight-thousand-line December weekend from Post 4, the blog platform, ended the same way: a structural do-over on Christmas Eve, rewriting a three-week-old codebase, because the naive first cut had made its architectural choices without me. Twice in one month. That’s not an accident. That’s a property of the tool, and I was slow to file it as one.
The Debrief
This stage is about orchestration and its speed limits, filed under the general heading of things I learned by ignoring them first:
On The Training Ground
The Markdown Kanban. You don’t need to build an IDE to test the idea that changed mine — one markdown file and two parallel agents will demonstrate it in under an hour.
Info
You’ll need: an agentic CLI you can run twice at once (two terminals), and a repo with a couple of small, independent tasks pending — doc fixes, small refactors, anything that won’t collide.
At the repo root, WORK.md:
## To do
- [ ] TASK-2: add usage examples to README
- [ ] TASK-3: rename config.js exports to camelCase
## Doing
## DoneAnd the protocol, in your CLAUDE.md or session preamble:
Before starting work: move your task line to "Doing" and add your
session name in brackets. Before touching any shared file: re-read
WORK.md. When finished: move your line to "Done" with one summary
sentence.Two terminals, same repo, one task each: You are session-A. Take TASK-2 per the board protocol. — and session-B takes TASK-3. Watch the first thing each one does: the board edit is the claim.
While both are working, add to To do:
- [ ] TASK-4: add a LICENSE file (MIT)Then tell whichever session finishes first: Check the board for anything unclaimed. Watch it find the card, claim it, and go — work you never assigned to anyone in particular, routed by shared state.
While they run, don’t scroll terminals — just watch WORK.md (watch cat WORK.md, or your editor). Notice the moment you stop wondering what’s happening: the answer is a file, not a memory of which terminal said what. That’s the whole TermQ insight, in one artifact: work as movable, inspectable units instead of ephemeral scrollback.
If this makes you want to build the real app — the board, the columns, the glorious UI — do one thing first: decide out loud what platforms it must run on. Write the answer down. Then open the prompt. One paragraph up, you have already read what happens to people who skip this step.
Tip
What you just proved: parallel agents don’t need supervision so much as shared visible state — and the agents themselves can read and maintain it. A markdown file scales surprisingly far; when your team outgrows it, you’ll know exactly what to look for in an agentic workbench: where does context live, can agents see work state, what survives a session.
The pasta, for anyone still wondering, was a fairly ordinary carbonara. I have thought about it more, in the eighteen months since, than most people think about the meal that accidentally launches their side project. Which, statistically, should be more people than it is.