Loop engineering అంటే ఏమిటి? పూర్తి వివరణ

Loop engineering అంటే ఏమిటి

Loop engineering అనేది AI agent నడిచే పునరావృత చక్రాన్ని రూపొందించే పద్ధతి: ఏది దాన్ని మేల్కొల్పుతుంది, అది దేనిని తాకగలదు, దాని అవుట్‌పుట్ ఎలా తనిఖీ చేయబడుతుంది మరియు దేనితో అది ఆగిపోతుంది అనే అంశాలను ఇది నిర్ణయిస్తుంది. Prompt engineering ఒక సందేశాన్ని మోడల్‌కు అనుగుణంగా మారుస్తుంది. Loop engineering మీరు నిద్రిస్తున్నప్పుడు వేలకొద్దీ సందేశాలను పంపే ప్రక్రియను రూపొందిస్తుంది. ఇక్కడ పని యొక్క ప్రాథమిక యూనిట్ prompt నుండి loop కు మారుతుంది.

క్లుప్తంగా చెప్పాలంటే: మీరు సూచనలు రాయడం ఆపివేసి, ఒక కంట్రోల్ సిస్టమ్‌ను రాయడం ప్రారంభిస్తారు. ఏజెంట్‌కు ఇప్పటికీ మంచి సూచనలు అవసరం, కానీ అవి ఒక చక్రంలో భాగంగా మారతాయి. ఈ చక్రం నిర్ణీత సమయానికి నడుస్తుంది, మీ కోడ్ యొక్క ఐసోలేటెడ్ కాపీలో పనిచేస్తుంది, తన ఫలితాన్ని పరీక్ష ద్వారా నిరూపించుకుంటుంది మరియు బడ్జెట్ అయిపోయినప్పుడు ఆగిపోతుంది.

2026లో ఈ పదం ఎందుకు ప్రాచుర్యంలోకి వచ్చింది

ఈ పేరు ప్రస్తుతం బహిరంగంగా స్థిరపడుతోంది. GitHub repository cobusgreyling/loop-engineering మొదట కనిపించిన రెండు నెలల్లోనే 9,600 stars దాటింది (2026 July నాటికి). 2026-10-27 నాటికి అది సుమారు 11,600 stars చూపించింది. దాని tagline: "Stop prompting. Design the loop. Get a score." 2026 Julyలో దాని README ఈ మార్పును ఆరు building blocksగా విభజించింది: scheduling, worktrees, skills, plugins and connectors, sub-agents, అలాగే conversation వెలుపల నిల్వ చేసే durable memory. ప్రస్తుత READMEలో ఆ జాబితా లేదు (2026-10-27 న పరిశీలించబడింది). అయితే loop యొక్క stateను conversation వెలుపల ఉన్న fileలోనే ఉంచుతోంది.

ఈ repositoryకి Anthropicలో Claude Codeకు నాయకత్వం వహిస్తున్న Boris Cherny ప్రేరణలలో ఒకరిగా credit ఇవ్వబడింది. ఆయన విస్తృతంగా నివేదించబడిన మాటలు ఇవి:

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

రెండవ repository, AI-Builder-Club/skills, 1,300 starsకు సమీపంలో ఉంది (2026-10-27 నాటికి). ఇది రెండు rolesను నేరుగా నిర్వచిస్తుంది: ఒక repositoryలో agent tests మరియు deploys నడపడం సురక్షితంగా చేసే "codebase harness"; trigger వచ్చినప్పుడు మేల్కొని పని చేసి, తాను నేర్చుకున్నదాన్ని shared fileలో రాసే workflowsను నిర్మించే "loop engineer".

ఈ రెండు repositories ఈ విధానాన్ని కనిపెట్టలేదు. nightly build, continuous integrationలో linter, లేదా ticket తెరిచే cron job నడిపినవారికి దీని నిర్మాణం ఇప్పటికే తెలుసు. కొత్త విషయం ఏమిటంటే loopలోని worker ఇప్పుడు non-deterministicగా ఉంది. అందువల్ల చుట్టూ ఉన్న machinery చేయాల్సిన పని మారుతుంది.

లూప్‌లోని నాలుగు భాగాలు

ప్రతి పని చేసే లూప్‌లో ఈ నాలుగు భాగాలు ఉంటాయి. వీటిలో ఏ ఒక్కటి లేకపోయినా, ఆ లూప్ మిమ్మల్ని అర్ధరాత్రి 3 గంటలకు నిద్రలేపే అవకాశం ఉంది.

• Trigger. రన్ ప్రారంభమయ్యే సంఘటన: ఇది ఒక టైమర్, వెబ్‌హుక్ (webhook), కొత్త పుల్ రిక్వెస్ట్ (pull request) లేదా అలర్ట్ కావచ్చు.
• Boundary. రన్ సమయంలో ఏజెంట్ యాక్సెస్ చేయగల ఫైళ్లు, క్రెడెన్షియల్స్ మరియు నెట్‌వర్క్ పరిధి.
• Verification. రన్ అవుట్‌పుట్‌ను ఉంచాలా లేదా తొలగించాలా అని నిర్ణయించే ఎగ్జిట్ కోడ్ (exit code) తో కూడిన తనిఖీ.
• Budget. రన్ విజయవంతమైనా లేదా విఫలమైనా, దానిని ముగించే టోకెన్, సమయం మరియు ఖర్చు పరిమితి.

ఈ నాలుగు భాగాలను ప్రశ్నలుగా మార్చి చూస్తే, మీరు రన్ చేయడానికి సిద్ధంగా ఉన్న ఏ ఏజెంట్ కైనా డిజైన్ రివ్యూ సిద్ధమవుతుంది.

ఏది agent ను మేల్కొలుపుతుంది

Timer అనేది అత్యంత సరళమైన trigger. Linux server లో దీనికి cron కంటే systemd timer మెరుగైనది. ఎందుకంటే ఇది logs ను నమోదు చేస్తుంది, మీరు నిర్దేశించిన విధంగా retries చేస్తుంది, ఇంకా ఇప్పటికే నడుస్తున్న unit కు రెండవ copy ను ప్రారంభించదు. ఈ చివరి లక్షణం agent loops లో సాధారణంగా కనిపించే overlap bug ను తొలగిస్తుంది: ఒకే branch ను రెండు runs సవరించడం.

ముందుగా agent కోసం ప్రత్యేక user ను సృష్టించండి. ఆ user boundary లో భాగం. కాబట్టి అది /srv/agent ను మాత్రమే own చేయాలి:

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

తరువాత 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 ను, countdown ను చూపించే LEFT column ను చూపాలి. ఫలితం ఖాళీగా ఉంటే timer enabled కాలేదు. ఎందుకంటే enable ను --now లేకుండా ఉపయోగిస్తే అది తదుపరి boot కు మాత్రమే schedule అవుతుంది. TimeoutStartSec=1800 ప్రాధాన్యత కనిపించేదానికంటే ఎక్కువ. Type=oneshot service గా ఉన్నది దాని script exit అయ్యే వరకు starting స్థితిలో ఉంటుంది. systemd oneshot units కోసం start timeout ను default గా off చేస్తుంది. కాబట్టి ఈ line లేకపోతే input కోసం వేచి ఉండే agent unit ను activating స్థితిలో ఎప్పటికీ నిలిపివేస్తుంది. తరువాతి ప్రతి timer tick దానిని ఇంకా running గా గుర్తించి ఏదీ ప్రారంభించదు. ఈ line ఉంటే systemd 30 minutes తర్వాత run ను terminate చేసి failed గా mark చేస్తుంది. ఎప్పుడైనా unit ను default Type=simple కు మార్చితే, TimeoutStartSec run ను స్వయంగా cover చేయదు. దాని గరిష్ఠ కాలాన్ని నిర్ణయించే setting RuntimeMaxSec=. ఒక run ను journalctl -u agent-loop.service -n 50 తో పరిశీలించండి.

బదులుగా loop ను cron తో నడిపిస్తే, మీ స్వంత overlap guard ను జోడించండి. ఎందుకంటే cron రెండవ copy ను సులభంగా ప్రారంభిస్తుంది:

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

Lock ఇప్పటికే held లో ఉంటే flock -n status 1 తో వెంటనే exit అవుతుంది. అందువల్ల రెండవ run మొదటి run తో race చేయకుండా నిశ్శబ్దంగా ముగుస్తుంది. ఈ box లో agent అయినా కాకపోయినా ఏ long-running job కైనా అదే systemd service మరియు timer setup వర్తిస్తుంది.

సరిహద్దు: ప్రతి run కు ప్రత్యేక కాపీ ఇవ్వండి

మీ working tree ను సవరించే agent, commit చేయని మీ పనిని కోల్పోయే అవకాశం ఉన్న agent కూడా. 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 తో ఒక line ను ముద్రిస్తుంది. run ముగిసినప్పుడు git worktree remove /srv/agent/work/triage-01 worktree ను తొలగిస్తుంది, కానీ clean worktree ను మాత్రమే. tree లో untracked files లేదా మార్చిన tracked files ఉంటే, లేదా అందులో submodules ఉంటే, --force ను జోడించే వరకు git నిరాకరిస్తుంది. అందుకే దిగువ gate script, run ను తొలగించే path పైన మాత్రమే removal ను బలవంతంగా అమలు చేస్తుంది. Directory కనిపించకుండా పోయిన entries ను git worktree prune తొలగిస్తుంది. ఈ దశలో parallel loops సురక్షితమవుతాయి, ఎందుకంటే వేర్వేరు directories లోని వేర్వేరు branches పై పనిచేసే రెండు agents ఒకదాని పనిని మరొకటి overwrite చేయలేవు.

ఈ boundary credentials కు కూడా వర్తిస్తుంది. unattended గా నడిచే loop లో long-lived tokens ఉంటాయి. ప్రతి run లో ఒక token ను log, commit లేదా model context లోకి లీక్ చేసే అవకాశం ఉంటుంది. loop తాకే ఒకే repository కు token scope ను పరిమితం చేయండి. సాధ్యమైన చోట agent యొక్క స్వంత shell చూసే environment నుండి token ను దూరంగా ఉంచండి. loop కు production access ఇచ్చే ముందు AI agents నుండి secrets ను ఎలా దూరంగా ఉంచాలో చదవండి. మరింత కఠినమైన isolation కోసం, ప్రతి run తర్వాత నాశనం చేయగల disposable VM పై మొత్తం loop ను అమలు చేయండి. మీరు ఎంచుకునే tool, దాని నిర్మాణానికి ముందే boundary లోని కొంత భాగాన్ని నిర్ణయిస్తుంది. అందువల్ల మీకు మీరే ఎంత isolation నిర్మించాలో నిర్ణయించే ముందు మీ స్వంత machine పై Claude Code తో Cowork managed sandbox ఎలా పోలుస్తుందో చదవండి.

ధృవీకరణ: loop ను సురక్షితంగా చేసే gate

ఇదే loop ను కేవలం టైప్ చేసే cron job నుంచి వేరు చేస్తుంది. agent ఇచ్చే output ఒక ప్రతిపాదన మాత్రమే. నిర్ణయం 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 పేరు తప్పుగా రాసినప్పుడు అది ఖాళీ string గా విస్తరిస్తుంది. అప్పుడు cleanup స్పష్టమైన error తో ఆగకుండా తప్పు path పై అమలవుతుంది. చివరి line లో ఉద్దేశపూర్వకంగా --force లేదు. Run తర్వాత tree లో track చేయని లేదా commit చేయని files మిగిలి ఉంటే, git వాటిని తొలగించడానికి నిరాకరిస్తుంది. Push తర్వాత ఎవరూ commit చేయని పని మౌనంగా తొలగించకుండా, -e run ను error తో ముగిస్తుంది.

if ! npm test block లోనే మొత్తం విధానం ఉంది. మీరు ఇప్పటికే విశ్వసించే check యొక్క exit code, అంటే మీ test suite లేదా type checker, branch ను push చేయాలా లేదా తొలగించాలా నిర్ణయిస్తుంది. gate లేని loop ఎవరూ సమీక్షించడానికి సమయం కేటాయించలేని పనిని ఉత్పత్తి చేస్తుంది. అది అసలు పని లేకపోవడంకన్నా దారుణం. gate ఉన్న loop, మానవ contributor branch కు వర్తించే అదే ప్రమాణాన్ని ఇప్పటికే దాటిన branch ను ఉత్పత్తి చేస్తుంది. Gate green గా ఉందనడం agent ఎంత code ను మార్చిందో చెప్పదు. అందువల్ల check ను agent పనిచేసే కనిష్ట మార్పును ఎంచుకునేలా చేసే నియమం వంటి స్థిరమైన instruction తో కలిపి ఉపయోగించడం మంచిది. అప్పుడు diff చిన్నగా ఉంటుంది, దాని review ఖర్చు కూడా తక్కువగా ఉంటుంది.

నిజాయితీగా విఫలమయ్యే gate ను ఎంచుకోండి. ఖాళీ diff పై కూడా pass అయ్యే test suite, ఏమీ చేయకపోవడమే విజయమని loop కు నేర్పుతుంది. బలహీనమైన tests ఉన్న repositories బలహీనమైన loops ను పొందుతాయి. అందుకే ప్రముఖ repositories “codebase ను agent-ready గా చేయడం” ను “loop రాయడం” కంటే ముందుగా ఉంచుతాయి. మీ suite regression ను నిజంగా గుర్తిస్తుందో, లేక lines ను కేవలం execute చేస్తుందో తెలుసుకోవాలంటే mutation testing ఆ ప్రశ్నకు సమాధానం ఇచ్చే check. అలాగే మీ diff చదవమని అడగకుండా మళ్లీ అమలు చేయగల evidence report ను అందించే agent ఆ సమాధానాన్ని మీరు స్వయంగా నిర్ధారించుకోగల రూపంలోకి మార్చుతుంది.

బడ్జెట్: ఒక రన్‌ను ఆపేవి

ఎప్పటికీ retry చేస్తూ ఉండే agent‌కు పరిమితి లేని బిల్లు ఉంటుంది. ప్రతి loop‌కు wall-clock పరిమితిని ఇవ్వండి. దాన్ని పైన ఉన్న TimeoutStartSec అమలు చేయాలి. మీ script‌లో retry count‌ను కూడా ఉంచండి. అలాగే provider account అమలు చేసే spend cap‌ను సెట్ చేయండి. తరువాత ప్రతి run‌కు అయిన ఖర్చును log చేయండి. అప్పుడు invoice రాకముందే loop క్రమంగా పెరుగుతున్న ఖర్చును గుర్తించగలరు. ఎల్లప్పుడూ నడిచే agent VPS కోసం ఖర్చు నియంత్రణలో accounting అంశాలు ఉన్నాయి. turnల మధ్య agent తీసుకెళ్లే context నిర్వహణలో ప్రతి run ఖర్చుపై ప్రభావం చూపే అతిపెద్ద అంశం ఉంది. ఎందుకంటే ప్రతి 30 నిమిషాలకు అదే repositoryని మళ్లీ చదివే loop, ప్రతి 30 నిమిషాలకు దాని కోసం చెల్లించాల్సి ఉంటుంది.

Loops సాధారణంగా ఒకే సుదీర్ఘ session కంటే మెరుగ్గా పనిచేయడానికి ఖర్చే కారణం. కొత్తగా ప్రారంభమయ్యే run ఒక పరిమితమైన పనిని చేసి ముగిస్తే, దాని context చిన్నదిగా ఉంటుంది. ఎనిమిది గంటల పాటు తెరిచి ఉంచిన session తన historyలో ముందరి ప్రతి తప్పును తీసుకెళ్తుంది. ప్రతి turnలో మొత్తం transcript‌కు చెల్లించాల్సి ఉంటుంది.

Trending repositories ప్రమాణీకరిస్తున్న నమూనాలు

loop-engineering repository ఎనిమిది production patternsను జాబితా చేస్తుంది (2026-10-27 నాటికి). వీటిని manifestoగా కాకుండా menuగా చదవడం మంచిది. Daily triage. State fileను ఉంచని, GitHub Actionగా నడిచే thin loop. Review comments కోసం monitor చేసి వాటికి సమాధానం ఇచ్చే pull-request babysitter. విఫలమైన buildsను తీసుకునే continuous-integration sweeper. Dependency sweeper. Changelog drafter. Post-merge cleanup. Issue triage.

వీటన్నింటికీ ఒకే లక్షణం ఉంది: స్పష్టమైన gate కలిగిన పరిమిత పని. "Fix the failing build"కు machine చదవగల pass condition ఉంటుంది. "Improve the codebase"కు అలాంటి condition ఉండదు. అందువల్ల అది loopగా మారదు. Scheduleతో కూడిన messగా మారుతుంది.

వీటన్నింటిలో written record కూడా ఉంటుంది. రెండు repositories stateను conversation నుంచి బయటకు తీసి repositoryలోని filesలో ఉంచుతాయి: ఏమి నడిచింది, ఏమి కనుగొంది, ఏమి నిర్ణయించింది. ఆ file loop యొక్క memory. అందువల్ల రెండవ loop మొదటి loop పనిపై ఆధారపడగలదు; అదే విషయాన్ని మళ్లీ కనుగొనాల్సిన అవసరం ఉండదు. తర్వాత agentను audit చేయడానికి కూడా ఇదే ఉపయోగపడుతుంది, ఎందుకంటే run ముగిసిన వెంటనే model context తొలగిపోతుంది. Live coordination వేరే channelలో జరుగుతుంది. రెండు sessions నడుస్తున్నప్పుడే ఒక Claude Code session అదే boxలోని మరొకదానికి పనిని అప్పగించగలదు. అయితే ఆ exchangeలోని ఏదీ రెండు sessionsలో ఏదీ ముగిసిన తర్వాత నిలిచి ఉండదు. అందువల్ల తర్వాత తిరిగి చదవగలిగే భాగంగా file మిగులుతుంది.

లూప్‌లు ఎక్కడ విఫలమవుతాయి

ఈ వైఫల్యాలు సాధారణమైనవి మరియు వివిధ టీమ్‌లలో పదేపదే జరుగుతుంటాయి.

• గేట్ లేకపోవడం. అవుట్‌పుట్ పేరుకుపోతుంది, ఎవరూ దానిని సమీక్షించరు, నమ్మకం సన్నగిల్లుతుంది, చివరకు ఆ లూప్‌ను నిలిపివేస్తారు.
• ఓవర్‌ల్యాప్. ఒకే బ్రాంచ్‌పై రెండు రన్‌లు లేదా ఒకే వర్కింగ్ ట్రీలో రెండు ఏజెంట్లు పనిచేయడం వల్ల వైరుధ్యాలు (conflicts) ఏర్పడతాయి, వాటిని పరిష్కరించడానికి ఏజెంట్ ప్రయత్నిస్తుంది.
• సైలెంట్ డ్రిఫ్ట్. చెక్ చాలా బలహీనంగా ఉండటం వల్ల లూప్ పాస్ అవుతూనే ఉంటుంది.
• అపరిమిత పరిధి (Unbounded scope). బిజీగా ఉన్న రిపోజిటరీలో ప్రతి కమిట్‌కు ట్రిగ్గర్ అవ్వడం వల్ల ఒకే రోజులో ఖర్చు సమస్యగా మారుతుంది.

వీటన్నింటికీ ఒకే పరిష్కారం ఉంది: జాబ్‌ను తగ్గించండి, చెక్‌ను మరింత కచ్చితంగా మార్చండి మరియు రన్‌ను లాగ్ చేయండి. ఒకవేళ మీరు పాస్ అయ్యే కండిషన్‌ను ఒక్క వాక్యంలో వివరించలేకపోతే, ఆ జాబ్ ఆటోమేషన్‌కు సిద్ధంగా లేదని అర్థం.

పరిభాష అవసరం లేకుండా ప్రారంభించడం

మీకు ఎటువంటి framework అవసరం లేదు. ఎల్లప్పుడూ ఆన్‌లో ఉండే ఒక చిన్న Linux సర్వర్, పరీక్షలు విఫలమైనప్పుడు తప్పును గుర్తించే ఒక git repository, ఒక systemd timer మరియు ఒక if ఉన్న shell script కలిస్తే ఒక పూర్తి లూప్ తయారవుతుంది. చాలామంది ఇక్కడే ప్రారంభించాలి, ఎందుకంటే ఒక సాధనాన్ని ఎంచుకోవడం కంటే, ఆ పనిని నేరుగా అమలు చేయడం ద్వారానే డిజైన్ పరమైన ప్రశ్నలకు సమాధానాలు దొరుకుతాయి. ఒక లూప్ స్థిరంగా ఉన్న తర్వాత, మరొక లూప్‌ను నడపడం అనేది కేవలం మరొక timer మరియు మరొక worktree ని జోడించడం మాత్రమే. బేస్ సెటప్ కోసం VPS పై coding AI agent ను ఎలా రన్ చేయాలి చూడండి, మరియు మీరు నియంత్రించే హార్డ్‌వేర్‌పైనే agent రన్ అవ్వాలనుకుంటే ప్రస్తుతం అందుబాటులో ఉన్న self-hosted AI agent ఎంపికలు చూడండి.

FAQ

Loop engineering మరియు prompt engineering వేర్వేరుగా ఉంటాయా?

Prompt engineering ఒక message ను optimize చేస్తుంది: wording, examples, output format. Loop engineering ఆ message చుట్టూ ఉండే cycle ను optimize చేస్తుంది: run ను ప్రారంభించే trigger, అది నడిచే sandbox, దాని output ను అంగీకరించాలా లేదా తిరస్కరించాలా నిర్ణయించే check, మరియు cycle ను ముగించే budget. Loop లోపల మీకు ఇంకా మంచి prompt అవసరం. అయితే రోజువారీగా tune చేయాల్సిన ప్రధాన అంశం prompt కాదు. Gate మరియు trigger ఫలితంపై ఎక్కువ ప్రభావం చూపుతాయి.

Agent loop నిర్మించడానికి framework అవసరమా?

అవసరం లేదు. systemd timer, ప్రతి run కు ఒక git worktree, test command తో ముగిసే shell script, మరియు provider account పై spend cap — ఇవి definition లోని ప్రతి భాగాన్ని కవర్ చేస్తాయి. మీరు అనేక loops నడపడం ప్రారంభించినప్పుడు frameworks scheduling interfaces, shared memory formats మరియు multi-agent routing ను అందిస్తాయి. అయితే మొదటి loop కోసం అవి తప్పనిసరి కావు.

Codebase harness అంటే ఏమిటి?

మనిషి ప్రత్యక్షంగా లేకపోయినా agent repository లో పని చేయడానికి అవసరమైన అంశాల సమాహారమే codebase harness. ఇందులో one-command setup, non-interactively నడిచి స్పష్టంగా fail అయ్యే tests, linter, మరియు change ను deploy లేదా preview చేసే విధానం ఉంటాయి. Loop engineering తో పాటు 2026లో ఏర్పడిన repositories wave నుంచే ఈ term వచ్చింది. దీని practical test సులభం: కొత్త human contributor ఒక command తో clone నుంచి green tests వరకు చేరలేకపోతే, agent కూడా చేరలేడు.

Agent loop పెద్ద bill ను సృష్టించకుండా ఎలా ఆపాలి?

మూడు చోట్ల cap పెట్టండి. పై ఉదాహరణలో ఉన్నట్లుగా Type=oneshot systemd unit పై TimeoutStartSec ను set చేయండి. అప్పుడు hang అయిన run kill అవుతుంది. Type=simple service పై దీనికి సమానమైన setting RuntimeMaxSec. Script లో success వచ్చే వరకు loop చేయకుండా retries కు పరిమితి పెట్టండి. API account పై hard spend limit ను set చేయండి. Agent దాటలేని ఏకైక ceiling అదే. తరువాత ప్రతి run cost ను log చేయండి. ఎందుకంటే cost రెట్టింపు అయ్యే loop సాధారణంగా తన scope ను నిశ్శబ్దంగా విస్తరించిన loop అయి ఉంటుంది.

ముందుగా ఏ jobs ను loop గా మార్చడం విలువైనది?

Machine-readable pass condition మరియు చిన్న blast radius ఉన్న job ను ఎంచుకోండి. Red build ను సరిచేయడం, dependency ను update చేయడం, changelog ను తిరిగి generate చేయడం — ఇవన్నీ సరైనవి. ఎందుకంటే test suite లేదా diff ఫలితాన్ని నిర్ధారించగలవు. Refactoring లేదా design వంటి open-ended work కు ఇంకా ఇది సరిపోదు. వాటిని check చేయడానికి gate ఉండదు. Gate లేని loop review debt ను ఖరీదైన పద్ధతిలో సృష్టిస్తుంది.