omc345 notes

You installed cmux, nightshift, and swarm. You have a terminal multiplexer for parallel agent sessions, a scheduler for overnight automation, and an orchestrator for coordinated multi-agent work. The tools are ready.

Now what?

The temptation is to throw everything at them—point nightshift at your biggest codebase and queue up twenty tasks before bed. That's a recipe for waking up to twenty half-broken branches. The agentic stack is powerful, but its leverage depends entirely on what you point it at.

This post is about selection. Which projects benefit most? Which tasks are high-leverage overnight candidates? Which orchestration pattern fits which problem? And what should you avoid entirely?

I spent time auditing my own portfolio of 60+ repositories and researching what the community has learned from real multi-agent workflows. Here's what I found.

The selection problem

Not every project benefits equally from multi-agent automation. A weekend side project with 500 lines of code doesn't need a swarm. A production monolith with 200,000 lines of untested legacy code is a gold mine.

The difference comes down to three variables:

Decomposability — Can the work be broken into independent units that don't step on each other?
Verifiability — Can an agent confirm its own work succeeded (tests pass, types check, linter is clean)?
Risk tolerance — What's the blast radius if an agent makes a mistake?

Projects that score high on all three are where the agentic stack pays for itself overnight—literally.

A scoring framework

Before queuing anything in nightshift, run each candidate task through this filter:

| Criteria | High leverage | Low leverage | |-------------------|----------------------------------------------------|---------------------------------------------------| | Independence | Files/modules with clear boundaries | Tightly coupled code where changing one file breaks five others | | Self-validation | Has tests, type checking, linting | No tests, no CI, "works on my machine" | | Scope | Well-defined: "add tests for X", "refactor Y to pattern Z" | Open-ended: "improve the codebase", "make it better" | | Reversibility | Easy to revert (git branch per task) | Database migrations, external API changes, deployed infrastructure | | Context window| Task fits in one conversation | Requires understanding the entire codebase simultaneously |

Tasks that score 4-5 high leverage marks are prime candidates. Tasks with 2 or fewer should stay manual.

Six high-leverage opportunity categories

1. Test generation at scale

Why it works: Tests are inherently independent (one test file doesn't affect another), self-validating (they either pass or fail), well-scoped, and fully reversible.

The pattern: Use the self-organizing swarm. Create a task for each untested module. Spawn 3-4 workers that race to claim and complete them.

nightshift task add "write unit tests for auth service — target 80% coverage"
nightshift task add "write integration tests for payment API endpoints"
nightshift task add "write unit tests for notification dispatcher"
nightshift task add "add edge case tests for rate limiter"

Real numbers from the community: Teams report 80-90% of generated tests being usable with minor tweaks. The overnight run produces a test suite that would have taken 2-3 days of manual work.

Best fit from my repos:

mcp-supersubagents — Has Vitest setup but sparse coverage across 5 agent launchers
clawdbot — Massive monorepo with 150+ npm scripts, many untested code paths
omc345-expo-starter-with-supabase — Production template that should have comprehensive tests
turkish-legal-ai — RAG pipeline with vectorize/KV integration, needs integration tests

2. Parallel code review with specialists

Why it works: Review agents are read-only (zero blast radius), inherently parallelizable, and each specialist catches things the others miss.

The pattern: Parallel specialists via swarm. One security reviewer, one performance reviewer, one simplicity reviewer, one architecture reviewer—all running simultaneously on the same PR or module.

Community data shows the 9-agent parallel review pattern yields a ~75% useful suggestion rate. That's better than most human reviewers on code outside their primary domain.

Best fit from my repos:

clawdbot — Multi-channel AI gateway handling WhatsApp, Telegram, Discord, Slack, Signal, iMessage. Security review across all channel handlers is critical but tedious manually
mcp-supersubagents — Token rotation and multi-account provider abstraction needs security + architecture review
turkish-legal-ai — Legal AI handling sensitive data, needs dedicated security and data integrity review

3. Dead code and dependency auditing

Why it works: Purely analytical, zero risk of breaking anything, and the findings directly reduce maintenance burden.

The pattern: Pipeline—research agent catalogs unused exports/imports, then a second agent validates findings, then a third agent creates cleanup PRs.

nightshift task add "audit dead code in clawdbot — find unused exports, unreachable functions, orphaned files"
nightshift task add "audit npm dependencies in omc345-expo-starter — find unused, outdated, and duplicate packages"
nightshift task add "scan for hardcoded secrets and credentials across all repos"

Best fit from my repos:

clawdbot — At 150+ npm scripts, there's almost certainly dead code and unused dependencies
Any repo that's been actively developed for 6+ months

4. Documentation sync

Why it works: Documentation is independent from code execution, easy to verify (does the described API match the actual API?), and always behind.

The pattern: Research agent reads the current code, compares against existing docs, generates a diff of what's outdated. Implementation agent updates the docs.

nightshift task add "sync README.md with current API endpoints in md-cms"
nightshift task add "update CLAUDE.md in omc345-expo-starter to reflect current architecture"
nightshift task add "generate API documentation for mcp-supersubagents endpoints"

Best fit from my repos:

md-cms — CMS with full documentation that may have drifted from implementation
33 repos with CLAUDE.md files—any of these could be out of date
claude-code-agents-collection — 152 agents that need accurate descriptions

5. Large refactors via decomposition

Why it works—when done right: The winning pattern from the community is decomposing refactors into independent units, using a rolling integration branch (not main), and automating 80-90% with human checkpoints at integration points.

The pattern: Pipeline with fan-out. Research agent maps the refactor scope. Plan agent decomposes into independent units. Multiple implementation agents work the units in parallel. Integration agent merges and resolves conflicts.

Community data: One practitioner reports reviewing 10-15 agent PRs in the time of one manual refactor. Citadel (a multi-agent orchestrator) achieved a 3.1% merge conflict rate across 109 waves of parallel changes.

Critical constraint: Each agent must work on files that no other agent touches. File-level isolation is what makes parallel refactoring safe. The moment two agents edit the same file, you get merge conflicts and wasted work.

nightshift task add "refactor auth module: extract JWT validation to standalone service"
nightshift task add "refactor auth module: migrate session storage from cookie to token-based"
nightshift task add "refactor auth module: update all route handlers to use new auth service"

Best fit from my repos:

clawdbot — Multi-channel gateway could benefit from extracting shared channel handler logic
omc345-expo-starter-with-supabase — Template refactoring to newer Expo patterns

6. Automated bug fixing from issue trackers

Why it works: Issues are pre-scoped descriptions of what's broken, often with reproduction steps. An agent can read the issue, find the relevant code, write a fix, and validate it against tests.

The pattern: For each open issue, spawn an agent that reads the issue, explores the codebase for the relevant files, writes a fix, runs tests, and opens a PR. The Lazy Bird pattern from the community: GitHub issues → agent PRs → review on your phone.

nightshift task add "fix: notification dispatcher drops messages when queue exceeds 1000 items"
nightshift task add "fix: rate limiter doesn't reset after window expires"
nightshift task add "fix: API returns 500 instead of 422 on invalid input"

Best fit from my repos:

linear-automations — Already integrates with Linear; could pull issues automatically
Any repo with an active GitHub Issues backlog

Pattern matching: which orchestration fits which task

| Task type | Orchestration pattern | Why | |-------------------|----------------------------|------------------------------------------| | Test generation | Self-organizing swarm | Independent tasks, natural load balancing| | Code review | Parallel specialists | Each domain expert runs independently | | Dead code audit | Pipeline | Research → validate → cleanup is sequential | | Doc sync | Pipeline | Read code → compare docs → update | | Large refactor | Pipeline with fan-out | Research → decompose → parallel implementation → integrate | | Bug fixing | Self-organizing swarm | Each bug is independent | | Dependency updates| Self-organizing swarm | Each package update is independent | | Security audit | Parallel specialists | Different vulnerability classes need different expertise |

The overnight delegation playbook

Here's how I structure a productive nightshift run:

Before bed (10 minutes)

Audit the queue: nightshift task list—make sure each task is specific, scoped, and verifiable
Budget check: nightshift budget—confirm you have headroom for the run
Preview: nightshift preview—review what nightshift plans to do
Kick off or let the schedule handle it: nightshift run or just go to sleep

Morning (20 minutes)

Check history: nightshift history—see what ran, what succeeded, what failed
Review PRs: Each task should have produced a branch. Review the diffs
Run validation: Tests pass? Types check? Linter clean?
Merge or iterate: Good PRs get merged. Bad ones get a new task for the next night

The cadence

Monday: Queue test generation tasks for the most critical untested modules
Tuesday: Queue security and performance review of last week's merged code
Wednesday: Queue dead code audit and dependency updates
Thursday: Queue documentation sync across repos with stale CLAUDE.md files
Friday: Queue exploratory research tasks for next week's feature work

This gives you a rolling cycle where maintenance, quality, and research happen overnight while your daytime hours stay focused on feature work and architecture decisions.

What to avoid

The community has been burned enough to establish clear anti-patterns. Learn from their mistakes:

Don't: Queue open-ended tasks

Bad: nightshift task add "improve the codebase" Good: nightshift task add "add input validation to all POST endpoints in the API controller"

Agents need constraints. Without a clear definition of done, they'll wander, make arbitrary changes, and produce branches you can't review meaningfully.

Don't: Let agents make architectural decisions

Bad: nightshift task add "redesign the database schema for better performance" Good: nightshift task add "add an index on users.email and orders.created_at per the schema optimization plan"

Architecture requires understanding trade-offs, business context, and future direction. Agents excel at executing architectural decisions, not making them. You decide the architecture; agents implement it.

Don't: Run more than 4-6 parallel agents

Community consensus is clear: 4-6 parallel agents is the sweet spot. Beyond that, coordination overhead grows faster than productivity. Resource contention (CPU, memory, API rate limits) compounds the problem.

Don't: Skip human checkpoints for anything touching production

Overnight automation is for generating PRs, not merging them. Every agent-produced change should pass through human review before hitting main. The Lazy Bird pattern—review agent PRs on your phone over morning coffee—is the right level of oversight.

Don't: Automate tasks that require full codebase context

If the task requires understanding how 15 different modules interact, it's not a good overnight candidate. Agents work best with tasks that fit in a conversation window. Tasks requiring global codebase awareness should stay manual or be decomposed into smaller, context-independent units.

Getting started: your first week

If you've just installed the agentic stack and want to start seeing value immediately, here's a five-day ramp:

Day 1: Single overnight test generation run. Pick your most critical untested module. Queue one task: nightshift task add "write comprehensive unit tests for [module]". Run it overnight. Review in the morning. This builds confidence in the loop.

Day 2: Parallel code review. Use /swarm to spawn 3 specialist reviewers (security, performance, simplicity) on a recent PR or module you're unsure about. Run it during the day so you can watch it work. This teaches you the swarm workflow.

Day 3: Multi-task overnight run. Queue 3-4 independent tasks (test generation for different modules). Run overnight. Morning review. This tests nightshift's ability to manage multiple parallel sessions via cmux.

Day 4: Pipeline workflow. Use /swarm to set up a research → plan → implement pipeline for a small feature. This teaches you task dependencies and sequential orchestration.

Day 5: Full delegation cycle. Queue a mix of task types—tests, docs, dead code audit, one small bug fix. Run overnight. Morning review and merge. This is your steady-state workflow from here on.

By the end of the week, you'll have a feel for which tasks produce good overnight results, how to scope them for agents, and how much you can realistically delegate.

The leverage equation

The agentic stack doesn't replace your judgment. It replaces your hands. You still decide what to build, how to architect it, and what quality bar to hold. But the tedious execution—writing tests, reviewing code from five angles, updating documentation, cleaning up dead code, fixing well-described bugs—that's overnight work now.

The developers who will get the most out of this aren't the ones who automate everything. They're the ones who get good at identifying which 20% of their task list is perfectly shaped for agent delegation. Finding those tasks—scoped, independent, verifiable, reversible—is the real skill.

The tools are ready. The question is: what are you going to delegate tonight?