Loop Engineering

Sidebar is where this site keeps content that's genuinely worth a real, standalone write-up, but too narrow to justify a multi-chapter course of its own — link collections, interactive tools, and one-off lessons like this one, organized by subject rather than by a fixed outline. This lesson covers loop engineering, a real, current shift in how AI coding agents are actually used.

What "Loop Engineering" Actually Means

In June 2026, Addy Osmani and Boris Cherny — the engineer who built Claude Code — put a name to a shift that had already been happening in practice: loop engineering. Cherny's own line has become the unofficial founding statement of the idea: "I don't prompt Claude anymore. I have loops that are running. They're the ones that are prompting Claude and figuring out what to do. My job is to write loops."

The distinction is about where the effort actually goes. Prompt engineering optimizes a single exchange: you write an instruction, the model responds, you read the output, and if it's wrong, you write a better instruction — you hold the pen for the entire conversation. Loop engineering optimizes a system that runs that conversation on your behalf, repeatedly, without you reading every single reply. A loop, in this sense, is a goal-driven cycle: receive a goal, gather context, decide on an action, use a tool or call another agent, observe what happened, update state, and repeat.

This Isn't Entirely New Ground for This Site

The Five Core Techniques

Osmani's own framing identifies five concrete techniques loop engineering is actually built from — each with a real, working implementation in tools like Claude Code today:

What's Actually New: Worktrees for Parallel Isolation

Claude Code Agents: Advanced Orchestration 3 already taught the deciding question between parallel and sequential agent work. What it didn't cover is the specific mechanism that makes running several agents on the same codebase at the same time safe: a git worktree.

A worktree is an additional working directory linked to the same underlying git repository — a second (or third, or fourth) checkout, each with its own files on disk, all sharing the same commit history and git objects underneath. Two agents working in two separate worktrees can edit files freely without either one ever seeing, or overwriting, the other's uncommitted changes — because each agent's own file edits genuinely live in a different folder.

A Real, Concrete Loop

Cherny's own "my job is to write loops" line is a useful test: what does actually writing one look like? A simple, realistic example — a loop that watches for new work, triages it, and only surfaces what's genuinely actionable:

1. A scheduled trigger wakes the loop (an automation)
2. It gathers context — new issues, failed test runs, whatever the goal is scoped to
3. For each item, it spawns a dedicated sub-agent to investigate, isolated in its own worktree if the investigation involves editing code
4. Each sub-agent reports back a distilled result — not its full exploratory process, just the finding
5. The loop decides: escalate to a human, take an automatic action, or discard as not actionable
6. It goes back to sleep until the next trigger, and repeats

The Honest Caveat: Verification Is Still On You

Loop engineering doesn't remove the need for human judgment — it relocates it. Instead of reviewing every individual response, the real work shifts to designing good stop conditions, sensible escalation rules, and periodic verification that the loop is actually doing what it's supposed to. The genuine risk, named directly in the original writing on this topic, is cognitive surrender — letting a loop's own fluent output stand in for actually checking its work. A loop that runs unattended for longer, on more consequential tasks, needs more deliberate verification design, not less, echoing exactly the /loop skill's own guidance on scheduling meaningful check-ins rather than optimistically assuming everything will go right.

Hands-On Exercises