loop engineering: the loop's the easy part
the hot take of the month is “stop prompting your agents, start writing loops.” it’s right. Boris Cherny, who built Claude Code, put it plainly: “i don’t prompt Claude anymore. i have loops running. my job is to write loops.”
so people are calling it loop engineering and writing the loop. then they close the laptop and the loop dies.
the loop is the easy part. keeping it alive, and keeping it in bounds, is the whole game.
what loop engineering actually is
it’s the next layer up from prompting. prompt engineering tunes one message. context engineering manages what the model sees. loop engineering designs the cycle: what kicks it off, what the agent does each turn, and the condition that tells it it’s actually done.
the canonical shape (Geoffrey Huntley calls it the ralph loop) is almost insultingly simple:
while not done: reset the context, run the agent against the spec, check the result, repeat.
that’s it. you can write it in an afternoon.
so why doesn’t everyone have one
because a loop that matters runs for hours or days, not one coffee break. and the second it has to survive real time, three boring problems show up:
- it has to run on something that doesn’t sleep. a loop in your terminal ends when your terminal does. close the lid, the work stops.
- it has to survive a restart. processes crash. machines reboot. if your loop’s progress lives in RAM, a restart isn’t a pause, it’s a reset to zero.
- it can’t be allowed to run forever, or run wild. an agent grinding on a broken goal at 3am, burning budget, touching things it shouldn’t, is not a feature.
none of that is the loop. all of it is the infrastructure around the loop. that’s the part the hot takes skip.
how we keep a loop alive
5dive is, underneath the org chart and the agents, a place for loops to actually live. on a box you own, on your own Claude plan, running whether you’re awake or not.
- triggers fire the loop. a cron line or a heartbeat tick starts work on a schedule or an event. no one has to be sitting there to kick it off.
- the state lives outside the agent. the task, its history, and the result sit in a database and in files and git on your box, not in a session that evaporates. kill the box mid-loop and restart it: the loop picks up where it was, it doesn’t start over.
- each agent runs as its own user on its own box. isolation isn’t a config flag you hope you set. it’s the operating system.
- a human gate can stop the loop cold. when the agent hits something only a person should decide, it parks the task and pings you, and it cannot quietly mark its own approval and roll on. the loop waits.
- and it can’t run away. a task that’s been grinding too long gets cut automatically. unattended doesn’t mean unbounded.
that’s the unglamorous half of loop engineering. the half that decides whether “agents working while you sleep” is a real sentence or a screenshot.
the rule the whole discipline rests on
here’s the one every serious practitioner lands on: the agent that did the work can’t be the one that decides the work is good. the writer doesn’t grade its own homework. the strongest loops put a separate set of eyes on the output before anything is called done.
that’s the frontier, and it’s where this all goes next. but it only means anything on top of a loop that survives the night in the first place.
the takeaway
write the loop. it’s the easy, fun part. just don’t confuse it with the job. the loop is ten lines. the box it runs on, the state that outlives a crash, the gate that stops it, the leash that bounds it: that’s loop engineering. that’s the part worth getting right.
5dive is an agent team you run on your own box, on your own plan. the loops run there, and they’re still running when you wake up. the code’s open.