From Prompt to Loop Engineering: Is the Next‑Gen AI Computing Engine a Tool or an Operating System?

Introduction

AI is no longer a niche tool for actuaries; as every insurance business step becomes formula‑driven, the computing engine’s scope expands beyond traditional actuarial tasks. With AI lowering the barrier to "write code" through conversation, the development model itself is being re‑engineered into what the author calls Loop Engineering .

Three Topics Covered

Eight insurance scenarios outside actuarial work that urgently need a visual computing engine.

Eight AI‑era evolution directions for a universal computing engine.

Practical experience engineering Loop Engineering in the "云擎" project, including ten concrete Loops.

Part 01 – 8 Non‑Actuarial Computing Scenarios

Auto claim decision : real‑time auto, medical, and flash claim decisions with millisecond latency.

Underwriting risk engine : health disclosure underwriting and pre‑policy risk screening, typically >50 decision‑tree nodes.

Fraud score : hybrid rule engine + ML model, requiring interpretability.

Reserve calculation : chain‑ladder, triangle, case‑average methods; must be auditable.

Pricing tier : customer‑profile × product × channel rule‑based pricing formulas.

Reinsurance split : proportional, non‑proportional, temporary reinsurance with layered business rules.

ALM simulation : stochastic simulation, scenario analysis, stress testing with node‑level trace.

Regulatory report : frequent rule updates demand versioning and traceability.

Part 02 – 8 Evolution Directions in the AI Era

🗣️ Direction 1: NL2Formula – Natural‑Language‑to‑Formula Graph

Business users describe requirements in plain language (e.g., "30‑year‑old male, life‑insurance 20% discount, VIP extra 10% discount"), and an LLM generates a DAG that can be manually reviewed and edited.

🧬 Direction 2: AI Operators – ML Models as First‑Class Nodes

ML model outputs are seamlessly chained with arithmetic nodes, enabling "rule + ML" hybrid graphs that are more intelligent than pure rules and more explainable than pure ML; nodes support ONNX, PMML, or custom HTTP calls.

🔍 Direction 3: Intelligent Diagnosis & Trace Interpretation

After execution, an LLM parses trace logs to pinpoint abnormal nodes and explains results in natural language, moving from raw node outputs to actionable diagnostics.

⚡ Direction 4: Adaptive Computation Graph

The engine automatically optimizes based on historical execution data: merging redundant nodes, caching hot results, skipping unlikely branches, and applying branch‑prediction based on data distribution.

🔐 Direction 5: Privacy Computing & Federated Nodes

In cross‑institution collaborations, nodes operate without exposing raw data (e.g., multi‑insurer anti‑fraud modeling) using MPC, homomorphic encryption, or federated learning protocols.

🧪 Direction 6: AI‑Generated Test Cases

LLMs read DAGs and automatically produce boundary‑value and equivalence‑class test suites, execute them, compare results, and generate full‑chain reports.

🌊 Direction 7: Streaming & Real‑Time Computing

Beyond one‑off input → output, scenarios like telematics require continuous input streams; the engine supports Kafka/WebSocket sources, time windows, sliding averages, and state accumulation.

🤝 Direction 8: AI‑Co‑Development & Auditing

AI assists not only in formula generation but also in reviewing logic flaws, suggesting regulatory‑driven modifications, and drafting documentation for business users.

Key Insight

AI will not replace the computing engine; it will upgrade the engine from a "drawing tool" to a "business‑model operating system"—much like Excel became a data source for BI tools.

Part 03 – Loop Engineering: A New Craft for the AI Era

Core definition: Loop Engineering is the engineering of tight, automated, observable, and persistent feedback loops that make each AI‑generated code iteration instantly verifiable.

Ten Loops Implemented in the 云擎 Project

L1 – Compile Loop : mvn compile -DskipTests (≈3 s) – catches type errors, missing imports, signature mismatches.

L2 – JUnit Test Loop : mvn test (≈15 s) – validates business logic with ~30 core service tests.

L3 – Docker Full‑Stack Loop : cd docker && docker‑compose up -d (≈60 s) – spins up MySQL, backend, frontend containers to verify deployment health.

L4 – API Smoke Loop : curl http://localhost:8080/api/v1/… (≈1 s) – lightweight end‑to‑end check of HTTP status and JSON response.

L5 – Python Integration Test Loop : python3 tests/test_api.py (≈20 s) – cross‑language, cross‑layer validation of normal and error paths.

L6 – Playwright Visual Loop : python3 tests/test_ui_playwright.py (≈45 s) – real browser screenshots verify UI interactions.

L7 – Database Verification Loop : python3 tests/test_database.py (≈5 s) – direct SQL checks of foreign keys, indexes, data consistency.

L8 – Calculation Accuracy Loop : python3 tests/test_calculation_accuracy.py (≈5 s) – ensures actuarial numbers stay within 0.01 tolerance.

L9 – Persistent Context Loop : stores project conventions and lessons in .claude/projects/.../memory/*.md (0 s) – provides long‑term memory across sessions.

L10 – Runtime Log Loop : SELECT * FROM execution_log (≈2 s) – persists execution traces for post‑mortem analysis.

Loop Economics

Reducing a Loop’s latency dramatically increases iteration capacity:

Compile Loop: 3 s → 1 200 iterations/hour → 9 600 per 8‑hour day (300× baseline).

Test Loop: 15 s → 240 iterations/hour → 1 920 per day (60×).

Docker Loop: 60 s → 60 iterations/hour → 480 per day (15×).

Manual test: 5 min → 12 iterations/hour → 96 per day (3×).

Manual deployment: 30 min → 2 iterations/hour → 16 per day (baseline).

Compressing a Loop from 30 s to 3 s yields a ten‑fold increase in daily iterations, representing an exponential boost in R&D productivity. The bottleneck is the feedback loop, not AI code generation speed.

Four Attributes of a Good Loop

Latency : total time from trigger to feedback; sub‑3 s loops enable thousands of daily runs.

Determinism : identical inputs must produce identical outputs; flaky tests destroy trust.

Observability : failures must surface clear diagnostics (stack trace, screenshots, SQL output, HTTP body) for AI to generate precise fixes.

Persistence : Loop artifacts must be reusable across sessions, personnel, and AI agents (e.g., test suites, CI pipelines, documentation).

Engineering a New Loop (4 Steps)

Identify pain points – any manual verification step is a Loop candidate.

Script the manual action using Python or Shell so it can run non‑interactively.

Assert outcomes programmatically (e.g., assert response.status_code == 200).

Make failure output AI‑readable (e.g., tabulated SQL results, HTML diffs).

Concrete Example – API Smoke Loop L5

def test_formula_publish_flow():
    # 1. Create formula
    formula = create_formula(name="测试公式", category="保费计算")
    # 2. Save graph (3 nodes)
    save_graph(formula.id, nodes=[input_node, arithmetic_node, output_node])
    # 3. Publish
    resp = post(f"/formulas/{formula.id}/publish")
    assert resp.status_code == 200
    # 4. Published state should reject further edits
    resp = put(f"/formulas/{formula.id}/graph", ...)
    assert resp.status_code == 403

Five Anti‑Patterns

Loose Loop : manual verification without automation; quickly abandoned.

Hallucination Loop : AI writes a self‑validating script that always reports pass; external validation is required.

Mock Loop : tests run against mocks and fail in production; real resources must be exercised.

Isolated Loop : scattered test files never aggregated; all Loops must be runnable with a single command.

Flaky Loop : nondeterministic failures break trust; Loops must be idempotent and state‑isolated.

Conclusion

In the next decade, the computing engine will evolve from a "tool" into a "business operating system," and Loop Engineering will mature from a development trick into a core engineering capability for the AI era.

Make every line of calculation visible; make every Loop respond in seconds.