Guv: A Code Governor for the Age of Endless AI Streams
Endless walls of streaming AI text were stealing my attention, so I built guv. It manages a kanban board of ideas, bugs, and approved specs, turning them into a work queue that commits to git worktrees, runs tests, and pings me for approval — no meandering chats.
I’ve built three homegrown AI tools for developing software, and the third, guv, is finally starting to pull its weight. Guv is my code governor, and it exists to reclaim my attention.
The suite looks like this: yap, mum, and guv, all three letter words, perfect for vibecoded software. Yap is the wall of streaming text. Mum is the blank page — the quiet you asked for and then didn’t know what to do with. Guv is the thing that stops me from staring at either of them.
Yap: my daily driver, and my problem
Yap was my first foray into LLM coding tools. It is, by now, effectively a Claude Code of my own making: a scrolling wall of streaming output with bash tools, file read and write tools, HTML prototypes, a background process tool, scheduler, a run_script tool, artifact tools, and more. It is full-featured, I’ve spent a lot of my time on it, and I love that it generally works.
It runs in three modes. There’s a full GUI mode that runs in webkit, a repl mode, and there’s a prompt mode (yap -p) that answers a single prompt at a time — optionally reusing a session so it keeps context between calls. That prompt mode matters later; it’s the entire engine under guv.
Yap is where I live. It’s my daily driver, and it’s where I spend the majority of my time on my computer these days.
But the wall of text is exhausting. It demands my attention even though there is almost nothing I can do while it works and streams. That idle attention-stealing — the constant pull of a screen that might need me, but probably doesn’t — wears me down. And something else keeps happening: while yap works on one feature, five more pop into my head. I have to sit on all of them until yap is done, because my LLM provider, Ollama, is limited to three concurrent LLM streams.
So I built two more tools around the same time to fight back: mum and guv.
Mum: the opposite of yap
Mum is a web interface that holds terminals — a container for ghostty sessions. It uses ghostty-web for the tty, and each AI terminal pane executes all bash commands through a real Ghostty terminal. Yap puts a small terminal inside each chat pane; mum flips that, putting the terminal first, with small chatbots tucked on the side. Those side agents can read my diff, do reviews, or — when I’ve written only pseudocode in context — turn my plain English into real, working code. I imagined it would be novel and grand, but it ended up just being neat.
Mum was a crazy idea that kept me up for days — I worked hard to get it to a prototype, and the prototype left me wanting. What I wanted was quiet: an agent working without a wall of streaming text. Mum proved that’s possible. But when the stream went quiet, I found myself staring at a blank terminal, or a file in nvim waiting for me to write code again — and the quiet was deafening. I looked for quiet, found it, and found it unsettling.
Underneath, though, mum had yap’s problem: both are built for single-process work, while AI can do parallel work. Sure, you can run multiple tabs, but the focus is one task at a time — zoomed in. Guv is zoomed out.
I still think mum has potential. It knows my terminal commands, and one day when I want to write code again, it’ll be there as my pair-programming sidekick. But for now, it paved the way for guv.
Guv: the code governor
Guv is the answer to a bundle of problems at once. You add projects (git repos), and you add tasks for each project. It looks a lot like a Trello kanban board, and that’s the point: it’s the durable home for everything that pops into my head while the machine is busy.
The core loop is short and fast:
- Jot down an idea.
- Each idea gets its own small chatbot that interviews you and turns the idea into a full spec.
- Review the generated spec, chat with the agent to make changes.
- Approve, and the task gets queued.
That interview loop fixes a habit of mine. When I use a coding agent like Claude or yap, I tend to chat and chat until I’m forced to auto-compact. Chat just feels like that to me — every bit of history could be relevant, and there is never a natural point where I’d choose to compact, especially since compaction is slower than just continuing to chat. In guv, context never blows out of proportion. The conversation is hyper-focused on the one task in front of it.
Tasks move through a state machine:
- Drafting — the idea is being turned into a spec.
- Ready for work — the spec is approved and waiting.
- Working — an agent is implementing it.
- Validating — tests are written and run.
- Needs a human or Ready to merge — over to you.
Here’s what that looks like in practice. Task #33 was small: “If a task is up and I click on a nav link, close the task drawer.” I jotted it as a one-line capture. A chatbot interviewed me, asked the obvious follow-up I hadn’t thought about — what about browser back? — and wrote the spec. I approved it, and it went into the queue.
The part I still find remarkable: I didn’t design anything. I never sketched what a minimized task should look like. The worker used the design system already in the repo, guessed at what would look good, and got it right on the first try — no fuss, no back-and-forth. Is it perfect? No. But it’s damn close, and I never had to think about it.
Then I walked away. The worker spawned a git worktree (factory/task-33) off the current main, implemented the change, and wrote an e2e test — including a phone-width assertion that the new restore bar sits below the capture bar. Its report arrived with the exact commands it ran and their results.
When it was done, validation ran the project’s command — the full test suite, unit and e2e — and it passed. Then the task moved to “ready to merge,” and guv pushed me a notification. All that was left for me was the decision: read the diff, merge the branch, done.
The next morning I merged it and went back to what I was doing.
That’s the whole thing: a one-line idea in, a reviewed and tested diff out, with exactly one interruption — and the interruption was a real one.
Why guv exists
The payoff is peace of mind, and it comes from a few places:
- Durable storage for ideas. New bug reports and features used to be lost in the gap between “I noticed it” and “yap is free.” Now they land on the board instantly, and I’m not blocked by an agent that’s currently working.
- Fewer tokens per spec. A short, focused interview produces a spec far more cheaply than a long meandering chat.
- Focus. No meandering conversations, no walls of streaming tool commands, no blinky loading animations.
- Nothing half-baked reaches me. The agent turns a short interview into a robust spec I can still tweak, and the code is tested before I ever see it. Every project gets its own validation command — for me, that’s running the full test suite including e2e browser tests.
And here’s the neat part: guv uses yap under the hood. The chat in guv is yap’s prompt mode plus session restoration — the same engine I use interactively, repurposed for short, disposable specs. But guv itself is coding-agent agnostic. You can point it at pi, Claude Code, opencode, etc.
With three tools, the trick is knowing which one to reach for. Guv takes a bundle of feature implementations and bug fixes: jot, spec, queue, walk away. Yap is for detailed, tricky sessions with a lot of back-and-forth. And mum is for the day I want to open an editor again.
Guv still has its rough edges, but I like where this is heading. The wall of streaming text is gone. My ideas have somewhere to live. And I can walk away, do something else, and trust that the work will be waiting — tested, specced, and ready for me — when I get back.