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

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

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

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

2026-ல் இந்தச் சொல் ஏன் உருவானது

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

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

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

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

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

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

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

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

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

தூண்டுதல்: agent-ஐ இயக்குவது எது

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

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

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

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

flock -n, lock ஏற்கனவே இருந்தால் status 1-உடன் உடனடியாக வெளியேறிவிடும். எனவே, முதல் run-உடன் போட்டியிடாமல், இரண்டாவது run அமைதியாக மறைந்துவிடும். இதே systemd service and timer setup முறை, agent ஆக இருந்தாலும் இல்லாவிட்டாலும், 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 அந்த directory-ஐ நீக்குகிறது, மேலும் git worktree prune எந்தெந்த directory-கள் மறைந்துவிட்டனவோ அவற்றின் பதிவுகளை நீக்குகிறது. இந்த நிலையில் parallel loops பாதுகாப்பானதாக மாறுகிறது, ஏனெனில் இரண்டு வெவ்வேறு directory-களில் உள்ள இரண்டு branch-களில் இயங்கும் இரண்டு agents ஒன்றையொன்று மேலெழுத (overwrite) முடியாது.

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

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

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

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

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

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

Trending repositories குறியீடாக்கும் முறைகள்

loop-engineering repository ஏழு production முறைகளை பட்டியலிடுகிறது. இவற்றை ஒரு கொள்கை அறிக்கையாகப் பார்க்காமல், ஒரு மெனுவாகப் பார்ப்பது சிறந்தது. தினசரி triage. review comments-ஐக் கவனித்து அவற்றுக்கு பதிலளிக்கும் pull-request babysitter. தோல்வியடைந்த builds-ஐக் கண்டறியும் continuous-integration sweeper. dependency sweeper. changelog drafter. Post-merge cleanup. Issue triage.

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

இவை அனைத்தும் ஒரு எழுத்துப்பூர்வமான பதிவையும் பகிர்ந்து கொள்கின்றன. இரண்டு repositories-ம் தகவல்களை உரையாடலில் இருந்து வெளியேற்றி, 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 என்பது அந்தச் செய்தியைச் சுற்றியுள்ள சுழற்சியை மேம்படுத்துகிறது: ஒரு run-ஐத் தொடங்கும் trigger, அது இயங்கும் sandbox, அதன் வெளியீட்டை ஏற்கும் அல்லது நிராகரிக்கும் சரிபார்ப்பு (check), மற்றும் அதை முடிக்கும் budget. சுழற்சிக்குள் இன்னும் ஒரு சிறந்த prompt தேவைப்படுகிறது. நீங்கள் அன்றாடம் மாற்றியமைக்கும் விஷயமாக prompt இருப்பதில்லை, ஏனெனில் gate மற்றும் trigger ஆகியவை முடிவுகளில் அதிக தாக்கத்தை ஏற்படுத்துகின்றன.

Agent loop-ஐ உருவாக்க எனக்கு framework தேவையா?

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

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

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

Agent loop அதிக கட்டணத்தை உருவாக்குவதைத் தடுப்பது எப்படி?

மூன்று இடங்களில் வரம்புகளை அமைக்கவும். Systemd unit-ல் TimeoutStartSec-ஐ அமைக்கவும், இதனால் சிக்கிக்கொண்ட run நிறுத்தப்படும். வெற்றி பெறும் வரை சுழற்சி செய்வதற்குப் பதிலாக, script-க்குள் retries-ஐக் கட்டுப்படுத்தவும். API account-ல் ஒரு கடினமான spend limit-ஐ அமைக்கவும், ஏனெனில் இதுவே agent-ஆல் மீற முடியாத ஒரே உச்சவரம்பு. பிறகு, ஒவ்வொரு run-ன் செலவையும் log செய்யவும், ஏனெனில் செலவு இரட்டிப்பாகும் ஒரு சுழற்சி, பொதுவாக அதன் நோக்கம் அமைதியாக விரிவடைந்த சுழற்சியாகும்.

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

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