I sat down after lunch and the work was done. Not partially done. Not paused, waiting for me to approve the next step. Done. Twenty-six product packages — ZIPs, system prompts, social copy, the works — sitting in a folder like they had always been there.
I had been gone for about 40 minutes.
I found this mildly interesting. Interesting enough to document.
The Problem With How Most People Use Claude
You open Claude. You type a prompt. Claude starts working. Claude stops and asks a clarifying question. You answer. Claude continues. Claude stops again. You confirm the direction. Claude produces something. You review it, ask for changes. Claude adjusts. You confirm.
This is not automation. This is a slow assistant.
If you are paying for Claude Max and still sitting at your computer approving each micro-step, you have not automated anything. You have just replaced one form of manual labor with another. The subscription costs more. The output rate is roughly the same.
"You're paying for Claude Max and still babysitting it one step at a time. That's not automation. That's a slow assistant."
The check-in loop is the default behavior because it is the safe behavior. Claude does not know what done looks like unless you tell it. So it stops and asks. Every time. Until you give it a structure that removes that ambiguity.
The Discovery: Four Panes, Four Roles
tmux is a terminal multiplexer. The short version: it lets you split your terminal into multiple panes and run separate processes in each one simultaneously. It has been around for decades. Most people who use it treat it as a convenience for keeping multiple terminal tabs organized.
The setup that changed things for me was assigning a specific role to each pane instead of treating them as interchangeable.
Pane 1 — The Implementer: This is where Claude executes. It receives tasks and builds output without stopping for approval.
Pane 2 — The Planner: This pane handles sequencing. It determines what gets built next and feeds tasks to the implementer in order.
Pane 3 — The Reviewer: This pane checks output against a defined standard after each task completes. It flags problems without interrupting the build loop.
Pane 4 — The Background Script: A persistent watcher that monitors file output, catches errors, and restarts stalled processes automatically.
Four roles running simultaneously. The implementer does not wait for the planner to finish planning. The reviewer does not pause the implementer to report findings. Everything runs in parallel, and the background script makes sure nothing falls over quietly.
The Prompt Structure That Prevents Check-Ins
The setup is only half of it. The other half is how you write the prompt that goes into the implementer pane.
Claude stops and asks when it hits ambiguity. So the prompt has to eliminate ambiguity before Claude encounters it. That means telling Claude exactly what done looks like — not as a goal, but as a specific, checkable output state.
A prompt that produces check-ins looks like: 'Build a product package for the bookkeeping guide.' A prompt that does not looks like: 'Build a product package for the bookkeeping guide. Output must include: system-prompt.txt, social-copy.txt, product-description.txt, and a ZIP containing all three. Do not ask for confirmation. If you encounter a decision point, apply the following defaults: [list of defaults]. Mark complete when all four files exist in /output/bookkeeping/.'
The difference is specificity about the exit condition. Claude knows it is done when it can check four boxes. Until those boxes are checked, it keeps building. When they are checked, it marks the task complete and the planner feeds it the next one.
"Tell Claude what done looks like — not as a goal, but as a specific, checkable output state. Then it stops asking."
What the Session Actually Produced
Twenty-six product packages in one autonomous session. Each one followed the same structure: system prompt, social copy for three platforms, product description, and a compiled ZIP.
Not all of them were perfect. Three had formatting inconsistencies that the reviewer flagged. Two needed minor copy edits. One product prompt was slightly off-tone and got a rewrite.
But twenty-six packages existed, which is the thing that matters. I reviewed them after lunch. I fixed six issues. The other twenty were done.
Why This Became a $9 Product
The GitHub tutorials for tmux and Claude Code exist. They explain what tmux is and how Claude Code works. They do not explain the 4-pane role assignment, the specific prompt structure that eliminates the check-in loop, or how to configure the background watcher so it catches stalled processes without interrupting builds in progress.
Those are the parts that are not obvious. The parts that take an afternoon to figure out through trial and error. The parts that make the difference between a setup that feels clever and a setup that actually runs while you are eating lunch.
The guide is the configuration and the prompt structure. Packaged so you can set it up in an hour and have it running the same day. That is what the $9 is for.
The Vibe Coders Shelf
This post is also an announcement. The Vibe Coders section is live.
Vibe Coders is a shelf of $9 single-trick guides for people who already know what they are doing. Not beginner walkthroughs. Not "what is an API" explainers. Specific setups for specific problems, written for people who would rather read a tight guide than reverse-engineer something from a forum thread.
Five products at launch. The parallel terminals setup is one of them. The autonomous loop configuration — the full loop that handles task sequencing, error recovery, and output validation without check-ins — is another.
Browse the Vibe Coders shelf at /vibe-coders. $9 each. Single-trick guides. No subscription.
If you already have Claude Max and you are still manually approving each step, the parallel terminals guide is the place to start. If you want the full autonomous setup — the one that built 26 packages while I was at lunch — that is the autonomous loop guide.
Lazy Parallel Terminals: /products/lazy-parallel-terminals — the 4-pane tmux config, role assignments, and prompt structure. One hour to set up.
Lazy Autonomous Loop: /products/lazy-autonomous-loop — the full autonomous session configuration with error recovery and output validation.