Andrew Ng’s Three‑Layer Loop: Faster Agents Demand Slower Human Feedback

Loop Engineering has become a hot topic, with Peter Steinberger emphasizing a shift from prompting coding agents to designing the prompt‑agent loop, and Boris Cherny noting that “my work is writing loops.” This transition is a natural extension of the author’s ongoing work on Agent engineering.

Three‑Layer Loop

Andrew Ng breaks 0‑to‑1 product development into three layers:

Agentic coding loop : runs in minutes; the agent receives a specification and a set of acceptance tests, writes code, runs tests, fixes bugs, and iterates until the spec is satisfied.

Developer feedback loop : spans tens of minutes to hours; developers review the current product, adjust the specification, interaction design, and scope, and decide the next direction.

External feedback loop : ranges from hours to weeks; real users, alpha/beta tests, A/B experiments, and market changes feed signals back into the product vision.

When placed into the broader Loop Engineering pipeline, these layers form a complete chain: the inner layer checks whether code runs, the middle layer verifies whether the specification still makes sense, and the outer layer asks whether the problem itself is worth pursuing.

Agentic Coding Loop Details

Given a product spec and a suite of tests, the agent writes code, runs the tests, discovers failures, and continues fixing until the results meet the spec. This mirrors the author’s earlier /goal discussion: a runnable goal must include scope, invariants, verification method, budget limits, and stop conditions. Ng cites a weekend typing‑practice app where the coding agent works for about an hour, repeatedly checks the output in a browser, and reports back.

Addy Osmani further decomposes the loop into engineering components—automation triggers, worktrees for isolation, skills for knowledge, connectors for tool integration, sub‑agents to split “do” and “check”, and a state file to record each iteration—addressing recurring problems of workspace isolation, asset persistence, verifier independence, and state handoff.

Limits of the Inner Loop

The agentic coding loop can only iterate within the given specification; it cannot decide whether the spec itself is correct. A wrong spec leads the agent to faithfully implement a flawed product, illustrating that speed alone does not guarantee correctness.

Developer Feedback Loop

Human work moves upward: translating vague vision into concrete specifications, incorporating real‑world context (user, scenario, constraints, competitive landscape), and recording decisions. The author prefers the term “context advantage” over “taste” because it is more actionable for engineering teams. Three lightweight artifacts are recommended:

SPEC : defines what to change, what to keep untouched, user scenarios, interface constraints, and acceptance evidence.

STATE : records the baseline, attempted solutions, passed verifications, discarded paths, and the next starting point.

FEEDBACK : captures real‑world signals (interviews, tickets, telemetry, A/B results), their evidence strength, and how they affect vision, specs, or acceptance criteria.

These records are valuable not for their format but for the handoff they enable between loops.

External Feedback Loop

The slowest but most valuable layer gathers real user feedback through alpha/beta testing, A/B experiments, and market observation. Ng notes that external data travels a longer path: it first influences developer vision, then detailed specs, and finally drives the coding agent. If feedback remains only in meeting minutes or AI‑generated summaries, it never reaches the system; it must become a new product judgment, a revised spec, or a new acceptance criterion for the next coding iteration.

AI can help collect, clean, and summarize signals, but the signals themselves cannot be fabricated by models.

Risks and Boundaries

Accelerating the inner loop without upgrading outer feedback can produce many internally consistent versions that miss the real user problem. Token consumption, long‑running sub‑agents, and scheduled tasks increase audit pressure, and prolonged automated changes can create “understanding debt.” Armin Ronacher warns that models tend to add local fallbacks for each failure, making the system harder to understand over time. The author’s earlier article on “Loop Engineering’s Continuous Cleanup System” discusses the same issue of complexity accumulation.

Therefore, loops are best applied to experimental, migration, performance‑exploration, or security‑scanning tasks—short‑lived, verifiable workloads. For core systems (persistent data structures, permission or billing services), invariants and design boundaries should still be guarded by humans.

Practical Adoption

Start with low‑risk scenarios (internal tool tweaks, UI optimizations, roll‑back‑able batch jobs) and run a one‑week trial. Record SPEC, STATE, and FEEDBACK for each iteration. Only after the handoff artifacts are reliable should the loop be extended to critical paths like core transaction pipelines.

Conclusion

Loop Engineering reshapes software development by compressing the time scale of implementation while expanding the human role to higher‑level vision, context capture, and feedback design. Proper interfaces between the three loops—clear specifications, state tracking, and feedback integration—are essential for turning fast AI‑driven coding into sustainable product development.