From Manual AI Chores to Self‑Driving Loops: Six Core Components and a Five‑Step Guide

Loop Engineering Definition

Loop Engineering replaces the manual “push” model (write a prompt → wait → read result → write next prompt) with an autonomous system that continuously discovers tasks, dispatches them to appropriate agents, verifies results, persists state, and decides the next step until a goal is reached.

Five Atomic Actions

Discover : Detect work from external signals (GitHub Issues, Slack messages, email alerts), scheduled scans (CI failures, dependency alerts), or goal‑driven conditions.

Dispatch : Choose a Skill based on task type, select model strength according to difficulty, and optionally assign a verifier for risky tasks.

Verify : Apply multi‑level checks – L0 deterministic (build succeeds, tests pass), L1 structural (lint, type check, formatting), L2 functional (behavioural tests), L3 quality (code review, coverage, performance).

Persist : Write execution results, progress, and error logs to durable storage such as progress.md, skill-state.json, or external systems (Linear tickets, GitHub Issues).

Schedule : Decide the next action – close an issue, retry with a different strategy, wait for human input, or start a new loop.

Six Core Components

Automations (Heartbeat) : Define when the loop runs. Three trigger modes are compared:

Schedule – fixed intervals (e.g., daily at 9 am). Simple, reliable, but may miss real‑time events.

Event‑driven – external events (new Issue, CI failure). Immediate response, requires event source support.

Goal‑driven – run until a condition is satisfied (e.g., “all tests pass”). Self‑terminating, but needs safeguards against infinite loops.

低风险监控任务 → 定时触发（每周/每天）
高风险响应任务 → 事件驱动 + 人工审批
自动修复任务 → 目标驱动 + 最大轮数限制

Worktrees (Isolation) : Each agent works in its own Git worktree, sharing repository history but preventing file‑level conflicts. Parallelism is limited by review bandwidth.

Skills (Persistent Knowledge Packages) : Encode repeatable procedures and intent debt. Example contrast:

❌ 参考文档："测试应该覆盖边界情况"
✅ Skill：
1. 写一个会失败的测试
2. 运行看到失败
3. 编写最小代码让测试通过
4. 重构代码

Skills are stored on disk and loaded on demand, eliminating “agent forgets” problems.

Plugins & Connectors : Bridge the loop to real tools via the Model Context Protocol (MCP). Example connector configuration for GitHub:

{
  "mcpServers": {
    "github": {
      "command": "github-mcp-server",
      "args": ["--token", "${GITHUB_TOKEN}"]
    }
  }
}

Connectors enable reading issues, opening PRs, posting to Slack, updating Linear tickets, etc.

Sub‑Agents (Implementer & Verifier) : Inspired by GAN architecture, the implementer generates code while an independent verifier checks quality. This separation avoids bias, blind‑spot sharing, and over‑confidence. Token cost warning: each sub‑agent incurs separate model inference.

Memory (External State) : Persistent files (Markdown, JSON) or external systems record what has been done, what failed, and what remains. “Agent forgets, repository doesn’t.”

Loop vs. Workflow

Workflows are linear (A→B→C) with static branching and no memory. Loops form a feedback‑driven circle (discover→dispatch→verify→persist→schedule) that dynamically decides the next step and retains state.

When to Use a Loop

Task repeats at least weekly (economies of scale).

Verification can be automated (tests, lint, type checks).

Token budget is sufficient for repeated context loading.

Agents have access to required tooling (logs, build systems, APIs).

Suitable Scenarios

CI failure triage.

Dependency‑upgrade PRs.

Lint‑fix automation.

Issue‑to‑PR draft generation.

Documentation sync.

Test‑coverage gap filling.

Unsuitable Scenarios

Architectural rewrites requiring deep design decisions.

Core security or payment code (high risk).

Production deployments that need manual approval.

Subjective design work.

Tasks that depend heavily on human coordination.

Industry Case Studies

Anthropic – /loop plugin : Every hour pulls new Issues, lets Claude fix bugs, run tests, and submit PRs. After five failed attempts the loop exits with a diagnostic report.

OpenAI Codex – /goal mode : A small independent model checks “all tests pass & lint clean” after each iteration; the implementer never decides completion.

Andrej Karpathy – AutoResearch verifier loop : 700 autonomous experiments yielded an 11 % efficiency gain by automatically scoring and feeding back each run.

Stripe – Minions architecture : Hundreds of tiny agents process ~1300 PRs/week. Each PR goes through layered verification (automated tests, type checks, human review) and risk‑based routing (low‑risk auto‑merge, high‑risk manual approval).

发现：自动扫描代码库中的可优化点
交付：分配给对应的 Minion Agent
验证：自动化测试 + 独立 Verifier Agent
持久化：状态写入 Linear 工单系统
调度：根据风险等级决定自动合并或人工审批

Three Major Risks & Mitigations

Verification Debt : “Loop says completed” may hide errors. Mitigate by keeping mandatory human review and using an independent verifier sub‑agent.

Comprehension Debt : Rapid AI output widens the gap in developer understanding. Mitigate by regularly reading generated code and maintaining architectural awareness.

Cognitive Surrender : Success can lull engineers into blind trust. Mitigate by periodically reviewing loop design, asking whether you could fix the loop if it broke, and keeping the engineer’s judgment active.

Five‑Step Practical Guide

Start with a tiny scheduled task. Example daily CI status check:

# 每天早晨检查 CI 状态
automation:
  schedule: "0 9 * * *"
  task: "检查昨天 CI 失败记录"
  output: "ci-daily-report.md"

Create the first Skill that codifies a repeatable procedure. Example skill file:

<!-- SKILL.md -->
# 项目构建与测试

## 触发条件
需要构建或测试项目时激活。

## 核心流程
1. 运行 `npm run build`
2. 运行 `npm test`
3. 检查 lint 是否通过
4. 失败时读取错误日志并修复

## 项目约定
- TypeScript 严格模式
- 公共 API 必须有文档注释
- 测试覆盖率 ≥ 80%

Configure a verifier Sub‑Agent to separate implementation from checking:

# .claude/agents/verifier.toml
name = "verifier"
description = "验证代码质量和测试通过情况"
model = "strong-model"
instructions = "严格检查：代码质量、测试覆盖率、文档完整性、边界情况处理"

Connect a real tool (e.g., GitHub) so the loop can open issues, read PRs, and update status. Example MCP server config shown above.

Monitor and iterate weekly: track token consumption, output quality, automation frequency, and skill freshness; adjust schedule or add components as needed.

Key Metrics

Daily token consumption < 100 K (warning > 500 K).

Human review time < 30 min (warning > 2 h).

Loop success rate > 80 % (warning < 50 %).

Skill update frequency weekly (warning monthly).

Core Principles

Process over documentation : Executable workflows beat static manuals.

Verification is non‑negotiable : Every Skill must end with concrete evidence (tests, builds, runtime checks).

Progressive loading : Load only the Skills relevant to the current stage to conserve tokens.

Scope discipline : Modify only what is required; avoid sweeping refactors without full understanding.

Stay an engineer : Design loops that augment, not replace, engineering judgment.