Loop Engineering Is Not New: The History of Loops as the Fundamental Building Block of Software

The New Vocabulary: Loop Engineering

The term comes from a practical shift in how people use coding agents. Instead of writing a prompt, reading the response, and writing the next prompt, you build the system that does the prompting for you. Google engineer Addy Osmani gave the pattern its name: a loop is a recursive goal — you define a purpose and let the agent iterate until it is met. Practitioners around Claude Code and Codex have been converging on the same idea, with Anthropic’s Boris Cherny describing his own work as writing loops that run the agent rather than prompting it directly.

The building blocks people list are real and useful: automations that schedule and triage work, worktrees that let parallel agents run without overwriting each other, skills that persist project knowledge between runs, connectors that wire in external tools, sub-agents that split making from checking, and a memory layer that holds state outside the conversation. Claude Code, Codex, and Devin all operate on this model: give the agent a task, a codebase, and tools, and it loops — read, write, run, read the errors, revise, repeat.

It is a useful frame. It is also not new. The loop is the oldest idea in computing.

Before AI, Programs Were Already Loops

The first computers were not prompt-and-response systems. They were machines executing a cycle: fetch an instruction, decode it, execute it, update state, repeat. The CPU itself is a loop. Every program ever written runs on top of that loop. The abstraction predates AI by decades, and nothing about it was incidental — repetition over changing state is what computation is.

Structured Programming Made Loops Explicit

Between the 1960s and 1980s, languages lifted the loop out of machine code and into syntax: for, while, do-while, and recursion. Developers stopped thinking in instructions and started thinking in control flow. The loop became the primary unit of behavior, and structured programming was, in large part, a discipline for keeping loops comprehensible.

Event Loops Took Over Modern Software

Then everything became event-driven. A browser tab waits for an event, handles it, updates state, and repeats. A web server accepts a request, processes it, returns a response, and repeats. An operating system scheduler picks a task, runs it, switches context, and repeats. GUIs, web servers, and kernels are all loops at their core. Most production software already is loop engineering — we just stopped calling it that.

DevOps Introduced Autonomous Loops

CI/CD moved the loop past simple execution. A pipeline detects a change, runs tests, deploys, monitors, and rolls back — then repeats. For the first time the loop made decisions, and humans moved outside the execution path. We did not respond by trusting the loop blindly. We wrapped it in deployment gates, approvals, and policy.

Machine Learning Added Feedback Loops

Training is a loop: predict, measure the error, update the weights, repeat. Reinforcement learning is a loop: observe, act, receive a reward, update the policy, repeat. Intelligence itself, as the field builds it, is loop-based. The loop stopped merely executing fixed logic and started changing its own behavior over time.

Agents Put LLMs Inside Loops

This is the current shift. The structure is familiar — plan, act, evaluate, revise, repeat. What is new is the component sitting inside it. The loop is not the innovation. The model is. An LLM has become another executable inside a control system, the same way a function or a service was before it.

Why Everyone Suddenly Notices Loops

Because for the first time the thing inside the loop can generate genuinely new behavior. Traditional software is a loop wrapped around a deterministic function: same input, same output, predictable over a million iterations. An agent system is a loop wrapped around a probabilistic generator. Run it a thousand times and it explores a thousand slightly different paths.

The Real Innovation Is Governance of Autonomous Loops

Here is the pattern the loop-engineering discussion usually stops short of. Every historical increase in loop autonomy produced a corresponding increase in governance. Operating systems gained permission rings and process isolation. Databases gained ACID transactions. Cloud platforms gained policy engines like IAM and OPA. CI/CD gained deployment controls. The more autonomous the loop, the more its surrounding system had to constrain what the loop was allowed to do.

Agent systems are following the same arc. The next layer is not more loops, better harnesses, or smarter sub-agents — those are this generation’s execution machinery, and they are being solved. The next layer is governance of autonomous loops: deterministic constraints that decide what the probabilistic generator inside the loop is permitted to commit, applied before the change lands rather than discovered after. Even the loop-engineering advocates concede the seam — their own best practices say to define explicit exit conditions, persist state, and read what the loop merges rather than just watching tests pass. Those are governance instincts without a governance layer.

The Novelty Is Not the Loop

Loop engineering is not a new programming paradigm. It is the latest chapter in a seventy-year history of computing systems built around repetitive execution and feedback. The novelty is not that we have loops. It is that the actor inside the loop is now an AI capable of generating its own actions. That single change shifts the engineering challenge from execution to governance — from making the loop run to constraining what it does while it runs.