Prioritizing a backlog when agents work fast

Prioritizing a backlog when agents work fast means ranking tasks by what they will take from you, not by how long they take to implement. When an agent can produce a first version of almost any task in an hour, implementation effort stops being a useful tiebreaker. What still varies a lot is the value of the outcome, the effort to review and verify it, the risk it carries for other parts of the code, and whether other work is waiting on it. Those four inputs decide the order. This article gives a simple scoring approach, a clear meaning for P0 to P3, and guidance on what to leave for later. It assumes you already cap work in progress; see WIP limits for agent work for that side of the problem.

Why fast implementation changes the ranking

Traditional prioritization often weighs value against effort, and effort mostly means build time. Quick wins float to the top because they are cheap to build. With agents, nearly everything looks like a quick win at the build stage, so that heuristic stops discriminating.

The effort that remains is yours. A task that changes a shared money-rounding helper may take an agent ten minutes and you two hours to verify across every caller. A task that adds a self-contained admin page may take the agent longer but be easy to check. If you rank by apparent build effort, you will keep starting changes that are fast to produce and slow to trust.

There is also a temptation to do everything because it is cheap to start. Every item you start still needs review, still touches the codebase, and still adds to what can go stale. A backlog that grows because agents make it easy to add tasks needs firmer prioritization, not less. Leaving work undone is a decision you are allowed to make.

Four inputs: value, review effort, risk, order

Value: what changes for a user, a deadline or the team when this is accepted? Be concrete. Fixes the export bug two customers reported is value; tidies the utils folder usually is not, unless it unblocks something.

Review effort: how long will a careful check take? Estimate the size of the diff you expect, how many callers are affected and whether good tests already exist. A task with no reliable check scores badly here, which is often a sign to write the check first.

Risk: what breaks if the change is wrong and the review misses it? Shared helpers, data migrations, authentication and money handling are high risk. Isolated UI copy is low.

Order: does other work depend on this? A task that unblocks three others earns priority even if its own value is modest. A task that depends on unfinished work should wait regardless of value.

A simple scoring rule: start with value, subtract for review effort and risk, then pull dependency-unblocking work forward. Do not overengineer the arithmetic; the conversation about each input matters more than the score.

P0 to P3 as commitments

Priority labels are only useful if each one means something you will act on. One workable convention:

P0: drop other work. Production is broken, data is at risk, or a hard deadline is in danger. There should rarely be more than one P0 at a time.

P1: next up. Work you will start as soon as WIP allows, in dependency order. Keep this list short enough to finish within the current planning cycle.

P2: planned. Worth doing and expected within the next few cycles, but not committed this week.

P3: someday. Ideas and improvements with no commitment. Review them occasionally and decline the ones that have not moved.

The common failure is label inflation: everything becomes P1 because agents could start it today. Guard against that by capping how many P1 items you allow, for example no more than twice your WIP limit. When something new arrives as P1, something else drops to P2. Write that trade-off down so the next re-plan can see it.

A weekly triage routine and what to leave

Step 1: Clear the review queue first. Prioritizing new work while old work waits for review only lengthens the queue.

Step 2: Check blocked items. Anything waiting on a decision gets a decision or an owner and a date.

Step 3: Rescore new arrivals with the four inputs and place them in P0 to P3.

Step 4: Confirm P1 order follows dependencies, so you never start a task whose prerequisite is still open.

Step 5: Prune P3. Decline or hold anything that has sat untouched for a month. See keeping the backlog clean.

What to leave for later: speculative refactors with no test coverage, cosmetic changes to shared code, and agent-suggested follow-ups that nobody asked for. Agents often propose extra work at the end of a task; record it, but rank it like anything else. Tasks discovered mid-run should not jump the queue just because they are fresh. The article on discovered tasks goes into how to capture them without losing the plan.

QUESTIONS

How do I prioritize tasks when an AI agent can do them all quickly?

Rank by value, review effort, risk and dependency order instead of build time. Fast implementation does not reduce the time you need to verify a change. Start tasks that unblock others and are easy to check, and delay high-risk changes until you have time to review them properly.

What do P0, P1, P2 and P3 priorities mean?

A common convention: P0 means drop everything, P1 means next up when capacity frees, P2 means planned but not committed this cycle, and P3 means someday with no commitment. The labels only help if the P0 and P1 lists stay short and each new P1 pushes something down.

Should agent-suggested follow-up tasks go to the top of the backlog?

No. Record them so they are not lost, then score them like any other task. Suggestions arrive at the end of a run while the context feels fresh, which makes them seem urgent. Most belong in P2 or P3 until someone confirms they matter.

RELATED GUIDES

• How to find and organize work across projects
• How to create a project card in BRAIN FLUID Desk

RELATED HARNESS PAGES

• WIP limits for AI agent work WIP limits for AI agent work: why agents make starting too easy, and why the limit belongs on review capacity rather than on running sessions.
• Keeping an AI project backlog clean Keeping an AI project backlog clean: decline or hold work instead of deleting it, merge duplicates, avoid ID collisions and groom on a schedule.
• Managing tasks an AI agent discovers mid-work Managing tasks an AI agent discovers mid-work: record each as a new linked task, mark it required or optional and never widen the current task silently.
• Task dependency graphs for AI agents Task dependency graphs for AI agents: declare prerequisites, let selection skip blocked work and keep dependencies in the context each agent gets.
• The blast radius of AI code changes The blast radius of AI code changes: what one agent edit can break elsewhere, a worked rounding example, and how a reviewer finds affected features.
• A solo developer's workflow with AI agents A solo developer's workflow with AI agents: one person as planner, reviewer and release owner, with a weekly plan and a short daily routine.