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

Loop engineering என்பதன் பொருள்

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

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

இந்தச் சொல் 2026-ல் ஏன் தோன்றியது

இதற்கான பெயர் தற்போது பொதுவெளியில் நிலைநிறுத்தப்பட்டு வருகிறது. cobusgreyling/loop-engineering என்ற GitHub repository, அது அறிமுகமான இரண்டு மாதங்களுக்குள்ளேயே 9,600 stars-ஐக் கடந்தது (ஜூலை 2026 நிலவரப்படி). 2026-10-27 அன்று, "Stop prompting. Design the loop. Get a score." என்ற வரியின் கீழ் அது சுமார் 11,600 stars-ஐக் கொண்டிருந்தது. ஜூலை 2026-ல், அதன் README இந்த மாற்றத்தை ஆறு கட்டுமானக் கூறுகளாகப் பிரித்திருந்தது: scheduling, worktrees, skills, plugins and connectors, sub-agents, மற்றும் உரையாடலுக்கு வெளியே பராமரிக்கப்படும் durable memory. தற்போதைய README-ல் அந்தப் பட்டியல் இல்லை (2026-10-27 அன்று சரிபார்க்கப்பட்டது), ஆனால் அது இன்னும் loop-ன் நிலையை உரையாடலுக்கு வெளியே ஒரு கோப்பில் வைத்திருக்கிறது.

இந்த repository, Anthropic-ல் Claude Code-ஐ வழிநடத்தும் Boris Cherny-ஐ தனது உத்வேகங்களில் ஒன்றாகக் குறிப்பிடுகிறது. அவர் கூறியதாகப் பரவலாக அறியப்படும் வரி இது:

நான் இனி Claude-ஐ prompt செய்வதில்லை. Claude-ஐ prompt செய்யும் loops-ஐ நான் இயக்கி வருகிறேன்.

இரண்டாவது repository-ஆன AI-Builder-Club/skills, 1,300 stars-க்கு அருகில் உள்ளது (2026-10-27 நிலவரப்படி). இது இரண்டு பாத்திரங்களை நேரடியாகப் பெயரிடுகிறது: ஒரு agent சோதனைகளை இயக்கவும், deploy செய்யவும் ஏதுவாக repository-ஐப் பாதுகாப்பாக மாற்றும் "codebase harness", மற்றும் ஒரு தூண்டுதலின் (trigger) மூலம் விழித்துக்கொண்டு, வேலையைச் செய்து, அடுத்த loop வாசிக்கும் வகையில் தான் கற்றுக்கொண்டதை ஒரு பகிரப்பட்ட கோப்பில் எழுதும் "loop engineer".

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

ஒரு லூப்பின் நான்கு பகுதிகள்

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

• Trigger. ஒரு ரன்-ஐத் தொடங்கும் நிகழ்வு: இது ஒரு டைமர், வெப்ஹூக் (webhook), புதிய புல் ரெக்வெஸ்ட் (pull request) அல்லது அலர்ட் ஆக இருக்கலாம்.
• Boundary. அந்த ரன்-ன் போது ஏஜென்ட் அணுகக்கூடிய கோப்புகள், நற்சான்றிதழ்கள் (credentials) மற்றும் நெட்வொர்க்.
• Verification. ரன்-ன் வெளியீட்டைச் சேமிப்பதா அல்லது நிராகரிப்பதா என்பதைத் தீர்மானிக்கும் எக்ஸிட் கோட் (exit code) கொண்ட சரிபார்ப்பு.
• Budget. ரன் வெற்றி பெற்றாலும் இல்லாவிட்டாலும், அதை முடிவுக்குக் கொண்டுவரும் டோக்கன், நேரம் மற்றும் பணத்திற்கான வரம்பு.

இந்த நான்கு பகுதிகளையும் கேள்விகளாகக் கருதிப் பாருங்கள். நீங்கள் இயக்கப்போகும் எந்தவொரு ஏஜென்ட்டிற்கும் இது ஒரு சிறந்த வடிவமைப்பு மதிப்பாய்வாக (design review) அமையும்.

தூண்டுதல்: ஏஜென்ட்டை இயக்குவது எது

ஒரு டைமர் (timer) என்பது மிக எளிமையான தூண்டுதல் ஆகும். Linux server-ல் cron-ஐ விட systemd timer சிறந்தது; ஏனெனில் இது பதிவுகளை (logs) பராமரிக்கிறது, உங்கள் விருப்பப்படி மீண்டும் முயற்சிக்கும் (retry) வசதியை வழங்குகிறது, மேலும் ஏற்கனவே இயங்கிக்கொண்டிருக்கும் ஒரு unit-ன் இரண்டாவது நகலைத் தொடங்காது. இந்த கடைசி அம்சம், ஏஜென்ட் சுழற்சிகளில் ஏற்படும் பொதுவான பிழையான, ஒரே கிளை (branch) மீது இரண்டு முறை மாற்றங்கள் செய்வதைத் தவிர்க்கிறது.

முதலில் ஏஜென்ட்டிற்கு எனத் தனி பயனர் கணக்கை உருவாக்கவும். அந்த பயனர் கணக்கு பாதுகாப்பின் ஒரு பகுதி என்பதால், அது /srv/agent-ஐ மட்டுமே சொந்தமாகக் கொண்டிருக்க வேண்டும்:

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

பின்பு /etc/systemd/system/agent-loop.service-ல் unit கோப்பை எழுதவும்:

[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

மற்றும் /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 நெடுவரிசையும், மீதமுள்ள நேரத்தைக் காட்டும் LEFT நெடுவரிசையும் தெரிய வேண்டும். முடிவு காலியாக இருந்தால், டைமர் இயக்கப்படவில்லை என்று பொருள். ஏனெனில் --now இல்லாமல் enable-ஐ மட்டும் பயன்படுத்தினால், அது அடுத்த boot-க்கு மட்டுமே திட்டமிடப்படும். TimeoutStartSec=1800 பார்ப்பதை விட முக்கியமானது. ஒரு Type=oneshot service அதன் script முடியும் வரை இயங்குவதாகவே கருதப்படும். systemd இயல்பாகவே oneshot unit-களுக்கு start timeout-ஐ முடக்கிவிடும். எனவே, இந்த வரி இல்லையென்றால், உள்ளீட்டிற்காகக் காத்திருக்கும் ஏஜென்ட் நிரந்தரமாக activating நிலையிலேயே சிக்கிக்கொள்ளும். அதன் பிறகு வரும் ஒவ்வொரு டைமர் சுழற்சியும் அந்த service ஏற்கனவே இயங்குவதாகக் கருதி எதையும் தொடங்காது. இந்த வரியைச் சேர்ப்பதன் மூலம், 30 நிமிடங்களுக்குப் பிறகு systemd அந்தச் செயல்பாட்டை முடித்துவிட்டு, அதை failed என அடையாளப்படுத்தும். நீங்கள் unit-ஐ இயல்பான Type=simple-க்கு மாற்றினால், TimeoutStartSec அந்தச் செயல்பாட்டைத் தடுத்து நிறுத்தாது; அதற்குப் பதிலாக RuntimeMaxSec= தான் கால அளவைக் கட்டுப்படுத்தும். journalctl -u agent-loop.service -n 50 மூலம் ஒரு செயல்பாட்டின் பதிவுகளைப் படிக்கலாம்.

நீங்கள் cron மூலம் சுழற்சியை இயக்குகிறீர்கள் என்றால், நீங்களே ஒரு பாதுகாப்பு வளையத்தை (overlap guard) உருவாக்க வேண்டும். ஏனெனில் cron இரண்டாவது நகலைத் தொடங்கத் தயங்காது:

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

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

எல்லை: ஒவ்வொரு இயக்கத்திற்கும் தனித்தனி நகல்

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

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

சரிபார்ப்பு: சுழற்சியைப் பாதுகாப்பானதாக்கும் வாயில்

இதுதான் ஒரு சுழற்சியை (loop), தட்டச்சு செய்யும் cron job-லிருந்து வேறுபடுத்திக் காட்டுகிறது. முகவரின் (agent) வெளியீடு ஒரு முன்மொழிவு மட்டுமே. அந்த வாயில் (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 புறக்கணிக்கப்பட்டு, பழைய origin/main-ஐ வைத்து இயக்கம் தொடரும். -u இல்லையென்றால், variable பெயரில் உள்ள தட்டச்சுப் பிழை காலியான string-ஆக விரிவடையும்; அப்போது cleanup தவறான பாதையில் இயங்கும், பிழையை வெளிப்படையாகக் காட்டாது. கடைசி வரியில் வேண்டுமென்றே --force சேர்க்கப்படவில்லை: ஒருவேளை அந்த இயக்கத்தில் கண்காணிக்கப்படாத அல்லது commit செய்யப்படாத கோப்புகள் இருந்தால், git அதை நீக்க மறுத்துவிடும். இதனால், யாரும் commit செய்யாத வேலையை அமைதியாக நீக்குவதற்குப் பதிலாக, push செய்த பிறகு -e பிழையுடன் இயக்கத்தை முடித்துவிடும்.

if ! npm test தொகுதிதான் முழு கருத்தாக்கமும். நீங்கள் ஏற்கனவே நம்பும் ஒரு சோதனை (test suite) அல்லது type checker-ன் exit code-தான், அந்த branch push செய்யப்பட வேண்டுமா அல்லது அழிக்கப்பட வேண்டுமா என்பதைத் தீர்மானிக்கிறது. வாயில் இல்லாத ஒரு சுழற்சி, யாரும் ஆய்வு செய்ய நேரமில்லாத வேலையை உருவாக்கும்; இது வேலையே செய்யாததை விட மோசமானது. வாயில் கொண்ட ஒரு சுழற்சி, ஒரு மனித பங்களிப்பாளர் கடக்க வேண்டிய அதே தரநிலையைத் தாண்டிய ஒரு branch-ஐ உருவாக்குகிறது. ஒரு வெற்றிகரமான வாயில், அந்த நிலையை அடைய முகவர் எவ்வளவு குறியீட்டை மாற்றியது என்பதைப் பற்றி எதையும் கூறாது. எனவே, இந்தச் சோதனையை முகவர் மிகச்சிறிய மாற்றத்தைச் செய்ய வைக்கும் விதி போன்ற ஒரு நிலையான அறிவுறுத்தலுடன் இணைப்பது நல்லது. இது diff-ஐ சிறியதாக வைத்திருக்கும், இதனால் ஆய்வு செய்வது எளிதாக இருக்கும்.

நேர்மையாகத் தோல்வியடையும் ஒரு வாயிலைத் தேர்வு செய்யுங்கள். காலியான diff-ல் வெற்றிபெறும் ஒரு test suite, எதையும் செய்யாமல் இருப்பதே வெற்றி என்று சுழற்சிக்குக் கற்றுக்கொடுத்துவிடும். பலவீனமான சோதனைகளைக் கொண்ட repositories பலவீனமான சுழற்சிகளையே உருவாக்கும். இதனால்தான், பிரபலமான repositories "குறியீட்டுத் தொகுப்பை முகவர்-தயார் நிலையில் வைத்தல்" என்பதை "சுழற்சியை எழுதுதல்" என்பதற்கு முன்னால் வைக்கின்றன. உங்கள் test suite வெறும் வரிகளை இயக்குகிறதா அல்லது உண்மையில் ஒரு regression-ஐக் கண்டறியுமா என்பதை நீங்கள் அறிய விரும்பினால், mutation testing-ஐப் பயன்படுத்தலாம். மேலும், diff-ஐப் படிக்கச் சொல்வதற்குப் பதிலாக, மீண்டும் இயக்கக்கூடிய ஆதார அறிக்கையை வழங்கும் முகவர், அந்தப் பதிலை நீங்கள் நீங்களே உறுதிப்படுத்தக்கூடிய ஒன்றாக மாற்றுகிறது.

பட்ஜெட்: ஒரு run-ஐ நிறுத்துவது எது

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

நீண்ட நேரம் இயங்கும் ஒரு session-ஐ விட, சிறிய loop-கள் பொதுவாகச் சிறந்தது என்பதற்கு செலவுதான் முக்கிய காரணம். புதிதாகத் தொடங்கி, ஒரு குறிப்பிட்ட வேலையை மட்டும் செய்துவிட்டு வெளியேறும் ஒரு run, தனது context-ஐச் சிறியதாக வைத்திருக்கும். எட்டு மணிநேரம் திறந்து வைக்கப்பட்ட ஒரு session, தனது வரலாற்றில் உள்ள அனைத்து முந்தைய தவறுகளையும் சுமந்து செல்லும்; மேலும், ஒவ்வொரு turn-இலும் முழு transcript-க்கும் கட்டணம் வசூலிக்கும்.

Trending repository-கள் வகைப்படுத்தும் முறைகள்

loop-engineering repository, 2026-10-27 நிலவரப்படி எட்டு production முறைகளைப் பட்டியலிடுகிறது. இவற்றை ஒரு கொள்கை அறிக்கையாகப் பார்க்காமல், ஒரு மெனுவாகப் பார்ப்பது சிறந்தது. Daily triage. GitHub Action-ஆக இயங்கும், state file எதையும் வைத்திருக்காத ஒரு மெல்லிய loop. review comments-ஐக் கவனித்து அவற்றுக்குப் பதிலளிக்கும் pull-request babysitter. தோல்வியடைந்த builds-ஐக் கையாளும் continuous-integration sweeper. Dependency sweeper. Changelog drafter. Post-merge cleanup. Issue triage.

இவை அனைத்திலும் பொதுவானது, தெளிவான இலக்கு கொண்ட குறுகிய வேலைதான். "தோல்வியடைந்த build-ஐச் சரிசெய்" என்பதற்கு இயந்திரத்தால் படிக்கக்கூடிய ஒரு வெற்றி நிபந்தனை (pass condition) உள்ளது. "Codebase-ஐ மேம்படுத்து" என்பதற்கு அத்தகைய நிபந்தனை இல்லை, எனவே அது ஒரு loop-ஆக மாறாது. அது ஒரு ஒழுங்கற்ற கால அட்டவணையாகவே மாறிவிடும்.

அவை அனைத்திலும் ஒரு எழுத்துப்பூர்வமான பதிவும் உள்ளது. இரண்டு repository-களுமே state-ஐ உரையாடலிலிருந்து வெளியேற்றி, repository-ல் உள்ள கோப்புகளில் சேமிக்கின்றன: என்ன இயங்கியது, என்ன கண்டறியப்பட்டது, என்ன முடிவு செய்யப்பட்டது போன்றவை. அந்தக் கோப்பே loop-ன் நினைவகம். இதனால்தான், முதல் loop-ன் வேலையை மீண்டும் கண்டறியாமல், இரண்டாவது loop அதன் அடிப்படையில் செயல்பட முடிகிறது. ஒரு run முடிந்தவுடன் model-ன் context அழிந்துவிடுவதால், ஒரு agent-ன் செயல்பாட்டைப் பிற்காலத்தில் தணிக்கை (audit) செய்யவும் இதுவே வழிவகுக்கிறது. நேரடி ஒருங்கிணைப்பு என்பது ஒரு தனி channel; ஒரே box-ல் இயங்கும் ஒரு Claude Code session மற்றொரு session-க்கு வேலையை வழங்க முடியும். ஆனால், அந்தப் பரிமாற்றத்தில் எதுவுமே session-ஐத் தாண்டி நீடிக்காது என்பதால், பிற்காலத்தில் நீங்கள் வாசித்துப் பார்க்கக்கூடிய பகுதியாக அந்தக் கோப்பு மட்டுமே எஞ்சியிருக்கும்.

சுழற்சிகள் (loops) தோல்வியடையும் இடங்கள்

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

• கட்டுப்பாடு இன்மை (No gate). வெளியீடு (output) குவிகிறது, யாரும் அதை ஆய்வு செய்வதில்லை, நம்பிக்கை குறைகிறது, இறுதியில் அந்தச் சுழற்சி அணைக்கப்படுகிறது.
• மேலெழுதல் (Overlap). ஒரே branch-ல் இரண்டு இயக்கங்கள் அல்லது ஒரே working tree-ல் இரண்டு agents, மோதல்களை (conflicts) உருவாக்குகின்றன; அதை அந்த agent சரிசெய்ய முயல்கிறது.
• அமைதியான விலகல் (Silent drift). சோதனை (check) மிகவும் பலவீனமாக இருப்பதால், தோல்வியடைய வேண்டிய சுழற்சி தொடர்ந்து வெற்றி பெறுகிறது.
• வரம்பற்ற நோக்கம் (Unbounded scope). பரபரப்பான repository-ல் ஒவ்வொரு commit-க்கும் தூண்டப்படும் (trigger) ஒரு செயல்பாடு, ஒரு நாளுக்குள் செலவுப் பிரச்சினையாக மாறுகிறது.

ஒவ்வொரு பிரச்சினைக்கும் ஒரே தீர்வுதான்: பணியைச் சுருக்குங்கள், சோதனையைத் துல்லியமாக்குங்கள், மற்றும் இயக்கத்தைப் பதிவு (log) செய்யுங்கள். ஒரு பணியின் வெற்றி நிலையை உங்களால் ஒரே வாக்கியத்தில் விவரிக்க முடியாவிட்டால், அந்தப் பணி தானியக்கமாக்கப்படுவதற்குத் தயாராக இல்லை என்று அர்த்தம்.

எந்தவொரு கூடுதல் கட்டமைப்பும் இன்றி தொடங்குதல்

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

FAQ

Loop engineering மற்றும் prompt engineering ஒன்றா?

Prompt engineering ஒரு செய்தியை மேம்படுத்துகிறது: வார்த்தைகள், உதாரணங்கள், வெளியீட்டு வடிவம் போன்றவை. Loop engineering அந்தச் செய்தியைச் சுற்றியுள்ள சுழற்சியை மேம்படுத்துகிறது: ஒரு செயல்பாட்டைத் தொடங்கும் தூண்டுதல், அது இயங்கும் sandbox, அதன் வெளியீட்டை ஏற்கும் அல்லது நிராகரிக்கும் சோதனை, மற்றும் அதை முடிக்கும் வரவு செலவுத் திட்டம். சுழற்சிக்குள் இன்னும் ஒரு சிறந்த prompt தேவைதான். ஆனால், சுழற்சியின் வாயிலும் (gate) தூண்டுதலும் (trigger) முடிவுகளில் அதிக தாக்கத்தை ஏற்படுத்துவதால், prompt-ஐ மட்டும் தினமும் மாற்ற வேண்டிய அவசியம் இருக்காது.

ஏஜென்ட் சுழற்சியை உருவாக்க framework தேவையா?

இல்லை. ஒரு systemd timer, ஒவ்வொரு செயல்பாட்டிற்கும் ஒரு git worktree, சோதனைக் கட்டளையுடன் முடியும் ஒரு shell script, மற்றும் API கணக்கிற்கான செலவு வரம்பு ஆகியவை போதுமானவை. Framework-கள் திட்டமிடல் இடைமுகங்கள், பகிரப்பட்ட நினைவக வடிவங்கள் மற்றும் பல-ஏஜென்ட் routing போன்றவற்றை வழங்குகின்றன. இவை பல சுழற்சிகளை இயக்கும்போது பயனுள்ளதாக இருக்கும். முதல் சுழற்சியைத் தொடங்க இவை கட்டாயமில்லை.

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

மனிதர்கள் இல்லாதபோதும் ஒரு repository-ல் ஏஜென்ட் வேலை செய்ய உதவும் கருவிகளின் தொகுப்பு இது: ஒரே கட்டளையில் அமைத்தல், தானாக இயங்கி தோல்வியைத் தெளிவாகக் காட்டும் சோதனைகள், linter, மற்றும் மாற்றங்களை deploy அல்லது preview செய்யும் வழிமுறை. இந்தச் சொல் 2026-ல் loop engineering-உடன் உருவானது. இதற்கான நடைமுறைச் சோதனை எளிது: ஒரு புதிய நபரால் ஒரு கட்டளையில் clone செய்து சோதனைகளை வெற்றிகரமாக (green) முடிக்க முடியாவிட்டால், ஏஜென்ட்டாலும் முடியாது.

ஏஜென்ட் சுழற்சி அதிக கட்டணத்தை உருவாக்குவதைத் தடுப்பது எப்படி?

மூன்று இடங்களில் கட்டுப்படுத்தவும். மேலே உள்ளதைப் போல Type=oneshot systemd unit-ல் TimeoutStartSec-ஐ அமைக்கவும், இதனால் நீண்ட நேரம் இயங்கும் செயல்பாடு நிறுத்தப்படும் (Type=simple service-ல் இதற்கு RuntimeMaxSec-ஐப் பயன்படுத்தவும்). வெற்றி பெறும் வரை சுழற்சி செய்வதைத் தவிர்த்து, script-க்குள்ளேயே மீண்டும் முயற்சிக்கும் எண்ணிக்கையைக் கட்டுப்படுத்தவும். API கணக்கிற்கு ஒரு கடினமான செலவு வரம்பை (hard spend limit) அமைக்கவும், ஏனெனில் ஏஜென்ட் அதைத் தாண்ட முடியாது. ஒவ்வொரு செயல்பாட்டின் செலவையும் பதிவு செய்யவும், ஏனெனில் செலவு இரட்டிப்பாகும் சுழற்சி, பெரும்பாலும் அதன் எல்லை (scope) அமைதியாக விரிவடைந்திருப்பதைக் குறிக்கிறது.

எந்தப் பணிகளை முதலில் சுழற்சியாக மாற்றலாம்?

இயந்திரத்தால் சரிபார்க்கக்கூடிய நிபந்தனை மற்றும் சிறிய பாதிப்பு எல்லை (blast radius) கொண்ட பணிகளைத் தேர்ந்தெடுக்கவும். தோல்வியடைந்த build-ஐச் சரிசெய்தல், dependency-ஐப் புதுப்பித்தல், மற்றும் changelog-ஐ உருவாக்குதல் போன்றவை இதற்குப் பொருந்தும். ஏனெனில் சோதனைத் தொகுப்பு (test suite) அல்லது diff மூலம் முடிவை நிரூபிக்க முடியும். Refactoring அல்லது வடிவமைப்பு போன்ற முடிவற்ற வேலைகள் இதற்கு இன்னும் பொருந்தாது, ஏனெனில் சரிபார்க்க வாயில் (gate) எதுவும் இல்லை. வாயில் இல்லாத சுழற்சி என்பது, மதிப்பாய்வுச் சுமையை (review debt) உருவாக்குவதற்கான விலையுயர்ந்த வழியாகும்.