🧮 Loops × Queues

In July, the engineer Geoffrey Huntley published an article (14/jul) that went viral in the community: the Ralph loop. The idea is delightfully simple — you write a loop while in bash that calls the Claude Code passing the same prompt again and again. The agent finishes one pass, the loop restarts, and it receives the instruction again. It runs like this, in AFK, without you at the keyboard.

The name "Ralph" is an inside joke (a reference to the character Ralph Wiggum from The Simpsons, who does simple things without thinking too much) — and part of the fun is precisely that: brutally simple, yet effective. Why does it work? Because each new agent run starts with fresh context and rereads the state of the codebase and takes it one step further. It’s the rawest way to take you out of the equation. The common mistake here is thinking “loop = autonomous magic”: the loop only repeats; the agent still does the work, and it depends on the prompt and the harness behind it.

Here comes Pocock's position—and it's an important turning point. He recognizes that the Ralph loop is ingenious, but says in no uncertain terms: "I don't need to run it as a loop — I just need the AFK agent to pick up a specific task and do it." In other words, what really unlocks it isn’t the infinite repetition; é o AFK (the agent working without you present). The loop is just one way—and not the best—to achieve that.

Why? Because a single loop that tries to “do everything” doesn’t match how real teams work. A team doesn’t have a robot spinning forever; it has a backlog clear tasks, each with a beginning, middle, and end. Blind repetition wastes tokens, loses focus, and makes it harder to say “this is done.” According to Pocock, the right answer is to change the verb: instead of "loop", think about "pick up the next task from the queue". Same autonomy, much more control and clarity. A common mistake is confusing “running on its own” (good: AFK) with “running in circles” (rarely what you want).

Pocock’s central point is: "I think of this mainly as queues, not loops." A queue is simply your backlog tasks. And he gives the concrete example of Sand Castle (his tool): it looks at issues, triages it (is it trivial? is it possible?), adds the label agent:implement and the agent implements it via GitHub Actions (covered in module 4.3).

And then comes the definition that organizes everything: "all development is just a" task queue: PMs add tasks to the queue; you complete them; multiple nodes (devs) pick items from the queue." Notice how this describes any software team in the world — without any AI involved. The PM feeds the queue, developers consume. Pocock’s insight is that the “nodes” can now be agents instead of (or alongside) humans. You don’t change the team’s mental model—you just change who picks up the items. That’s why the queue fits naturally, and the one loop that “does everything” doesn’t match how teams work.

Before an item becomes work, it goes through triage. In the Sand Castle workflow, Pocock looks at each issue and answers two questions: is it trivial? e is it possible? — and this can already be done in AFK. There’s a real issue (#795 in his example) that keeps changing its label: agent:explore → agent:in-progress, while the bot github-actions post a comment of "Triage" with a TL;DR and an estimate of Difficulty (difficulty).

Why does this matter? Because triage gives you scope — and scope is what separates a “pick-up-able” task from a vague request. When the agent gets “implement issue #795, medium difficulty, TL;DR: such-and-such,” it has a clear target. Compare that with “fix the bugs” tossed into a loop: there’s no place to start and no way to know when it’s done. Triage also filters out what no should go to the agent alone (things that require human judgment). The common mistake is to skip triage and dump everything raw into the queue — then the agent works hard on the wrong item or stumbles on an impossible one.

David (the interviewer) offered an analogy that crystallizes the difference between a loop and a queue: the medieval king. Think of a minister in a distant region running in a loop on its own—it can go well, or it can go very wrong, and the king only finds out once the damage is done. That's the "loop" approach: blind autonomy, with no central prioritization. The sensible king doesn't want that.

The king wants the queue-based approach: the problems reach him (an invasion, a hunger, a proposal for brand deal — where it checks reputation first before accepting), and it prioritizes. Out of 50 bugs that come in, maybe only 3 are critical — and it decides which ones to tackle now. The point, in the conversation’s words: you keep in the command. The queue doesn't take away your decision-making power; it focuses it on what matters. The loop hands the kingdom to a distant minister; the queue keeps the crown on your head. Common mistake: delegating autonomy without keep the prioritization point — then you become an absent king, and the kingdom does whatever it wants.

Wrapping up the module: the biggest advantage of thinking in terms of a queue is that it scales with multiple nodes. Remember Pocock’s line: "multiple nodes (devs) pick up items from the queue." Each node could be you, a colleague, or an agent running in GitHub Actions (module 4.3). Since each task has a clear scope (thanks to triage), two or three agents can work in parallel on different tasks without getting in each other’s way—exactly what you saw in module 4.2 about parallelizing with sandboxes. The single loop doesn’t scale that way: it’s just one worker, spinning. The queue is an architecture—it makes room for “two, three, four of you,” as Pocock describes AFK. Use the skeleton below to try the Ralph loop and experience for yourself why, in the end, you’ll want to move from it to a queue with triage:

#!/usr/bin/env bash
# Ralph loop (Geoffrey Huntley, 14/jul) — o esqueleto cru:
# um while que chama o Claude Code com o MESMO prompt, de novo e de novo.

PROMPT="Pegue a próxima tarefa pendente em TODO.md, implemente-a,
rode os testes e marque-a como feita. Se TODO.md estiver vazio, escreva DONE.txt."

while true; do
  # injeta o mesmo prompt no agente, em modo AFK (sem você no teclado)
  claude code -p "$PROMPT"

  # condição de parada: o agente sinaliza que a fila esvaziou
  if [ -f DONE.txt ]; then
    echo "Fila vazia — encerrando o loop."
    break
  fi

  sleep 2   # respiro entre as passadas
done

# Lição do módulo: isto FUNCIONA, mas é um loop cego (1 nó, foco difuso).
# Prefira virar isto numa FILA: triagem -> label agent:implement ->
# vários nós (agentes em GitHub Actions) puxam itens em paralelo. Você, o rei, prioriza.