Why Is AI Coding Still Unstable? Loop Engineering May Be the Next Step

Recent discussion around “Loop Engineering,” sparked by the author of OpenClaw, looks on the surface like another new pattern for AI Coding. Underneath, it feels more like rediscovering a path the Kubernetes community already walked more than a decade ago: use a continuous feedback control loop to keep pushing a system toward its desired state.

If we line up the last two years of AI coding tools, the migration path is fairly clear: from Prompt Engineering, to Context Engineering, and now to Loop Engineering. At first, people cared about how to write better prompts. Later, they realized that what really affects Agent performance is context, tools, memory, and environment. Then the question changed again: even with enough context, the Agent is still unstable. What do we do?

The answer is not to make the model “think correctly” in one shot. It is to put it into a loop of observing, acting, verifying, and correcting until it gradually converges.

That is exactly the basic worldview of Kubernetes.

From One Call to a Continuous Loop

Real software development has never been a single inference. It usually looks more like this:

1. Read the code.
2. Understand the goal.
3. Modify the implementation.
4. Compile or run tests.
5. Find the deviation.
6. Keep fixing.
7. Review.
8. Fix again.
9. Stop when the result reaches an acceptable state.

This is not “prompt -> answer.” It is “goal -> loop -> evaluation -> feedback.” The value of Loop Engineering is here: it stops treating AI Coding as automatic code generation and starts treating it as automatic goal convergence.

Some early practices are already close to this direction. For example, people have used loops to repeatedly wake up Claude Code, make it reread the repository, planning files, and Git state, and then push one small task forward. There is a key lesson here: Agents forget, repositories do not. Conversation history is unreliable. Persisted state is the fact the next loop can depend on.

Kubernetes Already Proved This Pattern

Many people think of Kubernetes as a container orchestration platform, but its deeper contribution is bringing control theory into software engineering.

What a Kubernetes controller does can be summarized in four steps:

1
2
3
4
5

Desired State
  -> Observe
  -> Compare
  -> Act
  -> Repeat

This is the reconciliation loop. The controller repeatedly checks whether the actual state equals the desired state. If not, it keeps adjusting.

For example, when you declare:

1

replicas: 3

You do not tell Kubernetes, “start the first Pod, then start the second Pod, then start the third Pod.” You only declare the desired state. How many replicas currently exist, which Pods have died, and whether replacements are needed are all handled by the controller inside the loop.

AI Coding is forming a similar structure. You no longer command an Agent step by step to open a file, modify a function, and add a test. Instead, you declare a goal: fix this concurrency issue and make sure the tests pass. The Agent observes the repository, modifies code, runs verification, reads feedback, and continues the next round.

Prompt is becoming Spec.

Components of Loop Engineering

A usable Loop Engineering system usually contains several kinds of components:

• Automatic triggers: timers, cron, webhooks, and GitHub Actions, so the loop does not depend on a human clicking a button.
• Isolated workspaces: Git worktree and similar mechanisms that let multiple Agents work in parallel without stepping on each other.
• Project knowledge: SKILL.md, AGENTS.md, specification documents, and task files that turn experience into reusable context.
• Tool connections: MCP, plugins, CI/CD, issue systems, and databases that let the Agent observe the real environment.
• Sub-Agents: split maker, checker, and reviewer roles so the model is not grading itself.
• External state: Markdown, issues, Git commits, or task boards that record progress so the loop can be killed, restarted, and resumed.

Together, these components look like a control plane for the AI era. The model is only the executor. What really determines system capability is how the loop is organized, how state is persisted, and how feedback enters the next round.

The Differences Matter More Than the Similarities

Loop Engineering and Kubernetes controllers look structurally similar, but they are not equivalent. The most important difference is this: Kubernetes controls a relatively deterministic system, while an LLM loop controls a probabilistic system.

When Kubernetes creates a Pod, the result is usually predictable, observable, and retryable. When an LLM receives the same instruction, “fix the payment system concurrency bug,” it may make one change today and another tomorrow. Claude and GPT may also produce completely different solutions.

That brings several hard problems:

• Uncertain executor: the same input does not guarantee the same output.
• Unprovable convergence: the loop may repeatedly change things, spin in place, or even break something already fixed.
• Unreliable completion judgment: when the model says “task complete,” that does not mean the task is actually complete.
• Ambiguous goals: “optimize the payment system” may refer to performance, stability, security, or maintainability.
• Expensive verification: passing tests does not mean there is no performance regression, security vulnerability, or architectural debt.

So AI Coding is harder than a Kubernetes Operator. It needs not only reconciliation, but also stronger goal definition and evaluation systems.

Maker-Checker as Admission Controller

Why are more Agent systems now splitting maker and checker roles? The reason is simple: you cannot fully trust the executor.

The Agent that writes code may self-confirm. It may say “fixed” without running enough tests. It may say the solution is cleaner while introducing new risk. So another independent role is needed to inspect it: run tests, check the diff, scan for security issues, read logs, and decide whether the goal is truly satisfied.

This has a similar engineering intuition to Admission Controller and Validating Webhook in Kubernetes: do not let an action enter the system directly. Pass it through policy, validation, and constraints first.

Future Agent systems will probably have more layers:

1
2
3
4
5

Maker
  -> Checker
  -> Reviewer
  -> Policy Engine
  -> Human

This is not making the workflow complicated for its own sake. It is adding a control system around a probabilistic executor.

The Real Ceiling Is Goal and Evaluation

The core of Loop Engineering is not only designing loops. At a deeper level, it is trying to solve Goal and Evaluation.

Kubernetes works reliably because Desired State is formalized. The completion condition for replicas: 3 is clear: the actual replica count equals 3. There is no aesthetic judgment and no “close enough.”

AI Coding’s biggest problem sits right here. Many goals are fuzzy:

• “Help me optimize this system.”
• “Refactor the user module.”
• “Fix the online stability issue.”
• “Make this code easier to maintain.”

If these goals are not decomposed into observable, verifiable, and stoppable conditions, the loop is hard to converge. The Agent does not know when to continue, and it does not know when to stop.

A more reasonable form should look closer to this:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28

goal:
  description: "Fix the payment system concurrency issue"
  metrics:
    correctness:
      unit_test_pass_rate: "100%"
      integration_test_pass_rate: "100%"
    performance:
      latency_p99: "< 100ms"
      throughput: ">= 1000 tps"
    safety:
      critical_vulnerability: 0
      data_race: 0

evaluation:
  layers:
    - unit_test
    - integration_test
    - e2e_test
    - benchmark
    - static_analysis
    - security_scan
  judge:
    model: "independent-checker"
    threshold: "all_layers_pass"

loop:
  max_iterations: 20
  strategy: "exponential_backoff"

At this point, what we write is no longer just a prompt. It looks more like an Agent CRD. The important fields are no longer whether we choose Claude or GPT, but goal.metrics and evaluation.layers.

Software Engineers Will Look More Like Control System Engineers

This shift does not necessarily mean AI will directly replace engineers. A more likely outcome is that the center of gravity of engineering work changes.

In the past, engineers mainly wrote code. In the future, engineers will spend more time designing goals, validation, state, and feedback:

• Translate vague business intent into convergent goals.
• Design multi-layer evaluation pipelines.
• Move Agent memory out of the conversation and into repositories, task boards, and persistent state.
• Define the boundaries between maker, checker, and reviewer.
• Define stopping conditions and retry strategies.
• Decide what must still be confirmed by a human.

Prompt Engineer may gradually fade, not because prompts are useless, but because prompt writing itself will be systematized. The scarcer abilities will become Goal Engineering and Evaluation Engineering.

Conclusion

Loop Engineering is not a new concept appearing out of nowhere. It is more like the revival of control theory, state machines, feedback systems, Kubernetes controllers, and the Operator Pattern in the age of AI Coding.

Understanding this change can be split into four layers:

1. Structural similarity: Loop resembles Operator.
2. Implementation similarity: Agent resembles Controller.
3. Essential similarity: Goal resembles Spec, Evaluation resembles Status.
4. The most important layer: AI Coding is not automation of code writing, but automation of moving toward a goal.

Every system that automatically moves toward a goal eventually returns to control theory: whether the goal is clear, whether the state is observable, and whether the feedback is accurate.

So the most important question for AI Native software engineering over the next decade may not be “which model is stronger?” It may be: when software starts modifying itself, how should we design the control loop that constrains it, verifies it, corrects it, and finally decides whether to trust it?