3.1 Automations — The “Heartbeat” of the Loop#

Automations are responsible for making the Loop start itself, rather than waiting for someone to call it. It includes two types of triggers:

Key design principle: Don’t let “a human remembering to start it” become a precondition of the system. A good Loop should be self-driving.

3.2 Worktrees — Isolated Runtime Environments#

When multiple Agents work in parallel, they can’t share the same file system — they’d overwrite each other’s changes.

Git’s Worktree mechanism solves this problem:

1
# Each subtask runs in an independent Worktree
2
git worktree add ../fix-auth-bug main
3
cd ../fix-auth-bug
4
# The Agent works in this environment without interference

The three major values of Worktrees:

• Parallel safety: 10 Agents fixing bugs simultaneously won’t conflict
• Rollback capability: If an Agent breaks something, just delete the Worktree without affecting the main branch
• Reviewability: One branch per Worktree, changes isolated and independently reviewable

3.3 Skills — Persistent Project Knowledge#

If Context Engineering solves “what to show the Agent in a single session,” Skills solve “how to accumulate knowledge across sessions.”

Skills are Markdown files stored in the project that the Agent automatically loads each round. They contain:

1
.claude/
2
├── SKILL.md          # Overall project conventions
3
├── agents/
4
│   ├── reviewer.md   # Behavior definition of the code review Agent
5
│   └── fixer.md      # Behavior definition of the bug fix Agent
6
└── skills/
7
    ├── coding-style.md   # Code style conventions
8
    ├── architecture.md   # System architecture conventions
9
    └── pitfalls.md       # Pitfalls encountered

Every pitfall you’ve stepped into and every convention you’ve summarized settles into a Skill, becoming the “muscle memory” of all subsequent Agents. The quality of Skills determines the quality of the Loop’s output.

3.4 Connectors — Letting Agents Access the Real World#

Based on MCP (Model Context Protocol), Agents can connect to external tools:

1
Agent ←→ MCP Server ←→ External Systems
2
                           ├── GitHub API (read Issues, open PRs)
3
                           ├── Slack (send notifications, receive commands)
4
                           ├── Database (query data, validate results)
5
                           ├── CI/CD (trigger builds, read logs)
6
                           └── Linear / Jira (update ticket status)

Without Connectors, an Agent is just “talking to itself in a sandbox.” With Connectors, it can truly affect the outside world — opening PRs, updating tickets, notifying the team.

3.5 Sub-agents — Maker/Checker Separation#

This is the most easily underestimated yet most important design pattern in Loop Engineering: Don’t let the same Agent both write code and review code.

1
// Incorrect design: one Agent produces and reviews its own work
2
const result = await agent("Fix this bug, then review your own fix");
3

4
// Correct design: separation of Maker and Checker
5
const fix = await agent("Fix this bug", { role: "maker" });
6
const review = await agent(`Review this fix: ${fix.diff}`, { role: "checker" });

Why separate them?

The Checker should be prompted with “default to distrust unless proven correct,” not “default to pass unless there’s an obvious problem.” This tiny difference in the prompt determines the effectiveness of verification.

3.6 Memory / State — Beyond the Context Window#

An Agent’s context window is limited, but a continuously running Loop needs to remember what has been done and what remains to be done.

The Memory layer can be implemented very simply:

1
## Current Status
2
- Last run: 2026-06-16 09:00 UTC
3
- In progress: fix-login-timeout (PR #42 awaiting review)
4

5
## Completed
6
- [x] Fix API timeout retry logic — #41 merged
7
- [x] Update dependency versions — #40 merged
8

9
## Pending
10
- [ ] Investigate intermittent CI failures — assigned Worktree ci-flaky-test
11
- [ ] Upgrade Node.js to v26 — awaiting LTS

Osmani emphasizes: “Behind every successful Loop, there’s a set of quietly working state files.” State files are the Loop’s “short-term memory,” and Skills are the Loop’s “long-term memory.”

6.1 Verification Is Still a Human Responsibility#

A Loop can automatically complete “declaring done,” but it cannot automatically complete “proving correct.”

“Done” is a declaration. “Did it right” is a fact. A declaration is not a fact. —Addy Osmani

A Checker Agent can reduce omissions, but it cannot replace human judgment. Security changes, architectural decisions, user experience issues—these require human confirmation.

Principle: A Loop can automatically handle problems you fully understand; for problems you do not understand, a Loop only helps you make the problem clearer, and the decision is still yours.

6.2 Comprehension Debt#

This is a key concept proposed by Osmani, more hidden and more dangerous than technical debt.

1
Loop's speed of generating code
2
         >
3
Your speed of understanding code
4
         =
5
Comprehension debt is accumulating

When a Loop produces tens of thousands of lines of code every day, while your comprehension speed is constant, comprehension debt will grow exponentially. One day, you will face a system whose workings you have no idea about.

Mitigation strategies:

• Set an “output rate cap” for the Loop—do not let it run as fast as possible
• Periodically stop and manually review all recent automatic changes
• Forbid the Loop from automatically modifying core modules; allow only manual operations

6.3 Cognitive Surrender#

This is the most profound risk—when the system can run on its own, people instinctively stop thinking.

Cherny’s exact words: “The most comfortable posture is precisely the most dangerous one. When you no longer understand what the Loop is doing but the Pipeline can still run, you have already handed over the core capability of an engineer.”

Counter-strategies:

• Regular “offline days”: One day a week without using Agents, purely handwriting, to keep your skills sharp
• Self-questioning test: If this Loop disappeared tomorrow, could you still do what it does on your own?
• Keep building Loops “as an engineer”: You are designing a system, not pressing the “start button”