Boris Loop Engineering Kit for Claude

A practical, source-grounded guide to turning Claude Code from a chat tool into a repeatable engineering loop you can run on every project.

By Arjav Jain · COO @ Hyperke, @lifeofarjav 11 min read Originally a reel on @lifeofarjav

curated and compiled by Arjav Jain

@lifeofarjav

A practical, source-grounded guide to turning Claude Code from a chat tool into a repeatable engineering loop.

Use this when you want Claude to keep working toward a defined outcome instead of asking it one prompt at a time.

Important accuracy note

Boris Cherny is widely reported as the creator and head of Claude Code. Public reporting says he uses multiple Claude Code sessions, many agents, /loops, and Routines for persistent automation. The official Claude Code documentation confirms the underlying mechanisms used in this guide: the agent loop, CLAUDE.md, /goal, /loop, Routines, subagents, agent teams, dynamic workflows, hooks, and the Agent SDK.

This document does not claim that Boris personally wrote every template below. It turns publicly reported Boris-style usage into an accurate, practical, copy-pasteable workflow using officially documented Claude Code features.

The core idea
What Boris Cherny is actually known for here
What a loop means in Claude Code
The 5 levels of loop engineering
Setup: install and open Claude Code
Starter project structure
Template 1: CLAUDE.md
Template 2: review-only loop
Template 3: goal-based coding loop
Template 4: scheduled /loop
Template 5: durable Routine
Template 6: dynamic workflow
Template 7: programmatic Agent SDK harness
Safety, permissions, and cost controls
Use cases
Anti-patterns
Final checklist
Source notes

The core idea

Most people use AI like this:

Human writes prompt
AI gives answer
Human checks answer
Human asks for correction
AI tries again
Human checks again

That is useful, but it does not scale.

The loop engineering mindset is different:

Define the goal
Define the rules
Let Claude act
Let Claude observe the result
Let Claude judge progress
Let Claude repeat until the exit condition is met
Review the final output

The shift is simple:

Old way: You keep prompting Claude.
New way: You build a loop where Claude keeps working toward a verifiable outcome.

That is why the interesting part is not the prompt. The interesting part is the harness around the prompt.

A good harness gives Claude:

a clear task
access to the right files and tools
rules it must follow
tests or checks to verify progress
a stopping condition
a final reporting format

Without the harness, Claude is just answering.

With the harness, Claude is working.

What Boris Cherny is actually known for here

Boris Cherny is reported by The Verge as the creator and head of Claude Code.1 Business Insider reported that Cherny described a workflow involving multiple Claude Code sessions, many agents, /loops, and Routines during a May 2026 Sequoia Capital interview.2

The important reported details are:

He typically runs multiple Claude Code sessions.
Those sessions can contain multiple agents.
He described having thousands of agents doing deeper work overnight.
He said he relies on /loops and Routines for persistent automation.
He framed this as a way to use AI less like a chatbot and more like an always-on assistant.

The official Claude Code docs line up with the underlying system:

Claude Code can read a codebase, edit files, run commands, and integrate with development tools.3
The agent loop is officially described as: Claude receives a prompt, evaluates the state, requests tools, tools execute, results feed back to Claude, and the cycle repeats until Claude returns a final answer.4
CLAUDE.md is officially documented as a project instruction file Claude reads at the start of every session.5
/goal keeps Claude working until a completion condition is met.6
/loop repeats prompts on a schedule inside a session.7
Routines run saved Claude Code configurations on Anthropic-managed infrastructure and can trigger on schedules, API calls, or GitHub events.8
Dynamic workflows let Claude write and orchestrate multi-agent harnesses for complex tasks.9

That is the factual base for this guide.

What a loop means in Claude Code

A loop is not magic. It is a control system.

At the simplest level, it looks like this:

1. Act
2. Observe
3. Judge
4. Repeat or stop

In Claude Code, that usually means:

1. Claude reads the goal.
2. Claude inspects files.
3. Claude edits code or writes output.
4. Claude runs a check.
5. Claude reads the result.
6. Claude decides what to fix next.
7. Claude repeats until the goal is satisfied.
8. Claude reports what changed.

Example:

Goal: All auth tests pass.
Act: Edit auth.ts.
Observe: Run npm test.
Judge: Did all auth tests pass?
Repeat: If no, inspect failure and fix.
Stop: If yes, summarize the changes.

This is different from prompting because the human is no longer manually driving every correction.

The human’s job becomes:

Define the destination.
Define the boundaries.
Define the evidence of success.
Review the final work.

That is the real skill.

The 5 levels of loop engineering

Do not jump straight into autonomous agents editing production code. That is amateur behavior wearing an advanced costume.

Start safe. Earn autonomy.

Level 1: Review-only loop

Claude reviews files and writes feedback. It does not edit the original files.

Use this for:

reviewing landing pages
reviewing code files
reviewing specs
reviewing copy
reviewing technical claims
reviewing documents before you publish them

This is the safest first loop.

Level 2: Goal-based local loop

Claude keeps working inside one session until a condition is met.

Use this for:

tests passing
lint passing
a file being created
a migration being completed
a bug being fixed
acceptance criteria being satisfied

Best tool: /goal

Level 3: Time-based loop

Claude checks something repeatedly on a schedule.

Use this for:

checking CI every few minutes
watching a deployment
checking PR comments
babysitting a build
running recurring maintenance while the session is open

Best tool: /loop

Level 4: Durable routine

Claude runs automatically even when your machine is not the thing driving the session.

Use this for:

nightly PR review
weekly dependency audits
scheduled documentation drift checks
morning engineering summaries
routine backlog triage

Best tool: Claude Code Routines

Level 5: Dynamic workflow

Claude writes an orchestration script and uses many subagents to do large-scale work.

Use this for:

codebase-wide audits
many-file migrations
cross-checked research
adversarial review
sorting hundreds or thousands of items
debugging with competing hypotheses

Best tool: dynamic workflows with ultracode or explicit workflow prompts.

Setup: install and open Claude Code

Install commands change over time, so always confirm them against the official Claude Code docs before posting them publicly. At the time this document was created, the official docs listed the following commands.

macOS, Linux, WSL

curl -fsSL https://claude.ai/install.sh | bash

Then open Claude Code in your project:

cd your-project
claude

Homebrew on macOS

brew install --cask claude-code

Windows PowerShell

irm https://claude.ai/install.ps1 | iex

Windows CMD

curl -fsSL https://claude.ai/install.cmd -o install.cmd && install.cmd && del install.cmd

Starter project structure

Use this starter folder if you want a safe review-only loop before letting Claude edit real code.

mkdir claude-review-loop
cd claude-review-loop
mkdir -p input reviews .claude
mkdir -p examples
printf "# Claude Review Loop\n" > README.md
touch CLAUDE.md
touch .claude/loop.md
touch input/first-review.md

Your folder should look like this:

claude-review-loop/
  CLAUDE.md
  README.md
  .claude/
    loop.md
  input/
    first-review.md
  reviews/
  examples/

Purpose of each file:

File or folder	Purpose
`CLAUDE.md`	Persistent project instructions Claude reads at session start
`.claude/loop.md`	Default instructions for a bare `/loop`
`input/`	Files you want Claude to review
`reviews/`	Where Claude writes review reports
`examples/`	Optional examples of good output

This is the safest architecture because Claude can produce useful work without touching the original files.

Template 1: `CLAUDE.md`

Put this in CLAUDE.md at the project root.

# Claude Review Loop

You are running a review-only loop.

## Your job

Review files placed inside the `input/` folder and write clear feedback reports inside the `reviews/` folder.

## Critical rules

-Do not edit files inside `input/`.
-Do not delete files inside `input/`.
-Do not rewrite the original file directly.
-Do not create new project files outside `reviews/` unless I explicitly ask.
-Only write review reports inside `reviews/`.
-Keep feedback practical, specific, and easy to understand.
-If a file is weak, say exactly why.
-If a file is good, say exactly what is good.
-If you are unsure, say what you are unsure about.

## Review report format

For each reviewed file, create one markdown file inside `reviews/`.

Use this filename format:

`reviews/YYYY-MM-DD-file-name-review.md`

Each review must include:

1.File reviewed
2.One-sentence summary
3.What the file is trying to do
4.What is good
5.What is weak or unclear
6.Specific improvements
7.Suggested rewrite or code change, if useful
8.Final score out of 10
9.What I should do next

## Scoring rubric

10 = excellent, ready to ship
8 to 9 = strong, only minor fixes needed
6 to 7 = useful but needs meaningful improvement
4 to 5 = unclear or incomplete
1 to 3 = not useful in current form

## If there is nothing new

If there are no new files to review, say:

`Nothing new to review.`

Why this matters:

CLAUDE.md is where you put stable instructions. Do not bury important rules inside one prompt and expect the model to remember them across long work. Put durable rules in the project instruction file.

Template 2: review-only loop

This is the cleanest beginner loop.

Step 1: add a file to review

Create a file:

cat > input/first-review.md <<'EOF'
# Landing page headline

We help businesses grow with AI.
EOF

Step 2: start Claude Code

claude

Step 3: run a manual review loop

Paste this into Claude Code:

Run the review-only loop.

Follow `CLAUDE.md` strictly.
Review all files inside `input/`.
Do not edit anything inside `input/`.
Write one review report inside `reviews/` for each file.
Use today's date in the filename.
If there is nothing new to review, say that clearly.

Step 4: inspect the result

Check the reviews/ folder:

ls reviews
cat reviews/*.md

Step 5: improve the input manually

Read the review, improve your original file yourself, and rerun the loop.

This builds the muscle before you let Claude edit files directly.

Template 3: goal-based coding loop

Use /goal when the job has a verifiable finish line.

Officially, /goal sets a completion condition, and Claude keeps working across turns until a model evaluator confirms the condition is met.10

Example 1: fix tests

/goal `npm test -- auth` exits 0, `npm run lint` exits 0, and the final response lists every file changed.

Example 2: implement a feature

/goal The login form works end to end, all existing tests pass, at least one new test covers invalid password handling, and `npm run lint` exits 0.

Example 3: refactor safely

/goal Split `src/services/billing.ts` into focused modules under 250 lines each, preserve all public exports, run the test suite successfully, and show a before/after file map.

Example 4: issue backlog

/goal Every GitHub issue labeled `small-bug` has either a linked PR, a reproduced failure, or a comment explaining why it cannot be reproduced.

What makes a good `/goal`

A good goal has three parts:

1. Measurable end state
2. Explicit proof check
3. Boundary conditions

Weak:

/goal improve the auth module

Strong:

/goal All tests in `test/auth` pass, `npm run lint` exits 0, no public API names change, and the final response explains the root cause.

The difference is that the strong version tells Claude how to know it is done.

Template 4: scheduled `/loop`

Use /loop when you want Claude to repeat a prompt on a schedule inside the current session.

The official docs describe /loop as the quickest way to run a prompt repeatedly while the session stays open. You can supply an interval and a prompt, only a prompt, or neither.11

Fixed interval example

/loop 5m check whether CI passed. If it failed, inspect the failing log and propose the smallest fix. If it passed, say "CI is green" and do nothing else.

Dynamic interval example

/loop check whether the deployment finished and whether any errors appeared in the logs. Choose a sensible delay after each check based on what you find.

PR maintenance example

/loop 20m check the current branch's PR. If there are new review comments, address them. If CI is failing, inspect the failing job and fix the smallest issue. If everything is green and quiet, say so in one line.

Default `.claude/loop.md`

Put this in .claude/loop.md if you want a bare /loop to run your own maintenance prompt.

Check the current branch and PR.

If CI is red, inspect the failing log, diagnose the root cause, and propose or apply the smallest safe fix.

If review comments are open, address each one and summarize what changed.

If there are no active failures, run a light cleanup pass:

-look for obvious lint issues
-look for missing tests around recently changed code
-look for stale comments

Do not start unrelated feature work.
Do not delete files without explicit approval.
Do not push unless the current transcript already authorized pushing.

End with a short status:

-What changed
-What still needs review
-Whether CI is green

When not to use `/loop`

Do not use /loop for work that must run forever. Session-scoped scheduled tasks have limits. The official docs say session-scoped tasks only fire while Claude Code is running and idle, and recurring tasks expire after seven days.12

Use Routines for durable automation.

Template 5: durable Routine

Use a Routine when you want Claude to run without relying on your current open terminal session.

Officially, a Routine is a saved Claude Code configuration that includes a prompt, repositories, connectors, and triggers. Routines run on Anthropic-managed infrastructure and can trigger on a schedule, API call, or GitHub event.13

Example Routine: nightly PR review

Routine name

Nightly PR Review

Trigger

Weekdays at 9:00 AM

Prompt

Review all open pull requests in this repository.

For each PR:

1. Read the diff.
2. Check for obvious bugs, missing tests, risky logic, security concerns, and unclear naming.
3. Run the relevant test command if available.
4. Leave a concise review summary.
5. If a small fix is obvious and safe, open a draft PR branch with the fix instead of pushing directly to the original branch.

Do not approve your own work.
Do not merge anything.
Do not modify production secrets.
Do not push to protected branches.

At the end, post a summary with:

- PRs reviewed
- issues found
- fixes proposed
- anything needing human review

Example Routine: docs drift check

Each Friday, scan merged PRs from the last 7 days.

Find code changes that should be reflected in documentation.

For each possible docs drift:

1. Identify the changed API, behavior, command, or config.
2. Find the relevant documentation file.
3. Open a draft PR with the minimal docs update.
4. If no docs file exists, create an issue explaining what needs documentation.

Do not change code.
Only update documentation or open issues.

Example Routine: morning engineering brief

Every weekday morning, summarize engineering changes since the last run.

Include:

1. Merged PRs
2. Open PRs waiting on review
3. Failed CI runs
4. New production errors, if connectors expose them
5. Issues that look blocked
6. Recommended focus for today

Keep the final summary under 500 words.
Do not make code changes.

Routine safety rules

Routines are powerful because they can run autonomously. That means your prompt must be stricter than a normal prompt.

Include:

Do not merge.
Do not delete.
Do not modify secrets.
Do not push to protected branches.
Use draft PRs for proposed code changes.
Escalate anything ambiguous.
Summarize all actions taken.

Template 6: dynamic workflow

Use a dynamic workflow when the job is too large or too adversarial for one context window.

The official Claude article says dynamic workflows allow Claude Code to write and orchestrate its own multi-agent harness on the fly.14 The docs describe dynamic workflows as JavaScript scripts that orchestrate subagents at scale. Claude writes the script for your task, and the runtime executes it in the background.15

When to use a dynamic workflow

Use it when the task needs:

many parallel investigations
independent verification
competing hypotheses
a loop until no new findings appear
a migration across many files
a tournament or scoring process
adversarial review

Prompt: codebase audit

ultracode: audit every API endpoint under `src/routes/` for missing authentication checks.

Use a dynamic workflow.

Requirements:

1. Spawn separate agents to inspect different route groups.
2. For each suspected issue, spawn a verifier agent to check whether the issue is real.
3. Deduplicate findings.
4. Do not edit code yet.
5. Produce a final markdown report with:
   - endpoint
   - file path
   - issue
   - evidence
   - severity
   - recommended fix
   - verifier result

Stop when every route file has been inspected and every finding has been verified or rejected.

Prompt: keep fixing until tests pass

ultracode: fix the failing test suite.

Use a dynamic workflow only if the failures are spread across multiple modules.

Process:

1. Run the test suite.
2. Classify failures by module.
3. Spawn one agent per independent failure group.
4. Each agent proposes the smallest fix in its own worktree.
5. Spawn verifier agents to review each fix.
6. Merge only fixes that pass verification.
7. Run the full test suite again.
8. Repeat until the full suite passes or until you hit 5 iterations.

Constraints:

- Do not rewrite large files unless necessary.
- Do not change public APIs without explaining why.
- Do not ignore failing tests.
- Stop and ask me if the fix requires deleting tests.

Final output:

- root causes
- files changed
- tests run
- remaining risks

Prompt: technical claim verification

ultracode: verify every technical claim in `input/post.md` against official documentation or source code.

Use a workflow.

Process:

1. Extract every factual technical claim.
2. Spawn one source-checking agent per claim.
3. For each claim, classify it as:
   - verified
   - partially true
   - unsupported
   - false
4. Spawn a verifier agent to challenge each classification.
5. Produce a final report in `reviews/claim-check.md`.

Do not rewrite the post yet.
Only produce the verification report.

Prompt: mine your corrections into rules

This one is very close to the spirit of loop engineering because it improves the harness itself.

ultracode: review my last 50 Claude Code sessions and identify corrections I repeatedly made.

Turn recurring corrections into proposed `CLAUDE.md` rules.

Process:

1. Find repeated human corrections.
2. Cluster them by theme.
3. For each candidate rule, ask whether it would have prevented a real mistake.
4. Remove rules that are too vague, too broad, or likely to create false positives.
5. Produce a final patch proposal for `CLAUDE.md`.

Do not edit `CLAUDE.md` directly until I approve the proposed rules.

Template 7: programmatic Agent SDK harness

The deepest version of loop engineering is building your own harness with the Claude Agent SDK.

The official Agent SDK docs say the SDK lets you embed Claude Code’s autonomous agent loop in your own applications and gives you programmatic control over tools, permissions, cost limits, and output.16

Here is a simple educational skeleton.

Treat this as a starting pattern, not production infrastructure.

import asyncio
from claude_agent_sdk import query, AssistantMessage, ResultMessage

PROMPT = """
You are reviewing this repository for authentication bugs.

Goal:
Find likely authentication bugs and write a report.

Rules:
- Do not edit files.
- Read only the files needed to understand auth flow.
- Prefer evidence from source code over guesses.
- Return a markdown report with file paths, line references, risk, and suggested fix.
"""

async def main():
    async for message in query(prompt=PROMPT):
        if isinstance(message, AssistantMessage):
            print("Turn completed")

        if isinstance(message, ResultMessage):
            if message.subtype == "success":
                print(message.result)
            else:
                print(f"Stopped with status:{message.subtype}")

asyncio.run(main())

A more serious harness would add:

max_turns
max_budget_usd
tool allowlists
tool denylists
structured output
persistent session storage
logs
human approval points
test execution
rollback or checkpointing

Conceptually, your harness should look like this:

Input
  -> Claude agent
  -> tool calls
  -> results
  -> evaluator
  -> continue or stop
  -> final artifact

This is the real engineering layer. The prompt is only one piece.

Safety, permissions, and cost controls

This is where beginners get reckless.

The more autonomy you give Claude, the more specific your constraints need to be.

1. Start read-only

Before allowing edits, run review-only loops.

Good first command:

Review this codebase for auth issues. Do not edit files. Write a report only.

Bad first command:

Fix all security issues everywhere.

The second prompt is lazy and dangerous.

2. Define allowed areas

Tell Claude what it can touch.

You may edit only:

- `src/auth/**`
- `test/auth/**`

Do not edit:

- `.env`
- infrastructure files
- billing code
- database migration files
- production deployment config

3. Add proof checks

Do not accept “done” as proof.

Ask for evidence:

Proof required:

- `npm test -- auth` exits 0
- `npm run lint` exits 0
- `git diff --stat` is included
- every changed file is listed

4. Use budgets

Claude Code sessions and workflows can use many tokens. The official docs warn that running several sessions or subagents at once multiplies token usage, and workflows may use significantly more tokens.17 18

Use budget language:

Use at most 10k tokens for exploration.
If you need more, stop and explain why.

For programmatic agents, use SDK budget controls such as max_turns and max_budget_usd where appropriate.19

5. Do not use unrestricted permissions outside isolation

If you run with high autonomy, use a safe environment.

Safe options:

a disposable branch
a local sandbox
a container
a worktree
a test repository
CI with limited credentials

Dangerous options:

production credentials
unrestricted shell access on your main machine
access to private customer data without strict scope
permission to push directly to protected branches

The official Agent SDK docs explicitly say broad permission bypass should be reserved for CI, containers, or other isolated environments.20

Use cases

Use case 1: review a landing page

Folder:

input/landing-page.md
reviews/

Prompt:

Run the review-only loop.
Review `input/landing-page.md` for clarity, offer strength, proof, objections, and conversion risk.
Write the report inside `reviews/landing-page-review.md`.
Do not rewrite the page yet.

Use case 2: fix a failing test

Prompt:

/goal `npm test -- billing` exits 0, `npm run lint` exits 0, and the final answer explains the root cause in simple English.

Use case 3: weekly docs drift

Routine prompt:

Every Friday, inspect merged PRs from the last 7 days.
Find code changes that should update docs.
Open draft docs PRs only.
Do not change application code.

Use case 4: PR review loop

/loop 30m review the current PR. If new review comments appear, address them. If CI fails, inspect logs and propose the smallest safe fix. If everything is green, say so and wait.

Use case 5: claim-check a technical post

ultracode: verify every technical claim in `input/post.md` against official docs.
Do not rewrite the post.
Write a source-backed report to `reviews/post-claim-check.md`.

Use case 6: triage a bug backlog

ultracode: triage all issues labeled `bug`.
Group duplicates, identify likely root causes, and propose next actions.
Do not close issues.
Do not assign severity above P2 without evidence.
Write a final triage report.

Anti-patterns

Anti-pattern 1: vague goals

Bad:

Make the app better.

Good:

Find the top 5 reasons the checkout flow might fail, verify each against code or logs, and write a report with evidence.

Anti-pattern 2: no exit condition

Bad:

Keep improving until it is good.

Good:

Stop when `npm test` and `npm run lint` both exit 0, or after 10 turns if blocked.

Anti-pattern 3: no boundaries

Bad:

Fix everything you find.

Good:

Only edit files under `src/auth/` and `test/auth/`. Ask before changing anything else.

Anti-pattern 4: no verification

Bad:

Tell me when done.

Good:

Show the exact command outputs proving the checks passed.

Anti-pattern 5: trusting the first answer

Bad:

Write the solution and ship it.

Good:

Write the solution, then run a separate verification pass against the acceptance criteria before summarizing.

Anti-pattern 6: using multi-agent workflows for tiny tasks

Bad:

Use 10 agents to rename one variable.

Good:

Use one normal Claude Code session for simple edits. Use workflows only when parallelism or verification earns the extra cost.

Final checklist

Before you run any serious loop, answer these questions:

1. What is the exact goal?
2. What proves the goal is complete?
3. What is Claude allowed to edit?
4. What is Claude forbidden from touching?
5. What commands should Claude run?
6. What should happen if tests fail?
7. What should happen if Claude is unsure?
8. What is the maximum number of turns or token budget?
9. Should Claude write a report, open a PR, or ask for review?
10. What human approval point is required before anything risky?

If you cannot answer these, you are not ready to automate the task.

You are still prompting.

The next level is not better prompts.

The next level is better systems.

Copy-paste starter pack

Safe review loop prompt

Run the review-only loop.

Follow `CLAUDE.md` strictly.
Review everything inside `input/`.
Do not edit files inside `input/`.
Write review reports inside `reviews/`.
If there is nothing new to review, say that clearly.

Safe coding goal prompt

/goal All tests related to this feature pass, `npm run lint` exits 0, no files outside the agreed scope are modified, and the final response lists every changed file with the reason for the change.

Safe PR loop prompt

/loop 20m check the current PR. If CI failed, inspect the log and propose the smallest safe fix. If review comments arrived, address them one by one. If everything is green and quiet, say "PR is green and quiet".

Safe workflow prompt

ultracode: use a workflow to audit the codebase for the specified issue.

Rules:

- Do not edit code.
- Spawn agents by module.
- Verify every finding with a separate verifier agent.
- Deduplicate findings.
- Return a markdown report only.
- Stop when every relevant file has been inspected.

Safe Routine prompt

Run this routine on schedule.

Your job is to inspect, report, and propose fixes.

Rules:

- Do not merge.
- Do not delete.
- Do not modify secrets.
- Do not push to protected branches.
- Use draft PRs for proposed code changes.
- Escalate anything ambiguous.
- End with a clear summary of actions taken.

Source notes

This guide was built from the following public sources and official docs:

Boris Cherny has publicly discussed using many Claude Code agents, `/loops`, and Routines for persistent automation. 

Claude's official docs now include `/goal`, `/loop`, Routines, dynamic workflows, subagents, and Agent SDK tools that make this loop-based workflow practical.

The Verge, “Claude has been having a moment, can it keep it up?” February 5, 2026. https://www.theverge.com/report/874308/anthropic-claude-code-opus-hype-moment ↩︎
Business Insider, “Claude Code’s creator says his setup involves thousands of AI sub-agents doing ‘deeper work’ overnight,” May 13, 2026. https://www.businessinsider.com/anthropic-engineer-claude-boris-cherny-ai-agent-use-overnight-2026-5 ↩︎
Claude Code Docs, “Overview.” https://code.claude.com/docs ↩︎
Claude Code Docs, “How the agent loop works.” https://code.claude.com/docs/en/agent-sdk/agent-loop ↩︎
Claude Code Docs, “Overview,” section describing CLAUDE.md. https://code.claude.com/docs ↩︎
Claude Code Docs, “Keep Claude working toward a goal.” https://code.claude.com/docs/en/goal ↩︎
Claude Code Docs, “Run prompts on a schedule.” https://code.claude.com/docs/en/scheduled-tasks ↩︎
Claude Code Docs, “Automate work with routines.” https://code.claude.com/docs/en/routines ↩︎
Claude by Anthropic, “A harness for every task: dynamic workflows in Claude Code,” June 2, 2026. https://claude.com/blog/a-harness-for-every-task-dynamic-workflows-in-claude-code ↩︎
Claude Code Docs, “Keep Claude working toward a goal.” https://code.claude.com/docs/en/goal ↩︎
Claude Code Docs, “Run prompts on a schedule.” https://code.claude.com/docs/en/scheduled-tasks ↩︎
Claude Code Docs, “Run prompts on a schedule,” limitations and seven-day expiry. https://code.claude.com/docs/en/scheduled-tasks ↩︎
Claude Code Docs, “Automate work with routines.” https://code.claude.com/docs/en/routines ↩︎
Claude by Anthropic, “A harness for every task: dynamic workflows in Claude Code,” June 2, 2026. https://claude.com/blog/a-harness-for-every-task-dynamic-workflows-in-claude-code ↩︎
Claude Code Docs, “Orchestrate subagents at scale with dynamic workflows.” https://code.claude.com/docs/en/workflows ↩︎
Claude Code Docs, “How the agent loop works.” https://code.claude.com/docs/en/agent-sdk/agent-loop ↩︎
Claude Code Docs, “Run agents in parallel.” https://code.claude.com/docs/en/agents ↩︎
Claude by Anthropic, “A harness for every task,” sections on when not to use workflows and token budgets. https://claude.com/blog/a-harness-for-every-task-dynamic-workflows-in-claude-code ↩︎
Claude Code Docs, “How the agent loop works,” section on turns and budget. https://code.claude.com/docs/en/agent-sdk/agent-loop ↩︎
Claude Code Docs, “How the agent loop works,” section on permission mode. https://code.claude.com/docs/en/agent-sdk/agent-loop ↩︎

Related in Open-source AI

← Back to Writing

Table of contents

The core idea

What Boris Cherny is actually known for here

What a loop means in Claude Code

The 5 levels of loop engineering

Level 1: Review-only loop

Level 2: Goal-based local loop

Level 3: Time-based loop

Level 4: Durable routine

Level 5: Dynamic workflow

Setup: install and open Claude Code

macOS, Linux, WSL

Homebrew on macOS

Windows PowerShell

Windows CMD

Starter project structure

Template 1: CLAUDE.md

Template 2: review-only loop

Step 1: add a file to review

Step 2: start Claude Code

Step 3: run a manual review loop

Step 4: inspect the result

Step 5: improve the input manually

Template 3: goal-based coding loop

Example 1: fix tests

Example 2: implement a feature

Example 3: refactor safely

Example 4: issue backlog

What makes a good /goal

Template 4: scheduled /loop

Fixed interval example

Dynamic interval example

PR maintenance example

Default .claude/loop.md

When not to use /loop

Template 5: durable Routine

Example Routine: nightly PR review

Example Routine: docs drift check

Example Routine: morning engineering brief

Routine safety rules

Template 6: dynamic workflow

When to use a dynamic workflow

Prompt: codebase audit

Prompt: keep fixing until tests pass

Prompt: technical claim verification

Prompt: mine your corrections into rules

Template 7: programmatic Agent SDK harness

Safety, permissions, and cost controls

1. Start read-only

2. Define allowed areas

3. Add proof checks

4. Use budgets

5. Do not use unrestricted permissions outside isolation

Use cases

Use case 1: review a landing page

Use case 2: fix a failing test

Use case 3: weekly docs drift

Use case 4: PR review loop

Use case 5: claim-check a technical post

Use case 6: triage a bug backlog

Anti-patterns

Anti-pattern 1: vague goals

Anti-pattern 2: no exit condition

Anti-pattern 3: no boundaries

Anti-pattern 4: no verification

Anti-pattern 5: trusting the first answer

Anti-pattern 6: using multi-agent workflows for tiny tasks

Final checklist

Copy-paste starter pack

Safe review loop prompt

Safe coding goal prompt

Safe PR loop prompt

Safe workflow prompt

Safe Routine prompt

Source notes

Related in Open-source AI

Template 1: `CLAUDE.md`

What makes a good `/goal`

Template 4: scheduled `/loop`

Default `.claude/loop.md`

When not to use `/loop`