How I Plan, Build, and Run Loops with Claude Code (Thariq Shihipar)

Source: raw/How_I_Plan_Build_and_Run_Loops_with_Claude_Code_in_40_Minutes_Thariq_Shihipar.md Creator: Thariq Shihipar (Anthropic, Claude Code team), interviewed by Peter Yang · URL: https://www.youtube.com/watch?v=aVO6E181cNU · Platform: YouTube

A ~40-minute first-party walkthrough from a Claude Code team member on how to design loops and workflows that get Claude to run long-horizon — with a live video-editing demo and a running thread on planning, verification, and context discipline. Where Anthropic’s own loop taxonomy lays out the four loop types formally, this is the same team’s operator-level “how I actually work” companion: which primitive to reach for, why, and the failure modes he sees people hit. The framing anchor: “As the models have gotten smarter, they need less direction, fewer constraints, and fewer examples.”

Key Takeaways

• Three primitives to run long-horizon: /loop, /goal, and workflows. All three exist to get the agent working for long periods in an orchestrated way; they differ in what you hand off and how the agent knows when to stop.
• /goal hands off the exit condition. It reminds the agent what its exit condition is and only lets it stop once that’s met — a “power through” signal. Best for a complicated task you need guaranteed done, where you’ve already done enough spec/exploration and want the agent to fill in complications itself rather than stop early to ask.
• Workflows are the most powerful form (Thariq’s words): they spin up subagents to do the work, parallelize it, and verify it. They turn a non-deterministic task into a roughly deterministic one — strongest for non-technical work.
• Verification should be done by a separate agent because of self-referential bias — a model prefers (and is more lenient toward) its own outputs. A workflow with a coordinator + per-task doers + a rubric-reading verifier gives cleaner, more-compute-per-item results than doing several tasks in one context.
• Pick the primitive by how verifiable the task is. A Figma design has a spec you can check (/goal make the rendered design match the Figma MCP) — easier than eyeballing a screenshot. A “squishy” target (a screenshot, a good short) needs a workflow with a rubric and a verification agent.
• Planning is “getting rid of your unknowns”, not a one-shot plan-then-do handoff. It’s iterative exploration — learning how a tool works, its edge cases, mockups, HTML artifacts to explore designs — and it de-risks the build before you commit to it.
• Trim your context. The Claude Code system prompt was cut ~80%; smarter models need fewer examples and constraints (examples can over-constrain). Give reasons and principles instead of hard “never” rules where you can. CLAUDE.md files and skills are “probably too long.”
• Claude Tag (Claude in Slack) is where the parallel work now happens. Explorations, PR specs, and background/multi-Claude work run in Claude Tag; the one thing he’s actively iterating on stays in Claude Code.

/loop, /goal, and workflows

The three primitives, as Thariq frames them:

Primitive	What it gives you	Reach for it when
/loop	Re-runs a prompt on an interval to keep the agent going	Recurring work, or work gated on something changing
/goal	Reminds the agent of its exit condition; blocks early stopping	A complex task that must be finished, where you trust it to fill gaps
Workflows	Subagents that do + parallelize + verify the work	Non-deterministic / “squishy” tasks; anything needing clean verification

/goal — hand off the exit condition

/goal is the signal to “power through.” Stepping into Claude’s shoes: when you hit a complication or something not quite up to spec, you might stop early and ask “should I keep going?” /goal is the user saying “I’ve done enough spec and exploration, I understand the problem space — go execute, and if you run into something, fill it in.” It’s strongest when there’s a deterministic signal to chase — e.g. latency, where /goal can let the agent explore optimizations in an “auto-research” way until the number moves.

The design example is the clearest: if your design lives in a Figma file, use the Figma MCP and /goal make sure the rendered design matches the Figma MCP — a spec the agent can verify directly. That’s far easier than verifying against a screenshot, which is “squishy” and pushes you toward a workflow with a rubric instead.

Workflows — do, parallelize, verify

Workflows spin up subagents to both do the work and verify it. The load-bearing reason to prefer a workflow over a single skill or a single agent doing everything:

• Context — subagents keep the main agent’s context clean.
• Laziness + verification — a rubric-reading verification agent reviews each output and gives feedback, which a single lazy pass won’t.
• Self-referential bias — Anthropic’s term for a model being more lenient when grading its own output. So you want a separate Claude verifying the work, and (in the coordinator pattern) a separate Claude coordinating it: the main agent coordinates, each subagent does one unit, then a verifier checks against the rubric. Different contexts mean less bias, and each unit gets maximum compute (less likely to stop early, more thinking) versus running two or three simultaneously in one context where any individual item gets less care.

Worked example — generating shorts. To make 5-10 shorts from a video: the main agent decides which regions of the clip to cut, the workflow spins off a subagent per short, you hand it a rubric for what a good clip looks like, and each subagent verifies its output against that rubric.

Turning a workflow into a reusable skill. You create a workflow just by asking (“create 10 clips here, use a workflow, here’s my rubric to verify a good clip”). A workflow is just a JS file — you can have Claude save that JS file into a skill, giving you a reusable, packaged skill + workflow.

The other named team example: Jared’s Bun rewrite in Rust used workflows (Thariq flags a fuller talk from Jared on it).

Planning is getting rid of your unknowns

Thariq pushes back on “planning” as a single plan-then-implement handoff. It’s an iterative process of exploring, investigating, and finding out what you don’t know or don’t want — and it “simplifies itself” by the end. It takes many shapes: learning, technical specs, mockups, exploration.

• Learn the tool’s edge cases first. Before building his video workflow he prompted Claude to explain whisper to me and understand the edge cases — surfacing that silence can transcribe as “thanks for watching,” a word can split across chunks, and there’s no speaker recognition. Knowing the limits up front avoids the unknown-unknowns that would otherwise blow up a complicated workflow mid-build.
• Explore designs with HTML artifacts. “Create an HTML artifact for exploring different designs for the overlays and captions,” with a reference (Peter’s website) the agent can fetch. Prototype cheaply in HTML before the expensive React version that forces a full video re-render — the smallest step that proves out the spec. (Artifacts are how Anthropic shares plans, PRs, status reports, and incident reports internally.)
• Spec ↔ implementation is a back-and-forth. Human request → agent technical exploration → mockups/explainers → refine → implement, with the agent keeping implementation notes as it goes so surprises during the build feed back into a re-spec. The plan is a living document, not a one-time artifact.
• Failure mode: the lazy button. The prompt box “can be a lazy button” — “just do the thing.” You pay for it later in time and cost. The fix is to actually read the plans and explainers Claude generates (he uses the front-end design plugin to make them readable), not glaze over them.

The demo it all served: one prompt — “transcribe [the sample video] using whisper, then use Remotion to create a UI that shows the transcript with each word highlighted and different overlays, and /goal don’t stop until the video is fully rendered” — one-shot produced captions, an overlay, and a fade-to-black.

Trim the context

A recurring discipline: smarter models need less scaffolding. The Claude Code system prompt was cut by ~80% because the model no longer needs five examples of the batch tool and a list of “never do this in these cases.” Examples can actively over-constrain (“you want things like this example”), and a hard “never” usually means “most of the time, don’t” — giving the reason you don’t want something is more effective than the blanket constraint. Practical fallout: CLAUDE.md files and many skills are “probably too long”; trim them. (MCP context cost depends on the server, and tool search helps.) The Twitter-post example: rather than “280 chars, don’t do X,” give Claude context about you and your principles, keep the genuinely-needed constraint (280 chars), but leave room — “I’d prefer one tweet, but a two-tweet thread is OK” — so it can find something good.

Claude Tag — where parallel work happens

Claude Tag (Claude in Slack) has absorbed the “multi-Claude-ing.” Background work — initial explorations, PR specs, understanding something — happens in Claude Tag; the one thing he’s actively iterating on stays in Claude Code (back-and-forth, local). Each Claude Tag channel/agent has its own memory and identity and is proactive — Thariq frames it as an evolution of Claude Code, not a coworker metaphor to take literally. A representative pattern: “babysit this PR, fix the tests, then tag a reviewer,” and the human reviewer gets tagged in the same Slack channel to collaborate. His mental model: Slack is becoming the multiplayer Claude surface because that’s where the team already is.

Try It

1. Match the primitive to verifiability. If your target has a checkable spec (a Figma file, a test count, a latency number), use /goal against that spec. If it’s squishy (a screenshot, “a good short”), build a workflow with a written rubric and a separate verification agent.
2. Write the rubric before the workflow. The verifier is only as good as the rubric it reads — draft “what does a good output look like” first, then ask Claude to “use a workflow” against it.
3. Explore your unknowns before building. Ask Claude to explain the tool/library you’re about to depend on and enumerate its edge cases; read the explainer. Use an HTML artifact to explore design options cheaply before committing to the expensive build.
4. Keep implementation notes. Ask the agent to log surprises as it implements, so you can re-spec instead of discovering the gap at the end.
5. Trim. Audit your CLAUDE.md and skills for over-long example lists and blanket “never” rules; replace constraints with reasons and principles where you can.
6. Move background work to Claude Tag, keep one focused iteration loop in Claude Code.

Related

• Getting Started with Loops (Anthropic’s Official Framework) — the same team’s formal four-loop taxonomy; this talk is its operator-level companion on which primitive to reach for and why.
• Verifier-First Loops — the verification discipline this talk operationalizes; “self-referential bias” is the concrete reason to split maker and checker.
• The Loop Is the Unit of Work — the synthesis this fits into: designing the loop (and its verification) rather than perfecting a single prompt.
• Dynamic Workflows — the subagent-fan-out-plus-judge mechanism behind the “workflow” primitive Thariq calls the most powerful form.
• Claude Tag — Claude in Slack, where Thariq runs his parallel/background work.
• goal` Walkthrough — the hands-on mechanics of the /goal primitive this talk leans on.
• LOOPS — Everything You Need to Know (Berman) — the trigger x goal catalog; a third-party mapping of the same primitives.
• Harness Design for Long-Running Agents — Anthropic’s deeper treatment of running agents long-horizon, the goal this talk’s methodology serves.

Open Questions

• Thariq’s “workflows are just a JS file you can save into a skill” describes the packaging path but not the file format/API in detail — the mechanics live in Dynamic Workflows and are worth cross-checking against the current Claude Code release.^[inferred: the talk states the packaging path but not the schema]
• Artifacts for sharing plans/reports were “currently teams and enterprise, hopefully coming to Max and Pro” as of recording — availability may have since changed.