Loop engineering na wetin? Simple definition

Loop engineering mean wetin

Loop engineering na the practice of designing the repeating cycle wey an AI agent dey run: wetin dey wake am, wetin e fit touch, how dem go check the output, and wetin go stop am. Prompt engineering dey shape one message for a model. Loop engineering dey shape the process wey dey send thousands of messages while you dey sleep. The unit of work dey move from prompt go loop.

The short version be say: you stop writing instructions and start writing a control system. The agent still need good instructions, but dem become one part inside a cycle wey run on schedule, work inside an isolated copy of your code, prove the result with a test, and stop when budget finish.

Why di term show for 2026

Dem dey set this name publicly right now. The GitHub repository cobusgreyling/loop-engineering pass 9,600 stars within two months after e first show (as of July 2026), and e show about 11,600 on 2026-10-27, under the line "Stop prompting. Design the loop. Get a score." For July 2026, the README group the change into six building blocks: scheduling, worktrees, skills, plugins and connectors, sub-agents, and durable memory wey dem keep outside the conversation. The current README no longer get that list (checked 2026-10-27), but e still keep the loop state for a file outside the conversation.

The repository credit Boris Cherny, wey lead Claude Code for Anthropic, as one of the inspirations. The line wey people report widely na:

I don't prompt Claude anymore. I have loops running that prompt Claude.

Another repository, AI-Builder-Club/skills, dey near 1,300 stars (as of 2026-10-27) and e name the two roles directly: a "codebase harness" wey make repository safe for agent to run tests and deploys inside, and a "loop engineer" wey build workflows wey wake up from a trigger, do the work, and write wetin dem learn into a shared file so the next loop fit read am.

Neither repository invent this practice. Anybody wey don run nightly build, linter for continuous integration, or cron job wey open ticket already know the pattern. Wetin new be say the worker inside the loop now dey non-deterministic, and this change wetin the surrounding machinery need to do.

Loop get four parts

Every loop wey dey work get these four parts. If loop miss one, e fit keep waking you for 3am.

• Trigger. Event wey dey start one run: timer, webhook, new pull request, or alert.
• Boundary. Files, credentials, and network wey agent fit reach during that run.
• Verification. Check wey get exit code. E decide whether to keep or throw away the run output.
• Budget. Token, time, and money limit wey go end the run, whether e succeed or not.

Read these four parts again as questions. You go get design review for any agent wey you wan leave running.

Trigger: wetin dey wake the agent

Timer na the most straightforward trigger, and for Linux server, systemd timer better pass cron for this work because e dey log, e fit retry according to your setting, and e no go start second copy of unit wey still dey run. This last property remove the commonest overlap bug for agent loops: two runs dey edit the same branch.

Give the agent im own user first. That user na part of the boundary, so na im own /srv/agent and nothing else:

sudo useradd --system --home-dir /srv/agent --shell /usr/sbin/nologin agent
sudo chown -R agent:agent /srv/agent

Then write the unit for /etc/systemd/system/agent-loop.service:

[Unit]
Description=Agent loop: triage open issues
After=network-online.target
Wants=network-online.target

[Service]
Type=oneshot
User=agent
WorkingDirectory=/srv/agent/repo
ExecStart=/srv/agent/bin/loop.sh
TimeoutStartSec=1800

And the timer for /etc/systemd/system/agent-loop.timer:

[Unit]
Description=Run the triage loop every 30 minutes

[Timer]
OnBootSec=5min
OnUnitActiveSec=30min
Unit=agent-loop.service

[Install]
WantedBy=timers.target

sudo systemctl daemon-reload
sudo systemctl enable --now agent-loop.timer
systemctl list-timers agent-loop.timer

systemctl list-timers suppose show NEXT column wey get future time and LEFT column wey dey count down. Empty result mean say timer no dey enabled, because enable without --now schedule am only for the next boot. TimeoutStartSec=1800 important pass as e first look. Type=oneshot service dey count as starting until im script exit, and systemd dey switch off start timeout for oneshot units by default. So without this line, agent wey hang while e dey wait for input go leave the unit stuck for activating state forever. Every later timer tick go find am still running and e no go start anything. With the line, systemd go terminate the run after 30 minutes and mark am failed. If you ever change the unit to default Type=simple, TimeoutStartSec no longer cover the run itself, and RuntimeMaxSec= na the setting wey cap am. Read one run with journalctl -u agent-loop.service -n 50.

If you use cron to drive the loop instead, add your own overlap guard, because cron go gladly start second copy:

*/30 * * * * /usr/bin/flock -n /tmp/agent-loop.lock /srv/agent/bin/loop.sh

flock -n go exit immediately with status 1 when lock dey held, so the second run go disappear quietly instead of racing the first one. The same systemd service and timer setup apply to any long-running job for the server, whether na agent or not.

Boundary: make every run get e own copy

An agent wey dey edit your working tree fit lose work wey you never commit. Git worktrees solve this cheaply: every run get e own directory and e own branch, while dem share one object store.

cd /srv/agent/repo
git worktree add -b loop/triage-01 /srv/agent/work/triage-01 origin/main
git worktree list

git worktree list dey print one line for every tree, showing e path, commit, and branch. When the run finish, git worktree remove /srv/agent/work/triage-01 dey remove the worktree, but only if e clean. If the tree get untracked files or modified tracked files, or e contain submodules, git go refuse until you add --force. Na why the gate script below dey force removal only for the path wey throws that run away. git worktree prune dey clear entries wey directory don disappear. Parallel loops become safe for this point, because two agents for two branches and two directories no fit overwrite each other.

The boundary concern credentials too. A loop wey runs unattended dey hold long-lived tokens, and every run fit leak one enter log, commit, or model context. Limit the token to the one repository wey the loop dey touch. Where you fit, keep am out of the environment wey the agent own shell dey see. Read how to keep secrets out of AI agents before you give loop production access. If you need stronger separation, put the whole loop for a disposable VM wey you fit destroy after every run. The tool wey you run also sets part of the boundary before you write anything, so e worth reading how Cowork managed sandbox dey compare with Claude Code for your own machine before you decide how much isolation you need to build by yourself.

Verification: the gate wey make the loop safe

Na dis part dey separate loop from cron job wey only dey type. The agent output na proposal. Na the gate dey decide.

#!/usr/bin/env bash
set -euo pipefail

repo=/srv/agent/repo
branch="loop/$(date -u +%Y%m%dT%H%M%SZ)"
tree="/srv/agent/work/$(basename "$branch")"

cd "$repo"
git fetch --quiet origin
git worktree add -b "$branch" "$tree" origin/main
cd "$tree"

# the agent's own command runs here, in non-interactive mode

if ! npm test; then
  echo "gate failed: discarding $branch" >&2
  cd "$repo"
  git worktree remove --force "$tree"
  exit 1
fi

git push origin "$branch"
cd "$repo"
git worktree remove "$tree"

set -euo pipefail dey do real work inside dat script. Without -e, failed git fetch go ignore, and the run go continue with stale origin/main. Without -u, typo for variable name go expand to empty string, then cleanup go run against wrong path instead of failing clearly. The last line no get --force on purpose: if the run leave untracked or uncommitted files inside the tree, git go refuse to remove am, and -e go end the run with error after the push instead of silently deleting work wey nobody commit.

The if ! npm test block na the whole idea. Exit code from check wey you already trust, like your test suite or type checker, go decide whether to push or destroy the branch. Loop wey no get gate go produce work wey nobody get time to review, and dat one worse pass no work. Loop wey get gate go produce branch wey don already pass the same standard human contributor branch must pass. Green gate no tell you how much code agent touch to reach there, so e make sense to pair the check with standing instruction like the rule wey make agent take the smallest change wey work, so the diff go remain small enough for review to stay cheap.

Choose gate wey dey fail honestly. Test suite wey pass on empty diff go teach the loop say doing nothing na success. Repositories wey get weak tests go get weak loops, na why trending repositories put "make the codebase agent-ready" before "write the loop". If you want know whether your suite go really catch regression instead of only executing the lines, mutation testing na the check wey answer am, and agent wey return evidence report wey you fit rerun instead of asking you to read the diff go turn that answer to something wey you fit confirm by yourself.

Budget: wetin dey stop one run

Agent wey dey retry forever fit pile up bill without limit. Give every loop a wall-clock limit, enforce am with TimeoutStartSec wey dey above; put retry count inside your script; and use provider account take enforce spending limit. Then log how much each run cost, so you fit notice when loop dey drift before invoice show am. Cost control for VPS agent wey dey always on explain the accounting side, while how to manage context wey agent dey carry between turns cover the biggest single way to reduce cost for each run, because loop wey dey read the same repository again every 30 minutes go pay for am every 30 minutes.

Cost na why loops usually better pass one long session. Run wey start fresh, do one small specific job, then stop go keep im context small. Session wey remain open for eight hours go carry every earlier mistake for im history, and go pay for the complete transcript on every turn.

The patterns wey trending repositories dey codify

The loop-engineering repository list eight production patterns (as of 2026-10-27), and e better make you read dem as menu, no be manifesto. Daily triage. A thin loop wey run as GitHub Action and keep no state file. A pull-request babysitter wey monitor review comments and answer dem. A continuous-integration sweeper wey pick red builds. A dependency sweeper. A changelog drafter. Post-merge cleanup. Issue triage.

Wetin dem share na narrow job with clear gate. "Fix the failing build" get pass condition wey machine fit read. "Improve the codebase" no get one, so e never become loop. E become mess wey get schedule.

Dem also share written record. Both repositories push state comot from the conversation enter files for the repository: wetin run, wetin e find, and wetin e decide. That file na the loop memory, and na why second loop fit build on the first loop work instead of discovering the same thing again. E also be how you audit agent afterward, because model context disappear as soon as the run exit. Live coordination na separate channel, and one Claude Code session fit hand work to another for the same box while both still dey run, but nothing for that exchange survive either session, so the file remain the part wey you fit read later.

Wetin make loops fail

The failure dem boring, and teams dey see dem again and again.

• No gate. Output dey pile up, nobody dey review am, trust dey disappear, and dem go switch off the loop.
• Overlap. Two runs dey happen for one branch, or two agents dey work inside one working tree, and dem dey create conflicts wey the agent later try resolve.
• Silent drift. The loop dey continue to pass because the check no strong enough to fail.
• Unbounded scope. Trigger wey dey fire for every commit inside busy repository go turn to spending problem within one day.

Every one get the same fix: make the job smaller, make the check sharper, and log the run. If you no fit describe the pass condition with one sentence, the job no ready for automation.

Start without the big-big technical terms

You no need framework. Small always-on Linux server, one git repository wey test suite dey fail when e suppose fail, one systemd timer, and one shell script wey get if inside fit complete the whole loop. Na here most people suppose start, because you go answer the design questions by running the setup, instead of choosing tool first. Once one loop don stable, to run another one mostly na to add another timer and another worktree. See how to run coding AI agent for VPS for the basic setup, and the self-hosted AI agent options wey dey available now if you want make the agent itself run for hardware wey you control.

FAQ

Loop engineering different from prompt engineering?

Prompt engineering dey optimise one message: wording, examples, and output format. Loop engineering dey optimise the cycle around the message: the trigger wey start run, the sandbox wey run inside, the check wey accept or reject output, and the budget wey end am. You still need good prompt inside the loop. But prompt no longer be the thing you dey tune every day, because gate and trigger get more effect on the result.

I need framework to build agent loop?

No. One systemd timer, one git worktree for each run, shell script wey end with test command, and spend cap for provider account cover every part of the definition. Frameworks add scheduling interfaces, shared memory formats, and multi-agent routing. These things useful when you dey run several loops. But dem no be entry requirement for the first one.

Wetin be codebase harness?

Na the set of things wey let agent work for repository without human present: one-command setup, tests wey run non-interactively and fail loudly, linter, and way to deploy or preview change. The term come from the same 2026 wave of repositories as loop engineering. The practical test simple: if new human contributor no fit go from clone to green tests with one command, agent no fit do am too.

How I fit stop agent loop from running up big bill?

Cap am for three places. Set TimeoutStartSec for Type=oneshot systemd unit like the one above, so hung run go die. For Type=simple service, the equivalent na RuntimeMaxSec. Cap retries inside the script instead of looping until success. Set hard spend limit for API account, because na only this ceiling agent no fit talk its way past. Then log cost for each run, because loop wey cost double usually na loop wey quietly widen im scope.

Which jobs worth turning into loop first?

Choose job wey get machine-readable pass condition and small blast radius. Fixing red build, updating dependency, and regenerating changelog all qualify, because test suite or diff fit prove the result. Open-ended work like refactoring or design no qualify yet, because nothing dey for gate to check. Loop without gate na expensive way to generate review debt.