跪拜 Guibai
← All articles
Artificial Intelligence

A Solo Developer's Loop Engineering System That Learns From Its Own Mistakes

By 神奇小汤圆 ·
Read original on juejin.cn ↗ Google Translate ↗ Alt translation

Solo developers and small teams get a production-tested alternative to vibe coding that catches confirmation bias, review fatigue, and institutional amnesia through systematic constraints rather than discipline. The memory loop means the system's review accuracy improves with use — a compound effect that prompt-by-prompt workflows cannot replicate.

Summary

Loop Engineering replaces ad-hoc AI prompting with a structured seven-agent pipeline: clarify, architect, third-party review, dev, review, qa, and retro. Each agent runs in an isolated context with model assignments matched to cognitive demands — Opus for high-judgment review, Sonnet for fast execution. The review agent predicts likely defect areas before reading code, using a memory bank of hard-won, codebase-specific incident patterns that grows with every completed feature. A state-machine orchestrator enforces hard gates: critical issues block the loop, minor issues must be fixed if low-risk, and the pipeline terminates after five rounds to prevent token burn.

The system's real differentiator is an evolution loop. After each feature, the retro agent stores only non-Googleable, codebase-specific, hard-won lessons into a capped memory of 5–8 files. The next feature's review retrieves these patterns as starting points for pre-commit predictions, creating a measurable calibration loop where missed defect types expose cognitive blind spots. Over six months, prediction hit rates rose from roughly 50% to over 70% without any model upgrade.

Known bottlenecks include context-window pressure from accumulating review documents, shared blind spots between review and qa running on the same model family, and the pipeline's excessive weight for trivial tasks. The system also assumes a well-maintained CLAUDE.md; garbage project context produces garbage output across all agents. The repository installs with a single script into ~/.claude and runs via four slash commands in any project.

Takeaways
Seven specialized agents form a pipeline: clarify, architect, third-party review, dev, review, qa, and retro, each with isolated context windows and model assignments matched to task demands.
The clarify agent asks exactly one question per turn and reads code first; batch questioning is forbidden to match human serial attention.
Review predicts 3–5 likely defect areas before reading any code, using memory of past incidents as starting points, then records both hits and prediction misses.
Critical and Important review findings block the pipeline; Minor issues must be fixed if the change is ≤20 lines, single-file, and has no side effects — no deferral allowed.
Retro stores only non-Googleable, codebase-specific, hard-won lessons into a memory capped at 5–8 files; platitudes like "write tests" are explicitly excluded.
The /ship orchestrator is a state machine that skips QA when review blocks, terminates after 5 loops, and enforces incremental-append documentation with no deletion of history.
Cross-vendor design review runs design.md through a non-Anthropic model before any code is written, catching Claude-family blind spots without blocking the pipeline.
Context windows strain under multi-round loops as review documents grow; automatic summary compression of historical chapters is in development.
The pipeline is too heavy for trivial tasks; classifying task size currently relies on developer intuition rather than automation.
All agents depend on an accurate CLAUDE.md — blank or stale project context produces garbage output across the entire pipeline.
Conclusions

Review fatigue is not laziness but cognitive economics: when 95% of AI output is correct, the brain automatically reduces scrutiny, and the 5% of errors don't self-label.

Running review and qa in isolated subagents prevents the dev agent's thought process from contaminating the reviewer's judgment — a subtle but critical design choice.

The "low-risk fix" rule trades frictionless execution for zero technical debt accumulation, closing the loophole where minor suggestions get perpetually deferred.

Memory quality matters more than quantity for evolution: storing 100 generic platitudes degrades retrieval signal, while 7 precise, codebase-specific patterns raised prediction hit rates from ~50% to ~70%.

The pre-commit prediction mechanism creates a measurable calibration loop — missed defect types become explicit cognitive blind spots that drive the next round of system improvement.

Loop Engineering's compound advantage is that process rules themselves evolve: each agent's current constraints are the accumulated design judgment from dozens of prior loop iterations.

The system's honest defect list — context-window pressure, model-family collusion, heavy process for small tasks — shows the gap between a working pipeline and a polished product.

Concepts & terms
Loop Engineering
A development paradigm where autonomous agent loops prompt, verify, and iterate toward a goal, replacing single-shot prompt-and-response workflows. The loop itself accumulates knowledge, calibration, and process improvements across iterations.
Maker-Checker Architecture
A separation-of-duties pattern where one agent (maker) produces output and a different, isolated agent (checker) independently verifies it, preventing the checker from being influenced by the maker's reasoning.
Pre-Commit Prediction
A review technique where the reviewer predicts likely defect areas based on design documents before reading the implementation, then compares predictions against actual findings to measure and improve calibration.
Low-Risk Fix Rule
A policy requiring immediate repair of minor issues when the fix is objectively justified, has no side effects, touches ≤20 lines in a single file, and needs no user confirmation — eliminating perpetual deferral of small problems.
Evolution Loop
The retro → memory → next-feature cycle where hard-won, codebase-specific lessons are stored and retrieved to improve future review predictions, creating a compound improvement effect distinct from the code-level dev → review → qa loop.
Source: juejin.cn ↗ Google Translate ↗ Backup ↗