Loop Engineering: how to design loops that run coding agents themselves

The conversation begins with checking the status of the source. The HuaShu text looks like a scientific publication, but is an independent working note: it brings together the ideas of Addy Osmani, Anthropic and other practitioners, is not peer reviewed, does not contain a controlled experiment and does not represent the position of IEEE or Anthropic.

The main role change is the exit of a person from each turn. Prompt engineering controls one call, context engineering controls the filling of the current window, harness engineering controls tools and the completion of one run. Loop engineering adds reruns, scheduling, feedback, and state between runs.

One pass of the loop consists of five required movements. Discovery finds relevant work; handoff isolates it for the performer; verification accepts or rejects the result; persistence saves state outside of conversation; scheduling starts the next pass. They are implemented by automations, worktrees, skills, connectors, sub-agents and memory. A simple timer does not yet create a loop: without discovery, test feedback and external state, the system only repeats one command. Omissions produce recognizable failures - a blind, confused, yes-ying, forgetful or completely manual cycle.

The hardest part is the evaluator being able to say no. The author of the solution is already convinced by his own chain of reasoning, so the individual reviewer begins with pure context and a skeptical role. It should evaluate not just a confident self-report and not just diff, but observed behavior: run tests, open an interface, check the API and data state, collect evidence. Even green tests do not prove the completeness of the result, and the LLM-evaluator also makes mistakes, so deterministic gates and human review remain part of the design. Expensive testing is justified primarily where the task goes beyond the reliable solo operation of the model.

The invisible work of agents creates four related debts. Unverified output accumulates verification debt; rapid changes blur understanding of the system; then cognitive surrender occurs - the person stops forming his own judgment; retries and helpers inflate token consumption. When generating code, plans and PR becomes cheaper, the bottleneck becomes judgment: deciding which task is worth doing, what to trust and where to stop. Throughput, without taking into account defects, review and recovery time, rewards the wrong result.

It is recommended to make the first production loop small but complete: one source of tasks, one finding per pass, isolated worktree, external state, independent evaluator and mandatory human review. Before unattended run, limits on tokens, time, repetitions and actions are required; for external text - protection from prompt injection and minimal rights; for changes - audit trail, rollback and kill switch.