Warp Speed Systems — Warp 4: Autopilot

You stop sitting at the desk. The work still ships.

At Warp 3 you were the manager: you scheduled the work, briefed the team, and stayed in session while the sprint ran. Warp 4 is the first time the work continues after you close your laptop. You scope a project — one concrete outcome for one specific user, with a deadline — approve its plan, and the agent runs the sprints that get there overnight. In the morning there are PRs to review, not tasks to assign. The failure mode shifts accordingly — not a bad commit caught in session, but a night of autonomous work aimed at the wrong outcome.

The shift: scoping, approving, and executing become three different things

At every lower warp, these three activities were fused. You scoped the work, you approved it (implicitly, by starting a session), and you executed it (or sat beside the agent that did). At Warp 4 they split apart — and that split is the whole mechanism.

Scoping and approval stay human-gated. You decide what's worth working on — and at Warp 4 that decision is a project: a single concrete outcome for a specific user, with a deadline. You review the plan the agent drafts to get there and say go or say no. This happens on your schedule — a weekly planning hour, a morning review, whatever cadence suits you. The agent does not invent priorities and start shipping.

Execution runs autonomously. Once you've approved the project, the agent picks it up, dispatches its sprints to the Warp 3 team, and runs. One project is in flight per repo at a time: it runs until it merges to main, and only then does the next one start — everything else waits on its own branch. You are not needed until the next gate; this is the overnight or long-horizon run, a session that starts when you sign off and finishes when you wake up.

The decoupling is what gives Warp 4 its leverage. A human can only be present so many hours a day. An agent can advance the approved project continuously. Throughput goes up not because the agent is faster at any single task, but because it works the hours you can't.

Projects set the work, not priority scores

Priority scores don't work at small-scale SaaS. A score is only as good as the reasoning behind it, and at this scale priorities are accurate only when the reason why each item matters is written down and kept current. A number on its own goes stale the moment the situation it summarized changes.

A raw priority score doesn't capture context. It doesn't know that one ticket is blocked on a conversation that hasn't happened yet. It doesn't know that feature B is politically sensitive and the founder wants to be in the room when it ships. It doesn't know that another ticket is technically P2 but the one customer paying $5k/month asked for it personally. No formula produces a sensible queue from those signals — only the up-to-date reasons behind them do.

What actually works is to stop maintaining a ranked list of tickets at all. Instead you commit to one themed project at a time: a concrete outcome for a specific user, with a deadline. The named user and the date — not a score — are what decide whether a piece of work is in scope. Tickets that don't serve the current outcome simply aren't in the project; they stay as ideas until some future project needs them. The agent advances the project you committed to. It does not invent a backlog or re-rank one autonomously.

This is also how the project fixes the generic-product trap. A score-ranked backlog never says whothe work is for, so the agent builds the average of everyone and serves no one. A project names the user in its first line — so every decision down the run has a concrete person to be right for, and “laser-focused on one use case” stops being a slogan and becomes a field the work can't start without.

This is not a limitation of the tooling. It's the correct architecture. Approving a tightly-scoped project is fast (ten minutes on a Monday morning); recovering from a week of autonomous work aimed at the wrong outcome is not. The approval gate is cheap insurance.

Why this matters: the human-attention bottleneck

A human cannot meaningfully evaluate more than roughly five feature proposals at once before they start rubber-stamping. Read fifteen tickets back to back and by ticket twelve you're approving “sounds fine” without actually thinking. This is a real physiological limit, not a management failing.

The result at Warp 3: throughput is bounded by how many items a human can genuinely evaluate per session, times the number of sessions per week. Every hour the human spends approving is an hour not spent on the work only the human can do — architecture decisions, customer conversations, strategic calls.

Warp 4's decoupling removes that bottleneck by separating the approval rate (gated on human attention, bounded, batched) from the execution rate (autonomous, continuous). The human can batch-approve a week's worth of pre-scoped work in an hour on Monday morning; the agent executes it across the week without further human time. The human's scarce resource — focused attention — gets concentrated on the approval decision, not on sitting through the execution.

There is a second limit, on concurrency rather than throughput: a person can hold only about three live projects in their head at once. Past three, planning quality collapses — you stop steering each one well and start losing the thread. This is why autonomy is pinned to a small number of projects, not turned loose on the whole backlog. Themed scope is what makes even three tractable: because every question an overnight run sends back is about the same outcome, answering them is one context, not ten. Unrelated one-off tickets do the opposite — every question is a fresh context-switch, and your steering degrades.

During an autonomous run, two moves

Once a run is underway, the agent has exactly two options when it hits uncertainty:

Come back to the human. Some decisions genuinely require human input — a call that will affect a customer, a change to a shared contract, a security tradeoff. The agent surfaces the question and waits. The run pauses on that thread; other threads continue if they're unblocked.

Ship the least-risky thing and continue. Most decisions don't need the human. The agent should default to the simplest, most-reversible implementation that makes progress — and move on. This is especially true for scalability decisions. “Will this approach hold up at 100x load?” is almost never a question that needs answering in the first iteration. The answer is almost always: build the simple version now, and scale it when a real user trips the limit. Pulling the human into a scalability design debate at 2am is waste.

The discipline is knowing which category a decision falls into. Good role files specify this explicitly: “For decisions that affect only internal plumbing, use the simplest approach and continue. For decisions that affect the user-facing API shape, pause and surface the question.”

Deferred decisions: watched, not forgotten

Not every uncertainty is a blocker. Some things can be decided later without consequence — a database index that doesn't exist yet, a rate-limit that's probably never going to be hit at this usage level, a timeout value that could be tuned but currently works. These are deferred decisions: known imperfections the agent intentionally skips over to keep the run moving.

At Warp 3, deferred decisions often got lost. The sprint lead would note something in a comment, you'd intend to file a ticket, and three months later a user hits the 1000-record limit that nobody got around to raising. The consequence was a bug that felt like a surprise but wasn't — the decision to defer was recorded nowhere actionable.

At Warp 4, deferrals become a watched backlog. The agent logs each deferral with enough context to evaluate it later: what the known limit is, what usage pattern would trip it, what the fix would likely involve. This backlog gets reviewed — not because every item needs fixing, but because some items have a real user approaching the wire and that needs to be caught before it becomes an incident.

The watch mechanism matters. A deferral without a monitor is just a time-delayed bug. The agent should be checking, on each run: are any of these deferred decisions now close to being triggered by actual usage? If yes, the item moves from “known backlog” to “needs scheduling.”

This is the limit of Warp 4 on deferral management. At this warp, the agent informs you that a deferred issue exists and that a user is approaching its limit. It does not yet track whether you have pre-approved a direction for howto fix it. That tracking — “the human said in March that we should solve this with sharding, not caching” — is a Warp 5 problem. Here at Warp 4, the human is merely informed. What to do about it is a manual decision you make when you receive the alert.

The graduation condition

You're ready for Warp 5 when the autonomous runs are reliable enough that the thing you want isn't tighter control — it's for the system to maintain itself while it's live. Not just run new work overnight, but watch the existing product, catch quality regressions, and self-heal. That's the Manager warp: the first tier that keeps the product alive in front of users without a human in the loop.