After 2,000 hours of AI coding, he turned an efficiency problem into a scheduling problem

Four scheduling layers hiding inside a tool list

bb is the unified entry point. It brings Codex, Claude Code, Pi, Cursor CLI, OpenCode, and other programming agents into a single interface, reusing the user's existing provider CLI logins. cmux is a workspace that can display multiple terminals and browsers at once, and Ghostty is the terminal app hosting those sessions. Together, these three solve the "where do I launch and observe work" problem.

Herdr sits one layer down. It keeps agent terminal sessions running in the background and marks them with statuses like working, blocked, and idle. David's own Corral then queues up completed agents by priority, from P1 through P4. Herdr tells you what's happening; Corral decides where your next minute goes.

The execution environment consists of local machines, commercial cloud agents, and self-hosted VPSes. The governance layer is made up of skills, worktrees, ADRs, code review, read-only production data access, and release locks. Models run through all of this, but don't own any single layer exclusively.

The harness spans both entry points and execution environments. David uses Pi as his basic executor because it's minimal and lets him swap models freely, while Cursor CLI gives him multi-model support and pre-send capabilities. For more exploratory tasks where the approach isn't clear yet, he'll consider Hermes or Prime, which can accumulate skills during execution. The specific product picks are a matter of taste; the selection method that survives is: tasks with a clear path need a lightweight, controllable executor, while genuinely uncertain work is worth a harness that explores and accumulates knowledge on its own.

This architecture also explains why "just switch to a smarter model" often doesn't produce the expected productivity gains. A model might cut one task from 20 minutes down to 10, but if you're bouncing between 15 completed, blocked, and conflicting sessions, the savings get eaten by the scheduling overhead.

Once agents multiply, the bottleneck shifts from generation speed to human attention

In the single-agent era, a person watches one conversation: assign a task, look at the output, add context, confirm the result. Once agents run in parallel, work becomes a dynamic queue. Some are running tests, some need permissions, some are done and low-risk, and one just found a bug that could block a release.

Herdr's status panel makes those sessions visible, but visibility alone isn't the whole answer. Say a P1 agent just finished a payment bug fix while a P4 agent submits a copy tweak at the same time; processing them strictly in completion order lets low-value work capture the response window. Corral's prioritization is about treating human attention as a scarce resource and scheduling it deliberately.

This is an easy shift to miss: the human role changes from step-by-step author to exception handler and decision-maker. The workload doesn't disappear, it moves from writing code to defining tasks, prepping environments, judging risk, handling blockers, and accepting results. Without status tracking, clear priorities, and well-defined completion criteria, running more agents just creates more open loops.

David also emphasizes "pre-sending": when you already know what's coming next, queue up messages like "implementation plan," "switch to another model to review," or "fix the valid issues." This approach cuts down on waiting, but it's only suited for tasks where the path is already clear. When the architecture is still undecided, pre-sending six messages just amplifies an early misjudgment six times over.

The piece also calls out an input bottleneck that's easy to overlook: David uses voice transcription to send long prompts. His self-reported figures—about 250 words per minute, with input speed three to four times faster—are personal measurements, and actual results vary with speaking habits and revision costs. The transferable idea is that when you're frequently distributing context to multiple agents, reducing input friction genuinely shortens scheduling time. Voice only speeds up instructions you've already thought through; it can't replace task definition and acceptance judgment.

The cloud handles continuous running; self-hosted servers handle ownership

Local agents hit a physical ceiling fast. When multiple sessions are installing dependencies, compiling, and running full test suites at once, CPU, memory, disk, and network all compete for resources. Closing the laptop or losing connectivity can also interrupt long-running jobs. Cloud agents put each task in an isolated environment, run in parallel and unattended, and are easier to kick off from a phone or Slack.

Cursor said publicly in 2026, during June, that over 40% of its internal PRs already come from cloud agents, and that share is still climbing. In his August 31st article, David cites the number as "close to 60%," but the archived X Article only shows [image here] in that spot—the supporting chart isn't there. The trend has official backing; the specific 60% figure is the author's own claim, and the 70%, 80%, and 90% projections that follow are estimates.

Commercial cloud agents bring their own dependencies too: environment configuration, credentials, session history, pricing, and data are all tied to the vendor's platform. David's compromise is to rent a VPS, run Herdr on it, and connect over SSH from a laptop or phone. The terminal sessions live on the server, so the machine going offline doesn't stop the remote processes, and he can still use different agent CLIs.

The original post walks through a very concrete setup. David opens a coding agent in cmux's left pane, leaves an empty terminal on the right, and has the agent—using a skill that can manipulate other panes—provision a new VPS, installing Herdr, Node.js, Python, Git, and Pi. After a few prompts, two remote agents were running continuously on the server, surviving his MacBook shutting down. The case study shows how a self-hosted cloud environment actually comes together, and just as clearly, it exposes the risks of the same automation: in the process, the agent pulled an OpenRouter key off the local machine and got full root access on the remote box. The speed and control are real; so is the necessity of key isolation, least privilege, and rebuildable environments.

"Set up in ten minutes" and "80/20 for a few dollars" describe a smooth demo, not the total cost of ownership. Self-hosting returns control to the user, but it also hands back patching, key rotation, backups, logging, incident response, and failure recovery. That trade might be fine for a personal experiment; once you connect a production repository and real credentials, operational capability becomes part of the product itself.

Models and subscriptions are interchangeable compute, not the center of the workflow

David pays for several subscriptions at once, aiming for "more usable tokens for less money." He routes planning, new projects, tricky bugs, everyday chat, and front-end work to different models, and recommends spending a day testing a new model yourself rather than forming an opinion from social media.

The method is worth keeping; the shopping list is not. The plan prices, usage multipliers, model names, and relative rankings in the original piece are all bound to Q3 2026—David himself says things could look completely different two months later. Subscriptions also carry hidden constraints like peak throttling, concurrency limits, model switching policies, and platform rules; comparing monthly fees alone will miss those capacity boundaries.

His line about "never, ever paying API prices" only covers one scenario: high-frequency, interactive use of an off-the-shelf client. When you need programmatic batch processing, stable quotas, per-request cost attribution, service accounts, or unattended production tasks, the API is buying a different kind of control. Subscriptions and APIs aren't the same product, and you can't judge them purely on the per-million-token sticker price.

A more durable approach is to build task routing: how much reasoning does the task need, how much latency can it tolerate, how expensive is a failure, does it need an isolated environment, and is it worth having a second model review it? Models and plans are just constantly rotating suppliers on that routing table.

High throughput comes from presets and guardrails, not blanket autonomy

The most practical rule in the original piece is deceptively simple: turn repetitive single-step actions into text snippets, and repetitive multi-step workflows into skills. The savings aren't about typing a few dozen fewer characters; they're about the cognitive cost of reconstructing the sequence, checking for missed steps, and explaining acceptance criteria every time.

David's /total-review gets two different models to look at the same changes, then deduplicates their findings into a single issue list. His /ask-then-build prompts the agent to ask about important choices one by one before implementing. He's equally opposed to recursive review: asking the model to "find five more issues" tends to produce five issues, even if the remainder are imaginary bugs. Review should be triggered by the size of the change and the cost of failure, and it needs an explicit stopping condition.

Permissions follow the same tiered logic. David uses a short alias to jump straight into permission-bypass mode, which saves steps in isolated, rebuildable environments with no sensitive credentials. Pi's official security documentation explicitly notes that it is not a sandbox. Replicating that configuration on a daily-driver machine or in production gets you the same speed gains, but the blast radius of a wrong command is completely different.

Worktrees prevent parallel modifications from clobbering each other. ADRs capture architectural rationale that can't be reverse-engineered from code. A read-only role on the production database lets agents verify real-world data without rewriting it. A single-writer release lock chains merge, verification, push, CI, deploy, and health checks into one controlled exit path. Together, these practices do one thing: give agents the permissions they need for the task, while withholding the ability to cause damage that has nothing to do with it.

Testing follows the same principle. Requiring unit, integration, and end-to-end tests for every small change bloats the repo; banning tests outright leaves you without regression evidence. Work from risk and the existing test strategy, and add just enough evidence to prevent the same class of failure from recurring—don't measure diligence by test file count.

Most people should start with a one-primary-one-secondary setup

David's twenty-to-thirty-agent setup exists to serve his workload and his subscription capacity. Copying that scale from day one will just burn through quotas faster and shred your attention. A smaller closed loop is a better place to start:

1. One primary, one secondary. The primary agent does the implementation; only medium-to-large changes get an independent review from a second model. Start by seeing whether the review consistently surfaces issues that would change the delivered result.
2. One isolated worktree. Switch to a worktree when parallel tasks might touch the same files. Small projects and single-file changes stay on the current branch, keeping overhead low.
3. One trend line of results. Logging agent sessions, user prompts, and Git commits can show habit changes, but all three are proxy metrics. Add rework counts, post-merge failures, delivery cycle time, or actual user outcomes before you can tell whether efficiency is really improving.

Only when latency, conflict rates, or local resource limits in this small system actually become the bottleneck should you add a status panel, a VPS, or commercial cloud agents. The order of expansion follows the problems that have actually appeared, not the tool catalog.

What survives this 2,000-hour configuration is a division of engineering labor: an entry point that lowers switching costs, a scheduler that manages attention, an environment that keeps things running, and a governance layer that turns speed into acceptable outcomes. The next generation of models will change, the plans will change, and today's hottest client will change; these four jobs won't.