/loop is just the building block: a loop that repeats a task.

Loop Engineering is the craft around it – making sure the loop can run unattended for days without causing harm.

Boris Cherny runs several routines daily over his own apps, in a Slack channel.

A crash fuzzer taps around the app and fixes crashes, a dup unifier finds duplicate code, a dead-code remover cleans up – each routine with its own job.

Not necessarily. Without a time given, Claude picks the interval itself.

Short while things are actually happening – longer during quiet stretches. That’s exactly what makes running for days practical: nobody has to keep adjusting an interval.

Yes – that’s called a Ralph‑loop: plan, execute, check, from the top.

Robust, but crude – without a brake it keeps burning tokens even after it’s long since done. That’s exactly what auto-pacing is for, and the verification that comes next.

That’s exactly where Loop Engineering stands or falls: the loop has to be able to verify its own work itself, end‑to‑end.

Run the tests, have a second model review it – automated code review and security review – and only then offer the change as a pull request.

Then you adjust the routine – or just ask Claude to improve it itself.

Sometimes one day is enough, sometimes it takes several attempts before the routine sits reliably. That’s expected, not a failure.

The systematic version is called hill climbing: you measure quality with a fixed checklist – an eval – and adjust the routine on purpose.

No guesswork: every change gets tested against the eval, only what actually scores better stays in.

No – each routine works in its own copy of the project, a worktree.

That way parallel runs don’t interfere with each other, and a failed attempt doesn’t drag the main branch down with it.

Mostly yes: each routine its own Claude – many of them at once is called a fleet.

But sometimes several Claudes work together on a single task, with roles split up – that’s a squad: one plans, one builds, one reviews.

Yes – the sum of tools, permissions, memory, and orchestration around the model is called a harness.

Loop Engineering is exactly that: building a harness Claude can work in, unattended, for days.

For a single afternoon, /loop really is completely enough.

Loop Engineering pays off once several such routines are meant to run alongside each other permanently – then individual loops turn into a small workshop that maintains itself.

That’s exactly the point.