Continuous Cleanup of Architectural Entropy with Loop Engineering

Architecture entropy describes the state where a system accumulates hidden dependencies, outdated fields, and legacy logic that become increasingly costly to delete. A simple signal of entropy is when the risk of removal exceeds the cost of keeping the artifact, leading teams to adopt a "add‑only" approach that compounds complexity.

The article argues that Loop Engineering should be placed within architecture governance, not merely to run more cycles but to create a continuous feedback loop that surfaces, documents, and safely mitigates these burdens. Five concrete actions form the core of such a Loop:

Regularly discover new sources of complexity.

Write clear evidence for each finding.

Attempt fixes only within low‑risk boundaries.

Use independent verification to avoid self‑audit.

Stop the Loop when there is no progress, the risk is unclear, or a predefined limit is reached.

These actions are practical and form the basis for a sustainable cleanup system. However, not every task qualifies for a Loop; a task must satisfy three thresholds: it recurs often enough to merit automation, its outcome can be verified, and the benefit outweighs the cost of tooling and validation.

Why Deletion Becomes Expensive

Hyrum’s Law states that with enough users, every observable behavior will be depended upon by someone. In legacy systems this manifests as undocumented ordering guarantees, exception messages that become monitoring rules, or temporary fields that later become part of reports and scripts. Consequently, teams lose the ability to reason about impact, making retention cheap and deletion expensive.

Lehman’s laws of software evolution reinforce this: without dedicated effort to control complexity, it inevitably grows and quality degrades. Healthy architecture therefore requires a "metabolic" capability to absorb new demands while shedding old burdens.

Agent Amplification

In the AI Agent era, the friction that once forced engineers to discuss and document changes is reduced. Agents can quickly generate code, update documentation, and produce test scaffolding, which accelerates short‑term development but risks embedding undocumented logic that later becomes hard to understand. As Naur noted, a program is a projection of the developers' mental model, not the model itself; agents do not inherit that mental model automatically.

The key question becomes: which constraints, validations, and state must remain in the system rather than only in the agent’s context?

Designing an Entropy‑Reducing Loop

A minimal Loop can be expressed as a narrow closed‑cycle:

触发 -> 读取状态 -> 扫描证据 -> 低风险修复 -> 独立验证 -> 写回账本

For an "architecture rule violation" example, the Loop consists of the following steps:

Trigger: PR updates, daily inspections, CI failures.

Input: Architecture rules, dependency scan results, current baseline, recent diff.

Writable scope: Modify only low‑risk files in an isolated worktree.

Forbidden actions: Do not expand the baseline, bypass checkers, or change production configuration.

Verification: Run architecture checks, related tests, ensure baseline has no new issues.

Stop: Limit to at most two rounds; stop if no new evidence; hand over cross‑team contracts to humans.

The state ledger—implemented as a simple Markdown file, issue, board, or database record—stores four kinds of information for each round: what was observed, what was done, what was verified, and what risk remains.

Loop Layers

Execution loop: Determines whether an agent can perform a concrete action (e.g., scan dependencies, modify a small file, add a test, open a PR).

Verification loop: Checks whether the result can be independently validated (e.g., architecture checks, lint, diff range checks).

Trigger loop: Decides when the Loop should wake up automatically (e.g., PR, CI failure, daily inspection, log anomaly).

Improvement loop: Evaluates whether the next round can avoid the same mistake, updating failure patterns, rules, and checkers.

These outer layers must rely on auditable rules, logs, and state files rather than solely on the agent’s internal context.

Three Common Pitfalls

Hidden step dependencies: Without explicit dependencies the system cannot know which step must wait for another, nor whether a failure invalidates subsequent actions.

Unbounded recovery: Re‑trying CI fixes without a round limit or progress detection can trap the Loop in the same pit indefinitely.

Summarized history loss: Chat context compression and log summarization erase the raw commands, diffs, and failure traces, leaving only a vague summary.

Corresponding remedies are to make dependencies explicit, impose recovery limits, and write full history back to the system.

Four Small Scenarios to Start

Architecture rule baseline: Scan for circular dependencies, cross‑layer calls, and illegal imports. Focus on preventing new violations; the baseline should only shrink.

Deprecated path inventory: Periodically analyze access logs, code search, documentation references, and alert rules to classify old interfaces, configs, and fields into categories (still receiving traffic, referenced without traffic, documentation‑only, ready for deletion review).

Documentation drift check: Reconcile README, CI configs, runtime scripts, and actual commands; verify that commands still run and environment variables still exist.

Checker health monitor: Detect checkers that have not failed for a long period; verify whether they are still effective or have become dead weight by checking rule skips, baseline growth, missing owners, and excessive runtime.

All scenarios share the principle of "read more, change less, keep evidence clear, and make the result easy to verify."

Human In The Loop

Loop Engineering does not eliminate human judgment; it surfaces problems early, provides evidence, and pushes low‑risk fixes to a candidate state while leaving final trade‑offs—such as compatibility cost and contractual obligations—to people.

A production Loop must also be able to stop: cost caps, round limits, no‑progress detection, and manual escalation must be defined upfront. Without an exit mechanism, a Loop behaves like a system that cannot be retired.

Conclusion

In the past, architectural decay was a problem of legacy systems; with AI agents it becomes a runtime issue that can accelerate both improvement and hidden complexity. The value of Loop Engineering lies in turning the "prompt‑then‑action" model into a small, stable entropy‑reduction cycle that continuously discovers, verifies, and retires legacy burdens.

Good Loops do not make final decisions for the system; they surface issues earlier, make evidence easier to audit, and help old burdens enter a retirement process.

References: Addy Osmani (Loop Engineering, 2026‑06‑07), LangChain (The Art of Loop Engineering, 2026‑06‑16), Firecrawl (Should You Stop Prompting Agents and Start Designing Loops, 2026‑06‑11), arXiv "From Agent Loops to Structured Graphs" (2604.11378), Hyrum's Law, Peter Naur (Programming as Theory Building), Martin Fowler (Software Architecture Guide), Chris Richardson (Lehman's laws of software evolution).