Loop Engineering: The Framework That Changed How I Build With AI Agents

The Concept

Most AI-assisted development today runs on a single loop: you prompt an agent, it generates code, you review it, repeat. This works for small tasks but breaks down when you're building something real. The agent has no memory of why you made past decisions, no sense of what your users want, and no way to verify its own work beyond syntax checks.

Loop engineering reframes AI-assisted development as three nested feedback loops running at different time scales. The framework was articulated by Andrew Ng in June 2026 and quickly adopted by teams building Claude Code, OpenClaw, and other agent-driven tools. It's not a new invention but a name for a pattern that the most productive AI-native teams were already using.

The three loops

Loop 1: Agentic (~minutes). The AI agent writes code, runs tests, and iterates until the code is correct. This is the innermost loop. It closed in late 2025 / early 2026 when agents became capable of hour-long autonomous coding sessions. Before this loop closed, every AI coding interaction was effectively single-shot: prompt, generate, manually review, repeat.

Loop 2: Developer feedback (~hours). The developer examines what the agent built and steers it. This is where vision translates into specs, where evals get written, where "build the right thing" decisions happen. As the agentic loop gets stronger, humans spend less time debugging agent output and more time on this loop. The human context advantage lives here: you know your users, your organization, your taste. The agent doesn't.

Loop 3: External feedback (~days). Users try the product. Production data arrives. Alpha testers report what works and what doesn't. This is the slowest loop but it's the one that determines whether you're building something that matters. It feeds back into developer vision, which updates specs, which the agent executes on.

The golden rule: fix inner loops first

This is the insight that makes the framework actionable, not just descriptive. When something isn't working:

1. Check the agentic loop first. Can the agent verify its own work? Are tests passing? Is CI green? If not, fix this before anything else. Adding features, changing architecture, or chasing user feedback while your agent can't close its own loop is wasted effort.

2. Then check the developer loop. Are specs clear? Do evals exist? Is the agent building the wrong thing because the spec is ambiguous? This is a human problem, not an agent problem. Better vision and better specs fix this, not a more powerful model.

3. Then check the external loop. Are you building what users actually need? Is production data informing your priorities? If the inner two loops are healthy, this is where attention should go.

The mistake most teams make is jumping to the external loop when the agentic loop is broken. "Users want feature X" doesn't matter if your agent can't ship feature X without human hand-holding at every step.

When to apply loop engineering

This framework becomes useful the moment AI stops being a one-off tool and starts being part of how you build. Specifically:

• Sustained development, not quick prompts. If you are using agents for more than isolated code generation, for ongoing features, refactors, or product development, loop engineering helps you see where the process is breaking.
• Recurring failures you cannot diagnose. The build keeps failing but you are not sure if the problem is the agent, the spec, or the priorities. Loop classification gives you a vocabulary for this.
• "Should we use a better model?" debates. Often the answer is no. The issue is missing evals (agentic) or ambiguous specs (developer), not model capability. Loop engineering surfaces that distinction.
• Deciding what to work on next. Instead of building whatever feels urgent, check which loop is weakest and fix that. Inner loops first.

Common pitfalls

Blaming the model when the spec is weak. Upgrading from a fast model to a frontier model doesn't fix ambiguous requirements. That's a developer loop problem showing up as agentic loop symptoms.

Skipping evals. If the agent has no way to verify its own work, the agentic loop is fundamentally open. Every change requires human review. This is the single highest-leverage fix for most teams.

Over-automating the developer loop. The human context advantage is real. Automating spec generation from user feedback sounds efficient but strips out the judgment calls that make products good. Automate the agentic loop aggressively. Automate the developer loop cautiously.

Ignoring the external loop entirely. Building without user signal means the developer loop is running on guesses. Even a small amount of external feedback (five users, weekly check-ins) dramatically improves what the developer loop produces.

In practice: how I applied this to Ciel

Ciel is a thing I built to help me manage my own work. I didn't set out to "implement loop engineering" but when I learned this framework, I realized I'd been stumbling into these patterns already. Naming them just made it easier to fix problems.

The fast loop: I set up a part of Ciel that edits its own code, runs tests, and if something breaks, tries to fix the build and reviews its own changes before shipping. It just keeps going until tests pass. Getting this working was the first thing I had to do before anything else made sense.

The middle loop: I built a page where I can see which loop is struggling right now. Color-coded: indigo for the fast loop, amber for the middle, violet for the slow one. When the middle loop is weak (like the same kind of error keeps coming back, or specs are unclear), Ciel just tells me about it instead of trying to fix it on its own. Because I know my users and priorities better than it does.

The slow loop: I have this thing called Pulse that watches my X timeline, picks up on what's happening in the space, and once a week suggests what Ciel should work on next. The outside world feeding back into what I build.

The main behavior that changed: when the fast loop is struggling, Ciel won't touch anything else. It won't change model configs, it won't chase new features. It just fixes the fast loop first. I kept trying to do too many things at once before I set that up, and everything was slower because of it.

Quick Win: Claude Skill

You can use this prompt to diagnose which loop is weak in your current project. Paste in a description of what's going wrong and get a structured recommendation:

You are a development process analyst. Your job is to diagnose problems in AI-assisted development projects using the loop engineering framework. The framework defines three nested feedback loops: 1. AGENTIC LOOP (~minutes): The AI agent writes code, tests it, and iterates. Problems here look like: tests failing, CI broken, agent generating wrong code, manual review needed for every change, agent can't verify its own work. 2. DEVELOPER LOOP (~hours): The human steers the agent with specs, evals, and vision. Problems here look like: agent builds the wrong thing, specs are ambiguous, no evals exist, repeated failures on the same class of error, unclear acceptance criteria. 3. EXTERNAL LOOP (~days): Users, production data, and market signals inform what to build. Problems here look like: building features nobody uses, no user feedback mechanism, priorities based on assumptions, no production metrics. Given the problem description below: 1. Classify which loop is PRIMARILY weak (agentic, developer, or external) 2. Classify which loop is SECONDARILY weak (if any) 3. Explain WHY in 2-3 sentences 4. Recommend the TOP 3 actions to fix it, ordered by the golden rule: fix inner loops before outer loops 5. Flag if the user is trying to fix an outer loop when an inner loop is broken Be specific and practical. Name the exact type of fix (add tests, write evals, clarify spec, add user feedback channel, etc.). PROBLEM: [Paste your problem description here]

How to use it:

1. Describe what's going wrong in your AI-assisted project: failing builds, wrong output, unclear direction, user complaints, model cost concerns, whatever
2. Paste it into the PROBLEM section
3. The diagnosis tells you which loop to fix first and what specific actions to take
4. Revisit weekly as the project evolves. Which loop is weak changes over time.

This is the most practical application of loop engineering: turning a vague "something is off" into a specific "fix the agentic loop by adding integration tests, then revisit specs."

Full System Specification

Building loop engineering into an agent system means three things: classifying problems by loop, routing decisions based on which loop is weak, and enforcing structural gates that keep the inner loops healthy.

Layer 1: Loop Classification

Every degradation, failure, or anomaly in the system gets classified by which loop it belongs to. This classification is the foundation for everything else.

Implementation: map every metric and action in your system to a loop. Test failures, CI repairs, agent self-review errors map to agentic. Spec quality, human overrides, instruction intent map to developer. User feedback, production metrics, competitive intel map to external.

The classification should be a code constant, not a runtime config. You want every part of the system to know which loop it's operating in at compile time, not as an optional annotation that gets forgotten.

Layer 2: Loop-Aware Routing

Once you know which loop is weak, route decisions accordingly:

The key routing rule: when the agentic loop is weak, defer outer-loop work. Don't tune model tiers, adjust pricing, or chase feature requests while the agent can't close its own iteration loop. This is the "fix inner loops first" principle encoded as system behavior.

Concretely:

• If agentic is weak and a governance change is queued (model tier adjustment, cost optimization), defer it. The reason: tuning model tiers while the agent can't verify its own work is optimizing the wrong thing.
• If developer is weak, surface it to the human operator rather than trying to auto-fix. The human holds the context advantage here.
• If external is weak, prioritize production metrics and user signal before starting new development.

Layer 3: Structural Gates

Gates enforce that the agentic loop stays closed. Without gates, it's easy for the loop to silently open (agent ships code that works syntactically but is wrong behaviorally).

Gate 1: Acceptance criteria. Every spec or proposal that enters the system must have verifiable acceptance criteria. If the criteria are missing, the agent literally cannot close the agentic loop because it has no definition of "done." Reject specs without criteria at enqueue time, not at review time.

Gate 2: Test-eval retry. When an agent ships code and the test findings report failure, the agent gets one automatic retry before escalating. This keeps the agentic loop closed for recoverable errors (import typos, off-by-one, missing mocks) without human intervention.

Gate 3: Self-review. After the agent passes its own tests, it reviews its own diff for quality. This catches the class of errors where tests pass but the implementation is wrong (hardcoded values, skipped edge cases, security oversights). Self-review is cheap relative to human review.

Cost Architecture

Loop engineering is mostly prompt and routing changes, not new infrastructure:

• Classification: a static map from metric actions to loops. Zero runtime cost.
• Routing: conditional logic in existing health check and evolution paths. Negligible.
• Gates: acceptance criteria validation is string parsing. Test-eval retry is one additional agent call on failure (already happening manually). Self-review is one LLM call per shipped change.
• UI: loop badges on existing dashboards. Color-coding an existing component.

The most expensive part is the self-review gate (one mid-tier LLM call per change), and it pays for itself immediately by catching errors that would otherwise require human review or production rollback.

The real cost of not implementing loop engineering is harder to measure but more significant: building the wrong things because outer-loop problems are misdiagnosed as inner-loop problems, and wasting agent compute on tasks that fail because the spec was ambiguous.