Vibe Coding 101: How to Run 8 Agent Projects at Once

• Use Zed project tabs to keep many repos one click away without turning your desktop into a window pile.
• Use AGENTS.md or CLAUDE.md files so Codex and Claude Code read the local rules before editing.
• Use a JSON database double for Supabase so agents can run the full pipeline without touching production.
• Use TypeScript, LSP diagnostics, file-size limits, and tests as hard feedback for every agent run.
• Use Superwhisper or another dictation tool when the prompt needs several minutes of context.
• Use queued task files so Codex can keep working while you review another repo.
• Use regular refactor passes because smaller repos are easier for agents to search, edit, and verify.
• Use an always-on Mac when the workflow depends on open editors, long terminal runs, browser state, logs, and generated artifacts.

That outline is the whole lesson. Multi-project agent work becomes manageable when every repo has a small operating system around it: where the rules live, where local state lives, how the agent proves a change, and how the human gets back into the work later.

When you are moving across four, six, or eight projects, the slow part is not typing. The slow part is remembering which repo was running, which terminal belonged to it, which branch was active, and what the agent was supposed to finish.

Zed project tabs solve a very plain problem: each project gets a named tab instead of a separate editor window. You can keep a backend, a frontend, a side project, a work project, and a refactor project open without constantly hunting through the dock.

A root AGENTS.md or CLAUDE.md file is useful, but the better move is to add instructions close to the code. A database folder can explain the storage interface. A monitor folder can explain polling and retry behavior. A frontend folder can explain component and styling rules.

This reduces prompt weight. Instead of restating the same repo rules in every chat, you let the agent discover the durable instructions where the work happens. That matters a lot when you are dispatching small tasks across several repos.

The concrete pattern is simple: define one database interface, implement it twice, and switch implementations with an environment variable. Production can use Supabase. Local agent runs can use JSON files on disk.

That gives Codex or Claude Code a safe place to run the actual business flow. The agent can create records, inspect intermediate files, compare expected and actual state, and explain exactly what would have changed in production.

Prompt shape:
Read DatabaseInterface.
Run the pipeline with JsonDatabase.
Write every intermediate record to ./data/debug/.
Compare the final JSON state to the expected state.
Do not connect to Supabase unless I explicitly ask.

Agents will happily produce code that looks plausible and fails at the boundary. The fix is to make the repo complain immediately. Treat type errors, no-any violations, oversized files, missing tests, and broken imports as normal feedback inside the agent loop.

• Make no-any and unsafe escape hatches errors, not suggestions.
• Set file-length limits so agents split large changes into modules.
• Set directory-size limits so broad areas get subfolders and local docs.
• Require the agent to run the relevant type check and test command before handoff.
• Ask for the exact failing diagnostic when a check fails, then let the agent fix only that failure.

This is what lets you run several projects without blindly trusting any one of them. The agent can move fast because the repo gives it immediate, mechanical feedback.

Some prompts need a lot of context: what changed in the last few days, how the branch differs from main, what the architecture goal is, which tests matter, and what counts as done. Voice dictation is useful because it lets you describe that task at full detail without turning dispatch into a writing chore.

For longer runs, move from one giant prompt to a queue. Ask the agent to create rules.md, scope.md, and numbered task files. Then run the tasks in order. Each task should be small enough to review but complete enough that the agent can finish without stopping for minor decisions.

Work-pack queue:
Read rules.md and scope.md.
Implement task-00.md.
Run the named checks.
Write a handoff note with files changed, tests run, and decisions made.
Continue to task-01.md only if the checks pass.

When an agent edits business logic without first explaining the workflow, it often patches the wrong layer. A quick state diagram forces it to name the states, transitions, inputs, outputs, retries, and failure paths before touching files.

1. Ask the agent to diagram the current flow from the code, not from memory.
2. Make it list the files that define each state transition.
3. Compare the diagram to existing integration tests and debug artifacts.
4. Only then ask for the smallest code change that moves one transition.

This works especially well when you return to a repo after several hours away. The diagram rebuilds your mental model quickly and gives the agent a smaller target.

If you use agents heavily, cleanup is not optional. Models duplicate helpers, leave stale stubs, grow files by appending new branches, and create types that almost match existing types. That makes the next run worse because the search space gets noisier.

Treat refactoring as a normal agent workload. Ask the agent to find duplicates, delete dead code, merge types, split large files, and prove the behavior is unchanged with tests. This is not cosmetic. It is what keeps the repo legible enough for the next agent.

This workflow is a natural fit for the always-on Mac runtime where agents actually live. The value is not just remote access. The value is that Zed tabs, Codex queues, Claude Code sessions, browser profiles, generated JSON artifacts, screenshots, logs, and test output are still there when you reconnect.

What is the main idea of a vibe coding workflow?

The main idea is to reduce context switching and make repos easier for agents to reason about: modular architecture, local docs, typed interfaces, strict LSP rules, integration tests, state diagrams, and queued agent tasks.

Why use a JSON database alongside Supabase?

A JSON database can implement the same interface as the production database, giving agents a safe local backing store for development, tests, and inspectable pipeline artifacts.

Why does this workflow fit an always-on Mac?

The workflow depends on persistent editor tabs, terminal sessions, long Codex runs, browser state, generated artifacts, and desktop tools that should survive reconnects and laptop sleep.