Loop engineering क्या है? सरल परिभाषा और अर्थ

Loop engineering का अर्थ

Loop engineering उस repeating cycle को design करने की प्रक्रिया है जिसमें एक AI agent चलता है: उसे क्या जगाता है, वह किन चीजों को access कर सकता है, उसके output की जाँच कैसे होती है, और क्या चीज़ उसे रोकती है। Prompt engineering एक model के लिए एक message को तैयार करती है। Loop engineering उस process को आकार देती है जो आपके सोते समय हजारों messages भेजती है। काम की इकाई prompt से हटकर loop पर आ जाती है।

संक्षेप में: आप निर्देश लिखना बंद करते हैं और एक control system लिखना शुरू करते हैं। Agent को अभी भी अच्छे निर्देशों की आवश्यकता होती है, लेकिन वे एक ऐसे cycle का हिस्सा बन जाते हैं जो एक schedule पर चलता है, आपके code की एक isolated copy में काम करता है, test के माध्यम से अपने परिणाम को सिद्ध करता है, और budget खत्म होने पर रुक जाता है।

यह शब्द 2026 में क्यों सामने आया

इसका नाम अभी सार्वजनिक रूप से तय किया जा रहा है। GitHub रिपॉजिटरी cobusgreyling/loop-engineering ने पहली बार सामने आने के दो महीनों के भीतर (जुलाई 2026 तक) 9,600 स्टार्स पार कर लिए थे और 2026-10-27 तक इस पर लगभग 11,600 स्टार्स थे, जो "Stop prompting. Design the loop. Get a score." पंक्ति के अंतर्गत थे। जुलाई 2026 में इसके README ने इस बदलाव को छह बिल्डिंग ब्लॉक्स में वर्गीकृत किया था: शेड्यूलिंग, वर्कट्रीज़, स्किल्स, प्लगइन्स और कनेक्टर्स, सब-एजेंट्स, और बातचीत से बाहर रखी गई ड्यूरेबल मेमोरी। वर्तमान README में अब वह सूची नहीं है (2026-10-27 को जाँचा गया), लेकिन यह अभी भी लूप की स्थिति को बातचीत से बाहर एक फाइल में रखता है।

यह रिपॉजिटरी Anthropic में Claude Code का नेतृत्व करने वाले Boris Cherny को अपनी प्रेरणाओं में से एक मानती है। उनकी व्यापक रूप से चर्चित पंक्ति है:

मैं अब Claude को प्रॉम्प्ट नहीं देता। मेरे पास ऐसे लूप चल रहे हैं जो Claude को प्रॉम्प्ट करते हैं।

एक दूसरी रिपॉजिटरी, AI-Builder-Club/skills, 1,300 स्टार्स के करीब है (2026-10-27 तक) और दो भूमिकाओं का सीधे नाम लेती है: एक "कोडबेस हार्नेस" जो एक रिपॉजिटरी को एजेंट के लिए टेस्ट चलाने और डिप्लॉय करने हेतु सुरक्षित बनाता है, और एक "लूप इंजीनियर" जो ऐसे वर्कफ़्लो बनाता है जो ट्रिगर पर सक्रिय होते हैं, काम करते हैं, और जो सीखा उसे एक साझा फाइल में लिखते हैं ताकि अगला लूप उसे पढ़ सके।

किसी भी रिपॉजिटरी ने इस अभ्यास का आविष्कार नहीं किया है। जिस किसी ने भी नाइटली बिल्ड, कंटीन्यूअस इंटीग्रेशन में लिंटर, या क्रॉन जॉब चलाई है जो टिकट खोलती है, वह पहले से ही इसके स्वरूप को जानता है। नया यह है कि लूप के अंदर का वर्कर अब नॉन-डिटरमिनिस्टिक है, जो यह बदल देता है कि आसपास की मशीनरी को क्या करना है।

लूप के चार भाग

हर कार्यशील लूप में ये चार भाग होते हैं, और जो लूप इनमें से किसी एक को भी छोड़ देता है, वही लूप आपको रात के 3 बजे जगाता है।

• Trigger. वह घटना जो रन (run) को शुरू करती है: एक टाइमर, एक webhook, एक नया pull request, या एक alert।
• Boundary. वे files, credentials और network जिन तक agent उस रन के दौरान पहुँच सकता है।
• Verification. एक exit code के साथ की गई जाँच जो यह तय करती है कि रन के आउटपुट को रखा जाए या हटा दिया जाए।
• Budget. token, समय और पैसे की वह सीमा जो रन के सफल होने या न होने पर भी उसे समाप्त कर देती है।

इन चारों को प्रश्नों के रूप में पढ़ें, और आपके पास किसी भी ऐसे agent के लिए डिज़ाइन रिव्यू तैयार है जिसे आप चलने के लिए छोड़ने वाले हैं।

Trigger: एजेंट को क्या सक्रिय करता है

एक timer सबसे सरल trigger है, और Linux सर्वर पर systemd timer इसके लिए cron से बेहतर है क्योंकि यह logs रखता है, आपकी शर्तों पर retry करता है, और यह उस unit की दूसरी copy शुरू नहीं करेगा जो पहले से चल रही है। यह अंतिम विशेषता एजेंट loops में सबसे आम overlap bug को हटा देती है: दो runs का एक ही branch को edit करना।

सबसे पहले एजेंट को अपना user दें। वह user boundary का हिस्सा है, इसलिए वह केवल /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 पर 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 जो countdown कर रहा हो। खाली परिणाम का मतलब है कि timer enabled नहीं है, क्योंकि --now के बिना enable इसे केवल अगले boot के लिए schedule करता है। TimeoutStartSec=1800 दिखने से कहीं अधिक महत्वपूर्ण है। एक Type=oneshot service तब तक starting मानी जाती है जब तक कि उसकी script exit न हो जाए, और systemd डिफ़ॉल्ट रूप से oneshot units के लिए start timeout को बंद कर देता है, इसलिए इस line के बिना इनपुट की प्रतीक्षा में लटका हुआ एजेंट unit को हमेशा के लिए activating state में फंसा देता है, और हर बाद की timer tick उसे अभी भी चलते हुए पाती है और कुछ भी शुरू नहीं करती है। इस line के होने पर, systemd 30 मिनट के बाद run को समाप्त कर देता है और उसे failed चिह्नित करता है। यदि आप कभी unit को डिफ़ॉल्ट Type=simple में बदलते हैं, तो TimeoutStartSec अब run को कवर नहीं करता है, और RuntimeMaxSec= वह setting है जो इसे सीमित करती है। journalctl -u agent-loop.service -n 50 के साथ run को पढ़ें।

यदि आप इसके बजाय cron से loop चलाते हैं, तो अपना खुद का 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 पहले वाली के साथ race करने के बजाय चुपचाप गायब हो जाती है। वही systemd service and timer setup बॉक्स पर किसी भी long-running job पर लागू होता है, चाहे वह एजेंट हो या न हो।

सीमा: प्रत्येक रन को अपनी अलग कॉपी दें

जो एजेंट आपके वर्किंग ट्री में बदलाव करता है, वह आपके अनकमिटेड (uncommitted) काम को खो सकता है। Git worktrees इस समस्या का सस्ता समाधान हैं: प्रत्येक रन को अपनी अलग डायरेक्टरी और अपनी अलग ब्रांच मिलती है, जबकि वे एक ही ऑब्जेक्ट स्टोर साझा करते हैं।

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

git worktree list प्रत्येक ट्री के लिए उसके पाथ, कमिट और ब्रांच के साथ एक लाइन प्रिंट करता है। जब रन समाप्त होता है, तो git worktree remove /srv/agent/work/triage-01 वर्कट्री को हटा देता है, लेकिन केवल तभी जब वह क्लीन हो। यदि ट्री में अनट्रैक्ड फाइलें या मॉडिफाई की गई ट्रैक्ड फाइलें हैं, या इसमें सबमॉड्यूल शामिल हैं, तो git तब तक मना कर देता है जब तक आप --force न जोड़ें। यही कारण है कि नीचे दी गई गेट स्क्रिप्ट केवल उसी पाथ पर रिमूवल को फोर्स करती है जो रन को डिस्कर्ड करता है। git worktree prune उन एंट्रीज को क्लियर करता है जिनकी डायरेक्टरी गायब हो गई है। इस बिंदु पर पैरेलल लूप सुरक्षित हो जाते हैं, क्योंकि दो अलग-अलग डायरेक्टरी में दो अलग-अलग ब्रांच पर काम कर रहे दो एजेंट एक-दूसरे के काम को ओवरराइट नहीं कर सकते।

यह सीमा क्रेडेंशियल्स के बारे में भी है। जो लूप बिना निगरानी के चलता है, वह लंबे समय तक चलने वाले टोकन रखता है, और हर रन में किसी लॉग, कमिट या मॉडल कॉन्टेक्स्ट में टोकन लीक होने की संभावना रहती है। टोकन को केवल उसी रिपॉजिटरी तक सीमित रखें जिसे लूप एक्सेस करता है। जहाँ संभव हो, इसे एजेंट के अपने शेल एनवायरनमेंट से दूर रखें, और लूप को प्रोडक्शन एक्सेस देने से पहले AI एजेंटों से सीक्रेट्स को कैसे सुरक्षित रखें पढ़ें। अधिक मजबूत सुरक्षा के लिए, पूरे लूप को एक डिस्पोजेबल VM पर रखें जिसे आप प्रत्येक रन के बाद नष्ट कर सकें। आप कौन सा टूल चलाते हैं, यह भी कोड लिखने से पहले सीमा का एक हिस्सा तय करता है, इसलिए यह तय करने से पहले कि आपको खुद कितनी आइसोलेशन बनाने की आवश्यकता है, Cowork का मैनेज्ड सैंडबॉक्स आपकी अपनी मशीन पर Claude Code की तुलना में कैसा है पढ़ना उचित है।

सत्यापन: वह गेट जो लूप को सुरक्षित बनाता है

यह वह हिस्सा है जो एक लूप को टाइप करने वाले क्रॉन जॉब (cron job) से अलग करता है। एजेंट का आउटपुट एक प्रस्ताव होता है। गेट निर्णय लेता है।

#!/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 उस स्क्रिप्ट में वास्तविक काम कर रहा है। -e के बिना, एक विफल git fetch को अनदेखा कर दिया जाता है और रन एक पुराने origin/main पर जारी रहता है। -u के बिना, वेरिएबल नाम में टाइपो एक खाली स्ट्रिंग में बदल जाता है, और फिर क्लीनअप विफल होने के बजाय गलत पाथ पर चलता है। अंतिम पंक्ति में जानबूझकर कोई --force नहीं है: यदि रन ने ट्री में अनट्रैक्ड या अनकमिटेड फाइलें छोड़ दी हैं, तो git इसे हटाने से इनकार कर देता है, और -e पुश के बाद रन को त्रुटि के साथ समाप्त कर देता है, बजाय इसके कि बिना किसी को बताए काम को डिलीट कर दिया जाए।

if ! npm test ब्लॉक ही पूरी अवधारणा है। जिस चेक पर आप पहले से भरोसा करते हैं, उसका एग्जिट कोड—चाहे वह आपकी टेस्ट सुइट हो या टाइप चेकर—यह तय करता है कि ब्रांच को पुश किया जाए या नष्ट। बिना गेट वाला लूप ऐसा काम पैदा करता है जिसे रिव्यू करने का समय किसी के पास नहीं होता, जो कि काम न होने से भी बदतर है। गेट वाला लूप एक ऐसी ब्रांच बनाता है जो पहले ही उस मानक को पार कर चुकी है जिसे एक मानवीय योगदानकर्ता की ब्रांच को पार करना होता है। एक ग्रीन गेट इस बारे में कुछ नहीं कहता कि वहां तक पहुंचने के लिए एजेंट ने कितना कोड बदला है, इसलिए चेक को उस नियम के साथ जोड़ना उचित है जो एजेंट को सबसे छोटा काम करने के लिए प्रेरित करता है, जिससे डिफ (diff) इतना छोटा रहता है कि उसे रिव्यू करना सस्ता बना रहता है।

ऐसा गेट चुनें जो ईमानदारी से विफल हो। एक टेस्ट सुइट जो खाली डिफ पर पास हो जाता है, वह लूप को यह सिखाता है कि कुछ न करना ही सफलता है। कमजोर टेस्ट वाले रिपॉजिटरी में कमजोर लूप होते हैं, यही कारण है कि ट्रेंडिंग रिपॉजिटरी "लूप लिखने" से पहले "कोडबेस को एजेंट-रेडी बनाने" पर जोर देते हैं। यदि आप यह जानना चाहते हैं कि क्या आपका सुइट वास्तव में लाइनों को निष्पादित करने के बजाय रिग्रेशन को पकड़ेगा, तो म्यूटेशन टेस्टिंग वह चेक है जो इसका उत्तर देती है, और एक ऐसा एजेंट जो आपसे डिफ पढ़ने के लिए कहने के बजाय एक पुनः चलाने योग्य साक्ष्य रिपोर्ट देता है उस उत्तर को ऐसी चीज में बदल देता है जिसे आप स्वयं पुष्टि कर सकते हैं।

बजट: रन को क्या रोकता है

जो एजेंट हमेशा retry करता रहता है, उसका बिल असीमित हो सकता है। हर लूप के लिए एक समय सीमा (wall-clock ceiling) तय करें, जिसे ऊपर दिए गए TimeoutStartSec द्वारा लागू किया जाए; अपनी स्क्रिप्ट के भीतर एक retry count रखें; और provider account के माध्यम से खर्च की एक सीमा (spend cap) निर्धारित करें। इसके बाद हर रन की लागत को log करें, ताकि invoice आने से पहले ही आप लूप में होने वाली वृद्धि को देख सकें। हमेशा चालू रहने वाले एजेंट VPS के लिए लागत नियंत्रण लेखांकन (accounting) पक्ष को कवर करता है, और एजेंट द्वारा टर्न के बीच ले जाए जाने वाले कॉन्टेक्स्ट का प्रबंधन प्रति-रन लागत को नियंत्रित करने का सबसे बड़ा तरीका है, क्योंकि जो लूप हर 30 मिनट में एक ही repository को फिर से पढ़ता है, वह हर बार उसके लिए भुगतान करता है।

लागत ही वह कारण है जिसकी वजह से लूप आमतौर पर एक लंबे सत्र (long session) से बेहतर होते हैं। एक रन जो नए सिरे से शुरू होता है, एक छोटा काम करता है और बंद हो जाता है, वह अपने कॉन्टेक्स्ट को सीमित रखता है। आठ घंटे तक खुला रहने वाला सत्र अपने इतिहास की हर पिछली गलती को साथ लेकर चलता है, और हर टर्न पर पूरे transcript के लिए भुगतान करता है।

Trending repositories द्वारा कोडिफाई किए गए पैटर्न

loop-engineering रिपॉजिटरी आठ प्रोडक्शन पैटर्न (2026-10-27 तक) सूचीबद्ध करती है, और इन्हें एक घोषणापत्र के बजाय एक मेनू के रूप में पढ़ना सार्थक है। दैनिक ट्राइएज (Daily triage)। एक पतला लूप जो GitHub Action के रूप में चलता है और कोई state file नहीं रखता। एक pull-request बेबीसिटर जो review comments पर नज़र रखता है और उनका उत्तर देता है। एक continuous-integration स्वीपर जो red builds को उठाता है। एक dependency स्वीपर। एक changelog ड्राफ्टर। Post-merge क्लीनअप। Issue ट्राइएज।

इनमें जो समानता है, वह है एक स्पष्ट गेट (gate) के साथ एक सीमित कार्य। "Fix the failing build" में एक पास कंडीशन होती है जिसे मशीन पढ़ सकती है। "Improve the codebase" में ऐसा नहीं होता, इसलिए यह कभी लूप नहीं बनता। यह एक शेड्यूल के साथ अव्यवस्था बन जाता है।

इनमें एक लिखित रिकॉर्ड भी साझा होता है। दोनों रिपॉजिटरी स्टेट को बातचीत से बाहर निकालकर रिपॉजिटरी की फाइलों में डालती हैं: क्या चला, क्या मिला, और क्या निर्णय लिया गया। वह फाइल लूप की मेमोरी है, और यही कारण है कि एक दूसरा लूप पहले लूप के काम को फिर से खोजने के बजाय उस पर निर्माण कर सकता है। इसी तरह आप किसी एजेंट का बाद में ऑडिट भी कर सकते हैं, क्योंकि रन समाप्त होते ही मॉडल का कॉन्टेक्स्ट खत्म हो जाता है। लाइव कोऑर्डिनेशन एक अलग चैनल है, और एक Claude Code सेशन उसी बॉक्स पर दूसरे को काम सौंप सकता है जबकि दोनों चल रहे हों, लेकिन उस आदान-प्रदान में कुछ भी किसी भी सेशन से अधिक समय तक जीवित नहीं रहता, इसलिए फाइल ही वह हिस्सा रहती है जिसे आप बाद में दोबारा पढ़ते हैं।

जहाँ लूप विफल होते हैं

विफलताएँ उबाऊ होती हैं और वे सभी टीमों में बार-बार दोहराई जाती हैं।

• कोई गेट नहीं। आउटपुट जमा होता रहता है, कोई इसकी समीक्षा नहीं करता, भरोसा खत्म हो जाता है और लूप को बंद कर दिया जाता है।
• ओवरलैप। एक ही ब्रांच पर दो रन, या एक ही वर्किंग ट्री में दो एजेंट, ऐसे संघर्ष (conflicts) पैदा करते हैं जिन्हें एजेंट फिर हल करने की कोशिश करता है।
• साइलेंट ड्रिफ्ट। लूप पास होता रहता है क्योंकि चेक इतना कमजोर है कि वह विफल नहीं हो पाता।
• असीमित दायरा। एक व्यस्त रिपॉजिटरी में हर कमिट पर चलने वाला ट्रिगर एक दिन के भीतर खर्च की समस्या बन जाता है।

हर समस्या का एक ही समाधान है: जॉब को छोटा करें, चेक को सटीक बनाएँ और रन को लॉग करें। यदि आप पास होने की शर्त को एक वाक्य में वर्णित नहीं कर सकते, तो वह जॉब ऑटोमेशन के लिए तैयार नहीं है।

शब्दावली के बिना शुरुआत करना

आपको किसी framework की आवश्यकता नहीं है। एक छोटा always-on Linux सर्वर, एक git repository जिसका test suite विफल होने पर विफल हो जाता है, एक systemd timer और एक shell script जिसमें if हो, एक पूर्ण लूप बनाते हैं। वास्तव में अधिकांश लोगों को यहीं से शुरुआत करनी चाहिए, क्योंकि डिज़ाइन संबंधी प्रश्नों के उत्तर किसी टूल को चुनने के बजाय उसे चलाने से मिलते हैं। एक बार जब एक लूप स्थिर हो जाता है, तो दूसरा लूप चलाना मुख्य रूप से एक और timer और एक और worktree का मामला होता है। बेस सेटअप के लिए VPS पर कोडिंग AI एजेंट कैसे चलाएं देखें, और यदि आप चाहते हैं कि एजेंट स्वयं आपके द्वारा नियंत्रित हार्डवेयर पर चले, तो वर्तमान self-hosted AI एजेंट विकल्प देखें।

FAQ

क्या loop engineering और prompt engineering अलग हैं?

Prompt engineering एक संदेश को अनुकूलित (optimize) करती है: शब्द, उदाहरण और आउटपुट का प्रारूप। Loop engineering उस संदेश के इर्द-गिर्द के चक्र को अनुकूलित करती है: वह ट्रिगर जो रन शुरू करता है, वह सैंडबॉक्स जिसमें यह चलता है, वह जाँच जो आउटपुट को स्वीकार या अस्वीकार करती है, और वह बजट जो इसे समाप्त करता है। आपको अभी भी लूप के अंदर एक अच्छे प्रॉम्प्ट की आवश्यकता होती है। प्रॉम्प्ट वह चीज नहीं रह जाता जिसे आप दिन-प्रतिदिन ट्यून करते हैं, क्योंकि गेट और ट्रिगर का परिणाम पर अधिक प्रभाव पड़ता है।

क्या मुझे एजेंट लूप बनाने के लिए किसी फ्रेमवर्क की आवश्यकता है?

नहीं। एक systemd timer, प्रति रन एक git worktree, एक शेल स्क्रिप्ट जो एक टेस्ट कमांड के साथ समाप्त होती है, और प्रोवाइडर अकाउंट पर खर्च की सीमा (spend cap) परिभाषा के हर हिस्से को कवर करती है। फ्रेमवर्क शेड्यूलिंग इंटरफेस, साझा मेमोरी प्रारूप और मल्टी-एजेंट रूटिंग जोड़ते हैं, जो तब उपयोगी होते हैं जब आप कई लूप चलाते हैं। वे पहले लूप के लिए प्रवेश शुल्क नहीं हैं।

codebase harness क्या है?

यह उन चीजों का समूह है जो एक एजेंट को बिना किसी इंसान की उपस्थिति के रिपॉजिटरी में काम करने देता है: एक-कमांड सेटअप, ऐसे टेस्ट जो नॉन-इंटरैक्टिव रूप से चलते हैं और विफल होने पर स्पष्ट संकेत देते हैं, एक लिनटर, और बदलाव को डिप्लॉय या प्रीव्यू करने का एक तरीका। यह शब्द 2026 की रिपॉजिटरी की उसी लहर से आया है जिससे loop engineering आई है। व्यावहारिक परीक्षण सरल है: यदि कोई नया मानव योगदानकर्ता एक कमांड के साथ क्लोन से ग्रीन टेस्ट तक नहीं पहुँच सकता है, तो एक एजेंट भी नहीं पहुँच सकता।

मैं एजेंट लूप को बड़ा बिल बनाने से कैसे रोकूँ?

इसे तीन जगहों पर सीमित करें। ऊपर दिए गए जैसे Type=oneshot systemd unit पर TimeoutStartSec सेट करें ताकि एक हैंग हुआ रन समाप्त हो जाए (Type=simple सर्विस पर इसका समकक्ष RuntimeMaxSec है)। सफलता तक लूप चलाने के बजाय स्क्रिप्ट के अंदर ही रिट्राय (retries) को सीमित करें। API अकाउंट पर खर्च की एक सख्त सीमा निर्धारित करें, क्योंकि यह एकमात्र ऐसी सीमा है जिसे एजेंट पार नहीं कर सकता। फिर प्रति-रन लागत को लॉग करें, क्योंकि जिस लूप की लागत दोगुनी हो जाती है, उसका दायरा आमतौर पर चुपचाप बढ़ गया होता है।

किन कार्यों को सबसे पहले लूप में बदलना सार्थक है?

ऐसा कार्य चुनें जिसमें मशीन-पठनीय पास स्थिति (pass condition) हो और जिसका प्रभाव क्षेत्र (blast radius) छोटा हो। रेड बिल्ड को ठीक करना, डिपेंडेंसी अपडेट करना और चेंजलॉग को फिर से जनरेट करना सभी इसके लिए उपयुक्त हैं, क्योंकि एक टेस्ट सुइट या डिफ (diff) परिणाम को साबित कर सकता है। रिफैक्टरिंग या डिज़ाइन जैसा ओपन-एंडेड काम अभी इसके लिए उपयुक्त नहीं है, क्योंकि गेट के पास जाँचने के लिए कुछ नहीं होता है, और बिना गेट वाला लूप रिव्यू डेट (review debt) उत्पन्न करने का एक महंगा तरीका है।