Developers have started to build systems that trigger, verify, and restart AI coding agents with no human typing the prompts. This paper defines that practice from eleven practitioner sources, then scans 36,710 open-source repositories: 217 already run confirmed agent loops — but the loops commit their configuration to git and almost none of their state.
In June 2026, several prominent engineers said that they no longer prompt coding agents by hand. Boris Cherny, the creator of Claude Code, said: "I don't prompt Claude anymore. I have loops that are running. They're the ones that are prompting Claude … My job is to write loops." Days later, Addy Osmani named the practice loop engineering: you replace yourself as the person who prompts the agent, and you design the system that prompts it instead. The term spread within weeks, and large claims came with it. A Stripe engineer reported that the company's internal agent system produces about 1,300 agent-written pull requests per week. Osmani reported that one loop pointed at Firefox produced 423 security fixes in one month. Skeptics answered that a loop is a renamed cron job, and that the main effect of the practice is higher token spend. Both sides argued from anecdotes and self-reports. Nobody had measured whether real software projects run such loops. This paper makes the first measurement.
The authors place loop engineering at the top of a four-layer stack. Prompt engineering shapes one instruction. Context engineering shapes everything the model sees in one call — the AGENTS.md and CLAUDE.md files that many repositories now commit. Harness engineering configures one agent run: skills, subagents, hooks, and tool connections. Loop engineering governs many runs over time. It decides what starts each run, when a run counts as done, and when a human must step in.
From eleven practitioner sources, the authors consolidate a working definition. A loop is an automated control structure that repeatedly invokes a coding agent. A trigger starts each run: a schedule, or a repository event such as a failing build or an opened issue. A machine-checkable stop condition ends it. A well-engineered loop adds five guardrails: state files that carry progress across runs (the agent forgets between runs; the repository does not), a verifier agent that checks results independently of the agent that produced them, token budgets with a documented pause control, limits on what an unattended run may change without approval, and defined escalation points where a human takes over.
The sources agree most strongly on the verifier. Separate the agent that makes from the agent that checks, and design the checker first — the verifier is what lets the loop run without supervision. They also agree on staged adoption: run a new loop in report-only mode first, let it apply fixes only after the verifier has proven reliable, and run it unattended last. One source adds an important caution: a loop satisfies the check you wrote, not the goal behind the check. The authors note one weakness of this consensus: the sources cite each other, so much of the agreement traces back to a single origin.
The team scanned 36,710 open-source repositories that an existing dataset classifies as engineered software projects. The sample was defined without reference to loops, so it works as a denominator: it tells you how many projects out of a fixed population run one. Deterministic rules — no LLM — searched every repository for committed loop artifacts: workflow files in which a schedule or event starts a coding agent, state files whose content records runs, verifier subagents referenced by a loop, budget files, and stop conditions. A second detector looked for behavioral signals in the git histories of context and state files: a regular commit cadence, a majority of commits from an agent, and edits that only add new dated log entries at the end of a file.
Every repository the rules matched — 256 in total — was then verified against archived GitHub Actions execution records. An LLM annotated the evidence against a fixed codebook, a second model tried to refute each label, and a human author made the final decision on every one.
217 repositories run confirmed autonomous agent loops — 0.59 percent of the sample. Most loops do review and triage work: 180 run on repository events only (largely automatic pull-request review), 21 on a schedule only, and 15 on both. Claude Code drives 189 of the 217. The detection rules reached a precision of 0.87.
The clearest finding is a split between configuration and state. Projects commit the configuration around their loops: 253 repositories hold a committed trigger, almost always a GitHub Actions workflow. The committed state that the discourse prescribes is absent. Across the full sample, the scan found two candidate state files, and manual inspection rejected both. It found no committed stop-condition file, no budget file, and no verifier subagent connected to a loop. The loops run, but their state stays outside version control, so nobody can audit from the repository what a loop knew, decided, or spent.
The authors state the limits of the measurement plainly. The scan ran ten weeks after the term was coined, so the practice had little time to spread. It covers public repositories only; internal systems such as Stripe's are not visible in public repositories, so the count understates adoption. Loops driven by tool-native commands such as /loop and /goal, or by schedulers outside the repository, leave no committed artifact at all. And a successful run record proves little: one hourly triage loop logged 6,290 successful runs in which the agent never executed once, because the issue search that controls it never finds a match.
If you run an agent loop, or plan one, the paper's synthesis works as a checklist. Design the verifier before you grant autonomy, and make rejection its default answer. Adopt in stages: report-only, then assisted fixes, then unattended. Commit the loop's state, budgets, and stop conditions, so you can audit the loop from the repository alone — this is exactly the step the 217 confirmed loops skip today. Do not trust run status alone; check step durations and produced output. And plan review capacity before you scale a loop: a nightly loop can open more pull requests than a team can review, and then the human reviewer approves without real inspection while the pipeline still reports success.
The failure catalog is worth reading on its own: one CI-fixing loop spent about eight million tokens in 48 hours; verifiers approved without real checks; and loop speed widens a gap the authors' sources call comprehension debt — the distance between what exists in the repository and what the developer understands. The authors' next step is a controlled experiment that tests whether handing off more of the loop actually improves outcomes. Until that evidence exists, the guardrails above are the tested part of the practice, and the productivity claims are not.