# How do you stop telling Claude Code what to work on next? > A finished session does nothing until a person decides what comes next. The decision depends on knowing which prerequisites are done, and the only place that lives is our heads, so nothing moves while we are busy elsewhere. ## By evening, how many times did we answer the same question? We started three sessions in the morning. Early in the afternoon one of them finished. We were reading a diff from a different session at the time. The finished one does nothing until we hand it something. When we were done reading we went back and typed the next job. It had been idle for maybe twenty minutes. We did not time it. This happens several times a day. Looking back at the end of the day, a noticeable chunk of what we did was answering the question "what next?". The sessions are fast. Being fast means they finish sooner, and a finished session stops until somebody decides the next thing. That somebody is only ever us. Deciding is not hard work in itself. Out of the candidates, pick one whose prerequisites are finished, that nobody else has started, and that is not parked on a human decision. The hard part is doing that several times a day, each time interrupting something else. And we are solving it in our heads. Knowing which cards are unblocked means remembering what just finished. The only copy of that is in our memory, so while we are thinking about something else, nobody can solve it. ## What we tried first In the order we tried them. All of them worked up to a point. First we put everything into one long prompt. Do A, then B, then C. For a short chain that works fine. The trouble starts when a prerequisite changes halfway. If B's result makes C pointless, the session still marches into C. We interrupt and type "skip C", which means we are watching it anyway. Then a `TODO.md` in the repo, checkboxes, work down from the top. Persisting is good. What it does not record is which item is in flight right now. Show the same file to two sessions and both take the same line. We did that twice. We also put "work down the list" in CLAUDE.md. It gets read every time, so we stop repeating the instruction. But CLAUDE.md is where standing rules belong, not today's ordering. Nothing removes an entry when the work is done, so stale instructions accumulated and got in the way. We stopped. Issue labels were next: a label meaning ready to pick up, and the AI only takes labelled issues. Issues have numbers, they survive, another AI can read them, labels can carry state. This was the best of the four. The catch is that moving the label when a prerequisite finishes is manual work for a person. If nobody moves it the moment something lands, the AI cannot take work that is actually available. With five sessions running, nobody keeps that up. We did not either. ## Where each one stopped keeping up They jam in the same spot. Unless somebody reflects "this prerequisite is done" by hand, the list of work that can start now never updates. That somebody is us, and we are the ones being interrupted. Issue labels were the one exception: while the labels are current, they work. What is left is relabelling on every finish. ## What this looks like for us Between our own product and client work we move across three or four projects in a day. On a busy day about five AI sessions are open. That is typical for us, not a measurement. A big piece of work cannot be handed over as-is. "Add payments" is not something a session can start. So we ask a chat AI to break it down into the smallest tasks, down to a first step, and register those. While it is breaking things down we have it write which task comes after which. Breaking work down makes each item small, which means more of them can run side by side. More of them also means more picking. What paid off was setting things up so that only the unblocked ones can be pulled out. It feels like the number of times a day we answer "what next?" went from several to one or two. We have not measured it. What is left clusters in two places: when the startable cards run out, and when a decision genuinely needs a person. ## How we designed it in Dazbench What we wanted was for the AI to come and fetch its own next job. Not any job, though. Only one whose prerequisites are finished and that no other session has started. So "can this start now?" is computed from the dependencies written on the cards, every time, instead of being looked up in our memory. 1. One job, one card. Each card gets a number like dz51. 2. On the later piece of work, add a line: this one comes after dz12. Prerequisites only work inside one project, and anything that would form a loop cannot be saved. 3. When we start a session we say: take whatever can be started. The AI only gets the cards whose prerequisites are finished and that nobody has picked up. Work already under way, work a person stopped, work waiting on a prerequisite, and work whose prerequisite no longer exists come back in separate groups, so it cannot take one of those by mistake. 4. The AI takes one of those cards and sets it to in progress. That is the signal to the other sessions that this one is taken, and it stops being offered to whichever session asks next. 5. When a decision belongs to a person, it asks with the options spelled out. A browser notification fires. 6. If it is stopped waiting on a reply from us or from someone else, the card goes to waiting. It counts as stopped, so no other session mistakes it for work it can start. 7. A card can only be completed after a person approves; the AI never decides that on its own. The moment a card completes, whatever was waiting on it stops waiting and becomes startable. The web side has a route view built from the same buckets: in progress, can run in parallel, waiting on prerequisites. It runs through the same function the AI's call does. If that were implemented twice, a human and an AI would eventually disagree about what "startable" means. ## What actually changed Starting a session is now one sentence: point at the project and say to work through whatever can start. Writing per-job instructions is gone. Finished sessions spend less time idle waiting on us. We have not measured that. It is how it feels. Handing the same card to two sessions happens less. A card set to in progress stops being offered, so it never shows up for a session we start later. We can still do it by handing over the number ourselves. > The parts that are not solved, plainly. When several cards can be started, a person still decides which one goes first; the AI has nothing to rank them by. Dependencies do not exist unless somebody writes them, and having them written during the breakdown is the cheapest way, but anything we forget shows up as startable. A card with a vague goal comes back to a person as a question even when it could be started. And on work with deep chains there are days when exactly one card can be started, so nothing runs in parallel. ## FAQ ### Is it safe to let an AI pick its own next task? We delegate picking one card out of the startable ones. We do not delegate deciding that work is finished: completion happens after a person approves, and the AI only records it. When several cards are startable, the ordering is still ours. ### Do you have to write out every dependency? No. Anything without dependencies simply shows up as able to run in parallel. Write them only where order actually matters. We have the chat AI write them while it breaks the work down. ### Can a TODO.md do the same thing? It can hold the ordering. What it could not do was reflect a finished prerequisite on its own, and remove work one session took from the candidates another session sees. Doing both by hand does not keep up on a day with five sessions running. ## Related - Let the AI choose today's work from deadlines and decision load: https://dazbench.app/tips#pick-todays-work - Check only the work that's stalled: replies, payments, reviews: https://dazbench.app/tips#whats-stuck - Split the work between you and the AI, and do your share while the AI runs: https://dazbench.app/tips#split-human-and-ai - Status: https://dazbench.app/manual#words/status - What you can hand over: https://dazbench.app/manual#ai/can-do - How do you manage task dependencies between AI agents without holding the order in your head?: https://dazbench.app/docs/ai-agent-task-dependencies-without-a-human-in-the-loop - Why does running several Claude Code sessions in parallel get unmanageable?: https://dazbench.app/docs/why-parallel-claude-code-gets-unmanageable Updated: 2026-09-12 --- The latest version of this file is always at https://dazbench.app/docs/stop-telling-claude-code-whats-next.md. The version for humans to read is at https://dazbench.app/docs/stop-telling-claude-code-whats-next.