Loop Engineering: A Pattern Library for Turning AI Coding Agents into a Managed Process

What This Project Actually Solves

Loop engineering is not another code generation tool. It addresses a specific operational problem: how do you keep an AI coding agent productive and safe over time, beyond a single prompt? The README frames it clearly: 'Stop prompting. Design the loop. Get a score.' The project provides a pattern library for operating agents around a codebase, covering tasks like issue triage, dependency updates, PR babysitting, and post-merge cleanup. It is aimed at developers and teams who already use tools like Claude Code, Codex, or Grok and find themselves typing repetitive prompts, checking results manually, and losing state between sessions. Instead of asking an agent to 'rewrite the module,' you design a system where work is discovered, handed to agents, verified, and persisted. This is a shift from treating the agent as an interactive assistant to treating it as a component in a larger workflow.

The Mechanism: Patterns, State, and Scoring

The core mechanism is a combination of documented patterns, a state file, and a scoring system. Patterns are described in markdown files under the patterns directory and registered in patterns/registry.yaml. Each pattern has a cadence, a week-one level, and a cost estimate. For example, Daily Triage runs every 1 day to 2 hours and is low cost, while CI Sweeper runs every 5-15 minutes and is very high cost. The state file, STATE.md, persists the loop's findings and actions. The 'Loop Ready' score is a key concept: it now 'weights recent runs harder than files on disk,' meaning a 30-day-old STATE.md does not count as ready for unattended operation. This scoring is central to the safety model. The CLI tools, loop-init, loop-audit, and loop-cost, help you set up a pattern, check its health, and estimate token costs. The unified command is npx @cobusgreyling/loop, which exposes init, doctor, status, audit, and cost subcommands. The README explicitly warns that token costs can explode and that unattended loops make unattended mistakes, so the scoring is not a formality; it is the gate for increasing autonomy.

Getting Started: Real Commands and Config Keys

The quickstart is straightforward. You run two commands in your project directory. The first initializes a pattern: npx @cobusgreyling/loop init . --pattern daily-triage --tool claude. The --tool flag defaults to claude if omitted, and you can swap it for grok, codex, or opencode. The second command runs a health check: npx @cobusgreyling/loop doctor . There is also a cost estimator: npx @cobusgreyling/loop cost --pattern daily-triage --level L1. The README emphasizes that 'Week one is report-only.' This means the loop does not make changes or open PRs; it only produces a report (L1) that you review. The project includes a thin-loop starter for GitHub Actions that requires almost no files and does not need a STATE.md. For an empty repository, there is a demo script at scripts/empty-to-state-demo.sh that walks through the first STATE.md creation. The progression is explicit: roll out L1 report, then L2 assisted, then L3 unattended, but only after the verifier has been right for a week. This staged rollout is a concrete config decision, not just advice.

Safety and Failure Modes Are First-Class

One of the most striking aspects is how much the project documents failure. The README links to docs on failure modes, anti-patterns, safety, and operating loops. It even collects 'stories' that include both wins and failures. This is not a marketing afterthought. The safety model is built around the verifier: a loop should not progress to L3 unattended mode until the verifier has been 'right for a week.' The Loop Ready score is designed to reflect recent activity, not stale state. That is a genuine attempt to prevent the common failure where an agent acts on outdated information. The documentation also warns that token costs can explode and that unattended loops make unattended mistakes. The phrase 'Read what the loop ships' is a direct instruction to operators. This is refreshingly honest for a tool that automates agents. However, the README does not detail exactly what the verifier checks or how it determines correctness. That is a gap you would need to investigate before trusting an L3 loop with real PRs.

A Real Limitation: It Is Not a Code Generator

The README is explicit: this is a pattern library for operating agents, 'not a rewrite the module button.' That is a real limitation for developers who expect a tool to take a task and produce code. Loop engineering is about the workflow around the agent, not the agent's code generation quality. It requires you to set up triggers, state files, and review processes. The cost is also a factor. The patterns table lists cost estimates from low to very high. CI Sweeper and PR Babysitter are marked as high or very high, meaning you could burn significant tokens if you run them frequently. The documentation warns that token costs can explode. So this is the wrong tool if you want a quick answer or a one-off refactor. It is also likely overkill for a solo developer on a small project who does not have recurring maintenance tasks. The value emerges when you have a steady stream of issues, PRs, and dependency updates that need constant attention.

Alternatives: Build Your Own vs. Use a Framework

The obvious alternative is to build your own agent orchestration using a general-purpose automation tool like GitHub Actions or a CI system, combined with direct calls to an agent CLI. That approach gives you full control but requires you to design the state management, verification, and safety gates yourself. Loop engineering offers a structured pattern library that codifies these decisions, so you do not have to invent them. Another alternative is to use a dedicated agent framework that handles orchestration, such as LangChain or similar, but those are typically more about composing LLM calls than about the operational loop of discovering work and verifying results. The difference here is the focus on patterns like daily triage and the explicit safety levels. The project also has companion repos like memory-engineering and fleet-engineering, but the README advises not to add them until a loop has actually run. That is a useful constraint. For teams already using Claude Code or Codex, the examples directory shows how to wire these patterns into those specific tools.

Maintenance, Upgrades, and License

The project is under active development, with recent releases v1.6.0 and v1.5.0 in mid-2026. The release notes mention a 'Foundry funnel + loop-gate' in v1.6.0, which suggests the tooling is evolving. The README states that older packages like loop-init and loop-audit remain supported, but the unified front door is npx @cobusgreyling/loop. This means you may need to migrate scripts if you started with the older packages. The documentation is extensive, and the project requests help with docs and small PRs, with a first response within 48 hours. That is a sign of an active maintainer community. The license is MIT, which gives you broad freedom to use and modify the code. There is no mention of a paid tier or enterprise support. Maintenance cost is primarily your own: you need to keep patterns updated as your tools change and as the project evolves. The companion repos are optional and explicitly not recommended until a loop is actually running, which keeps the initial footprint small.

Editorial conclusion

Adopt loop-engineering if you are already running AI coding agents and want to formalize how they discover work, verify output, and persist state. It is not a tool for generating code on demand; it is a discipline for operating agents safely. Teams new to agentic workflows should start with the daily-triage pattern and run in report-only mode for a week. Before adopting, verify that your CI and issue tracker can support the loop's automation hooks, and confirm that your team can commit to reviewing the loop's output daily. Avoid it if you need a simple autocomplete or a one-shot refactor tool. The project's own documentation emphasizes that unattended loops make unattended mistakes, so treat L3 autonomy as a goal, not a starting point. The CLI and patterns are MIT-licensed and actively maintained, but as with any agent orchestration layer, the real cost is the judgment you must invest in reading what the loop ships.

Official sources

1. cobusgreyling/loop-engineering on GitHub
2. License: MIT
3. Project website
4. README
5. Releases