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.
