Loop engineering, first contact: small stories, fresh context, human-merged PRs
'Giving an agent a small, testable task and repeatedly running this cycle' — the whole discipline in one sentence, learned live ('I'm also learning this one, so let's learn it together').
The cycle as taught: write a precise SPEC; select ONE small user story; the agent reads agents.md, the docs, and the relevant skills; implements the story; runs the tests; on failure it RECORDS the failure and starts again — on pass it reviews and commits; it opens a PULL REQUEST; a human reviews and merges. The safety rails come with it: each iteration starts with a FRESH agent context ('much safer than telling an agent build the entire application'), a maximum iteration limit, work only on a feature branch, never automatically run destructive production commands. The repo carries the machinery: agents.md, skills/, and a loop/ folder holding the loop prompt and a run.sh that re-runs it.
The lineage is told as comedy with a real point: Claude's community 'Ralph Wiggum' loop — named for the dumbest Simpsons character — was the crude ancestor ('it came out seven months ago, and we've matured a lot'); OpenClaw and Hermes 'borrowed a lot of their code from this.' Dumb agent + tight loop + tests beat smart agent + vague instruction.
Late in the build, a learner asks why prompts now trigger loops: 'because we already have loop commands within our codebase, the prompt directly results in the loop engineering' — the scaffold, once installed, changes what every prompt means.
This is the session where the course's loop doctrine enters the Catalyst track — s15 later deepens it; the sprint later prices it. Here it's the working minimum.
Loop engineering is letting the agent run unattended until done.
It's the opposite — MORE structure: smaller stories, harder gates, and a human holding the merge button.
The LLMs do not know that they are ChatGPT... it's just a system prompt that lets them know. You can use a Chinese model and do this as well.
Each iteration starts with a fresh agent context. This is much safer than telling an agent: build the entire application.
The model-identity aside was answered TO you — and it's load-bearing for your multi-vendor strategy: harnesses portable, brands interchangeable.
Go deeper
In one line: Loop engineering = spec-driven iteration: one small testable story per cycle, agent grounded in agents.md/skills, test-gated commit, PR with human merge; fresh context each iteration, capped iterations, feature branches, no destructive autonomy; scaffolded in-repo (loop/prompt + run.sh).
Model-agnostic by design, said to Paul: 'the LLMs do not know what they are... it's just a system prompt' — the loop works on any capable model ()
The failure RECORD matters as much as the retry — the loop learns from its own log, not from vibes ()
Ralph-loop origin shared with the actual repo link when a learner asks ()
'goal.md' arrives the next day (s20) as the companion discovery — end-state alongside behavior
▶ Watch this taught:
Answer from memory first — the recall attempt is what makes it stick. Then reveal.
Why fresh context per iteration instead of one long omniscient session?
Stale context compounds errors and hides drift; a fresh agent reading the spec, the code, and the failure log re-derives truth from artifacts — which is why the artifacts, not the chat, must carry the knowledge.
