From Simple Prompts to Closed-Loop SOPs: Loop Engineering for Reliable AI Code

Introduction

The same requirement description leads to completely different AI behavior after applying Loop Engineering. The problem is not that the AI is dumb, but that the prompt lacks a critical structure.

When the same requirement is given to two developers to let the AI write code, one may receive code that works almost out‑of‑the‑box while the other receives buggy, incomplete code. The root cause is the prompt structure , not luck.

This article focuses on forcing a single prompt to make the AI follow a fault‑tolerant workflow, an upgrade from “telling AI what to do” to “specifying how AI should do it”.

A Real Confusion

Typical requirement‑driven prompt for a “Message Notification Settings” page:

在 src/views/settings/notification.vue 新增一个消息通知设置页面：
1. 支持 3 种通知类型开关：系统通知、活动推送、短信提醒
2. 开关状态从接口 /api/notification/config 获取
3. 切换开关时调用 /api/notification/update 保存
4. 页面顶部显示「通知设置」标题

The prompt is clear and the AI can generate code, but it usually writes the whole page in one go and says “Done”. Running the generated code reveals issues such as:

No loading state after toggling, so the user cannot see whether the save succeeded.

Unprocessed error codes from the API, leading to silent failures.

Rapid clicking of the three switches sends new requests before the previous ones finish.

All listed requirements are satisfied, yet the result still needs 5‑10 % manual tweaking.

Where Is the Problem?

The prompt describes *what* to achieve but omits *process constraints*. The AI’s behavior follows the pattern:

Read requirement → write code directly → deliver

There is no “brake” mechanism; the AI does not ask clarifying questions such as whether to debounce the switch, roll back on API failure, or enforce mutual exclusion. The prompt simply does not require the AI to consider these aspects.

Adding a “Brake System” to Prompts

A different prompt structure for the same requirement introduces explicit stages:

## 0. Meta
- Requirement: Message notification settings page
- Modified file: src/views/settings/notification.vue
- Loop state: IDLE

## 1. Context Anchor
| Role | File | Description |
|------|------|-------------|
| Target page | src/views/settings/notification.vue | New file |
| API wrapper | src/api/notification.js | Existing, need to confirm export |

## 2. Spec (same as above, omitted)

## 3. File Change List (incremental boundary)
> Only modify the locations listed; other code must not be changed.

| File | Change point | Type |
|------|-------------|------|
| src/views/settings/notification.vue | Whole new file | Add |
| src/api/notification.js | Add getConfig/updateConfig methods | Add |

## 4. Execution Loop

### L0: Anchor (must be completed before AI acts)
- [ ] Read src/api/notification.js and record existing methods
- [ ] Confirm the project's request library (axios / fetch / custom)
- [ ] Check other settings pages for loading/debounce behavior

### L1: Execution Order
1. Write src/api/notification.js (API wrapper) first
2. Then write src/views/settings/notification.vue (page)

### L2: Verification Checklist
| ID | Check item | Expected | Result | Evidence |
|----|------------|----------|--------|----------|
| V-A1 | getConfig method exists and path correct | GET /api/notification/config | _ | _ |
| V-A2 | updateConfig receives correct params | Receives { type, enabled } | _ | _ |
| V-B1 | All three switches bound with v-model | Two‑way binding works | _ | _ |
| V-B2 | Switch toggle shows loading state | Disable during request, re‑enable after | _ | _ |
| V-B3 | Failed API rolls back switch state | Restore previous value in catch | _ | _ |
| V-R1 | Existing notification.js unchanged | Preserve original behavior | _ | _ |
| V-X1 | API method names match between page and file | No typo | _ | _ |

### L3: Fix Rules
- Only fix FAIL items; do not modify PASS items
- If the same item fails twice consecutively → pause and report to human

## 5. Exit Conditions
| Scenario | Action |
|----------|--------|
| All PASS | Output final diff |
| FAIL remains after 3 rounds | Output unresolved issue list, hand over to human |

The same requirement, but the prompt structure is completely different.

Fundamental Differences Between the Two Prompt Types

Difference One: Cognitive Load Before AI Acts

Ordinary prompts : AI reads the requirement and writes code immediately, basing its entire understanding on the description. Missing details lead to guesses.

Loop prompts : AI must first anchor —read existing files, record line numbers, confirm export methods—before making any changes. This step builds a concrete view of the current code base.

Anchoring eliminates many low‑level errors such as “AI invents non‑existent functions” or “AI redefines existing variables”.

Difference Two: Self‑Review After Completion

Ordinary prompts : AI finishes and says “Done”. Verification is left to the human.

Loop prompts : AI must fill a verification checklist with PASS/FAIL and line‑number evidence for each item.

This forces the AI to look back at its own output, reducing error rates similarly to a programmer reviewing code against a checklist before committing.

Difference Three: Bug‑Fix Boundary

Ordinary prompts : When a mistake is pointed out, the AI may unintentionally modify unrelated code.

Loop prompts : The rule “only fix FAIL items, never touch PASS items” prevents the AI from introducing new bugs while fixing existing ones.

Limitations

Loop Engineering assumes the AI tool follows instructions. If the AI skips L2 verification and simply reports “All PASS”, the two prompts become indistinguishable.

The specification itself is wrong.

The change is trivial (e.g., copy‑paste, UI tweak).

The underlying AI model lacks sufficient capability.

The ideal scenario for Loop Engineering is medium‑to‑high complexity tasks involving multiple files, state dependencies, and high error‑cost.

Final Thoughts

The core of prompt writing is not merely making the requirement clear; it is requiring the AI to self‑constrain during execution.

Ordinary prompts are like telling a chef “I want Kung Pao chicken, less spicy”. Loop Engineering prompts are a SOP: check ingredient freshness, follow standard seasoning ratios, self‑inspect temperature and color before serving, and reject dishes that do not meet standards.

The ceiling of AI‑assisted programming quality depends on how many “brakes” are embedded in the prompt, not on how smart the AI is.