@lennysan@gokulr I have a product manager agent trained on some of the best interviews you have done on your podcast. It's more like a product council from insights from @karrisaarinen and others. Not sure any "job function" is technically safe.
Notice how Slot 0 and Slot 4 don't have have overlap.
We chose this approach over any other GUI or manager because:
1. We just prefer working in the terminal; it's just nothing replaces that.
2. We do work agentically, but doing that in the context of the terminal is still the preferred way rather than some GUI.
The way we handle this:
Every Warp tab = one project = one Git worktree = one Linear ticket. Complete isolation.
The port collision problem: We solved this with what we call "dev slots." Our bin/dev script automatically detects open ports across instances and claims the next available slot (1-8). Each slot gets its own set of ports offset by 100:
Slot 1: 10000, 10001, 10002...
Slot 2: 10100, 10101, 10102...
Slot 3: 10200, 10201, 10202...
Backend, frontend, Redis, workers—all contained. No overlap. No hunting.
The workflow: Fire up a new tab, run bin/dev, it grabs a slot. The server prints its localhost URL on launch. In Warp you can Option-click to open directly in browser. Each tab runs its own Claude Code instance (sometimes Codex for adversarial review), its own server, its own terminal for ad-hoc commands. Everything lives together.
The secret sauce: We use Overmind to orchestrate a full tmux-style stack that's completely self-contained per tab. It's what makes the "one tab = one universe" model actually work.
One small ritual that matters: Rename your tabs immediately. In Warp, just double-click and give it the project name. You're no longer hunting through cryptic command prompts—you're scanning real names.
Realistically: We can run 8 parallel projects. I personally cap at 3-4. That's the limit where I can still context-switch meaningfully, especially when debugging. But the infrastructure supports more when you need burst capacity.