Loop engineering என்றால் என்ன? எளிய விளக்கம்

Loop engineering என்றால் என்ன

Loop engineering என்பது AI agent இயக்கும் மீண்டும் மீண்டும் நடைபெறும் cycle-ஐ வடிவமைக்கும் நடைமுறையாகும்: அதை எது தொடங்குகிறது, அது எதை அணுகலாம், அதன் output எவ்வாறு சரிபார்க்கப்படுகிறது, எது அதை நிறுத்துகிறது என்பவற்றை இதில் வரையறுக்கிறோம். Prompt engineering என்பது model-க்கு அனுப்பப்படும் ஒரு message-ஐ வடிவமைக்கிறது. Loop engineering என்பது நீங்கள் உறங்கிக்கொண்டிருக்கும்போது ஆயிரக்கணக்கான messages-ஐ அனுப்பும் process-ஐ வடிவமைக்கிறது. வேலைக்கான அலகு prompt-இலிருந்து loop-க்கு மாறுகிறது.

சுருக்கமாக: நீங்கள் instructions எழுதுவதை நிறுத்தி, control system எழுதத் தொடங்குகிறீர்கள். Agent-க்கு இன்னும் நல்ல instructions தேவை. ஆனால் அவை இப்போது ஒரு cycle-இன் ஒரு component ஆகின்றன. அந்த cycle schedule-ன் அடிப்படையில் இயங்கும், உங்கள் code-ன் isolated copy-ல் செயல்படும், test மூலம் தனது result-ஐ நிரூபிக்கும், மேலும் budget முடிந்ததும் நிறுத்தப்படும்.

2026-ல் இந்தச் சொல் தோன்றியதற்கான காரணம்

இந்தப் பெயர் தற்போது பொதுப் பயன்பாட்டில் நிலைபெற்று வருகிறது. GitHub repository cobusgreyling/loop-engineering, முதன்முதலில் தோன்றிய 2 மாதங்களுக்குள் 9,600 stars-ஐ கடந்தது (July 2026 நிலவரப்படி). அதன் வரி: "Stop prompting. Design the loop. Get a score." இது ஏற்பட்ட மாற்றத்தை 6 கட்டமைப்புக் கூறுகளாகச் சேர்க்கிறது: scheduling, worktrees, skills, plugins மற்றும் connectors, sub-agents, மேலும் conversation-க்கு வெளியே சேமிக்கப்படும் durable memory.

இது Anthropic-இல் Claude Code-ஐ வழிநடத்தும் Boris Cherny-யை மேற்கோள் காட்டுகிறது:

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

இரண்டாவது repository, AI-Builder-Club/skills, சுமார் 1,100 stars-ஐக் கொண்டுள்ளது (July 2026 நிலவரப்படி). இது அந்த 2 பணிப் பொறுப்புகளையும் நேரடியாகக் குறிப்பிடுகிறது: ஒரு "codebase harness" என்பது repository-யில் agent tests மற்றும் deploys-ஐ பாதுகாப்பாக இயக்குவதற்கான சூழலை உருவாக்குகிறது; ஒரு "loop engineer" என்பது trigger ஏற்பட்டதும் செயல்பட்டு, பணியை முடித்து, கற்றவற்றை shared file-ல் எழுதும் workflows-ஐ உருவாக்குகிறார், இதனால் அடுத்த loop அவற்றைப் படிக்க முடியும்.

இந்த நடைமுறையை எந்த repository-யும் புதிதாக உருவாக்கவில்லை. nightly build-ஐ, continuous integration-ல் linter-ஐ அல்லது ticket-ஐத் திறக்கும் cron job-ஐ இயக்கிய எவருக்கும் இதன் அமைப்பு ஏற்கனவே தெரியும். புதிதாக இருப்பது, loop-க்குள் செயல்படும் worker இப்போது non-deterministic ஆக இருப்பதுதான். இதனால் அதைச் சுற்றியுள்ள machinery செய்ய வேண்டிய பணிகள் மாறுகின்றன.

loop-இன் நான்கு பகுதிகள்

செயல்படும் ஒவ்வொரு loop-க்கும் இந்த நான்கு பகுதிகள் உள்ளன. இவற்றில் ஒன்றைத் தவிர்க்கும் loop, அதிகாலை 3am மணிக்கு உங்களை எழுப்பும் loop ஆகிவிடும்.

• Trigger. ஒரு run-ஐத் தொடங்கும் நிகழ்வு: timer, webhook, புதிய pull request அல்லது alert.
• Boundary. அந்த run நடைபெறும் போது agent அணுகக்கூடிய files, credentials மற்றும் network.
• Verification. exit code உடன் கூடிய சோதனை. அந்த run-ன் output வைத்திருக்கப்பட வேண்டுமா அல்லது நீக்கப்பட வேண்டுமா என்பதை இது தீர்மானிக்கும்.
• Budget. run வெற்றி பெற்றதா இல்லையா என்பதைப் பொருட்படுத்தாமல், அதை முடிக்கும் token, time மற்றும் money வரம்பு.

இந்த நான்கையும் கேள்விகளாக மீண்டும் படித்தால், தொடர்ந்து இயங்கவிடப் போகும் எந்த agent-க்குமான design review உங்களிடம் இருக்கும்.

Trigger: agent-ஐத் தொடங்குவது

Timer என்பது மிகவும் எளிய trigger ஆகும். Linux server-இல் இதற்காக systemd timer, cron-ஐவிடச் சிறந்தது. ஏனெனில் இது log பதிவுசெய்கிறது, உங்கள் விதிகளின்படி retry செய்கிறது, மேலும் இன்னும் இயங்கிக்கொண்டிருக்கும் unit-ன் இரண்டாவது copy-ஐத் தொடங்காது. இந்த இறுதி பண்பு, agent loop-களில் பொதுவாக ஏற்படும் overlap bug-ஐத் தவிர்க்கிறது: ஒரே branch-ஐ இரண்டு runs திருத்துவது.

Unit-ஐ /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

Timer-ஐ /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, எதிர்கால நேரத்தைக் கொண்ட NEXT column-ஐயும், மீதமுள்ள நேரத்தைக் கணக்கிடும் LEFT column-ஐயும் காட்ட வேண்டும். முடிவு காலியாக இருந்தால், timer enabled ஆகவில்லை என்று பொருள். ஏனெனில் enable என்பதை --now இல்லாமல் பயன்படுத்தினால், அது அடுத்த boot-க்கு மட்டும் schedule செய்யப்படும். TimeoutStartSec=1800 எதிர்பார்ப்பதைவிட முக்கியமானது. Input-க்காக காத்திருக்கும் agent இல்லையெனில் unit-ஐ முடிவில்லாமல் active நிலையில் வைத்திருக்கும். அப்போது timer மீண்டும் இயங்காது. ஒரு run-ஐ journalctl -u agent-loop.service -n 50 மூலம் பார்க்கவும்.

Loop-ஐ cron மூலம் இயக்கினால், cron இரண்டாவது copy-ஐத் தொடங்கிவிடும். ஆகவே உங்கள் சொந்த overlap guard-ஐச் சேர்க்கவும்:

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

Lock ஏற்கனவே பயன்படுத்தப்பட்டால் flock -n உடனடியாக status 1 உடன் வெளியேறும். இதனால் இரண்டாவது run, முதல் run-உடன் race செய்யாமல் அமைதியாக முடிந்துவிடும். Agent ஆக இருந்தாலும் இல்லாவிட்டாலும், server-இல் நீண்ட நேரம் இயங்கும் எந்த job-க்கும் இதே systemd service மற்றும் timer அமைப்பு பொருந்தும்.

எல்லை: ஒவ்வொரு run-க்கும் தனி copy வழங்கவும்

உங்கள் working tree-ஐத் திருத்தும் agent, commit செய்யப்படாத உங்கள் பணியை இழக்கக்கூடும். Git worktrees இதை குறைந்த செலவில் தீர்க்கின்றன: ஒவ்வொரு run-க்கும் தனி directory மற்றும் தனி branch கிடைக்கும்; அதே 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 ஒவ்வொரு tree-க்கும் அதன் path, commit மற்றும் branch அடங்கிய ஒரு வரியை அச்சிடுகிறது. run முடிந்ததும், git worktree remove /srv/agent/work/triage-01 அந்த directory-ஐ நீக்குகிறது; git worktree prune directory மறைந்துவிட்ட entries-ஐ அகற்றுகிறது. இந்த நிலையில் parallel loops பாதுகாப்பாகின்றன. ஏனெனில் வெவ்வேறு directories-ல் உள்ள வெவ்வேறு branches-ல் செயல்படும் இரண்டு agents, ஒன்றின் மாற்றங்களை மற்றொன்று overwrite செய்ய முடியாது.

இந்த எல்லை credentials-க்கும் பொருந்தும். unattended முறையில் இயங்கும் loop, நீண்டகாலம் செல்லுபடியாகும் tokens-ஐ வைத்திருக்கும். ஒவ்வொரு run-லும் token ஒன்று log, commit அல்லது model context-க்குள் கசியும் வாய்ப்பு உள்ளது. loop அணுகும் ஒரே repository-க்கு மட்டும் token-ன் scope-ஐ வரையறுக்கவும். முடிந்தவரை agent-ன் சொந்த shell பார்க்கும் environment-லிருந்து token-ஐ விலக்கி வைக்கவும். loop-க்கு production access வழங்குவதற்கு முன் AI agents-இலிருந்து secrets-ஐ எவ்வாறு விலக்குவது என்பதைப் படிக்கவும். மேலும் வலுவான தனிமைப்படுத்தல் தேவைப்பட்டால், ஒவ்வொரு run-க்கும் பிறகு அழிக்கக்கூடிய disposable VM-ல் முழு loop-ஐ இயக்கவும்.

சரிபார்ப்பு: loop-ஐ பாதுகாப்பாகச் செய்யும் gate

ஒரு loop-ஐ தானாக commands-ஐ type செய்யும் cron job-இலிருந்து வேறுபடுத்துவது இதுதான். Agent-ன் output ஒரு proposal. எதை ஏற்க வேண்டும் என்பதை gate தீர்மானிக்கிறது.

#!/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"

அந்த script-ல் set -euo pipefail உண்மையான பணியைச் செய்கிறது. -e இல்லையெனில், தோல்வியடைந்த git fetch புறக்கணிக்கப்படும்; run பழைய origin/main-ஐ அடிப்படையாகக் கொண்டு தொடரும். -u இல்லையெனில், variable name-ல் உள்ள typo, empty string ஆக expand ஆகும். பின்னர் cleanup, தெளிவாகத் தோல்வியடைவதற்குப் பதிலாக தவறான path-ல் இயங்கும்.

if ! npm test block-தான் முழு அணுகுமுறையின் அடிப்படை. நீங்கள் ஏற்கனவே நம்பும் check-ன் exit code — உங்கள் test suite அல்லது type checker — branch push செய்யப்பட வேண்டுமா அல்லது அழிக்கப்பட வேண்டுமா என்பதைத் தீர்மானிக்கிறது. gate இல்லாத loop, யாருக்கும் review செய்ய நேரமில்லாத work-ஐ உருவாக்கும். இது work எதுவும் இல்லாததைவிட மோசமானது. gate உள்ள loop, மனித contributor-ன் branch கடக்க வேண்டிய அதே தரநிலையை ஏற்கனவே கடந்த branch-ஐ உருவாக்கும்.

நேர்மையாகத் தோல்வியடையும் gate-ஐத் தேர்ந்தெடுக்கவும். Empty diff-ல் pass ஆகும் test suite, எதுவும் செய்யாதது வெற்றி என்று loop-க்கு கற்றுக்கொடுக்கும். பலவீனமான tests உள்ள repositories பலவீனமான loops-ஐ உருவாக்கும். அதனால்தான் trending repositories, "write the loop" என்பதற்கு முன் "make the codebase agent-ready" என்பதை வைக்கின்றன.

Budget: ஒரு run-ஐ நிறுத்துவது

என்றும் retry செய்யும் agent-க்கு வரம்பற்ற bill உருவாகும். ஒவ்வொரு loop-க்கும் wall-clock ceiling-ஐ அமைக்கவும்; இதை மேலே உள்ள TimeoutStartSec அமல்படுத்துகிறது. உங்கள் script-இல் retry count-ஐ அமைக்கவும். provider account மூலம் spend cap-ஐ அமல்படுத்தவும். பின்னர் ஒவ்வொரு run-க்கும் ஏற்பட்ட செலவை log செய்யவும். இதன் மூலம் invoice வருவதற்கு முன்பே loop-இன் செலவு அதிகரிப்பதை அறியலாம். எப்போதும் இயங்கும் agent VPS-க்கான செலவுக் கட்டுப்பாடு accounting பகுதியை விளக்குகிறது. turn-களுக்கு இடையில் agent எடுத்துச் செல்லும் context-ஐ நிர்வகித்தல் per-run cost-ஐ அதிகம் பாதிக்கும் ஒரே காரணியை விளக்குகிறது. ஏனெனில் ஒவ்வொரு 30 minutes-க்கும் அதே repository-ஐ மீண்டும் படிக்கும் loop, ஒவ்வொரு 30 minutes-க்கும் அதற்கான கட்டணத்தைச் செலுத்தும்.

செலவுதான் loops பெரும்பாலும் ஒரு நீண்ட session-ஐ விடச் சிறந்ததாக இருப்பதற்கான காரணம். புதியதாகத் தொடங்கி, ஒரு வரையறுக்கப்பட்ட வேலையைச் செய்து, வெளியேறும் run அதன் context-ஐ சிறியதாக வைத்திருக்கும். 8 hours திறந்த நிலையில் இருக்கும் session, அதற்கு முன் ஏற்பட்ட ஒவ்வொரு தவறையும் அதன் history-யில் வைத்திருக்கும். ஒவ்வொரு turn-க்கும் முழு transcript-க்கான கட்டணத்தையும் அது செலுத்தும்.

பிரபலமாகும் repositories முறைப்படுத்தும் patterns

loop-engineering repository, production patterns 7-ஐ பட்டியலிடுகிறது. அவற்றை ஒரு manifesto-வாக அல்லாமல், தேர்வுப் பட்டியலாகப் படிப்பது பயனுள்ளது. Daily triage. Review comments-ஐ கண்காணித்து அவற்றுக்குப் பதிலளிக்கும் pull-request babysitter. Red builds-ஐ எடுத்துச் செயல்படுத்தும் continuous-integration sweeper. Dependency sweeper. Changelog-ஐ உருவாக்கும் drafter. Post-merge cleanup. Issue triage.

இவற்றில் பொதுவாக இருப்பது, தெளிவான gate உடைய வரையறுக்கப்பட்ட பணி. "Fix the failing build" என்பதற்கு machine படிக்கக்கூடிய pass condition உள்ளது. "Improve the codebase" என்பதற்கு அது இல்லை. எனவே அது ஒருபோதும் loop ஆகாது. அது schedule உடன் கூடிய குழப்பமாக மாறும்.

இவற்றில் எழுதப்பட்ட record-ம் பொதுவாக உள்ளது. இரண்டு repositories-மும் state-ஐ conversation-இல் வைத்திருக்காமல், repository-யில் உள்ள files-க்கு வெளியே எழுதுகின்றன: எது இயக்கப்பட்டது, எதைக் கண்டறிந்தது, எதை முடிவு செய்தது. அந்த file-தான் loop-இன் memory. அதனால் இரண்டாவது loop, முதலாவது loop செய்த பணியை மீண்டும் கண்டறியாமல், அதன்மீது தொடர்ந்து செயல்பட முடியும். Run முடிந்தவுடன் model-இன் context மறைந்துவிடுவதால், பின்னர் agent-ஐ audit செய்வதற்கும் இதுவே வழியாகும்.

Loopகள் தோல்வியடையும் இடங்கள்

தோல்விகள் சிக்கலானவை அல்ல. அவை குழுக்களிடையே மீண்டும் மீண்டும் நிகழ்கின்றன.

• Gate இல்லை. Output தொடர்ந்து சேர்கிறது. யாரும் அதை மதிப்பாய்வு செய்வதில்லை. நம்பிக்கை குறைகிறது. இறுதியில் loop முடக்கப்படுகிறது.
• Overlap. ஒரே branch-ல் இரண்டு runs இயங்குகின்றன. அல்லது ஒரே working tree-ல் இரண்டு agents இயங்குகின்றன. இதனால் conflicts உருவாகின்றன. பின்னர் agent அவற்றைத் தீர்க்க முயற்சிக்கிறது.
• Silent drift. Check தோல்வியடையுமளவு கடுமையாக இல்லாததால், loop தொடர்ந்து pass ஆகிறது.
• Unbounded scope. Busy repository-ல் ஒவ்வொரு commit-க்கும் இயங்கும் trigger, ஒரே நாளுக்குள் செலவுச் சிக்கலாக மாறுகிறது.

ஒவ்வொன்றுக்கும் ஒரே தீர்வு உள்ளது: job-ஐச் சுருக்கவும், check-ஐத் துல்லியப்படுத்தவும், run-ஐ log செய்யவும். Pass condition-ஐ ஒரே வாக்கியத்தில் விளக்க முடியாவிட்டால், அந்த job இன்னும் automation-க்கு தயாராகவில்லை.

சொற்களஞ்சியம் இல்லாமல் தொடங்குதல்

உங்களுக்கு framework தேவையில்லை. எப்போதும் இயங்கும் சிறிய Linux server, தேவையானபோது test suite தோல்வியடையும் git repository, ஒரு systemd timer மற்றும் அதில் if உள்ள ஒரு shell script ஆகியவை சேர்ந்து முழுமையான loop-ஐ உருவாக்குகின்றன. பெரும்பாலானவர்கள் இதிலிருந்தே தொடங்க வேண்டும். ஏனெனில் tool-ஐத் தேர்ந்தெடுப்பதைவிட, அமைப்பை இயக்குவதன் மூலம் design தொடர்பான கேள்விகளுக்கு விடை கிடைக்கும். ஒரு loop நிலையாக இயங்கத் தொடங்கியதும், இரண்டாவது loop-ஐ இயக்குவதற்கு பெரும்பாலும் மற்றொரு timer மற்றும் மற்றொரு worktree போதுமானது. அடிப்படை அமைப்புக்கு VPS-ல் coding AI agent-ஐ இயக்குவது எப்படி என்பதைப் பார்க்கவும். நீங்கள் கட்டுப்படுத்தும் hardware-ல் agent-ஐயே இயக்க விரும்பினால், தற்போதைய self-hosted AI agent விருப்பங்கள் என்பதைப் பார்க்கவும்.

FAQ

loop engineering, prompt engineering-இலிருந்து வேறுபட்டதா?

Prompt engineering ஒரு message-ஐ மட்டும் மேம்படுத்துகிறது: சொற்தேர்வு, எடுத்துக்காட்டுகள், output format. Loop engineering அந்த message-ஐச் சுற்றியுள்ள cycle-ஐ மேம்படுத்துகிறது: run-ஐ தொடங்கும் trigger, அது இயங்கும் sandbox, அதன் output-ஐ ஏற்கிறதா அல்லது நிராகரிக்கிறதா என்பதைத் தீர்மானிக்கும் check, மேலும் அதை முடிக்கும் budget. Loop-க்குள் நல்ல prompt இன்னும் தேவை. ஆனால் நாள்தோறும் நீங்கள் சரிசெய்யும் முக்கிய அம்சமாக prompt இருக்காது, ஏனெனில் gate மற்றும் trigger ஆகியவை முடிவில் அதிக தாக்கம் செலுத்துகின்றன.

agent loop உருவாக்க framework தேவையா?

தேவையில்லை. systemd timer, ஒவ்வொரு run-க்கும் தனியான git worktree, test command-இல் முடியும் shell script, மேலும் provider account-இல் உள்ள spend cap ஆகியவை வரையறையின் ஒவ்வொரு பகுதியையும் உள்ளடக்குகின்றன. பல loop-களை இயக்கத் தொடங்கிய பிறகு frameworks பயனுள்ளதாக இருக்கும்; அவை scheduling interfaces, shared memory formats மற்றும் multi-agent routing ஆகியவற்றை வழங்குகின்றன. முதல் loop-ஐ உருவாக்க அவை கட்டாயத் தொடக்கத் தேவைகள் அல்ல.

codebase harness என்றால் என்ன?

மனிதர் நேரடியாக இல்லாதபோதும் repository-யில் agent செயல்பட உதவும் கூறுகளின் தொகுப்பே codebase harness: ஒரே command-இல் செய்யக்கூடிய setup, non-interactively இயங்கி தோல்வியைத் தெளிவாகக் காட்டும் tests, linter, மேலும் மாற்றத்தை deploy அல்லது preview செய்யும் வழி. loop engineering தோன்றிய அதே 2026 repository அலைக்காலத்திலிருந்து இந்தச் சொல் வந்தது. நடைமுறைச் சோதனை எளிது: புதிய human contributor ஒருவர் clone முதல் green tests வரை ஒரே command-இல் செல்ல முடியாவிட்டால், agent-ஆலும் முடியாது.

agent loop பெரிய bill உருவாக்கும் அளவுக்கு இயங்குவதை எவ்வாறு நிறுத்துவது?

மூன்று இடங்களில் வரம்பு அமைக்கவும். hung run நிறுத்தப்படுமாறு systemd unit-இல் TimeoutStartSec அமைக்கவும். success கிடைக்கும் வரை loop செய்வதற்குப் பதிலாக, script-க்குள் retries-க்கு வரம்பு அமைக்கவும். API account-இல் hard spend limit அமைக்கவும், ஏனெனில் agent தன் வாதத்தால் கடக்க முடியாத ஒரே ceiling அதுதான். ஒவ்வொரு run-க்கான cost-ஐ log செய்யவும்; cost இரட்டிப்பாகும் loop-ன் scope பெரும்பாலும் கவனிக்கப்படாமல் விரிவடைந்திருக்கிறது.

முதலில் எந்த jobs-ஐ loop ஆக மாற்றுவது பயனுள்ளது?

machine-readable pass condition மற்றும் சிறிய blast radius கொண்ட job-ஐத் தேர்ந்தெடுக்கவும். red build-ஐச் சரிசெய்தல், dependency-ஐப் புதுப்பித்தல், changelog-ஐ மீண்டும் உருவாக்குதல் ஆகியவை இதற்குத் தகும், ஏனெனில் test suite அல்லது diff மூலம் முடிவை நிரூபிக்க முடியும். refactoring அல்லது design போன்ற open-ended வேலைகள் இப்போது தகுதியற்றவை, ஏனெனில் gate சரிபார்க்க எதுவும் இல்லை. gate இல்லாத loop review debt உருவாக்கும் செலவான வழியாகும்.