Loop Engineering in Claude

I'll pull the Claude loops post and the HN thread so the paragraphs stay factual and concrete.Anthropic’s Claude Code team published **Loop engineering: Getting started with loops**, a practical guide that treats agent design as loop design rather than one-shot prompting. The post defines a **loop** as an agent repeating cycles of work until a stop condition is met, and frames loop engineering as choosing how work is triggered, how it stops, which Claude Code primitive runs it, and which tasks fit each pattern. On Hacker News the item sat at **2 points** with **0 comments**, so early discussion is thin relative to the product guidance inside the post.

Technically, the team breaks loops into four patterns. A **turn-based loop** starts from a user prompt and ends when Claude judges the task complete or needs more context; quality improves when verification steps live in a **SKILL.md** so the agent can see, measure, and re-run checks instead of stopping after a successful edit. A **goal-based loop** uses **/goal** with an explicit success condition and turn cap—for example, raise homepage Lighthouse to 90 or above and stop after 5 tries—while an evaluator model pushes Claude back to work if it tries to exit early. **Time-based loops** use **/loop** for local interval runs (such as check a PR every 5 minutes) and **/schedule** to move the same idea into cloud routines. **Proactive loops** compose those primitives with **auto mode**, skills, and **dynamic workflows** so recurring streams—bug reports, triage, migrations, dependency upgrades—run without a human in the real-time loop.

For engineers, this is a shift from prompt craft to system craft. You are deciding what you hand off: the check (turn-based), the stop condition (goal-based), the trigger (time-based), or the entire prompt and routine (proactive). The post’s quality rules are operational, not motivational: keep the codebase patterned so Claude follows existing conventions, encode “done” in skills, put docs in reach, and run a second agent or **/code-review** so code-writing loops are paired with review loops. Failures should update the system for the next iteration, not just fix the one bad result.

Competitively, the piece sits inside Claude Code’s broader stack—skills, hooks, subagents, schedules, and dynamic workflows—rather than presenting loops as a standalone model feature. That positions Anthropic against other coding agents that still default to chat turns without named stop conditions, interval runners, or evaluator-checked goals. The market language is already moving from “better prompts” to “designed loops”; this post is Claude Code’s explicit taxonomy for that shift, including token controls via **/usage**, **/goal** turn and token views, and **/workflows** per-agent cost visibility.

Practical takeaway: start with the simplest loop that removes you as the bottleneck. If you already know the verification steps, put them in a skill and stay turn-based. If “done” is measurable, use **/goal** with a hard try cap. If the work is recurring or depends on external systems, use **/loop** or **/schedule** and match the interval to how often the signal actually changes. Before large proactive runs, pilot a small slice—dynamic workflows can spawn many agents—and prefer scripts for deterministic work so tokens go to judgment, not re-deriving fixed steps. Watch whether teams adopt named primitives (**/goal**, **/loop**, **/schedule**) in daily workflow, or whether loop engineering stays blog-level language without durable stop criteria and review loops in the repo.