Loop engineering is the practice of designing automated systems that prompt AI coding agents on your behalf, rather than prompting them manually turn by turn. The concept, articulated by engineers at Anthropic and OpenAI, centers on five building blocks now present in both Claude Code and Codex: automations (scheduled discovery/triage), worktrees (parallel agent isolation via git), skills (persistent project context), plugins/connectors (MCP-based tool integrations), and sub-agents (maker/checker separation). A sixth element — external memory like a markdown file or Linear board — ties runs together across sessions. The post walks through how these pieces combine into a self-running loop that triages CI failures, drafts fixes, reviews them, opens PRs, and updates tickets autonomously. The author is cautiously optimistic but warns about token costs, comprehension debt (shipping code you don't understand), and cognitive surrender — the risk of disengaging from the work entirely when the loop runs itself.
For further actions, you may consider blocking this person and/or reporting abuse
Top comments (1)
The two failure modes you name in the warning section — comprehension debt and cognitive surrender — are the part most loop-engineering writing leaves out, and they're the ones that decide whether the rest of the architecture is actually doing what it claims. The five building blocks are necessary; without the operator paying continuous attention to what the loop is doing on their behalf, they're just a faster path to "shipping code you don't understand" at scale. That's the operator-side discipline question, and it doesn't get solved by better automations.
One sharpening I'd suggest on the maker/checker separation. Sub-agents from the same model class share the same training-data distribution, which means the maker and the checker tend to disagree only where the maker was obviously wrong and agree where the maker was confidently wrong. The maker/checker structure is the right shape; the implementation matters more than it sounds like — you want the checker either in a genuinely different model class or, even better, a deterministic check that doesn't depend on a model evaluating model output (a contract test that has to fail against the pre-change code, an MMU-style page fault, a Redis lookup against locked decisions). Otherwise you get the loop's verdict from two halves of the same probability distribution wearing different hats.
Your external-memory point is the one I'd build the rest of the loop around, not bolt on at the end. What gets carried between runs is where operator skill actually accrues — what was loud inside a session is rarely what the next session needs to walk in already standing on. That selection layer, run by deterministic rules with operator-authored source-of-truth, is what makes "leave it running" honest.