Loop Engineering makes a blunt argument: the person who writes prompts to a coding agent is now the bottleneck, so the job is to design the system that prompts the agent instead. The repo, cobusgreyling/loop-engineering, turns that claim into something you can measure. Run npx @cobusgreyling/loop-init . and it scaffolds skills, state, and budget files, then prints a "Loop Ready" score and your first loop command. The pitch on the tin is equally direct: stop prompting, design the loop, get a score.
The thesis has receipts
The README does not lean on its own authority. It quotes Peter Steinberger ("You shouldn't be prompting coding agents anymore. You should be designing loops that prompt your agents") and Boris Cherny, Head of Claude Code at Anthropic ("I don't prompt Claude anymore. I have loops running that prompt Claude... My job is to write loops"). The framing that follows is the useful part: the leverage point has moved from crafting individual prompts to designing the control systems that orchestrate agents over time.
Loop Engineering breaks that control system into five building blocks plus memory. Automations and scheduling handle discovery and triage on a cadence. Worktrees give safe parallel execution. Skills hold persistent project knowledge. Plugins and connectors reach into real tools through MCP. Sub-agents split the work into a maker and a checker. Memory and state sit outside any single conversation as the durable spine. That list is opinionated, and it reads like the parts list for the animated loop the README diagrams: schedule, triage skill, read and write state, isolated worktree, implementer sub-agent, verifier sub-agent, then a human gate that either commits or escalates with full context.
Tools that turn the idea into a checklist
What separates this from a manifesto is the CLI surface. The repo ships a cluster of npm packages, each doing one small job. loop-audit computes a Loop Readiness Score and can suggest fixes or emit a badge for your README. loop-init scaffolds a starter with a budget and run log. loop-cost estimates token spend for a given pattern and cadence before you commit to it. loop-sync detects drift between STATE.md and LOOP.md. loop-context manages stateful memory and adds a circuit breaker for long runs. loop-mcp-server exposes patterns, skills, and state over MCP. loop-worktree manages isolated git worktrees per fix attempt. The tools publish to npm from tagged releases, so no clone is required to try them.
The patterns section is where the token-cost honesty shows. Seven production patterns come with a cadence and a cost rating. Daily Triage runs on a one-day-to-two-hour cadence and is cheap. PR Babysitter runs every five to fifteen minutes and is flagged High. CI Sweeper, at the same cadence, is Very High. Dependency Sweeper, Changelog Drafter, Post-Merge Cleanup, and Issue Triage round out the set, mostly at Low cost. Putting "Very high" next to a pattern in the same table that sells you on it is a small act of restraint worth noting.
The rollout advice matches. The README pushes a phased path: L1 report only, then L2 assisted fixes, then L3 unattended. The Grok example even spells it out ("Run loop-triage. Update STATE.md. No auto-fix in week one"). This is a project telling you to start by watching before you let anything write.
Who it targets, and what to check
Loop Engineering aims at developers using Grok, Claude Code, Codex, Cursor, and Opencode, with a cross-tool primitives matrix meant to map loop concepts across those agents. The repo also dogfoods: it runs its own validate-patterns and audit workflows on every push and pull request, and ships a LOOP.md describing the loops that maintain it.
The README is heavy on links out to docs, starters, and a live interactive picker, so some of the depth lives outside the page itself. The concepts here are also young, and the core idea of handing scheduled, semi-autonomous loops write access to your repo carries real risk, which is exactly why the L1-first, human-gate framing matters. If you have been wiring up cron jobs and sub-agents by hand, this repo is a structured vocabulary and a scorecard for work you may already be improvising.
GitHub: https://github.com/cobusgreyling/loop-engineering
Curated by Agent Palisade — practical AI for small and mid-sized businesses.
Top comments (2)
@skillselion this is the sharpest pushback I have gotten on it, thank you. You are right that the score is necessary but not sufficient: it checks whether the loop can correct itself, not whether the work was worth doing. Verified-work-per-token is a better north star, and it needs a signal the harness cannot see, like what survives review a week out. Agree on event triggers over cadence too, the context re-pay on every poll is the hidden tax nobody prices. And the state-drift-before-token-exhaustion point matches what I have seen, loop-sync earns its keep long before the budget file does. How did you operationalize verified-work-per-token, manual review or an automated survives-a-week check?
Having run scheduled agent loops daily for a while: the readiness score measures the harness, not the output. You can score high and still ship vanity commits, because nothing in "is there a budget file, is there a state file" checks whether the loop's work survives review. The metric that eventually mattered for us was verified-work-per-token - how much of what the loop produced was still standing a week later. Two smaller notes: the polling patterns (PR Babysitter at 5-15 min) re-pay accumulated context on every poll, so event triggers instead of cadence cut the High rating substantially. And loop-sync is quietly the load-bearing tool in that list - long-running loops die of state drift well before they die of token exhaustion. Good writeup, the cost-honesty in the pattern table is rare.