Ano ang loop engineering? Simpleng depinisyon

Ano ang loop engineering

Ang loop engineering ay ang pagdidisenyo ng paulit-ulit na cycle na pinapatakbo ng isang AI agent: kung ano ang gumigising dito, kung ano ang maaari nitong galawin, kung paano sinusuri ang output nito, at kung ano ang nagpapahinto rito. Hinuhubog ng prompt engineering ang isang mensahe para sa isang model. Hinuhubog naman ng loop engineering ang prosesong nagpapadala ng libo-libong mensahe habang natutulog ka. Mula sa prompt, lumilipat sa loop ang unit of work.

Sa madaling sabi: hindi ka na lang sumusulat ng mga instruction; nagsusulat ka na ng control system. Kailangan pa rin ng agent ng mahuhusay na instruction, pero nagiging isang component ang mga ito sa loob ng cycle na tumatakbo ayon sa schedule, gumagana sa isolated copy ng iyong code, nagpapatunay sa sarili nitong resulta gamit ang test, at humihinto kapag naubos na ang budget.

Bakit lumitaw ang termino noong 2026

Kasalukuyang itinatakda sa publiko ang pangalan. Ang GitHub repository na cobusgreyling/loop-engineering ay umabot sa 9,600 stars sa loob ng dalawang buwan mula nang unang lumitaw (noong Hulyo 2026) at may humigit-kumulang 11,600 noong 2026-10-27, sa ilalim ng linyang “Stop prompting. Design the loop. Get a score.” Noong Hulyo 2026, hinati ng README nito ang pagbabagong ito sa anim na building block: scheduling, worktrees, skills, plugins at connectors, sub-agents, at durable memory na itinatago sa labas ng conversation. Wala na ang listahang iyon sa kasalukuyang README (sinuri noong 2026-10-27), ngunit nasa file pa rin sa labas ng conversation ang state ng loop.

Itinuturing ng repository si Boris Cherny, na namumuno sa Claude Code sa Anthropic, bilang isa sa mga inspirasyon nito. Ito ang linyang malawak na naiulat:

Hindi na ako gumagawa ng prompt para kay Claude. May mga loop akong tumatakbo na gumagawa ng prompt para kay Claude.

Ang ikalawang repository, AI-Builder-Club/skills, ay may halos 1,300 stars (noong 2026-10-27) at direktang pinapangalanan ang dalawang role: isang “codebase harness” na ginagawang ligtas ang isang repository para magpatakbo rito ang agent ng tests at deploys, at isang “loop engineer” na bumubuo ng workflows na nagigising sa isang trigger, nagsasagawa ng trabaho, at nagsusulat ng natutuhan nito sa isang shared file upang mabasa ito ng susunod na loop.

Wala sa alinmang repository ang nakaimbento ng practice na ito. Alam na ng sinumang nagpatakbo ng nightly build, linter sa continuous integration, o cron job na nagbubukas ng ticket ang ganitong anyo. Ang bago ay non-deterministic na ngayon ang worker sa loob ng loop, kaya nagbabago ang mga kailangang gawin ng nakapaligid na machinery.

A loop na may apat na bahagi

May apat na bahaging ito ang bawat gumaganang loop. Kapag may isang bahaging nawawala, maaari kang magising ng loop nang 3am.

• Trigger. Ang event na nagsisimula ng isang run: isang timer, webhook, bagong pull request, o alert.
• Boundary. Ang mga file, credential, at network na maaaring ma-access ng agent sa run na iyon.
• Verification. Isang check na may exit code. Tinutukoy nito kung pananatilihin o itatapon ang output ng run.
• Budget. Ang limitasyon sa token, oras, at gastos na nagtatapos sa run, nagtagumpay man ito o hindi.

Basahin muli ang apat na ito bilang mga tanong. Magagamit mo ang mga ito bilang design review para sa anumang agent na iiwan mong tumatakbo.

Trigger: kung ano ang gumigising sa agent

Ang timer ang pinakasimpleng trigger. Sa Linux server, mas mainam ang systemd timer kaysa cron dahil nagla-log ito, nagre-retry ayon sa itinakda mo, at hindi ito nagsisimula ng pangalawang kopya ng unit na tumatakbo pa. Inaalis ng huling property na ito ang pinakakaraniwang overlap bug sa agent loop: dalawang run na sabay na nag-e-edit ng parehong branch.

Bigyan muna ng sariling user ang agent. Bahagi ng boundary ang user na iyon, kaya pagmamay-ari nito ang /srv/agent at wala nang iba:

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

Pagkatapos, isulat ang unit sa /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

At ang timer sa /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

Dapat magpakita ang systemctl list-timers ng NEXT column na may oras sa hinaharap at LEFT column na nagbibilang pababa. Ang walang laman na resulta ay nangangahulugang hindi enabled ang timer, dahil itinatakda ng enable na walang --now ang timer para sa susunod na boot lamang. Mas mahalaga ang TimeoutStartSec=1800 kaysa sa inaakala. Ang Type=oneshot service ay itinuturing na nagsisimula hanggang sa matapos ang script nito. Bilang default, in-o-off ng systemd ang start timeout para sa oneshot units. Kung wala ang linyang ito, mananatiling stuck sa activating state ang unit kapag nag-hang ang agent habang naghihintay ng input. Sa bawat susunod na timer tick, makikita pa rin itong tumatakbo kaya walang sisimulan. Kapag naroon ang linya, tinatapos ng systemd ang run makalipas ang 30 minuto at minamarkahan itong failed. Kung babaguhin mo ang unit sa default na Type=simple, hindi na sinasaklaw ng TimeoutStartSec ang mismong run. Ang RuntimeMaxSec= ang setting na naglilimita rito. Basahin ang isang run gamit ang journalctl -u agent-loop.service -n 50.

Kung cron ang gagamitin mo para patakbuhin ang loop, magdagdag ng sarili mong overlap guard dahil awtomatikong makapagsisimula ang cron ng pangalawang kopya:

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

Agad na lumalabas ang flock -n na may status 1 kapag hawak na ang lock. Dahil dito, tahimik na nawawala ang pangalawang run sa halip na makipag-unahan sa unang run. Nalalapat din ang parehong systemd service at timer setup sa anumang long-running job sa server, agent man ito o hindi.

Boundary: bigyan ng sariling kopya ang bawat run

Ang agent na nag-e-edit ng working tree mo ay maaaring makapagpawala ng mga uncommitted work. Murang solusyon dito ang Git worktrees: bawat run ay may sariling directory at sariling branch, habang nagsha-share ng iisang object store.

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

Ang git worktree list ay nagpi-print ng isang linya para sa bawat tree, kasama ang path, commit, at branch nito. Kapag natapos ang run, inaalis ng git worktree remove /srv/agent/work/triage-01 ang worktree, pero malinis lamang na worktree ang maaari nitong alisin. Kung may untracked files o binagong tracked files ang tree, o naglalaman ito ng submodules, tatanggi ang git hanggang idagdag mo ang --force. Ito ang dahilan kung bakit pinipilit ng gate script sa ibaba ang removal lamang sa path na itinatapon ang run. Nililinis ng git worktree prune ang mga entry na nawala na ang directory. Ligtas na ngayon ang mga parallel loop, dahil hindi maaaring ma-overwrite ng dalawang agent na nasa magkaibang branch at magkaibang directory ang isa't isa.

Tungkol din sa credentials ang boundary. Ang loop na tumatakbo nang unattended ay may hawak na mga token na matagal ang bisa, at bawat run ay posibleng mag-leak ng token sa log, commit, o model context. Limitahan ang token sa iisang repository na ginagamit ng loop. Kung maaari, huwag itong isama sa environment na nakikita ng sariling shell ng agent. Basahin ang kung paano ilayo ang secrets sa AI agents bago bigyan ng production access ang isang loop. Para sa mas mahigpit na isolation, ilagay ang buong loop sa isang disposable VM na maaari mong sirain pagkatapos ng bawat run. Nakaaapekto rin sa boundary ang tool na gagamitin mo bago mo pa isulat ang alinman sa mga ito. Kaya mainam na basahin ang kung paano ikinukumpara ang managed sandbox ng Cowork sa Claude Code sa sarili mong machine bago magpasya kung gaano kalaking isolation ang kailangan mong buuin mismo.

Pagpapatunay: ang gate na nagpapanatiling ligtas sa loop

Ito ang bahaging naghihiwalay sa isang loop mula sa cron job na nagta-type lang. Proposal ang output ng agent. Ang gate ang nagpapasya.

#!/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 ang gumagawa ng aktuwal na trabaho sa script na iyon. Kung wala ang -e, hindi papansinin ang nabigong git fetch at magpapatuloy ang run gamit ang lumang origin/main. Kung wala ang -u, magiging empty string ang typo sa pangalan ng variable, at tatakbo ang cleanup sa maling path sa halip na malinaw na mabigo. Sadyang walang --force ang huling linya: kung may iniwang untracked o uncommitted files ang run sa tree, tatanggi ang git na alisin ito, at tatapusin ng -e ang run na may error pagkatapos ng push sa halip na tahimik na burahin ang gawaing hindi na-commit ninuman.

Ang if ! npm test block ang buod ng buong ideya. Ang exit code ng check na pinagkakatiwalaan mo na, gaya ng test suite o type checker, ang nagpapasya kung ipa-push o sisirain ang branch. Ang loop na walang gate ay gumagawa ng trabahong walang oras na mag-review, na mas masama kaysa walang gawa. Ang loop na may gate ay gumagawa ng branch na nakapasa na sa parehong pamantayang kailangang lampasan ng branch ng human contributor. Walang sinasabi ang green gate tungkol sa dami ng code na ginalaw ng agent para makarating doon, kaya mainam na ipares ang check sa isang standing instruction gaya ng patakarang nagpapagawa sa agent ng pinakamaliit na gumaganang pagbabago, upang manatiling maliit ang diff at murang i-review.

Pumili ng gate na tapat na nagfa-fail. Ang test suite na pumapasa sa empty diff ay nagtuturo sa loop na tagumpay ang walang gawin. Ang mga repository na mahihina ang tests ay nagkakaroon ng mahihinang loop, kaya inuuna ng mga trending repository ang “gawing agent-ready ang codebase” bago ang “isulat ang loop”. Kung gusto mong malaman kung talagang makakahuli ng regression ang suite mo sa halip na patakbuhin lang ang mga linya, mutation testing ang check na makakasagot dito, at ginagawa ng agent na nagbabalik ng rerunnable evidence report sa halip na hilinging basahin mo ang diff nito na isang bagay na makukumpirma mo mismo ang sagot na iyon.

Badyet: ano ang pumipigil sa isang run

Ang agent na walang katapusang nagre-retry ay agent na walang limitasyon ang gastos. Lagyan ang bawat loop ng wall-clock ceiling na ipinapatupad ng TimeoutStartSec sa itaas; magtakda ng retry count sa loob ng script; at magpatupad ng spend cap sa provider account. I-log din kung magkano ang gastos ng bawat run para makita mo ang unti-unting pagtaas ng gastos ng loop bago pa ito lumitaw sa invoice. Sinasaklaw ng Pagkontrol ng gastos para sa always-on agent VPS ang accounting side, at ng pamamahala sa context na dala ng agent sa bawat turn ang pinakamalaking salik sa per-run cost, dahil ang loop na muling nagbabasa ng parehong repository bawat 30 minuto ay nagbabayad para rito bawat 30 minuto.

Dahil sa gastos, kadalasang mas mainam ang mga loop kaysa sa isang mahabang session. Ang run na nagsisimula nang bago, gumagawa ng isang tiyak na gawain, at pagkatapos ay lumalabas ay nagpapanatiling maliit ng context nito. Ang session na bukas nang walong oras ay dala sa history nito ang bawat naunang pagkakamali at nagbabayad para sa buong transcript sa bawat turn.

Ang mga pattern na isinasaayos ng mga trending repository

Inililista ng loop-engineering repository ang walong production pattern (noong 2026-10-27), at mas mainam itong basahin bilang menu kaysa manifesto. Daily triage. Isang manipis na loop na tumatakbo bilang GitHub Action at walang state file. Isang pull-request babysitter na nagmo-monitor ng review comments at sumasagot sa mga ito. Isang continuous-integration sweeper na kumukuha ng mga red build. Isang dependency sweeper. Isang changelog drafter. Post-merge cleanup. Issue triage.

Pareho silang may makitid na gawain at malinaw na gate. May pass condition na mababasa ng machine ang “Ayusin ang failing build.” Walang ganoon ang “Pagandahin ang codebase,” kaya hindi ito nagiging loop. Nagiging magulong gawain ito na may schedule.

Pareho rin silang may nakasulat na record. Inilalabas ng dalawang repository ang state mula sa conversation at inilalagay ito sa mga file sa repository: ano ang tumakbo, ano ang nakita, at ano ang napagpasyahan. Ang file na iyon ang memory ng loop, at ito ang dahilan kung bakit makapagpapatuloy ang ikalawang loop sa ginawa ng una sa halip na ulitin ang pagtuklas dito. Ito rin ang paraan para ma-audit ang agent pagkatapos ng run, dahil nawawala ang context ng model sa sandaling matapos ang run. Hiwalay na channel ang live coordination, at maaaring ipasa ng isang Claude Code session ang trabaho sa isa pang session sa parehong machine habang tumatakbo pa ang dalawa, ngunit walang bahagi ng palitang iyon ang nananatili pagkalipas ng alinmang session, kaya ang file pa rin ang bahaging muli mong babasahin.

Kapag pumapalya ang mga loop

Nakababagot ang mga failure, at paulit-ulit itong nangyayari sa iba’t ibang team.

• Walang gate. Naiipon ang output, walang nagre-review nito, nawawala ang tiwala, at pinapatay ang loop.
• Nagkakapatong. May dalawang run sa isang branch, o dalawang agent sa iisang working tree, kaya nagkakaroon ng conflict na sinusubukang ayusin ng agent.
• Tahimik na paglihis. Patuloy na pumapasa ang loop dahil masyadong mahina ang check para magdulot ng failure.
• Walang limitasyon ang saklaw. Ang trigger na tumatakbo sa bawat commit sa isang abalang repository ay nagiging problema sa gastos sa loob lamang ng isang araw.

Iisa ang solusyon sa lahat ng ito: paliitin ang trabaho, gawing mas tiyak ang check, at i-log ang run. Kung hindi mo mailalarawan sa isang pangungusap ang kondisyon para pumasa, hindi pa handang i-automate ang trabaho.

Pagsisimula nang hindi muna kailangang alamin ang mga termino

Hindi mo kailangan ng framework. Sapat na ang isang maliit na Linux server na laging naka-on, isang git repository na nagfa-fail ang test suite kapag dapat itong mag-fail, isang systemd timer, at isang shell script na may if para makabuo ng kumpletong loop. Dito talaga dapat magsimula ang karamihan, dahil nasasagot ang mga tanong sa disenyo sa aktuwal na pagpapatakbo ng system, hindi sa pagpili ng tool. Kapag stable na ang isang loop, ang pagpapatakbo ng ikalawa ay karaniwang nangangailangan lamang ng isa pang timer at isa pang worktree. Tingnan ang kung paano magpatakbo ng coding AI agent sa isang VPS para sa pangunahing setup, at ang kasalukuyang mga opsyon para sa self-hosted AI agent kung gusto mong tumakbo mismo ang agent sa hardware na kontrolado mo.

FAQ

Magkaiba ba ang loop engineering at prompt engineering?

Ino-optimize ng prompt engineering ang isang message: wording, mga halimbawa, at output format. Ino-optimize naman ng loop engineering ang cycle sa paligid ng message: ang trigger na nagsisimula ng isang run, ang sandbox kung saan ito tumatakbo, ang check na tumatanggap o tumatanggi sa output nito, at ang budget na nagwawakas dito. Kailangan mo pa rin ng magandang prompt sa loob ng loop. Hindi na prompt ang pangunahing tina-tune araw-araw, dahil mas malaki ang epekto ng gate at trigger sa resulta.

Kailangan ko ba ng framework para gumawa ng agent loop?

Hindi. Sapat na ang isang systemd timer, isang git worktree para sa bawat run, isang shell script na nagtatapos sa isang test command, at isang spend cap sa provider account para masaklaw ang bawat bahagi ng depinisyon. Nagdaragdag ang mga framework ng scheduling interface, shared memory format, at multi-agent routing. Kapaki-pakinabang ang mga ito kapag nagpapatakbo ka na ng maraming loop. Hindi kailangan ang mga ito para makapagsimula sa unang loop.

Ano ang codebase harness?

Ito ang set ng mga bagay na nagpapahintulot sa isang agent na magtrabaho sa isang repository nang walang taong nagbabantay: one-command setup, mga test na tumatakbo nang non-interactive at malinaw na nagfa-fail, isang linter, at paraan para mag-deploy o mag-preview ng pagbabago. Nagmula ang termino sa parehong 2026 wave ng mga repository kung saan lumitaw ang loop engineering. Simple ang praktikal na test: kung hindi makakarating ang bagong human contributor mula clone hanggang green tests gamit ang isang command, hindi rin ito magagawa ng isang agent.

Paano ko pipigilan ang agent loop na magpatakbo ng malaking bill?

Lagyan ito ng cap sa tatlong lugar. Itakda ang TimeoutStartSec sa isang Type=oneshot systemd unit gaya ng nasa itaas upang mapatay ang hanging run. Sa isang Type=simple service, ang katumbas nito ay RuntimeMaxSec. Limitahan ang retries sa loob ng script sa halip na mag-loop hanggang magtagumpay. Magtakda ng hard spend limit sa API account, dahil ito lamang ang ceiling na hindi malalampasan ng agent sa pamamagitan ng pangangatwiran. I-log din ang cost ng bawat run, dahil ang loop na dumodoble ang cost ay karaniwang loop na palihim na lumawak ang scope.

Aling mga trabaho ang unang sulit gawing loop?

Pumili ng trabahong may machine-readable pass condition at maliit na blast radius. Kabilang dito ang pag-aayos ng red build, pag-update ng dependency, at muling pag-generate ng changelog, dahil mapapatunayan ng test suite o diff ang resulta. Hindi pa kwalipikado ang open-ended na trabaho gaya ng refactoring o design, dahil wala pang susuriin ang gate. Ang loop na walang gate ay magastos na paraan para lumikha ng review debt.