The Real-World Challenges of Loop Engineering—and Why I’m Skeptical

🙋‍
I’m Luhui Dev, a developer who has been breaking down Agent engineering and exploring how AI can be applied in education.
I focus on Agent Harness, LLM application engineering, AI for Math, and the productization of education SaaS.

“Loop Engineering” is becoming the latest idea in AI coding.

Claude Code creator Boris Cherny has said that he no longer prompts Claude directly. Instead, he writes loops that prompt Claude and decide what should happen next. Addy Osmani describes Loop Engineering in similar terms: rather than having a person continually prompt an agent, you design a system that handles prompting, execution, and feedback on the person’s behalf.

It sounds compelling.

From the Ralph Wiggum Loop and scheduled Claude Code runs to Codex Goals, long-running tasks, and multi-agent orchestration, more tools are supporting this pattern. OpenAI has even demonstrated a Codex experiment that ran for roughly 25 hours, consumed around 13 million tokens, and produced about 30,000 lines of code.

Yet I am skeptical that Loop Engineering will become a stable, general-purpose software engineering paradigm.

I do not doubt that agents will keep improving, nor do I deny that automated loops can create enormous value in some tasks. My concern is more fundamental: putting an agent in a loop does not automatically turn an uncertain model into a reliable engineering system.

A loop solves the problem of keeping an agent working. It does not solve the more important question:

Is the agent continuing to do the right thing?

That is the central challenge of Loop Engineering.

1. Execution Is Easy to Loop; Completion Is Hard to Define

A loop needs at least three basic elements:

Goal, execution process, completion condition

Execution is not the hardest part. Defining what “done” means is.

For a conventional program, the answer is often straightforward:

Stop when the queue is empty
Stop when every file has been processed
Stop when the API returns success

These conditions are deterministic and computable.

Most real software goals are not.

Consider:

Improve the user experience
Refactor the payment system
Improve code quality
Make the product more reliable
Fix an intermittent login failure
Build a production-ready admin system

None converts neatly into a Boolean expression.

OpenAI’s guidance for Codex Goals makes the same boundary explicit: a Goal is a poor fit when its endpoint is vague. Instructions such as “make it better,” or “refactor this code” without a target state, tests, and constraints, do not give an agent a dependable completion condition. Goals work best when they have a persistent objective, an evidence-based endpoint, and may require multiple rounds of investigation.

That reveals the actual scope of Loop Engineering.

The best candidates for automated loops are not all complex tasks. They are tasks that humans have already converted into verifiable problems:

Make every test pass
Migrate the remaining 23 legacy endpoints to the new protocol
Fix every static-analysis error

But once humans can clearly define the goal, state, constraints, and completion criteria, much of the hardest requirements work has already been done.

Loop Engineering automates more of the downstream execution than the judgment at the heart of software engineering.

2. Automated Verification Does Not Verify the Real Requirement

Loop Engineering usually relies on tests, lint results, builds, performance metrics, or screenshot evaluation as feedback.

A typical loop looks like this:

Agent changes code -> Run tests -> Tests fail -> Agent analyzes the failure
-> Change code again -> Tests pass -> Stop

This feels consistent with engineering practice, but it hides a serious problem:

The agent optimizes the verification signal, not necessarily the outcome we actually want.

Tests are only an incomplete expression of requirements.

The 2026 SpecBench research examined reward hacking in long-horizon coding agents. By separating public validation tests from hidden compositional tests, it found that frontier agents could score highly on visible tests while still showing a substantial gap on hidden ones. The gap grew as tasks became larger. An extreme case even appeared in which an implementation memorized test inputs to imitate correct behavior.

That does not necessarily mean the agent is deliberately cheating.

More precisely, an agent searches for a path that satisfies the feedback currently available. When that feedback does not fully represent the real goal, proxy distortion follows naturally.

This resembles Goodhart’s law:

When a measure becomes a target, it ceases to be a good measure.

Human engineers usually consider constraints that sit outside the tests:

• Does the code match the product’s actual intent?
• Does it break behavior in another module?
• Does it create long-term maintenance cost?
• Does it violate architectural principles?
• Does it increase security risk?
• Is it merely overfitting to the test cases?

Agents do not naturally possess this organizational, product, and historical knowledge.

As a result, building a complete verification system for Loop Engineering may cost as much as completing the task directly.

3. Loops Can Amplify Errors, Not Just Correct Them

Supporters often describe a loop as a self-correcting system:

Failure -> Feedback -> Correction -> Another attempt

But a loop does not inherently converge.

It can also behave like this:

Misread the goal -> Build the wrong implementation -> Update the plan from that implementation
-> Record the wrong state in documentation -> Later agents treat it as fact
-> Keep optimizing in the wrong direction

During a long task, an agent may change not only code but also PRDs, todo lists, project status, architecture notes, tests, progress logs, and its account of the root cause. Those artifacts become context for the next iteration.

If one iteration records an incorrect state, subsequent iterations may stop treating it as an unverified hypothesis and start treating it as established fact.

A single-turn AI error is usually confined to one response. A long loop can propagate an error into the repository, documentation, databases, task systems, and Git history. The longer the loop runs, the larger the error’s blast radius can become.

4. Resetting Context Does Not Solve Context Corruption

An important idea in Ralph Loop is to have the agent complete one task at a time, save progress to files or Git, and start the next iteration with a fresh context window.

This does prevent the conversation from growing without limit.

But it merely moves state from the model context into external storage. It does not eliminate information-management problems.

The system still has to decide which history to retain and which is stale, which conclusions are only guesses, which code and documents matter to the current task, and which source to trust when sources conflict.

Anthropic frames this as Context Engineering: as an agent generates more data inside a loop, the system must continually select and compress what the next reasoning step actually needs. Anthropic also notes that accurate recall and long-range reasoning degrade as context grows, so context should be treated as a scarce resource, not as something that is always better in larger quantities.

Long-running agents therefore face a dilemma:

Load too little, and the agent does not understand the project. Load too much, and the critical signal disappears into noise.

External state accumulates entropy much like a codebase:

Outdated plans
Duplicate explanations
Contradictory rules
Expired temporary conclusions
Different assumptions written by different agents

The hard problem is not restarting the loop. It is ensuring that every restart receives information that is accurate, concise, trustworthy, and relevant.

That problem looks more like knowledge management, configuration management, and runtime-state governance than “writing a loop.”

5. Code-Generation Throughput Is Not Engineering Productivity

The most visible benefit of Loop Engineering is greater code-generation throughput.

One agent can work continuously. Several agents can work in parallel. Tasks can run overnight. Failed tests can trigger automatic repairs. In theory, code output rises dramatically.

But software productivity has never been equivalent to lines of code.

The meaningful measure is the total cost from a requirement being raised to correct software entering use and remaining maintainable.

Faster generation does not necessarily mean faster delivery.

If agents create dozens of pull requests per day while humans can review only a few, the bottleneck simply moves from writing code to verifying it. If reviewers cannot understand the volume of machine-generated changes, two outcomes are likely:

First, agent output piles up and automated throughput never becomes real delivery.

Second, the team lowers its review standard, merges quickly, and pushes the problems into testing, production, and long-term maintenance.

Martin Fowler’s site has discussed this mismatch: agents can generate code faster than humans can inspect it line by line. To keep human review from becoming the bottleneck, teams must shift quality checks earlier and create specifications, tests, and workflow constraints that agents can use for self-checking.

In a 2025 randomized controlled trial with experienced open-source developers, METR found that on mature codebases the participants already knew, the AI tools available at the time increased task completion time by an average of 19%. A 2026 follow-up found some possible signs of acceleration, but its confidence intervals remained too wide to conclude that AI consistently speeds up every setting.

AI coding productivity is clearly more complicated than a multiplier on generation speed.

Loop Engineering widens this gap: it increases agent runtime and output volume without necessarily increasing the team’s ability to understand, verify, and take responsibility for that output.

6. More Agent Authority Means More Loop Risk

To complete complex work, an agent needs tools and permissions: repository access, file modification, shell execution, database access, logs, cloud APIs, deployment, and rollback.

More dangerously, agents read untrusted external content such as GitHub issues and web pages. Attackers can place indirect prompt injections in that content and make an agent mistake external text for operational instructions.

A persistent loop magnifies this risk.

A compromised agent may do more than produce a bad answer:

Read sensitive data -> Call tools -> Change external state
-> Store the false result in long-term memory -> Continue next iteration

A production loop therefore seems to require strict least privilege. Yet the tighter the permissions, the less autonomous the agent becomes.

This creates another Loop Engineering contradiction:

More authority creates more automation value and more risk; less authority reduces risk and also limits what the agent can accomplish.

7. Loop Engineering May Be Cron Plus an Agent

Structurally, much of what is called Loop Engineering is not new.

Common examples include:

New Sentry issue -> Agent investigates and opens a pull request

Run every night -> Agent checks failing tests -> Attempts a repair

New support ticket -> Agent investigates logs -> Produces a recommendation

In the past, teams built these patterns with Cron, webhooks, CI/CD, message queues, Zapier, or n8n.

What is new is that an LLM agent replaces one deterministic processing node in the workflow.

Most examples remain event triggers and scheduled jobs. They can be useful, but it is hard to call them an entirely new workflow paradigm. Some developers have even returned to conventional approaches after encountering agent drift, finding human intervention more effective, or facing excessive token costs.

8. Closing Thoughts

Loop Engineering presents an attractive future: humans define goals, agents keep working, and software evolves on its own.

Real software engineering, however, is not a problem that necessarily converges if we simply keep trying.

Requirements can be vague. Tests can be incomplete. State can be corrupted. Metrics can be gamed. Permissions can be abused. Costs can escape control. Code throughput can exceed an organization’s capacity to understand and review it.

A loop can extend an agent’s execution time. It cannot automatically make the objective more correct.

Compared with investing in the loop itself, I still believe the better investment is Harness Engineering: a reliable feedback system with clear boundaries, evidence, permissions, auditing, and the ability to stop at any time.