From Manual Prompts to Self‑Driving AI Loops: Build Your First Loop System in 14 Steps

Layer 1 – Why & Whether to Build a Loop

Loop Engineering replaces manual prompting

Traditional AI‑coding workflow:

write prompt → paste context → view result → write next prompt

. Loop Engineering builds a small system that (1) identifies work, (2) hands it to an agent, (3) checks results, (4) records actions, and (5) decides the next step, so the developer designs the flow once and the system repeats it.

Four‑condition test

Task repeats – occurs at least weekly. If unmet, setup cost cannot be recouped.

Verification can be automated – tests, type‑check, build, lint can objectively judge correctness. If unmet, the developer still reads every diff, making the loop wasteful.

Token budget tolerates waste – retries and context rereads burn tokens. If unmet, the bill arrives before any benefit.

Agent has advanced‑engineer tools – can run code, read logs, reproduce issues. If unmet, the loop iterates blindly.

Conclusion: Loop Engineering is real, but most developers do not need it yet.

Who benefits and who should skip

Beneficial : teams with repeatable, machine‑verifiable work (e.g., CI‑failure classification, dependency upgrades, lint‑auto‑fix, Issue→PR drafts) and strong test suites.

Skip : solo developers on cheap plans, code without automated verification, tasks where review is the bottleneck, one‑off or exploratory work.

30‑second checklist

Task repeats at least weekly.

Automated tests/type‑check/build/lint reject bad output.

Agent can execute the generated code.

Loop has a hard stop (token limit, iteration count, or time limit).

Human review before merge/deploy.

If any item is missing, continue using manual prompts.

Layer 2 – Five Core Components

Automations (the heartbeat)

Triggered by schedule, event, or condition. Examples: Codex “Automations” tab, Claude Code /loop command, desktop cron jobs, cloud routines.

Two primitive commands: /loop 30m – run a round every 30 minutes regardless of state. /goal <condition> – stop only when an objective condition, verified by an independent checker, is satisfied.

Worktrees (parallelism without clashes)

Use git worktree to give each agent an independent working directory and branch, preventing file collisions while keeping the repository clean.

Skills (project knowledge written once, read every run)

A SKILL.md folder stores project conventions, build steps, and classification rules. Example snippet:

## Classification rules
- env: missing key or bad env → manual
- flake: retry passes → archive
- bug: deterministic failure tied to recent commit → draft fix
- dependency: version upgrade → draft rollback
- infra: timeout, OOM → hand to human

## Prohibited
- never disable failing tests
- never change CI config without approval
- never touch payments/billing

Connectors (real‑world tool integration via MCP)

Connectors let the loop read/write GitHub, Linear/Jira, Slack, Sentry, etc. The highest ROI order is:

GitHub – read repo, create branches, open PRs, respond to webhooks.

Linear / Jira – update tickets, link PRs.

Slack – push triage results, @‑notify during upgrades.

Sentry – investigate alerts, draft high‑frequency fixes.

Sub‑agents (separate writer and verifier)

Separate agents for code generation and code verification reduce self‑bias. The article cites Anthropic’s December 2024 “Evaluator‑Optimizer” pattern (later renamed in the community). Typical division:

Exploration agent.

Implementation agent.

Spec‑compliant verification agent.

The verifier must be independent; otherwise the loop may exit on a half‑finished result.

State + Gate

State files (Markdown, JSON, or issue trackers) record progress; Gates enforce objective test/build/lint outcomes before advancing.

Layer 3 – Do It Right or Skip

State file importance

Agents forget; repositories do not. Store progress in harness/state/<task_id>.json or markdown files. Two storage options:

Repository‑internal Markdown/JSON – suitable for individuals or small teams, diffable and version‑controlled.

Linear / GitHub Issues / database – suitable for cross‑repo, multi‑person production loops.

High‑level specs ( VISION.md , AGENTS.md ) guide the loop’s direction.

Minimal Viable Loop (MVL)

Four pieces, exactly:

One automation – a scheduled or triggered run with a clear stop condition.

One skill – a SKILL.md containing project context.

One state file – records progress and enables resume.

One gate – objective test/type‑check/build that decides pass/fail.

Order matters:

Run a reliable manual iteration → solidify into Skill → package into Loop → schedule.

Ralph Wiggum Loop (quiet‑failure pattern)

Failure mode where the agent signals completion too early, leaving a half‑finished change in the repo. Three typical causes:

No real verifier – the second agent only “looks” and both agents agree optimistically.

Soft completion condition – “looks good” instead of passing tests/build.

No hard stop – loop runs until rate‑limit or bill shock.

Fix by adding a proper gate that checks tests, build, and lint results (e.g., gate_status=PASS ).

Comprehension debt & Cognitive surrender

Fast loops generate code developers never read, widening the gap between repository state and developer understanding (comprehension debt). Cognitive surrender occurs when developers stop forming their own judgment and accept whatever the loop produces. Mitigations:

Read diffs – avoid renting comprehension debt.

Audit gates – sample PRs produced by the loop to ensure tests capture real failure modes.

Prohibit loops from touching architecture – keep changes small and machine‑verifiable.

Co‑design loops with teammates – a second pair of eyes catches blind spots.

Security tax (expanded attack surface)

Unreviewed generated code merges – no SAST, dependency audit, or secret scan in the gate.

Skill as injection vector – community‑provided skills may carry prompt‑injection payloads.

Secrets in logs – long loops scatter credentials in debug output.

Permission creep – temporary write permissions added for testing and never audited.

Mitigation: forbid secrets in AGENTS.md , ensure state files and release gates check for token/secret leaks.

Conclusion

The leverage point shifts from crafting better prompts to deciding what agents do, when they do it, and how gates and state keep the loop safe. Most developers still do not need a loop until tasks are repeatable, verifiable, token‑budget‑friendly, and agents have advanced tooling. Start small: one automation, one skill, one state file, one gate, and follow the strict order (manual run → skill → loop → schedule).