Lesson 06 · Loop Engineering
Automations are what make a loop a loop, and not one run you did once.
You now have state, skills, a verifier and isolation. None of it repeats until something starts it without you. That is the automation.
Not the work. The discovery. Osmani lists what OpenAI runs internally: daily issue triage, summarising CI failures, writing commit briefings, hunting bugs somebody added last week. Boring, recurring, and exactly the things you keep meaning to check.
In the Codex app you set the project, the prompt, the cadence, and whether it runs
on your local checkout or a background worktree. Runs that find something go to a
Triage inbox; runs that find nothing archive themselves. In Claude Code you reach the
same place through scheduled tasks and cron, /loop, hooks on the agent
lifecycle, or GitHub Actions if you want it running after you close the laptop.
$skill-name instead of pasting a giant wall of instructions into a
schedule that nobody will ever update.
/loop versus /goalThese are two different primitives and the difference is the whole point of the course.
/loop | /goal | |
|---|---|---|
| Stops when | you stop it | a condition you wrote is true |
| Driven by | a cadence | a verifiable outcome |
| Who judges | nobody | a separate small model, after every turn |
| Good for | recurring discovery | run-until-done work |
A /goal condition must be checkable, not vague. "All tests in
test/auth pass and lint is clean" works. "The code is good" does not.
Codex has the same primitive, also called /goal, with pause and resume.
What should a scheduled automation mostly be doing?
Which is a usable /goal stopping condition?
Write a cadence and a prompt for your first automation. One line each.
$triage
skill against yesterday's CI failures and open issues, write findings to
LOOP.md, change no source files". Read-only for the first week.
Primary source: the Automations, this is the heartbeat section of Loop Engineering. Codex users should also read the Codex automations docs.