What Is Loop Engineering? Designing Systems That Direct AI

“Prompt engineering is over.” That claim is becoming increasingly common.

Instead of giving AI one instruction at a time, people are now building systems that supply instructions, verify the work, record state, and decide what should happen next. In July 2026, some observers went further and declared that “graph engineering” comes after loops.

Does that mean the ability to write prompts no longer matters? The opposite is closer to the truth.

Prompt engineering is not disappearing. What is declining is the need for a human to type every prompt manually. Prompts are moving into specifications, context, AGENTS.md, CLAUDE.md, skills, evaluation criteria, harnesses, loops, and graphs.

What is fading is the search for a magical phrase that makes AI obey perfectly in one attempt. What matters more is the ability to discover intent, values, constraints, examples, failure cases, evaluation criteria, and stopping conditions through dialogue with AI—and then encode them in a reusable system.

This article explains that shift using primary sources available as of August 2, 2026.

1. What Loop Engineering Means

The term “Loop Engineering” gained broad currency in its current sense after Addy Osmani published an article on June 8, 2026.

In simple terms, loop engineering means designing the system that repeatedly prompts an agent instead of remaining the person who manually prompts it every time.

Peter Steinberger argued that developers should design loops that prompt coding agents rather than continually prompting those agents themselves. Boris Cherny, who leads Claude Code at Anthropic, similarly described his work as writing loops that run Claude rather than issuing Claude one instruction after another.

The structure looks like this:

Goal and specification
        ↓
Discover and decompose work
        ↓
Execute
        ↓
Observe results, logs, and diffs
        ↓
Test, evaluate, and review
        ↓
Update state, plan, and documentation
        ↓
Retry if completion is not proven ↺

Completion, budget overrun, anomaly, or high risk
        ↓
Stop or escalate to a human

As a compact formula: Loop = Goal + State + Act + Observe + Evaluate + Update + Retry + Stop / Escalate.

The point is not to repeat the same prompt forever. A functioning loop must know what it is trying to achieve, where it is now, what it should do next, what evidence counts as correct, what changes after failure, when to give up, and when to call a human. Loop engineering is the construction of this control system for AI.

In a later essay, Osmani described the cycle as investigate, implement, verify, and repeat. Completion should be established by external evidence—tests or an independent evaluator—not by the model's own claim that it is finished.

Figure 1: A loop is more than repetition. It carries state forward, evaluates external evidence, and includes an explicit stopping gate.

2. The Loop Is Not New; Making It the Main Engineering Object Is

The cycle “reason, act, observe, decide what to do next” did not appear in 2026.

The 2022 ReAct paper interleaved reasoning and acting with observations from an environment. In 2024, Anthropic's guide to effective agents described evaluator-optimizer workflows, in which one model generates and another evaluates repeatedly, and orchestrator-worker workflows, in which a central model decomposes work for several workers.

In 2025, Geoffrey Huntley published the Ralph Wiggum loop, which repeatedly invoked Claude Code from a Bash while loop.

while :; do
  cat PROMPT.md | claude-code
done

The important part was not that one line of shell. Progress and learning were externalized into specifications, work plans, tests, Git state, and AGENTS.md so that each run could inherit the previous run's work. Huntley also emphasized that there is no perfect prompt: the prompt and environment must evolve as failures are observed.

The more accurate historical claim is therefore:

Loop engineering was not suddenly invented in 2026. It gave a name to the elevation of an existing agent loop from an individual trick into a systematic engineering object.

3. Prompt, Context, Harness, Loop, and Graph

Anthropic explicitly calls context engineering a natural progression from prompt engineering. Instead of optimizing only an instruction, it optimizes the full set of tokens available at inference time: system prompts, tool definitions, history, external data, and memory.

These terms are not replacements arriving one by one, and they do not form a simple set inclusion such as Prompt ⊂ Context ⊂ Harness ⊂ Loop ⊂ Graph. The useful observation is that the engineering target has expanded from a single utterance to the environment, then repetition, then organization.

How Harness Engineering Differs

A harness is the environment built around a model so it can perform real work. Osmani compares the model to an engine and the harness to the car built around it. Files, tools, memory, permissions, sandboxes, tests, monitoring, and recovery all belong to the harness. The loop repeatedly operates that machine and steers it toward a destination.

• Harness engineering designs the workplace in which AI operates.
• Loop engineering makes work repeat, evaluate itself, and continue in that workplace.
• Graph engineering connects and organizes several workplaces and cycles.

Figure 2: The model is the engine, the harness is its controlled environment, the loop is repetition, and the graph orchestrates multiple processes.

When AI Writes AGENTS.md

In an internal development case study published in February 2026, OpenAI reported that Codex created the initial repository structure, CI configuration, formatting rules, and even the first AGENTS.md. Over roughly five months, the project reached about one million lines of code and about 1,500 pull requests.

This was a special internal experiment, not a general productivity benchmark. It nevertheless supports the view that a human does not need to hand-author a perfect AGENTS.md from the outset. Claude Code follows a similar pattern: /init examines a repository and drafts CLAUDE.md from the build process, tests, and conventions it discovers.

The likely workflow is not “the human writes every word of the harness.” It is the AI investigates the repository, asks the human what cannot be inferred, drafts the harness, and the human approves its intent and boundaries.

Generation Is Not Ownership

Letting AI draft a harness is reasonable, but it cannot document what it cannot observe. In OpenAI's case, the initial bottleneck was not insufficient model capability. The environment, tools, abstractions, and internal structure were not sufficiently legible to the agent.

A huge AGENTS.md also buried important constraints and accumulated stale information. OpenAI replaced it with a short map pointing to more detailed documentation. Plans became version-controlled, first-class artifacts rather than temporary conversation state.

AI can generate a harness. Humans must own its meaning.

4. What Graph Engineering Means

“Graph Engineering” drew sudden attention after Peter Steinberger asked on July 18, 2026 whether people were still discussing loops or had moved on to graphs.

The post triggered claims that loop engineering was dead and graphs were next. Steinberger did not, however, publish a formal definition or framework. Prefect described the surge as excitement ignited by an almost offhand remark.

A practical working definition is:

Connecting multiple agents, tools, evaluators, humans, and loops as nodes and edges, then designing dependencies, branches, parallel execution, joins, permissions, and state transitions.

A node need not be an AI agent. It can be a conventional program, test, database query, external API, evaluation model, or human approval. An edge can mean continue on success, return on failure, take branch A under a condition, start several jobs in parallel, join after every result arrives, escalate above a risk threshold, or stop after a budget limit.

[Requirements]
      ↓
[Design review]
   ↙        ↘
[Backend] [Frontend]
   ↘        ↙
 [Integration test]
      ↙     ↘
[Human gate] [Repair loop ↺]

Prefect defines a directed agentic graph as a structure in which nodes represent units of work or business logic and edges define paths to subsequent calls. Its continuity with traditional DAG workflow systems is explicit.

Are Graphs a Superset of Loops?

Not in the simplistic sense often implied. Mathematically, a loop can be represented as a graph with a cyclic edge, so graphs are a more general structure. In practice, however, a task with one clear goal, one repository, one evaluation criterion, and a sequential path does not need a complex graph.

Adding multiple agents, shared state, branches, and joins to a task that needs only a simple loop increases failure points, coordination conflicts, debugging cost, token consumption, and observability burden.

Graph engineering is not a next-generation replacement for loops. It is an orchestration layer that arranges multiple loops and processes.

The graph in this usage should also be distinguished from a knowledge graph. A knowledge graph organizes what AI knows. An execution graph organizes what it does and in what order. A trace graph records what it actually did. A governance graph identifies where approval belongs. The current discussion is primarily about execution and control graphs.

The implementation predates the label. Google ADK 2.0 treats agents, tools, and functions as nodes in a graph-based execution engine and supports branching, iteration, multi-agent collaboration, automatic retry, and human-in-the-loop pauses. The graph itself is not new; the phrase “Graph Engineering” surged in July 2026.

5. Prompts Move Into Systems Instead of Disappearing

OpenAI still maintains official documentation for prompt engineering. The direction of production practice, however, is to manage prompts as application code with types, code review, tests, evaluations, and deployment processes rather than temporary text in a chat box.

This is not prompt extinction. Prompts are moving from conversation fields into source code, version control, and tests.

Small tricks are likely to matter less: phrases that supposedly unlock intelligence, declarations that the model is “the world's best expert,” one giant prompt that decides everything, and spell books exploiting model-specific quirks. Purpose and non-purpose, priorities, decision principles, examples and counterexamples, evaluation criteria, uncertainty, questions for the AI, authority boundaries, stopping conditions, and evidence of completion matter more.

Prompt engineering is not ending. The unit of prompting is expanding from a single message into specifications, context, harnesses, loops, and graphs.

Ask AI to Investigate and Design With You

Rather than specifying every detail of AGENTS.md in advance, ask the AI to inspect the repository, discuss what is needed, propose best practices, and only then create the file. This aligns with OpenAI's Codex best practices.

For complex, ambiguous work, the agent should plan first, ask questions, challenge human assumptions, and help make a vague idea concrete. A useful meta-prompt looks like this:

Design an agent harness appropriate for this repository.

Do not start writing AGENTS.md immediately.
1. Inspect code, CI, tests, structure, and existing documentation.
2. Separate facts you can infer from questions you cannot answer.
3. Ask me the unresolved questions in priority order.
4. Propose AGENTS.md, skills, hooks, tests, permissions, and stop conditions.
5. Explain the rationale, benefits, drawbacks, and maintenance cost.
6. Generate files only after approval.
7. Run a real task to verify that the harness works.

This is not prompt engineering as the writing of a perfect command. It is a prompt for discovering a specification together. A strong prompt increasingly resembles a well-designed meeting, product critique, one-on-one, or requirements session.

Voice-Driven Agent Engineering

When Andrej Karpathy popularized “vibe coding” in 2025, his original post described speaking to AI through SuperWhisper and barely touching the keyboard. Voice was present in the original practice. “Vibe coding” later became the Collins Dictionary Word of the Year for 2025.

Using voice does not by itself make development vibe coding. Simon Willison distinguishes vibe coding from ordinary AI-assisted development: in vibe coding, a person barely reviews the generated code or diff and proceeds on the feel of the result.

When tests, review, harnesses, and design consultation are present, voice-driven agent engineering or conversation-driven harness engineering describes the practice more accurately. These are useful descriptive phrases, not established formal terms.

Figure 3: Voice is valuable not only because it is fast. It can carry hesitation, unease, and exceptions into a joint specification-discovery process.

The ideal sequence is for a person to speak both concrete needs and abstract unease; for AI to correct transcription, structure intent, constraints, and unknowns, and return what it does and does not understand; for the human to correct that interpretation; and only then for the AI to inspect the repository and propose specifications, a harness, and evaluation criteria. The human approves boundaries and priorities before execution begins as a loop or graph.

Voice can transmit ambiguity, hesitation, emotion, exceptions, and discomfort before they are flattened into polished prose. Its weaknesses are mistranscription and jumps between topics. Instead of implementing immediately, the AI can first be asked: “Summarize what I said and separate decisions, hypotheses, open questions, contradictions, examples, and counterexamples.”

6. Concrete and Abstract Thinking—and What Humans Cannot Fully Verbalize

Koh Hosoya's Concrete and Abstract: The Structure of Intelligence That Changes How the World Looks was published by dZERO on November 27, 2014. The author describes movement between the concrete and the abstract as the foundation of thought. The book warns against a culture that values only what is concrete and easy to understand. The publisher reported in 2022 that it had reached its twenty-first printing and 70,000 copies.

No evidence found in this research supports the claim that the book caused businesspeople to start saying “to make that concrete.” That would in fact reverse the book's criticism of treating concreteness as automatically superior.

The spread of phrases such as “make it concrete,” “raise the resolution,” and “show the numbers” is more plausibly a combination of KPI and OKR practice, acceptance criteria in agile development, consulting presentation styles, meetings that demand rapid conclusions, and social-media and slide cultures that reward immediate clarity. This is an inference about multiple causes, not a verified origin story.

Only concrete examples make an AI overfit to examples. Only abstractions leave it unable to verify correctness. The required motion is from abstraction to concrete implementation, then back to abstraction to check whether meaning was lost.

A statement such as “verbalization removes 70 to 90 percent of information” is not a scientific figure established by the book; it should be presented as a personal metaphor. The underlying concern remains valuable: language compresses experience, and nuance can disappear during that compression.

Humans cannot verbalize 100 percent of what is in their minds. The crucial ability is therefore not perfect verbalization but recognizing what has been articulated and what has not.

• I know the direction, but not the best structure.
• I like this example, but cannot yet explain why.
• The technical requirements are fixed, but the UX remains unclear.
• I do not know the right answer, but I can show what feels wrong.
• I am undecided about whether A or B takes priority.
• An inarticulate discomfort remains; please ask me questions.

These are not merely vague prompts. They precisely locate the ambiguity. Language skill in the AI era is shifting from delivering a complete answer to making incomplete thought available for joint exploration.

7. How Much Can Today's AI Be Trusted to Do?

The important change appears less in isolated answers than in the length of time over which a model can maintain one objective and recover from failure.

In a February 2026 experiment, OpenAI reported that Codex worked for roughly 25 continuous hours from an empty repository, used about 13 million tokens, and produced about 30,000 lines of code. It repeatedly planned, implemented, tested, repaired failures, and updated documentation.

OpenAI explicitly described this as an experiment, not a production deployment. Running for a long time is not equivalent to being unconditionally trustworthy in ordinary business work.

The 2026 MirrorCode paper showed agents reconstructing relatively large programs from externally observable behavior. One large run, however, took 19 days and cost about $2,600. Tasks with precise requirements were more likely to succeed.

METR's Time Horizon is also frequently misunderstood. It does not tell us how many hours an AI can simply be left alone. It estimates the difficulty, measured in expert-human work time, of tasks a model can complete at a chosen success probability. Estimates beyond sixteen hours are currently less reliable, and the benchmark focuses mainly on clearly specified, self-contained, automatically gradable software, machine learning, and cybersecurity tasks.

AI is approaching a level at which it can perform long, multi-stage iterations when the boundary is clear, the outcome can be mechanically verified, and state is stored externally. It still does not automatically understand unspoken business intent, value judgments, organizational interests, or responsibility.

The capability boundary is determined less by “how long can it run?” than by what can count as verifiable correctness.

User Expertise Matters More, Not Less

Anthropic's analysis of Claude Code usage found that humans made about 70 percent of planning decisions in typical sessions while Claude made about 80 percent of execution decisions.

Prompts from users classified as beginners led to roughly five actions on average, while prompts demonstrating higher expertise led to about twelve. Expertise was not a job title. It was inferred from how well the user framed instructions, what they asked the AI to verify, and whether they corrected errors. Sessions showing task-specific expertise also had higher success rates.

As the amount of work an AI can execute from one instruction grows, the initial direction, evaluation criteria, and constraints have greater leverage. An AI that takes one step in the wrong direction is less dangerous than an AI that runs in that direction for 25 hours.

8. From Human-in-the-Loop to Human-on-the-Loop

The goal should not be to move every operation to human-on-the-loop supervision.

Anthropic analyzed about 990,000 public API tool calls. It estimated that 80 percent had some safety mechanism, 73 percent involved a human in some form, and 0.8 percent were irreversible. The study includes classification by Claude, and Anthropic could not observe every real-world outcome, so those limits matter.

The practical answer is a risk-dependent mixture. Research, static analysis, and test generation can be on-the-loop. Local code changes can combine on-the-loop operation with after-the-fact review. Creating a pull request can be automated; merging may require conditional approval. Production deployment belongs in the loop, while deletion, payment, and customer communication require strong human approval. Automated rollback paired with immediate notification may be appropriate in emergencies.

Human-on-the-loop supervision works only if the human can observe the system, understand anomalies, intervene in time, stop it, roll it back, and identify the responsible owner. “We delegated it to AI and glance at it occasionally” is not supervision.

Figure 4: AI can operate the inner execution loop. Humans own the outer boundary: constraints, evidence, approval, stopping, recovery, and accountability.

Conclusion: From Writing the Answer to Designing a World That Converges on It

Prompt engineering is said to be ending. Prompts themselves are not going away.

They are moving from a single conversation into specifications, AGENTS.md and CLAUDE.md, harnesses, loops, and graphs. Human work is moving from issuing every instruction toward designing a system in which AI proceeds in the right direction, detects error, and stops when necessary.

That does not require turning every thought into perfect language. It requires knowing which parts have been expressed and which remain unspoken.

Abstract purpose and concrete examples. Principles that must be protected and tests a machine can verify. A sense of what is good and examples of what is wrong. Humans and AI move between these repeatedly and encode what they agree on in a reusable system.

The engineer of the next era will not merely make AI write the right answer. The engineer will design a world in which AI can converge on the right answer.

References

• Addy Osmani, “Loop Engineering”
• Addy Osmani, “Own the Outer Loop”
• Anthropic, “Building effective agents”
• Geoffrey Huntley, “Ralph Wiggum as a software engineer”
• Anthropic, “Effective context engineering for AI agents”
• OpenAI, “Harness engineering”
• Prefect, “Loops vs. graphs”
• Google, “Agent Development Kit 2.0”
• OpenAI, “Prompt engineering”
• OpenAI, “Codex best practices”
• METR, “Time Horizon”
• Anthropic, “Measuring AI agent autonomy in practice”