The Control Plane for Coding Agents: Why Prompt Engineering Is Becoming Loop Engineering

The Shift from Stenographer to Systems Architect

Boris Cherny, who leads Claude Code at Anthropic, recently stated that he no longer prompts Claude directly. Instead, he writes loops—autonomous systems that decide what Claude should do, check the results, and schedule the next pass. Peter Steinberger, the iOS tooling veteran, put it more bluntly: you should not be prompting coding agents anymore; you should be designing the systems that prompt them.

This is the central claim of Loop Engineering, a reference repository and emerging practice that treats the orchestration layer as the new leverage point. The repository, maintained by Cobus Greyling and canonized in an essay by Addy Osmani, does not ship a framework. It ships a vocabulary: a set of primitives, patterns, and safety rails for turning coding agents from chatty pair programmers into unattended, recursive workers.

The premise is simple, and increasingly echoed across the industry. A recent IBM Technology analysis of AI in the software development lifecycle argues that while AI coding tools accelerate individual keystrokes, productivity frequently stalls across the broader pipeline. Faster coding alone does not translate into better delivery. The bottleneck has moved upstream from typing speed to workflow design. Loop engineering proposes that the valuable skill is no longer crafting the perfect prompt, but designing the control system that discovers work, distributes it, verifies it, records state, and decides whether to escalate to a human.

Anatomy of a Loop: The Five Primitives and the Memory Problem

A loop, in this taxonomy, is a recursive goal. You define a purpose—triage incoming issues, babysit a pull request, sweep CI failures—and the system iterates until completion or until it hits a human gate. Greyling’s repository distills this into five building blocks plus one critical externality.

The blocks are automations for scheduled discovery, worktrees for isolating parallel agents, skills files for persistent project knowledge, plugins and MCP connectors for reaching into real tools, and sub-agents to enforce a maker-checker split. The sixth element, external memory, is not a luxury; it is a workaround for the transformer’s biology.

Anthropic’s own engineering blog has framed this as “context engineering,” noting that LLMs suffer from attention scarcity. Every token attends to every other token, creating n² pairwise relationships that strain as the window grows. Models are trained on distributions where short sequences dominate, so they exhibit “context rot”—declining recall accuracy as token count rises. In other words, the longer the conversation, the more the model forgets why it started. Loop engineering accepts this constraint rather than fighting it. It moves state into Markdown files, project boards, or structured logs that survive between runs, because the conversation window is not a database; it is a leaky cache.

Worktrees isolate execution so that a sub-agent experimenting on a dependency sweep cannot accidentally corrupt the main branch. Skills—typically SKILL.md files—encode project conventions so the agent does not need to rediscover them every session. Plugins and MCP connectors let the loop file tickets, update project boards, or query databases without human intervention, anchoring the automation in your existing toolchain rather than a chat bubble. Sub-agents separate ideation from verification, a hedge against the agentic equivalent of confirmation bias. The maker-checker split is borrowed from manufacturing quality control: one agent proposes, another verifies against tests and gates. This matters because LLMs generate plausible text far more reliably than they verify it against an unseen specification. The result is not a single long chat, but a distributed system with a heartbeat.

A Pattern Language for Agentic Housekeeping

Where the repository becomes practical is in its pattern catalog. Greyling documents seven production patterns, each mapped to a cadence, a starter kit, and a token-cost estimate. Daily Triage summarizes incoming issues on a daily rhythm. PR Babysitter watches open pull requests for drift or conflict. CI Sweeper hunts broken builds. Dependency Sweeper checks for outdated packages. Changelog Drafter writes release notes from recent commits. Post-Merge Cleanup handles refactoring after merges. Issue Triage categorizes and routes incoming tickets. These are not aspirational demos. They are housekeeping loops, the kind of maintenance work that accumulates in every mature repository and that developers routinely deprioritize.

Each pattern ships with a maturity model. Level 1 is report-only: the loop observes, summarizes, and stops. Level 2 allows assisted fixes under human review. Level 3 is unattended, and the repository is explicit that most teams should not start there. The accompanying CLI tools—loop-audit, loop-init, and loop-cost—treat loop deployment as a governance problem. Loop-audit scores a project’s readiness; loop-cost estimates token spend before you turn the automation on. This reflects a sober understanding that the primary risk of unattended agents is not malice but bill shock and subtle drift.

The cost estimates themselves are revealing. Daily Triage and Changelog Drafter are cheap because they read more than they write and run on long intervals. PR Babysitter and CI Sweeper are expensive because they run every five to fifteen minutes and may spawn multiple sub-agents. The repository is transparent about this, which is rare in a field that often treats token spend as an afterthought.

The repository also maps these patterns across tools. Claude Code offers /loop and cron scheduling; Codex ships an Automations tab with triage inboxes and TOML-defined sub-agents. As O’Reilly Radar noted, the primitives are converging across vendors, which suggests the loop is becoming a first-class abstraction rather than a userland hack.

Why the Factory Still Needs a Foreman

The repository’s caveats section is unusually honest, and it is worth reading as a counterweight to the enthusiasm. Token costs can explode when sub-agents recurse. Verification remains the human’s job; an unattended loop makes unattended mistakes. And “comprehension debt” accumulates when developers let agents ship code they have not read. Comprehension debt is distinct from technical debt; it is a knowledge-management failure in which the team no longer understands how its own system works because an agent wrote the logic during the night shift.

This caution is grounded in the current state of coding agents. Independent reviews note that even leading tools struggle with context. GitHub Copilot’s agent mode has been described as literal-minded, updating only explicitly mentioned call sites while ignoring surrounding comments and other callers. Windsurf’s agent mode has, in some tests, generated duplicate code or infinite loops, and even confused pgvector distance operators. These are not edge cases; they are the noise floor of current agentic intelligence. Loop engineering does not eliminate this noise. It tries to contain it through verification layers, worktree isolation, and graduated autonomy.

LangChain’s articulation of the idea—stacking four loops from basic tool use up to “hill climbing” that automates improvement via execution traces—makes a similar point. Reliably automating real-world work requires a task-specific harness, not just a capable model. The loop is the harness. Faros.ai’s 2026 survey of the agent landscape reinforces this by defining an AI coding agent as the combination of a model and a harness that turns raw intelligence into a reliable system.

The Outlook

Loop engineering sits in an interesting architectural layer. It is above agent harness engineering—the environment for a single agent—and below the factory model that builds entire software products. It is the control plane: the scheduler, the triage nurse, the night watchman.

The repository is early. It is largely a curated set of markdown files, checklists, and npm scaffolding tools rather than a runtime. But its timing is precise. As OpenAI and Anthropic ship native primitives for automations, worktrees, and sub-agents, the missing piece is exactly the design language Greyling is assembling: how to compose these primitives into something that does not wake you up at 3 AM with a corrupted lockfile and a four-figure API bill.

The project eats its own dog food. The repository runs validate-patterns and audit workflows on every push, and it maintains a LOOP.md file describing the loops that maintain the repository itself. It is a neat bit of recursion, though the team is careful to note that the humans are still very much in the loop.

There is a broader conceptual shift here. The Prompt Engineering Guide defines an AI agent as an LLM-powered system that plans, uses tools, and remembers. Traditional prompt engineering optimizes a single inference: zero-shot, few-shot, chain-of-thought. It is query tuning. Loop engineering optimizes a system over time. It is database design. The difference is between asking a good question and building a good institution.

Addy Osmani’s closing warning in the canonical essay is apt: build the loop, but build it like someone who intends to stay the engineer, not just the person who presses go. The loop may replace the prompt. It has not yet replaced the judgment.