The next step in AI coding is not writing better prompts. It is designing better loops.
That is the argument behind cobusgreyling/loop-engineering, an MIT-licensed reference repository for recurring AI coding-agent workflows. The project gives developers patterns, starters, checklists, examples, and CLI tools for turning one-off agent prompts into systems that can discover work, preserve state, run on a cadence, verify output, and escalate when human judgment is required.
The tagline is direct: stop prompting, design the loop, get a score.
That matters because many AI coding workflows are still fragile. A developer opens a chat, pastes context, asks the agent to fix something, reviews the result, and repeats the process manually. That can be useful, but it does not scale well. Every new session loses intent. Every manual prompt becomes orchestration work. Every long-running task depends on the human remembering what happened last time.
Loop Engineering treats the agent as one part of a control system.
What Loop Engineering Is
Loop Engineering is a reference project for building recurring AI coding-agent workflows. It is not only a prompt collection. It is a system design guide for agent loops.
The repository includes:
- production loop patterns such as daily triage, PR babysitter, CI sweeper, dependency sweeper, changelog drafter, post-merge cleanup, and issue triage
- starters for tools such as Grok, Claude Code, Codex, OpenClaw, Opencode, and GitHub Actions
- CLI tools including
loop-init,loop-audit,loop-cost,loop-sync,loop-context, andloop-mcp-server - templates, examples, skills, docs, stories, and operating guidance
- a readiness checklist that moves teams from draft intent to report-only loops, assisted fixes, and eventually unattended operation
The key idea is simple: if an AI coding agent is going to work repeatedly, it needs a loop around it.
Why This Matters
Prompting is a manual control surface. It works when the task is small and the human is present. But many engineering problems are recurring:
- watch issues and categorize them
- scan PRs and identify stale review threads
- inspect CI failures and propose the next fix
- check dependencies and open safe update PRs
- draft changelog entries after merges
- clean up post-merge state
- keep a project memory file current
These are not one-prompt problems. They need cadence, state, verification, and handoff rules.
Loop Engineering makes that shift explicit. The human’s job moves from “write the next instruction” to “design the control system that decides what the next instruction should be.”
The Six Useful Primitives
The repository frames loop engineering around five primitives plus memory.
The first primitive is automation or scheduling. A loop needs a heartbeat: cron, GitHub Actions, tool-native scheduling, /loop, /goal, or another recurring trigger. Without scheduling, the workflow is just another manual agent run.
The second is worktree isolation. If agents edit the same files in the same working tree, collisions become inevitable. Worktrees let separate runs operate in isolated directories while sharing Git history.
The third is skills. Skills capture project conventions, review standards, build commands, and domain knowledge. This reduces intent debt because the loop does not need to rediscover the same rules every time it starts.
The fourth is plugins and connectors, often through MCP. A loop becomes more useful when it can read tickets, update issues, post summaries, query internal systems, or create PRs with scoped permissions.
The fifth is sub-agents, especially the maker/checker split. The agent that wrote the change should not be the only judge of whether the change is correct. Verification needs separation.
The sixth is memory or state. A loop needs durable context outside the chat window: STATE.md, LOOP-STATE.json, a board, a database row, or another record of what happened last run.
The CLI Tooling
The repository is practical because it ships tools, not only concepts.
loop-init scaffolds a project with loop files, skills, budget files, and starter commands. It can target different agent tools and patterns.
loop-audit gives a Loop Readiness Score and suggestions. This is useful because most agent automation fails at the invisible boundaries: missing state, weak verification, unclear scope, no denylist, or no budget.
loop-cost estimates token spend for a pattern and cadence. This matters because autonomous loops can quietly become expensive, especially with sub-agents or frequent CI checks.
loop-sync checks drift between STATE.md and LOOP.md. That is a small but important operational detail. A loop that acts from stale state is worse than no loop.
loop-context manages stateful memory and circuit-breaker behavior for long runs. loop-mcp-server exposes runtime lookup for patterns, skills, and state through MCP.
Together, those tools turn loop engineering from a blog idea into something a developer can test in a repository.
Readiness Levels: L1, L2, L3
The project’s readiness model is one of its strongest parts.
L0 is documented intent. You know what the loop should do, but it is not ready to run.
L1 is report-only. The loop can triage, summarize, and write state. It does not make code changes. This is the right starting point for most teams because it surfaces what the loop would do without letting it act.
L2 is assisted operation. The loop can make small changes, but only with scoped permissions, verifier separation, worktree isolation, explicit human handoff, and clear connector permissions.
L3 is unattended operation. This requires the full checklist: purpose, scheduling, skills, maker/checker split, state, handoff rules, connector scopes, cost limits, observability, safety policy, and kill criteria.
That progression is healthy. Too many teams jump from “agent can edit code” to “agent should run by itself.” Loop Engineering pushes the opposite path: observe first, assist second, automate only after the failure modes are understood.
Where It Fits with Codex, Claude Code, Grok, and Opencode
Loop Engineering is intentionally tool-aware but not tool-locked.
The repository includes examples and starters across Grok, Claude Code, Codex, OpenClaw, Opencode, and GitHub Actions. That is the right abstraction level. The loop concept should survive tool changes because the durable parts are not the model name. They are the cadence, state, verification chain, safety policy, and handoff rules.
For Codex-style local coding agents, the pattern is especially relevant. A strong loop can:
- read repo state and memory at the start of a run
- choose a small scoped task
- make changes in an isolated workspace
- run tests and build gates
- ask for human approval when permissions or product judgment are required
- update durable state before exiting
That is much closer to how engineering teams actually work.
Risks and Caveats
Loop Engineering is not a shortcut around engineering judgment.
The repository is explicit about the dangers: token costs can explode, unattended loops can make unattended mistakes, comprehension debt grows if humans stop reading the output, and two people can run the same loop with opposite results because the loop does not understand organizational judgment by default.
The biggest risk is cognitive surrender: treating the loop as a replacement for thinking. A good loop encodes judgment. A bad loop hides the fact that judgment has disappeared.
That is why the safety guidance matters. Denylist secrets and infrastructure paths. Avoid auto-merge unless there is an explicit allowlist. Keep human escalation triggers clear. Log each run. Cap costs. Separate the implementer from the verifier.
My Take
Loop Engineering is one of the more useful patterns in AI-assisted development because it names the real problem.
The bottleneck is no longer only prompt quality. The bottleneck is repeatability: how agents discover work, preserve context, isolate changes, verify results, manage cost, and hand control back to a human when the task crosses a risk boundary.
The project is not a finished platform, and that is a strength. It is a reference kit for designing your own loop around your own repo, your own agent, and your own risk tolerance.
For engineering teams already using Codex, Claude Code, Grok, Cursor, Opencode, or similar tools, cobusgreyling/loop-engineering is worth studying because it moves the conversation from “what should I prompt next?” to “what system should decide, run, verify, and remember the next step?”
