Loop Engineering Crash Course: Six Core Elements of AI Agents and Engineering in Practice

Over the past two years, prompt engineering has been practically a required course for every AI developer. But if you're still obsessing over "advanced prompt-writing techniques" right now, you may already be lagging behind the track that truly drives productivity gaps. In this video, a Bilibili creator puts forward a key judgment: how well you write prompts is rapidly declining in impact on productivity; what really determines your efficiency ceiling is whether you can design a system that lets AI autonomously run the entire development loop. This system-level approach is called Loop Engineering.

Why Prompt Engineering Is No Longer the Bottleneck

The creator uses a precise analogy: writing code with AI in the early days was like driving to an unfamiliar place in the era before navigation. You had to study the map in advance, pull over every few kilometers to ask for directions, and if you took a wrong turn, you'd have to pull over and re-check the map. Mapped onto the development workflow, this means: AI gives you a piece of code, you run it manually, and when it errors out, you manually paste the error back to the AI. Efficiency is entirely bottlenecked on the human.

Navigation today doesn't require you to stop—if you take a wrong turn, it replans the route on its own. What Loop Engineering aims to do is design a "navigation system" for AI: throw in a goal, and the system itself sends prompts, runs code, discovers errors, and auto-corrects until the problem is completely solved. The human is no longer a mandatory node in every loop iteration.

Behind this shift is the evolution of AI engineering through four stages:

• Prompt Engineering: optimizing how a single instruction is written
• Context Engineering: supplementing AI with background information via RAG and similar methods
• Harness Engineering: organizing toolchains and external APIs for AI to call
• Loop Engineering: letting AI autonomously set goals, execute, observe, and correct errors, with the entire closed loop driven by the system

The common trait of the first three stages is "humans teaching AI how to do things." The core shift in Loop Engineering is that humans step back into the role of system designer—no longer fixated on a single instruction or a single tool, but designing an automatically running mechanism that continuously produces results.

Reflected in everyday programming tools, this shows up as three generations of leap: from Copilot-style autocomplete (the human is the decision-maker), to current conversational tools like Doubao, DeepSeek^Ad, and ChatGPT (the human is still the bottleneck), to autonomous looping tools like Claude Code—once given a goal, the AI autonomously plans, modifies files, and runs tests; if tests fail, it reads the error and keeps fixing until they pass.

Inner Loop and Outer Loop: What Loop Engineering Actually Does

The first step to understanding Loop Engineering is dividing up responsibilities for the AI. The creator introduces a pair of core concepts: the inner loop and the outer loop.

The inner loop is the Agent's own core drive—perception, reasoning, execution, and observation of results. It's like a professional driver who brakes automatically at a red light; the passenger doesn't need to shout "brake!" This is the part the Agent can close on its own.

The outer loop is what the system developer actually needs to design. It's like a ride-hailing platform's dispatch system: discover tasks, assign them to the most suitable Agent, wait for the Agent to finish and verify results, record the current state, and trigger the next round of tasks. Loop Engineering isn't about hand-holding the Agent through how to brake—it's about designing, operating, and continuously improving this outer loop system.

Compared with prompt engineering, the two optimize fundamentally different things:

Dimension	Prompt Engineering	Loop Engineering
Optimization target	A single hand-written instruction	A complete self-running system
Interaction mode	One question, one answer	Multi-round automated workflow
Success criterion	A good first-step answer	Final delivery passes tests
Failure attribution	Poor model response quality	Flawed loop system design
Role of the human	A craftsman operating manually	A system architect orchestrating processes

A complete outer loop contains five operational nodes: intent definition (what counts as success), context gathering (relevant code and logs), action (modifying files or calling tools), observation (running tests, capturing results), and adjustment (updating the plan based on error signals). The most critical insight here is: a failed test isn't a bad thing—the error message is actually the most valuable context for the next iteration.

Six Core Elements for Building a Loop System

For a loop system to run stably in real projects, it needs support from six underlying elements.

Automated Triggers and Pre/Post Hooks

The system can't rely on manual clicking to drive it. It needs deterministic lifecycle management: wake the Agent on a schedule to execute tasks, pre-hooks automatically load environment variables and secrets, and post-hooks automatically trigger unit tests. Each step has a clear handoff, with no one watching over it.

Isolated Sandboxing

The last thing you want is AI randomly modifying code and breaking the main branch. The system needs a work tree mechanism: after the main agent receives a task, it branches off an independent branch, and different sub-agents modify code and run tests in parallel on their own branches without interfering with each other. Only after a branch fully passes tests is it merged back into the main branch.

A work tree is a native Git capability that allows the same repository to check out multiple working directories simultaneously, each pointing to a different branch while sharing the underlying object store. The conventional approach allows working on only one branch at a time; switching branches requires stashing or committing current changes. Work trees make parallel development possible. In an Agent loop system, this mechanism precisely solves the isolation requirement of "multiple sub-agents modifying code in parallel": each sub-agent edits files and runs tests in an independent work tree, without polluting the main branch or overwriting each other's changes. Compared to directly copying the repository directory, a work tree is more lightweight—it doesn't duplicate stored history objects, and branch merging and tracking are still managed uniformly by the same Git repository. Once all tests on a branch pass, you simply commit in that work tree and merge back to the main branch; the remaining failed branches can be discarded at any time, making the entire process clean and traceable.

Security Boundaries

Commands the AI can call must be risk-tiered. Safe commands like npm test are allowed through directly; high-risk operations like git push --force require human confirmation; dangerous operations like deleting the root directory are unconditionally blocked. Replace the all-purpose terminal with specialized small tools—like hiring a repairman: hand him the tool he needs, not the entire toolbox.

Tool Connectivity and the MCP Protocol

When local tools aren't enough, extend outward through the MCP protocol: connect to Slack notifications, GitHub PR handling, remote databases, and more. Capabilities expand gradually, but every step stays within the established security framework.

MCP, short for Model Context Protocol, is a standard protocol open-sourced by Anthropic at the end of 2024, aimed at establishing a unified communication interface between AI models and external tools and data sources. Before MCP, each time you integrated a new tool (such as a database, Slack, or GitHub), developers often had to write customized adapter code for a specific model, leaving the tool ecosystem highly fragmented. MCP uses a client-server architecture: the AI application acts as the client, and external capabilities are wrapped as MCP Servers, exchanging capability descriptions and invocation results through standardized JSON-RPC messages. This design allows the same MCP Server to be reused by different models or Agent frameworks, and makes capability expansion as simple as plugging in building blocks. For loop systems, the significance of MCP lies in decoupling the "tool connectivity" step from project code, so that security policies (permission tiers, audit logs) can be configured centrally at the protocol layer rather than scattered across every call site.

Role Separation

Having a single AI act as both strategist and programmer easily leads to confusion. Split into different sub-agents: an Explore Agent with read-only permissions handles planning and inspection; a Code Agent with read-write permissions handles only execution and modification. With clear division of labor, AI performs more reliably.

Layered Memory

No matter how large the context window, it has limits. Memory is divided into three layers: always-loaded core state (such as a to-do.md recording current progress), on-demand architecture docs and API specs, and background full-text-search-style history. The core principle is "the repository remembers, even if the model doesn't"—as long as the code repository has clean documentation, commit history, and test cases, the system can always feed precise context back to the AI.

The context window refers to the maximum total number of Tokens a large model can "see" in a single inference, including the system prompt, conversation history, code files, and tool return results—all inputs. Early models had windows of only a few thousand Tokens; today's mainstream models have expanded to 200K or even millions of Tokens. But "a big enough window" doesn't mean "you can stuff it blindly." There are two reasons: first, more Tokens means higher inference cost and longer latency; second, models easily exhibit "lost in the middle" behavior in extremely long contexts, where details in the middle get diluted by attention, actually degrading output quality. Layered memory is precisely the engineering response to this—core state stays in the window at minimal size, architecture docs and API specs are injected on demand, and the full history stays outside the window, retrieved by relevance. Its essence is a caching strategy: spend the limited attention budget on the context most needed for the current task, rather than dumping the entire repository at the model all at once.

Four Pitfalls of Engineering Implementation and How to Prevent Them

Once an automated system goes out of control, its destructive power is equally staggering. The creator summarizes two psychological pitfalls and four failure modes.

Comprehension debt: The Agent silently changes dozens of pieces of code overnight and passes all tests; you see a row of green and click merge. But AI writes code far faster than you can read it, and the more debt accumulates, the weaker your control over the system. The iron rule: no matter how smoothly tests pass, the code diff must be reviewed with your own eyes.

Cognitive surrender: Trusting the system's smooth operation too much and completely giving up architectural thinking. Large models are smart, but they don't know how to avoid long-term architectural risks. Final code merges and architectural sanity checks remain the absolute responsibility of human programmers.

Four typical failure modes:

• Spinning: Repeatedly modifying code but tests never pass, usually because the goal is too vague. The cure is to narrow the goal scope and give a single-line instruction that can be verified.
• Test overfitting: Unit tests are all green but the actual business is unusable; the AI exploited loopholes in the test cases. You need to add end-to-end real-scenario tests and human acceptance.
• Context drift: AI writes code based on outdated assumptions. Force the system to clear and re-gather the current state after observing errors.
• Unsafe autonomy: AI oversteps and executes destructive operations. Enforce the principle of least privilege and configure explicit stop rules.

Four Golden Rules

• Start with narrow tasks: Don't give grand goals like "optimize the payment module"; be specific about files and clear small tasks.
• Prefer small, reversible changes: Make only the minimal modification each time, verify, then expand. Like writing with a pencil—erasing and starting over costs almost nothing.
• Provide deterministic verification signals: Hard-code verification commands in the instructions so the system can measure for itself whether the task is complete.
• Respect existing code patterns: Force the AI to first check existing components and naming conventions, prioritize reuse, and not get clever by introducing unnecessary design patterns.

The Engineer's Role Upgrade

From writing prompts to designing self-driving loop systems, large models aren't eliminating engineers—they're driving a professional role upgrade. Previously you were a craftsman focused on laying a single brick well; now you become a system architect designing an automatic building machine. But the person who decides what the building looks like and whether the foundation is stable is always human. Maintain architectural judgment and reverence for code, and never fully take your hands off the wheel—this is the most irreplaceable core asset in the era of runaway AI.

One-line Summary

AI engineering is evolving from prompt engineering to loop engineering, and developers need to design outer-loop systems that let AI close the loop autonomously.

Paragraph Summary

The article points out that prompt engineering's impact on productivity is rapidly declining, and what truly creates efficiency gaps is Loop Engineering—a system-level approach that lets AI autonomously complete goals, execute, observe, and correct errors. AI engineering has gone through four stages: prompt engineering, context engineering, harness engineering, and loop engineering, with the human role shifting from operator to system designer. A loop system is divided into the Agent's own inner loop and the developer-designed outer loop, the latter containing five nodes: intent definition, context gathering, action, observation, and adjustment. Building a reliable loop requires six elements: automated triggers and hooks, work tree isolated sandboxing, command risk tiering, MCP tool connectivity, role separation, and layered memory. In implementation, watch out for two psychological pitfalls—comprehension debt and cognitive surrender—as well as four failure modes.