Loop Engineering in Practice: Automating Eight Kuiniu Features with a Single /loop-it Command

Loop Engineering Overview

I don't talk to an agent anymore, I talk to a loop or a routine. — Boris Cherny

Loop Engineering shifts the engineer’s role from prompting coding agents to writing loops that orchestrate agents. Peter Steinberger’s tweet (June 7) warned against prompting agents directly, and Boris Cherny (WorkOS talk, June 2) described using a set of loops to drive Claude Code, which now writes nearly 4 % of public GitHub commits. Simon Willison reported that in the prior 30 days all code submitted to Claude Code was generated by Claude Code itself, merging 259 PRs.

Evolution Stages

ReAct Loop (2022) – academic while‑loop, one model per loop, driven by human supervision.

AutoGPT (2023) – goal‑driven self‑prompting, driven by autonomous agents.

Ralph Loop (2025) – bash one‑liner that resets context to a fixed anchor file each iteration; assumes the terminal stays open.

/goal productization (Spring 2026) – small model validates a stop condition; launched once by a human.

Orchestration Loop (2026 now) – loops supervise other loops, with scheduling, persistence, and state stored in Git; assumes the terminal may be closed.

The earliest Ralph Loop, released by Geoffrey Huntley in July 2025, cost $297 to build a complete programming language and introduced the discipline of resetting context to a fixed anchor file.

In 2026 Codex and Claude Code embed a /goal command that runs until a separate verifier model confirms completion, providing the first split verifier where the coding agent does not grade its own work.

Goal‑workflow and the loop-it Skill

Installation: npx skills add smallnest/goal-workflow Pipeline:

/prd → /prd-to-spec (optional) → /to-issues → /loop-it (→ /goal → /review-it → /note-it → /ship-it)×N

Manual steps: /prd – discuss the product‑requirements document (PRD) with Claude and generate a PRD file. /prd-to-spec – optional conversion of the PRD to a technical design. /to-issues – split the PRD/SPEC into GitHub issues, each with acceptance criteria, dependencies, type, and priority, then push to the repository.

Automated loop ( /loop-it) processes each issue through four stages:

/goal      ← implementation
/review-it ← self‑code review
/note-it   ← record design decisions
/ship-it   ← commit, PR, merge, close issue

State persistence is achieved with a JSON file written to disk after every checkpoint. Example .loop-state.json:

{
  "version":1,
  "repo":"baidu/nettools",
  "total_issues":8,
  "issues":{
    "23":{"status":"shipped","branch":"feat/issue-23-config","attempts":1},
    "24":{"status":"shipped","branch":"feat/issue-24-codec","attempts":1},
    "25":{"status":"in_progress","phase":"review","attempts":1}
  }
}

If the loop crashes, rerunning /loop-it reads the state file, skips already shipped issues, and resumes from the last checkpoint.

Issues are processed in topological order based on declared dependencies, not numeric order. Example output:

📋 Found 8 open issues (topological sort):
 #23: create config format & GPU topology check (no deps)
 #24: implement codec extension (depends #23)
 #25: implement Sender/Receiver & UDP (depends #23, #24)
 #26: client same‑card detection (depends #23, #24, #25)
 #27: server GPU receive + CPU reply (depends #23, #24, #25)
 #28: bitflip detection (depends #25)
 #29: packet‑loss & latency stats (depends #25)
 #30: CLI entry & build integration (depends #23‑#29)

After implementation, a split verifier runs via /review-it in a clean context. A second agent reviews the spec and tests, allowing up to two iterations before proceeding to /ship-it. This matches Boris Cherny’s statement that a loop’s trustworthiness depends on its ability to check its own work.

Error recovery is encoded with fixed limits per category:

build_failure – compile or type error; read error, fix code, rebuild; limit 3.

test_failure – assertion failure; read output, fix implementation, retest; limit 3.

lint_failure – lint errors; lint --fix, then lint again; limit 2.

merge_conflict – CONFLICT marker; rebase main, resolve, push; limit 2.

ci_failure – gh pr checks failed; read CI logs, fix locally, push; limit 2.

rate_limit – secondary abuse; wait 60 s; limit 3.

unknown – other; mark failed, skip; limit 0.

Fatal errors mark the issue as failed, keep the branch for inspection, write a checkpoint, and move on.

Each step records a checkpoint state transition:

pending → in_progress → goal_done → review_done → note_done → shipped

This persistent checkpointing enables recovery after power loss, a capability missing from the original Ralph Loop.

Case Study: One‑Hour Implementation of Eight kuiniu Features

Repository: https://github.com/baidu/nettools (nettools) – the open‑source suite that includes bitflip, baize, and lidar. The next open‑source project, kuiniu, probes packet loss and latency on GPUs (8 cards per GPU, 8 IPs each) by sending packets from GPU and receiving on CPU.

Step 1 – PRD (≈30 min): /prd kuiniu Requirements captured:

Same‑card detection (card i probes card i).

Asymmetric path: GPU sends, CPU receives.

Payload carries source and destination IP/Port.

Focus on packet‑loss rate and latency.

Reuse existing codec/bitflip detection from baize.

Claude generated tasks/prd-kuiniu.md.

Step 2 – Split into issues (≈5 min): /to-issues Created eight issues:

#23 kuiniu: create config format & GPU topology check
#24 kuiniu: implement codec extension – payload carries src/dst IP & port
#25 kuiniu: implement Sender/Receiver interface & UDP
#26 kuiniu: client same‑card detection logic
#27 kuiniu: server GPU receive + CPU reply
#28 kuiniu: bitflip detection
#29 kuiniu: packet‑loss & latency stats
#30 kuiniu: CLI entry & build integration

Each issue includes acceptance criteria, dependencies, type, and priority, then pushed to the GitHub repository.

Step 3 – Run the loop: /loop-it The author stepped away while the loop executed.

One‑hour checkpoint output:

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
📊 Loop Complete — Summary
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
✅ Shipped: 8 issues (#23‑#30)
⏭️ Skipped: 0 issues
🔒 Blocked: 0 issues
❌ Failed: 0 issues
📋 Total: 8 issues
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

All eight issues were closed and merged. The loop performed the sequence /goal → /review-it → /note-it → /ship-it 32 times, resulting in roughly 60 agent turns because the review stage required two extra iterations on issues #25 and #27.

No manual prompts were issued after the initial /loop-it. The author later inspected the PR list and review notes to confirm design decisions.

Key insight: the difficulty lies not in the loop itself but in the component that can say “no.” Without a genuine self‑check, a loop merely repeats self‑approval.

Practical guidance (derived from the case): tasks with well‑defined CI pipelines—such as CI triage, dependency upgrades, lint‑fixes, and fully covered issue‑to‑PR flows—are good loop candidates; large‑scale architecture rewrites, authentication/payment systems, and production deployments are better left to manual work.

Project links:

goal‑workflow: https://github.com/smallnest/goal-workflow

kuiniu (loop‑it product): https://github.com/baidu/nettools/issues?q=is%3Aissue%20state%3Aclosed

Addy Osmani original article: https://addyosmani.com/blog/loop-engineering/

Matt Van Horn long read: https://x.com/mvanhorn/article/2063865685558903149