Loop Engineering, Harness Engineering, Context Engineering: what's the difference?

Boris Cherny, Head of Claude Code at Anthropic, said: "I don't prompt Claude anymore. I write loops that prompt Claude." Only days later, on June 7, 2026, Addy Osmani, Engineering Lead at Google Chrome, turned that into the term Loop Engineering. Since then, the word has been showing up everywhere: in Slack channels, in customer conversations, in tech podcasts. Yet hardly anyone means the same thing by it. This post sorts out the three terms that are currently getting mixed up (Loop Engineering, Harness Engineering, Context Engineering) and shows how they connect.

Three terms, one confusion: why sorting them out matters now

Since Cherny put out his statement and Osmani coined the term Loop Engineering on June 7, 2026, a wave of terminology has taken off. Within weeks the word was everywhere, but at every stop it meant something different. It shows most clearly where you'd expect it least: in our own internal channels, experienced codecentric consultants spent days debating whether "Loop Engineering" refers to building the guardrails, automating the repetition, or simply the entire field of autonomous agents.

This isn't a fringe issue. When people who work with these systems every day fill the term with different meanings, then customers and consultants end up talking straight past each other. Someone asks "Does my team need Loop Engineering?" and, depending on whom they ask, gets an answer about prompts, about MCP servers, or about cron jobs. The same misunderstandings show up inside teams.

That's why we sort them out here. Not to claim a term for ourselves, but to bring order to a field that's currently growing without clear edges. Whoever separates the three layers cleanly can ask more precisely, build more precisely, and buy more precisely. How we at codecentric think about AI systems sits in exactly this precision. More on our AI page.

What is Context Engineering? The bottom layer

Context Engineering is the discipline of giving an AI model the right information for the next task. It determines what goes into a single prompt: code snippets, architecture hints, examples, constraints. Clean Context Engineering is the foundation for everything that builds on top of it.

What goes in? Clean Context Engineering means giving the model exactly the building blocks it needs for the next task: relevant code snippets at the right scope, architecture hints at the right level of detail, concrete constraints, good examples. "The right scope" is the actual craft here. You don't dump the entire repository in unfiltered, but you also don't look at a single function in complete isolation. It's about curation, meaning the right selection from many possible sources: documents, memory files, tool definitions, domain knowledge, and the message history so far.

Exactly this difference, from single prompt to curated context for an agent, is hard to show in a short code snippet, because it plays out across many files, skills, and sources. The following diagram makes it tangible.

This diagram is from Anthropic's blog post "Effective context engineering for AI agents". It captures the difference between a single prompt and a curated context window for an agent so clearly that we adopted it here as-is.

What stays out? Everything that doesn't belong to the concrete task: irrelevant code sections ("background noise"), negative examples with no learning value, redundant documentation, and outdated spec versions. As the diagram shows, the step from "possible context" to "context window" is a deliberate trimming, symbolised in the image by the scissors. The difference between good and bad context rarely lies in adding, more often in deliberately leaving out.

Why is this the foundation for everything else? Because every layer on top builds on the context. If the foundation wobbles, so does the rest. Loop Engineering without clean Context Engineering becomes iteration theatre, because the loop then only repeats faster what was built on bad context.

What is Harness Engineering? The guardrails around the Coding Agent

Harness Engineering describes the guardrails around a coding agent: tools, skills, MCP servers, system prompts, hooks, sandboxes, and observability. This is what makes the model actually operational in a concrete technical context.

Why does the harness make the difference? An agent is always model plus harness, and the harness often decides the outcome. It's not the strongest model that wins, it's the best-equipped one. A solid model in a well-designed environment regularly beats a top model in a poor one. (Osmani post)

We at codecentric put this into an equation: Agent = Model + Tool Harness + User Harness. The model is the core. The Tool Harness brings tools and orchestration with it, for example in Claude Code or Cursor. The User Harness is the project-specific system of rules, tests, and context documents that we as developers shape ourselves. How to build this User Harness systematically is something we describe in detail in our Softwerker article "Guardrails for Coding Agents" (in German).

What goes into such a harness? Specifically the tools the agent uses to act, the skills and MCP servers that give it capabilities and data access, the system prompts that frame its behaviour, the hooks that intervene at the right moments, the sandboxes where it can execute safely, and the observability that makes what it does visible. It's only this bundle together that turns a language model into an agent that actually moves things in a real repository.

How do you organise these building blocks? A useful structure separates two directions of effect: Guides and Sensors. Guides act before code generation (feedforward). They give the agent context, rules, and specifications before it writes a single line. Sensors act after generation (feedback). They check the result and give the agent feedback so it can self-correct. We describe this pair in more depth in our Softwerker article "Guardrails for Coding Agents".

Rather than in code, a harness is best shown as a combination of tools and techniques. Here's what a concrete harness for a coding agent building a REST endpoint in a layered architecture could look like:

• Guides: a CLAUDE.md with the project's naming and architecture conventions, an OpenAPI or feature spec as a contract, a bootstrap template for the module structure, and an MCP server (e.g. Context7) for current framework docs.
• Sensors: ArchUnit tests that enforce layer separation, a linter like ESLint as a self-correction trigger, a coverage threshold, and a review agent (LLM as a Judge) that checks the proposed code changes against the functional requirements.

No single tool carries the quality, the combination does. Only this interplay of guides and sensors turns a generic model into an agent that meets the standards of a concrete project.

How much the harness makes the difference shows in an example from Anthropic. An initializer agent writes a progress file, a second coding agent works through it step by step and writes its progress back into the same file. What's needed for this isn't an exotic model, but thoughtful guardrails that make a long run viable in the first place. (Anthropic Engineering)

A harness therefore describes the workbench for a single agent: what tools it has, what rules it knows, how its output gets checked. As soon as this agent is no longer meant to be triggered task by task by a human, but to keep running on its own, the harness turns into a loop.

What is Loop Engineering? The next layer above

Loop Engineering describes the system that repeatedly triggers an AI agent, spawns helper agents, verifies results, and feeds itself, without a human prompting turn by turn. Loop Engineering builds on Harness Engineering and automates the repetition.

What's the shift in perspective? The emotional core of this layer is in Cherny's line: "I don't prompt Claude anymore. I write loops that prompt Claude." That's the shift away from the human who prompts turn by turn, towards the system that drives the agent itself.

What does a loop consist of? Osmani names five building blocks that make up such a loop: Automations (what triggers and paces the run), Worktrees (isolated work areas for parallel runs), Skills (persistent capability docs), Plugins & Connectors (tool and data hookup, among others via MCP), and Sub-Agents (helpers that work on subtasks and check results). On top of that comes Memory as external state, "a markdown file, a Linear board, something that lives outside". (Osmani post) Without this state, the loop loses the thread between iterations.

In practice this can look very different: time-triggered triage loops that sift through open issues in the morning, parallel work across multiple Git worktrees, sub-agents that handle subtasks and report their results back. A concrete example from our own practice is the Ralph Wiggum Loop (in German), an autonomous code generation approach that starts every iteration with fresh context.

Where does Loop Engineering end? At a single coding activity. It orchestrates the repeated building and checking of code, no more. Everything above that, meaning black-box verification of whole systems, learning from production, and hooking into business logic, belongs to different models and is the topic of later posts in this series.

Loop Engineering vs. Harness Engineering: what's the difference?

Aspect	Harness Engineering	Loop Engineering
What it is	Guardrails (guides and sensors) around a coding agent	System that repeatedly triggers an agent
Who's in control	Human prompts, agent works	Loop prompts, human observes
Discipline	Software architecture, tooling, DevX	Workflow automation, verification, DevOps
Typical question	"What guides and sensors does my agent need?"	"What does the loop need to run as long as possible without me?"
Example	CLAUDE.md, OpenAPI spec, ArchUnit tests, linter, review agent	Ralph Wiggum Loop, cron trigger, test-gated loops, sub-agents

Both layers interlock but play different roles. The harness is the construct of tools: the guides and sensors that direct and check an agent. The loop is the production line that repeatedly triggers this agent, verifies its results, and keeps it running without your involvement.

That's why the order isn't a matter of taste: context first, then harness, then loop. Every layer inherits the weaknesses of the one below. A loop that repeatedly invokes a poor harness doesn't make the mistake smaller, it just repeats it faster. Whoever saves at the start builds shakily upwards.

That leaves the practical question that actually comes up in projects: how do I recognise which layer I need?

When do I need what? An orientation

1. When your agent doesn't deliver reliably on a single task, improve the Context Engineering (prompts, system prompts, input structuring, files).
2. When your agent delivers but misses your project's quality and domain standards, or doesn't notice its own mistakes, expand the Harness Engineering. Guides direct it (CLAUDE.md, specs, templates), sensors check its output and let it self-correct (linters, architecture tests, review agents).
3. When your agent should run autonomously for hours or days without you triggering it step by step, introduce Loop Engineering (trigger, verification, correction, memory, sub-agents).

The three layers don't replace each other, they build on each other. Without clean context, the best harness gets you nowhere. Without a harness, no loop runs. Whoever saves at the loop level builds on a shaky foundation.

What makes loops dangerous right now: three open risks

As convincing as the three layers sound, Osmani himself warns in his original blog post about three risks that emerge precisely when loops run unsupervised. Anyone taking Loop Engineering seriously has to think them through, not away.

1. Lack of verification in unattended loops. They keep running even when the output has long been wrong. Osmani puts it plainly: "A loop running unattended is also a loop making mistakes unattended."
2. Loss of understanding through fast automation. Those who write the loop often no longer understand the underlying problem in detail. Osmani: "Your understanding still rots if you allow it."
3. Cognitive capitulation, meaning uncritically accepting loop outputs instead of exercising your own judgment. Osmani describes the temptation "to stop having an opinion and just take whatever it gives back."

All three share the same core: a loop amplifies what you give it, good work as well as bad. Verification is the only point where this amplifier gets a brake.

Whoever builds loops without addressing these three risks builds an expensive linter that hallucinates. How to take verification seriously is the topic of the next post.

FAQ: the most common questions

Is Loop Engineering the same as Agentic Engineering? No. Agentic Engineering describes individual autonomous agents, Loop Engineering describes the system that repeatedly triggers, verifies, and feeds agents.

Do I need Harness Engineering before I can do Loop Engineering? Yes. A loop without a proper harness inherits its weaknesses. The loop's repetition amplifies context or tool errors instead of mitigating them.

Who coined the term Loop Engineering? Addy Osmani (Engineering Lead, Google Chrome) on June 7, 2026, triggered by a viral statement from Boris Cherny (Head of Claude Code, Anthropic) just days earlier.

Is Context Engineering still relevant if Loop Engineering is the next level? Yes, more than ever. Loops amplify context errors instead of mitigating them. Bad context inside a loop multiplies its effects across iterations.

What separates Loop Engineering from classic workflow automation? Loops are non-deterministic. The model decides itself which path to take within the iteration. Classic workflows follow fixed, predefined paths.

Further reading

For those who want to go deeper, these sources contain valuable material not cited above:

• codecentric: "Guardrails for Coding Agents: How Harness Engineering Secures Software Quality" (our Softwerker article on guides, sensors, and the framework of deterministic and inferential checks; in German)
• Cobus Greyling: "Loop Engineering" (Substack synthesis with the hierarchy Context, Harness, Loop)
• GitHub: "Awesome Harness Engineering" (curated list of tools, patterns, evals, memory, MCP, permissions)
• The New Stack: "The Anthropic leader who built Claude Code says he ditched prompting" (background article on the Cherny statement)
• Anthropic Engineering: "Harness Design for Long-Running Applications" (deeper second Anthropic post)

Closing

In the next post, we'll take a closer look at the first of the three risks and explain why a loop without verification is an expensive linter.