# What loop engineering is Loop engineering means building the system that prompts, checks and restarts an agent, so you stop being the person who types every turn. The term is new, and the honest story of where it came from is short. ## From typing turns to designing the loop Normally you work with Claude Code in turns. You write a prompt, it works, you read the result, you write the next prompt. You are the part of the system that decides what happens next. Loop engineering moves that job out of your hands. You design a system that does the prompting: it starts the agent, gives it context, checks what came back, and runs it again if the work is not finished. Addy Osmani put it as a recursive goal: you define the purpose, the AI iterates until it is done, and you build the system that prompts the agent. The Claude Code team's own definition is plainer. A loop is agents repeating cycles of work until a stop condition is met. ## The parts of a loop Marek Kaput's guide breaks a loop into five parts. ```flow Trigger: something starts a turn Context: what the agent is given Work step: the agent does the task Verification step: something checks the result Stop condition: finished, or give up ``` Notice what that list excludes. A timer alone is not a loop. If a script wakes Claude every ten minutes and sends the same prompt without anyone looking at fresh evidence, it is only a clock. Each turn has to look at something that can have changed. This is also why the previous course ended where it did. The agent loop is one model using tools until a goal is reached. Loop engineering is a second loop around it, owned by you, that decides when to start it, how to check it and when to stop. **Question:** A script sends Claude the same prompt every ten minutes and never reads what happened. Is that a loop in the sense used here? - Yes, anything that repeats is a loop - No, a timer alone is not a loop, each turn must look at fresh evidence - Yes, but only if it uses /goal - No, because loops must run in the cloud **Answer:** No, a timer alone is not a loop, each turn must look at fresh evidence. The guide's anatomy needs a verification step and a stop condition. A repeating prompt with no check on the result is a timer. ## Where the term comes from Here is what can be said for certain, and no more. The Claude Code team published "Loop engineering: Getting started with loops" on 2026-06-30. The authors are Delba de Oliveira and Michael Segner. It is the official definition and it maps loops onto commands you can type: `/goal`, `/loop` and `/schedule`. It also says openly that the term has no single agreed meaning online. It does not claim to have invented it. Addy Osmani's essay "Loop Engineering", dated 2026-06-08, is the piece that named the idea and gave it a recipe: automations, git worktrees, skills, connectors, sub-agents and a memory file on disk. Who said the phrase first has not been established, so this course does not claim anyone did. What is established is that the idea is older than the name. > **The idea predates the name** Geoffrey Huntley's "Ralph" technique, published on 2025-07-14, is a bash while-loop that feeds one prompt file to a coding agent over and over, each time with a fresh context. Loop engineering keeps that shape and adds first-class commands and separate verifiers. The next lessons start from there. ## What changes in your job The work moves from writing prompts to writing three things around the agent. - **A check.** Something that can say whether the work is good, other than the agent itself. - **A stop.** A condition written as evidence, plus a hard cap so it cannot run forever. - **A memory.** Notes on disk, so the next turn knows what the last one did. Osmani is careful about one point: "done" is still a claim, and a human confirms it. Loop engineering removes you from typing every turn. It does not remove you from judging the outcome. Kaput adds where it pays off. Loops work best where correctness is cheap to check, such as CI failures, rebases and benchmark runs. Feature work needs human judgment, so the loop there should produce a draft and evidence, not a silent merge. > **Find your first loop** Think of a task you currently repeat by hand: re-running tests after each fix, or checking a pull request until it is green. Write down, in one line each, what would check it, and what would make it stop. If you cannot write the check, that task is not ready for a loop yet. Lesson 4 is about exactly that. **Question:** What does loop engineering take out of your hands? - Judging whether the final result is good - Typing the prompt for every turn - Choosing the goal - Reading the cost report **Answer:** Typing the prompt for every turn. You design the system that prompts, checks and restarts the agent. A human still confirms that the work is actually done.