Listen to this Post
Introduction:
The AI community has been rocked by a paradigm shift that renders traditional prompt engineering obsolete. Boris Cherny, the head of Claude Code at Anthropic, alongside Google’s Addy Osmani and Peter Steinberger, has unveiled an 11‑page manifesto on “Loop Engineering” — a framework where developers no longer prompt agents manually but instead design autonomous systems that prompt agents on their behalf. This marks the transition from linear, prompt‑by‑prompt interaction to closed‑loop, self‑improving agentic workflows that discover work, isolate environments, verify outputs, persist state, and run on schedules. The core thesis: stop being the person who prompts the agent; design the system that does it for you.
Learning Objectives:
- Understand the fundamental shift from prompt engineering to loop engineering and the architecture of autonomous agent loops.
- Master the five core moves of a loop — Discover, Isolate, Verify, Persist, and Schedule — and implement them using real‑world tools.
- Learn to design, audit, and deploy production‑ready agentic loops with safety guardrails, cost controls, and verification layers that sit outside the loop.
You Should Know:
1. The Five Moves of an Autonomous Loop
The 11‑page Anthropic guide distills loop engineering into five essential phases that every autonomous agent system must implement:
- Discover – The loop actively finds its own work: failing CI jobs, open issues, unmerged PRs, or scheduled maintenance tasks. Instead of waiting for a human to assign work, the agent scans repositories, monitors events, and identifies actionable items.
- Isolate – To prevent collisions and ensure reproducibility, each loop execution spins up a separate git worktree or containerized environment. This isolation guarantees that concurrent runs do not interfere and that each cycle starts from a clean state.
- Verify – A second agent reviews the work produced by the primary agent. The cardinal rule: never let agents self‑grade. Verification must be performed by a separate model or deterministic tools (e.g., test suites, linters) to avoid confirmation bias and hallucinated approvals.
- Persist – State is written to disk, not held in temporary context windows. By persisting checkpoints, logs, and intermediate outputs, the loop can resume after interruptions, maintain a historical record, and provide auditable traces of every decision.
- Schedule – Loops run automatically on a timer (cron, launchd, or a scheduler daemon) or in response to webhooks. This transforms agents from reactive tools into proactive background workers that operate 24/7.
2. Building Your First Loop: A Step‑by‑Step Implementation
Let’s build a production‑grade loop that monitors a repository for failing CI, attempts a fix, and opens a PR only after verification.
Prerequisites:
- Linux/macOS with
bash,git,jq, `curl`
– Claude Code CLI (claude -p) authenticated - GitHub CLI (
gh) authenticated
Step 1: Define the Loop Configuration
Create a `config.yaml` that specifies the repository, schedule, and verification rules:
repository: "https://github.com/your-org/your-repo" schedule: "/15 " every 15 minutes worktree_root: "/tmp/loop-worktrees" verifier_model: "claude-3-opus" separate model from the primary agent primary_skill: "fix-ci-failures" stop_conditions: max_attempts: 3 max_tokens: 100000 budget_usd: 0.50
Step 2: Implement the Orchestrator Script
The orchestrator handles the full loop lifecycle:
!/bin/bash
orchestrator.sh - main loop controller
WORKTREE_ROOT="${LOOP_WORKTREE_ROOT:-/tmp/loop-worktrees}"
REPO="$1"
TIMESTAMP=$(date +%s)
WORKTREE="${WORKTREE_ROOT}/run-${TIMESTAMP}"
<ol>
<li>DISCOVER - check if CI is failing
git clone --depth 1 "$REPO" "$WORKTREE" || exit 1
cd "$WORKTREE" || exit 1
if ! gh run list --status failure --limit 1 | grep -q "failure"; then
echo "No failing CI runs; skipping."
rm -rf "$WORKTREE"
exit 0
fi</p></li>
<li><p>ISOLATE - work in a separate worktree (already done)</p></li>
<li><p>EXECUTE - primary agent attempts a fix
claude -p "Fix the failing CI in this repository. Output only the diff." \
--allowedTools Read,Write,Bash \
--max-tokens 4000 > /tmp/fix.diff</p></li>
<li><p>VERIFY - second agent reviews the fix
VERIFIED=$(claude -p "Review this diff. Does it correctly address the CI failure? Answer YES or NO only." < /tmp/fix.diff)
if [[ "$VERIFIED" != "YES" ]]; then
echo "Verification failed; aborting."
rm -rf "$WORKTREE"
exit 1
fi</p></li>
<li><p>PERSIST - write the verified fix to disk
cp /tmp/fix.diff "$WORKTREE/verified-fix.diff"</p></li>
<li><p>SHIP - open a PR
git apply verified-fix.diff
git add .
git commit -m "Auto-fix: CI failure resolved by loop $(date)"
git push origin head:fix/ci-auto-${TIMESTAMP}
gh pr create --title "Auto-fix CI" --body "Generated by loop harness."</p></li>
<li><p>CLEANUP
rm -rf "$WORKTREE"
Step 3: Schedule the Loop
Add to crontab (Linux/macOS):
Run orchestrator every 15 minutes /15 /path/to/orchestrator.sh https://github.com/your-org/your-repo >> /var/log/loop.log 2>&1
For production, use `loop-harness` which provides a built‑in daemon, dashboard, and retry logic.
- The Verification Layer Must Sit Outside the Loop
A critical insight from Boris Paskalev (5x founder, ex‑DeepCode) is that a loop can pass tests, receive an approving review, and leave clean artifacts while still missing the actual customer problem. The final verification layer must be external:
- Did the patch merge unchanged? Monitor whether the PR was merged as‑is or required human rewrites.
- Did the production signal disappear? Check metrics, logs, and error rates after deployment.
- Did engineers reopen or rewrite it? Track reopens and follow‑up commits — they indicate the loop’s “fix” was insufficient.
- Did a regression appear later? Use time‑shifted analysis to detect issues that manifest hours or days after the loop’s intervention.
This external validation transforms a self‑checking loop into a genuinely self‑improving system.
4. Tooling and Frameworks for Loop Engineering
The community has rapidly built open‑source tooling to implement these patterns:
- Loop‑Harness – A bash‑based scheduler that spins up git worktrees, runs a primary agent, verifies with a second Claude session, and ships outputs (PRs, comments, Slack).
- Loopy – A meta‑agent that watches your terminal sessions, spots repetitive patterns, and auto‑generates loop definitions for you. Early users report discovering 3‑5 automatable patterns per month they would never have spotted manually.
- OpenLoop – A Python toolkit that provides monitored feedback loops with heartbeats, baselines, guardrails, and auditable stop conditions.
- Loop‑Engineering Skill – A Claude Code skill that distills 12 sources into seven load‑bearing principles, raising pass rates from 87% to 100% on tricky cases.
- Loop‑Audit / Loop‑Init / Loop‑Cost – CLI tools to score your loop’s readiness, scaffold new loops, and estimate token spend.
5. Linux and Windows Commands for Loop Management
Linux (systemd service for persistent loops):
Create a systemd service file sudo nano /etc/systemd/system/loop-harness.service
[bash] Description=Loop Harness Daemon After=network.target [bash] ExecStart=/path/to/orchestrator.sh start Restart=always User=youruser Environment="GITHUB_TOKEN=your_token" [bash] WantedBy=multi-user.target
sudo systemctl enable loop-harness.service sudo systemctl start loop-harness.service sudo systemctl status loop-harness.service
Windows (Task Scheduler + PowerShell):
Create a scheduled task that runs every 30 minutes $action = New-ScheduledTaskAction -Execute "powershell.exe" -Argument "-File C:\loop\orchestrator.ps1" $trigger = New-ScheduledTaskTrigger -Daily -At 00:00 -RepetitionInterval (New-TimeSpan -Minutes 30) Register-ScheduledTask -TaskName "LoopHarness" -Action $action -Trigger $trigger -User "youruser" -Password "yourpass"
Monitoring loops with `journalctl` (Linux):
journalctl -u loop-harness.service -f --output=json real‑time JSON logs
6. Security Hardening for Autonomous Loops
Running agents with shell access requires strict security measures:
- Principle of least privilege – Never grant tools a loop doesn’t need. Start with read‑only loops (PR reviewers, issue groomers) before enabling write capabilities.
- Human‑in‑the‑loop for irreversible actions – Gate destructive operations (database deletions, production deployments) behind explicit human approval.
- Token and budget limits – Set
max_tokens,budget_usd, and `max_attempts` per loop to prevent runaway costs. - Isolation – Use containers (Docker) or virtual machines for each loop execution to contain potential damage.
- Audit trails – Persist every action, decision, and verification result to an immutable log.
7. Cost and Performance Realities
Ronnie Gandhi (SSE, ex‑Microsoft/PhonePe) raised a valid concern: at what point does loop engineering become cost‑prohibitive in production? Data from early adopters provides a counter‑narrative:
- A single well‑chosen loop replaces 50‑200 manual prompts per month.
- At 3 seconds per prompt cycle, 3 active loops save roughly 15‑30 minutes per day.
- Token burn on repeated patterns drops by 20‑35% compared to manual prompting.
- Boris Cherny reports shipping 8‑15 PRs per day without touching code.
The trade‑off is clear: upfront investment in loop design yields exponential returns in developer productivity. Brandon Hunter (Cloud Networking Professional) notes that software should do the heavy lifting, pulling in AI only where needed — loops that are narrowly scoped and verification‑heavy actually reduce costs compared to LLM‑heavy manual integrations.
What Undercode Say:
- Key Takeaway 1: Loop engineering is not about eliminating humans — it’s about elevating them from prompt‑writers to system architects. The most reliable loops are semi‑autonomous, with human gates for irreversible actions and external verification for quality assurance.
- Key Takeaway 2: The verification layer must sit outside the loop. A second agent, CI checks, and persistent state can still verify the wrong thing. Only production signals — merged PRs, resolved issues, unchanged patches — confirm that the loop genuinely improved the system.
Analysis: The shift from prompt engineering to loop engineering represents a maturation of AI‑assisted development. We are moving from artisanal, one‑off interactions to industrial, repeatable processes. This mirrors the evolution of software engineering itself: from writing individual lines of code to designing compilers, build systems, and CI/CD pipelines. The frameworks emerging (Loop‑Harness, Loopy, OpenLoop) provide the scaffolding, but the hard part remains verification, stopping conditions, and escalation paths. Teams that master these will gain a compounding productivity advantage, while those still prompting manually will be left behind. The cost concerns are valid but addressable through strict budgeting, narrow scoping, and progressive rollouts — starting with read‑only loops and gradually expanding autonomy as trust builds.
Prediction:
- +1 Loop engineering will become a standard component of every CI/CD pipeline within 18 months, with major cloud providers offering managed loop services (AWS Loop, Azure Agentic Pipelines) that abstract away the orchestration complexity.
- +1 The number of developers who ship production code without manual prompting will exceed 50% by 2028, driven by tools like Loopy that auto‑discover automatable patterns.
- -1 Organizations that adopt loops without external verification layers will experience catastrophic failures — loops that “pass” internal checks but break production will erode trust and set back adoption by years.
- +1 Loop engineering will give rise to a new role: the Loop Architect — a specialist who designs, audits, and optimizes agentic loops, commanding salaries comparable to senior SREs.
- -1 The token and compute costs of large‑scale loop deployments will strain budgets, forcing teams to implement aggressive caching, model distillation, and hybrid human‑AI verification to remain cost‑effective.
- +1 Open‑source loop libraries (like the Loop Library project) will mature into shared repositories of battle‑tested patterns, enabling even small teams to deploy sophisticated loops with minimal custom code.
- -1 The “black box” nature of LLM‑driven loops will create compliance and auditability challenges in regulated industries, requiring new standards for explainable agentic systems.
- +1 The convergence of loop engineering with observability tools (OpenTelemetry, Prometheus) will produce self‑healing systems that not only fix code but also adjust their own loop parameters based on production telemetry — true autonomous DevOps.
▶️ Related Video (80% Match):
🎯Let’s Practice For Free:
🎓 Live Courses & Certifications:
Join Undercode Academy for Verified Certifications
🚀 Request a Custom Project:
Secure, high-velocity infrastructure and disruptive technological engineering. Contact our engineering team for high-tier development and proprietary systems:
[email protected]
💎 Smart Architecture | 🛡️ Secure by Design | ⭐ Trusted by Thousands
IT/Security Reporter URL:
Reported By: Charlywargnier A – Hackers Feeds
Extra Hub: Undercode MoN
Basic Verification: Pass ✅
