Loop Engineering Explained Simply (With DIY Python Snippets)

A few weeks ago, Peter Steinberger, the creator of OpenClaw who now works at OpenAI, made an observation that signals a massive structural shift in how we build software:

"You shouldn't be prompting coding agents anymore. You should be designing loops that prompt your agents."

Shortly after, Boris Cherny, who leads Claude Code at Anthropic, described the exact same evolution in his own daily workflow:

"I don't prompt Claude anymore. I have loops running that prompt Claude and figure out what to do. My job is to write loops."

When two of the most prominent engineers shaping the frontier AI landscape independently reach the exact same conclusion, it is no longer a passing trend. It is a fundamental shift in computer science.

The era of manual, chat-based prompt engineering is officially dead. We have entered the age of Loop Engineering.

To understand why this is happening—and how to survive it—we have to look at the cybernetic theory of the loop, the raw economic physics making it possible, and the exact software blueprints required to build them.

---

Part 1: The Computer Science Theory of the Loop

When most people hear the word "Loop," they picture a basic while(true) statement in Python. But in the context of autonomous agents, "Looping" relies on three core concepts taken directly from Control Theory and Systems Cybernetics.

1. Open-Loop vs. Closed-Loop Cybernetics

For the last two years, we treated LLMs as Open-Loop Control Systems.

Think of a cheap kitchen toaster. You turn the dial to "4", push the lever down, and it applies heat for 120 seconds. If the bread was frozen, it comes out cold. If the bread was already toasted, it catches fire. The toaster has zero awareness of the bread's actual state; it just blindly executes a feedforward instruction. That is a prompt.

An Agent Loop is a Closed-Loop Control System (like a smart home thermostat). It measures the current room temperature, applies heat, measures the room again, calculates the delta (the error) between the current state and the target state, and adjusts itself. It uses feedback.

2. Probabilistic Cores inside Deterministic Shells

Large Language Models are fundamentally stochastic (probabilistic). If you ask an LLM the same complex coding question five times, you will get five slightly different variations of logic.

Trying to build reliable, enterprise-grade software out of purely stochastic prompts is like trying to build a skyscraper out of wet clay; the foundation constantly shifts.

Loop Engineering solves this by wrapping a non-deterministic engine inside a deterministic state machine. The LLM inside the loop is allowed to guess, hallucinate, and be creative. But the State Machine governing the loop holds the strict, binary pass/fail gates. The LLM supplies the raw cognitive horsepower; the Loop supplies the mathematical verification.

3. The Entropy Horizon (Why Loops Decay)

In information theory, systems degrade over time due to entropy.

When an AI agent runs through a loop 15 times trying to fix a bug, its context window fills up with past failed code snippets, messy stack traces, and its own redundant apologies ("Ah, I see my mistake!"). As the signal-to-noise ratio drops, the system hits an Entropy Horizon—it loses track of the original goal and starts hallucinating phantom bugs.

This theoretical limit is why state management and context pruning are the most difficult parts of loop design. A good loop actively throws away dead context to keep the model's entropy close to zero.

---

Part 2: The Economic Reality of Autonomy

If the theory of closed-loop systems is so obviously superior, why didn’t we build software this way in 2023?

Because of the API bill.

The dirty secret of autonomous loops is that they are token incinerators. While a manual prompt costs you a few hundred tokens, an automated loop pays a massive "token tax" for autonomy:

• A Single-Agent Debugging Loop: Iterating 8 times to resolve a complex database migration easily burns 50,000 to 200,000 tokens.
• A Multi-Agent Fleet: An orchestrator delegating sub-tasks to a Researcher, a Coder, and a QA agent across a 10-step plan can rapidly consume 500,000 to 2,000,000 tokens per run.
• Scheduled CI/CD Loops: Pointing an autonomous loop at your GitHub repository every morning adds up to tens of millions of tokens per month.

When Peter Steinberger posted his advice, the immediate pushback from developers was: "Easy for you to say—you work at OpenAI and don't pay the token bill."

The Frontier Price Collapse

This financial blocker is precisely why Loop Engineering has suddenly gone mainstream. The arrival of ultra-low-cost, frontier-tier models—most notably DeepSeek V4—has fundamentally broken the token tax.

With massive 1M context windows and 384K maximum output limits priced at fractions of a cent per thousand tokens, the financial penalty for a loop failing 10 times in a row has dropped to near zero. You can finally afford to let a machine spend $0.40 worth of compute to autonomously solve a problem that would take a human engineer three hours of salary to fix.

---

Part 3: The 5 Stages of the Loop Lifecycle

Every production loop rotates through the exact same five distinct evolutionary phases. If your system architecture handles these handoffs cleanly, the loop becomes self-sustaining:

1. Discover: The agent reads its environment. It inspects directory structures, parses git diffs, or reads API documentation to establish a factual baseline.
2. Plan: The system generates a deterministic, step-by-step DAG (Directed Acyclic Graph) to map out the journey from the current state to the target state.
3. Execute: The agent performs the physical work—writing files, refactoring code, or calling external endpoints.
4. Verify: The most vital stage. The system runs an objective, non-AI quality gate. This must be a cold, hard test: a compiler check (tsc), a test runner (pytest), or a syntax linter.
5. Iterate: If the verification gate returns an exit code other than 0, the loop captures the raw terminal stderr output and routes it directly back into Stage 1, starting the loop over with the failure logs attached.

---

Part 4: The 6 Production Software Pillars

To move from an abstract flow diagram to a real-world engine that touches your codebases safely, your software needs six concrete architectural pillars:

1. Automations (The Heartbeat)

Automations replace the human finger pressing "Enter". You write background daemons that evaluate state triggers. For example: Watch /src; if a new file is added, trigger the RefactorLoop until unit test coverage is >= 90%.

2. Git Worktrees (Parallel Workspace Isolation)

When you run multiple agents simultaneously, they will eventually try to read and write to the same file at the exact same millisecond, causing catastrophic race conditions.

Using Git worktrees allows your orchestrator to check out the exact same repository branch into totally isolated, separate physical directories on your hard drive. Agent A can rewrite the backend in Worktree 1 while Agent B writes unit tests in Worktree 2. Zero file-locking collisions.

3. Skills (Compounding System Memory)

An agent shouldn't have to guess your architectural patterns every time it boots up. You drop a dedicated .agent/ configuration directory into your project root containing explicit guardrails.

DIY Snippet: Project Guardrails (.agent/RULES.md)

# Project Engineering Constraints

1. **Strict Typing:** All Python code MUST pass `mypy --strict`. Do not use `Any`.
2. **No Silent Failures:** Never use `except Exception: pass`. Catch explicit errors and log them.
3. **Immutability:** Favor `dataclasses` with `frozen=True`.
4. **Network Layer:** Use `httpx` for async calls. Strictly forbid the `requests` library.

4. Environmental Integrations (MCP Connectors)

An AI agent trapped inside its own chat window is useless. By adopting the Model Context Protocol (MCP), your loop connects securely to your local and cloud infrastructure. Instead of outputting a code block for you to copy, an MCP-enabled loop can query a PostgreSQL database, pull a ticket down from Jira, write the code, and submit a Pull Request to GitHub autonomously.

5. Separation of Concerns (The Maker-Checker Decoupling)

The Golden Rule of Looping: The model that writes the implementation must never be the one that validates it.

If you ask an LLM to review its own broken code, it will easily talk itself into believing its logic is brilliant. You must decouple your system: use a highly creative model for the Maker (Execution stage), and route the output to a completely separate, highly pedantic prompt profile—or a different model family entirely—for the Checker (Verification stage).

6. Persistent State (The Ledger)

Because models are stateless across separate API calls, your loop needs an external brain. You maintain a structured state ledger on disk to record the history of the loop's trajectory. This prevents the agent from getting stuck in an infinite loop, trying the exact same failed regex fix over and over again.

DIY Snippet: State Tracking Ledger (.agent/state_ledger.json)

{
  "session_id": "MIGRATION_LOOP_v4",
  "target_goal": "Migrate user_id column from INT to UUIDv4 in production DB",
  "max_allowed_attempts": 5,
  "current_attempt": 2,
  "execution_log": [
    {
      "attempt": 1,
      "action": "Generated ALTER TABLE script using default cast",
      "gate_status": "FAILED",
      "error_payload": "ERROR: default for column cannot be cast automatically"
    },
    {
      "attempt": 2,
      "action": "Added explicit USING gen_random_uuid() clause to statement",
      "gate_status": "PENDING_VERIFICATION"
    }
  ]
}

---

Part 5: Hands-On DIY — Building a Python Loop Engine

Here is a complete, dependency-free Python implementation of a Closed-Loop State Machine.

This engine accepts a high-level goal, asks an LLM to generate code, writes that code to disk, executes the system's Python compiler as an objective quality gate, and forces the LLM to autonomously consume its own syntax errors and fix them until the gate clears.

import subprocess
import os
import json

def simulate_llm_call(system_prompt: str, user_prompt: str) -> str:
    """
    Simulates an API call to a frontier LLM (e.g., DeepSeek / Anthropic / OpenAI).
    In production, replace this with your actual SDK invocation.
    """
    # For demonstration, we simulate an LLM returning broken code on Attempt 1, 
    # and fixed valid code on Attempt 2 after reading the error feedback.
    if "SyntaxError" in user_prompt:
        return "def calculate_fibonacci(n: int) -> list[int]:\n    fib = [0, 1]\n    for i in range(2, n):\n        fib.append(fib[-1] + fib[-2])\n    return fib[:n]"
    else:
        # Intentionally broken syntax (missing a colon) to trigger the feedback loop
        return "def calculate_fibonacci(n: int) -> list[int]\n    fib = [0, 1]\n    return fib"

def execute_compiler_gate(file_path: str) -> tuple[bool, str]:
    """Runs a strict, non-AI verification gate (the Python syntax compiler)."""
    try:
        subprocess.run(
            ["python", "-m", "py_compile", file_path],
            capture_output=True,
            text=True,
            check=True
        )
        return True, "Verification Gate Passed: Zero syntax errors."
    except subprocess.CalledProcessError as err:
        return False, f"Verification Gate Failed:\n{err.stderr}"

def autonomous_agent_loop(goal: str, output_file: str, max_loops: int = 4):
    """The deterministic state machine governing the stochastic LLM."""
    print(f"🚀 Initializing Loop Engine...\nGoal: '{goal}'\nTarget: {output_file}\n")

    # Load system skills (guardrails)
    rules = "Write pure Python code. Do not include markdown formatting or explanations."
    context_accumulator = f"Target Goal: {goal}"

    for attempt in range(1, max_loops + 1):
        print(f"──► [Loop Iteration {attempt}/{max_loops}]")

        # STAGE 1, 2 & 3: DISCOVER, PLAN, EXECUTE (Maker Phase)
        print("    ⚙️ Maker Agent generating implementation...")
        prompt_payload = f"{context_accumulator}\nFollow these rules strictly:\n{rules}"
        generated_code = simulate_llm_call("You are an expert Python coding agent.", prompt_payload)

        # Commit work to isolated workspace
        with open(output_file, "w") as file_pointer:
            file_pointer.write(generated_code)

        # STAGE 4: VERIFY (Checker Phase)
        print(f"    🛡️ Executing compiler gate against {output_file}...")
        gate_cleared, gate_logs = execute_compiler_gate(output_file)

        if gate_cleared:
            print(f"    ✅ Exit Code 0: Output verified successfully on loop {attempt}! Shipping.")
            break

        # STAGE 5: ITERATE (Feedback Loop)
        print(f"    ❌ Gate Failed. Capturing stderr and injecting back into state...")
        # Mutate the state accumulator so the LLM reads its own error on the next pass
        context_accumulator += f"\n\nOn Attempt {attempt}, your code failed with this exact error:\n{gate_logs}\nRewrite the code to fix this specific compiler error."
        print("    🔄 Re-routing back to Stage 1...\n")
    else:
        print(f"🛑 CRITICAL: Loop exhausted all {max_loops} attempts without clearing verification gate.")

if __name__ == "__main__":
    autonomous_agent_loop(
        goal="Write a valid Python function to calculate the Fibonacci sequence.",
        output_file="fibonacci_service.py",
        max_loops=3
    )

---

Part 6: The Professional Divide

We are watching the software engineering job market bifurcate in real time:

Engineering Dimension	The Prompt Engineer	The Loop Engineer
Core Paradigm	Conversational input/output	State machines & Systems cybernetics
Primary Artifact	Multi-paragraph English text blocks	Automated verification gates & DAG workflows
Human Role	Manually drives iterations; copies terminal errors	Architects system flows; manages error escalation
System Output	A single, isolated probabilistic generation	A repeating, self-correcting verified outcome
Financial Optimization	Minimizing cost per individual chat prompt	Minimizing total compute cost per verified feature

---

The Ultimate Point of Leverage

As this technology scales across the industry, an uncomfortable reality is becoming clear: two software engineers can write the exact same agent loop and achieve completely polar opposite results.

The first engineer uses the loop as a force multiplier, deploying it to navigate and refactor complex architectures they already understand deeply. The second engineer uses the loop as an escape hatch, deploying it to avoid learning how the underlying codebase works at all.

The loop itself does not know the difference—but your production infrastructure certainly will.

Boris Cherny and Peter Steinberger are not telling us that software engineering just got easier. They are warning us that the fundamental point of leverage has shifted higher up the stack. We are no longer manual laborers carefully instructing a machine on how to swing a hammer. We are factory architects designing the automated assembly lines that inspect, reject, and refine their own output until it is structurally flawless.

Build the loop. But build it with the rigorous, uncompromising mindset of someone who intends to remain the master engineer—not just the person who presses the start button.

---

Still learning. Still building. Still curious. — Ram Bikkina | bikkina.vercel.app