Short answers to the questions people ask first. Each links to the chapter that goes deeper.
No. A cron job repeats blindly — same action, no matter what. A loop
discovers what to work on, verifies the result with an independent
checker, persists state so the next run resumes, and decides what's next
or stops for an honest reason. /loop (cadence) is the cron-like piece; it's
only one of the seven lifecycle stages. → docs/03
No — the prompt moved inside the loop. You still write it carefully; you just stop retyping it every turn. Osmani is explicit that prompting agents directly is still effective and "it's all about finding the right balance." Loop engineering sits on top of prompt, context, and harness engineering — it doesn't replace them. → docs/02
No, and this is the most common misconception. Osmani is explicit: "That's what makes loop design harder than prompt engineering, not easier… the leverage point moved." Two people can build the identical loop: one moves faster on work they understand deeply, the other uses it to avoid understanding the work at all. The loop doesn't know the difference — you do. The hard thinking moves from typing prompts to designing verification, owning intent, and reviewing output. → docs/01
No. The five building blocks (automations, worktrees, skills, connectors, sub-agents) ship in both and map almost one-to-one, but the skill is designing a loop that survives a tool switch. The minimal "Ralph" loop is one line of bash around any headless CLI agent, and the examples/ folder runs in plain Python with no API key. → docs/04
Verification by a separate checker. A loop running unattended is also a loop making mistakes unattended; the only reason you can walk away is a verifier you trust. The agent that writes must not be the agent that decides it's done — models reliably skew positive grading their own work ("GANs for prose"). Prefer a deterministic check (a test's exit code) over an LLM judge whenever one exists. → docs/05
Two different ceilings. Money: cap iterations/tokens/time/dollars, gate before acting (if the check is already green, do nothing), cache the stable prefix (a loop re-sends the same context every turn — caching discounts that repeated part ~90%), compact long context, and right-size the model per role. An N-step loop trends toward O(N²) because each turn re-bills the history. Your attention: you can only merge what you can read — "scale the fleet to your review rate," usually a low single digit. → docs/08
Fewer than the tool will let you. The bottleneck isn't the tool's lane count, it's your review bandwidth — "you are the GIL of your AI agents." Adding agents optimizes the part that was never the constraint (generation) and just deepens the queue waiting on the part that is (your judgment). → docs/08
Name the cheats explicitly in the maker's instructions: never weaken or delete a test, never widen scope to go green, never stub a function and call it done. Then make the checker adversarial — default to REJECT, re-run the tests itself rather than trusting the maker's claim, and confirm the diff is scoped. The verifier prompts show the pattern.
- Read docs/01 and the Cheat Sheet.
- Get one single-agent run reliable (a good harness) before you automate it.
- Copy a
/goalprompt from prompts/goal-and-loop.md and run it report-only for a while before granting write access. - Add a separate verifier, then a budget, then an escalation path.
Parts of it are over-sold, and the repo keeps the skeptics in the reading list on purpose — Karpathy's "keep AI on the leash," the field reports that agents can "feel like a slot machine," and the critiques of the exponential-capability narrative. The durable core isn't hype: runs tools in a loop, verify with something that isn't the maker, remember on disk, know when to stop. Read the critics and stay calibrated.