লুপ ইঞ্জিনিয়ারিং কী? সহজ সংজ্ঞা ও ব্যাখ্যা

লুপ ইঞ্জিনিয়ারিং বলতে কী বোঝায়

লুপ ইঞ্জিনিয়ারিং হলো একটি AI agent যে পুনরাবৃত্ত চক্রে চলে, সেটি নকশা করার পদ্ধতি। এতে নির্ধারণ করা হয় agent-কে কী জাগাবে, এটি কোন কোন জিনিসে কাজ করতে পারবে, এর output কীভাবে যাচাই করা হবে এবং কোন অবস্থায় এটি থামবে। Prompt engineering একটি model-কে পাঠানো একটি message-এর কাঠামো নির্ধারণ করে। Loop engineering এমন একটি process-এর কাঠামো নির্ধারণ করে, যা আপনি ঘুমিয়ে থাকলেও হাজার হাজার message পাঠাতে পারে। কাজের একক prompt থেকে loop-এ স্থানান্তরিত হয়।

সংক্ষেপে, আপনি শুধু instruction লেখা বন্ধ করে একটি control system লেখা শুরু করেন। Agent-এর জন্য এখনও ভালো instruction প্রয়োজন। তবে instruction এখন এমন একটি cycle-এর একটি component, যা schedule অনুযায়ী চলে, আপনার code-এর একটি isolated copy-তে কাজ করে, test-এর মাধ্যমে নিজের result প্রমাণ করে এবং budget শেষ হলে কাজ ছেড়ে দেয়।

2026-এ শব্দটি কেন প্রচলিত হলো

নামটি এখন প্রকাশ্য ব্যবহারে স্থির হচ্ছে। GitHub repository cobusgreyling/loop-engineering প্রথম প্রকাশের দুই মাসের মধ্যে 9,600 stars অতিক্রম করে (জুলাই 2026 অনুযায়ী) এবং 2026-10-27 তারিখে প্রায় 11,600 stars দেখায়। এর tagline ছিল "Stop prompting. Design the loop. Get a score." জুলাই 2026-এ এর README এই পরিবর্তনকে ছয়টি building block-এ ভাগ করেছিল: scheduling, worktrees, skills, plugins and connectors, sub-agents এবং conversation-এর বাইরে সংরক্ষিত durable memory। বর্তমান README-তে আর এই তালিকা নেই (2026-10-27 তারিখে পরীক্ষা করা হয়েছে), তবে loop-এর state এখনও conversation-এর বাইরের একটি file-এ রাখা হয়।

Repository-টি Claude Code-এর নেতৃত্বদানকারী Boris Cherny-কে এর অন্যতম অনুপ্রেরণা হিসেবে উল্লেখ করে। বিভিন্ন প্রতিবেদনে উদ্ধৃত তাঁর বক্তব্যটি হলো:

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

দ্বিতীয় repository AI-Builder-Club/skills-এ প্রায় 1,300 stars রয়েছে (2026-10-27 অনুযায়ী)। এটি দুটি ভূমিকার নাম সরাসরি উল্লেখ করে: একটি "codebase harness", যা কোনো repository-কে agent-এর জন্য test চালানো ও deploy করার উপযোগী এবং নিরাপদ করে; এবং একজন "loop engineer", যিনি এমন workflow তৈরি করেন যা কোনো trigger-এ চালু হয়, কাজ সম্পন্ন করে এবং শেখা বিষয়গুলো একটি shared file-এ লিখে রাখে, যাতে পরবর্তী loop সেগুলো পড়তে পারে।

এই practice কোনো repository-ই উদ্ভাবন করেনি। যারা nightly build, continuous integration-এ linter বা ticket খোলা একটি cron job চালিয়েছেন, তারা ইতিমধ্যেই এর কাঠামো জানেন। নতুন বিষয় হলো, loop-এর ভেতরের worker এখন non-deterministic। ফলে চারপাশের machinery-কে ভিন্নভাবে কাজ করতে হয়।

একটি loop-এর চারটি অংশ

প্রতিটি কার্যকর loop-এ এই চারটি অংশ থাকে। কোনো loop একটি অংশ বাদ দিলে সেটিই রাত 3টায় আপনাকে জাগিয়ে দেবে।

• Trigger। যে event একটি run শুরু করে: timer, webhook, নতুন pull request বা alert।
• Boundary। ওই run চলাকালে agent যে files, credentials ও network-এ পৌঁছাতে পারবে।
• Verification। exit code-সহ একটি check, যা নির্ধারণ করে run-এর output রাখা হবে নাকি বাতিল করা হবে।
• Budget। token, সময় ও অর্থের সীমা, যা run সফল হোক বা না হোক, সেটি শেষ করে।

এই চারটি বিষয়কে প্রশ্ন হিসেবে পড়লে, যে agent-কে চালু রেখে যেতে চলেছেন তার জন্য একটি design review পেয়ে যাবেন।

এজেন্টকে কী জাগিয়ে তোলে: ট্রিগার

একটি timer হলো সবচেয়ে সরল trigger। Linux server-এ এর জন্য cron-এর চেয়ে systemd timer ভালো, কারণ এটি লগ রাখে, আপনার নির্ধারিত নিয়মে retry করে এবং কোনো unit এখনও চলমান থাকলে তার দ্বিতীয় copy শুরু করে না। এই শেষ বৈশিষ্ট্যটি agent loop-এর সবচেয়ে সাধারণ overlap bug দূর করে: একই branch সম্পাদনা করা দুটি run।

প্রথমে agent-এর জন্য আলাদা 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 নয়। কারণ enable-কে --now ছাড়া ব্যবহার করলে এটি শুধু পরবর্তী boot-এর জন্য schedule হয়। TimeoutStartSec=1800-এর গুরুত্ব প্রথম দেখায় যতটা মনে হয়, তার চেয়ে বেশি। একটি Type=oneshot service তার script exit না করা পর্যন্ত starting অবস্থায় গণ্য হয়। systemd oneshot unit-এর জন্য defaultভাবে start timeout বন্ধ রাখে। তাই এই line ছাড়া input-এর অপেক্ষায় আটকে থাকা agent unit-টিকে চিরকাল activating অবস্থায় আটকে রাখে। পরবর্তী প্রতিটি timer tick unit-টিকে এখনও running দেখে এবং কিছুই শুরু করে না। এই line থাকলে systemd 30 মিনিট পরে run বন্ধ করে এবং সেটিকে failed হিসেবে চিহ্নিত করে। কখনও unit-টি default Type=simple-এ পরিবর্তন করলে TimeoutStartSec আর পুরো run-কে cover করে না। তখন run-এর সর্বোচ্চ সময় নির্ধারণ করে RuntimeMaxSec=। 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 ধরে রাখা থাকলে flock -n status 1 দিয়ে সঙ্গে সঙ্গে exit করে। ফলে দ্বিতীয় run প্রথমটির সঙ্গে race না করে নীরবে বন্ধ হয়ে যায়। এই একই systemd service ও timer setup box-এ চলমান যেকোনো দীর্ঘস্থায়ী job-এর ক্ষেত্রেই প্রযোজ্য, সেটি agent হোক বা না হোক।

সীমানা: প্রতিটি রানকে নিজস্ব কপি দিন

আপনার working tree সম্পাদনা করা কোনো agent আপনার commit না-করা কাজ হারিয়ে ফেলতে পারে। Git worktree সাশ্রয়ীভাবে এই সমস্যা সমাধান করে: প্রতিটি রান নিজস্ব 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 সরিয়ে দেয়, তবে শুধু clean worktree সরায়। tree-তে untracked file বা পরিবর্তিত tracked file থাকলে, অথবা submodule থাকলে, --force যোগ না করা পর্যন্ত git অপসারণ করতে অস্বীকার করে। তাই নিচের gate script-টি শুধু যে path-টি রানটি বাতিল করে দেয়, সেটিতেই জোরপূর্বক অপসারণ চালায়। git worktree prune এমন entry পরিষ্কার করে, যার directory আর নেই। এই পর্যায়ে parallel loop নিরাপদ হয়, কারণ আলাদা directory-তে থাকা দুই branch-এর দুই agent একে অপরের কাজ overwrite করতে পারে না।

এই সীমানা credentials-এর ক্ষেত্রেও প্রযোজ্য। unattended অবস্থায় চলা কোনো loop দীর্ঘস্থায়ী token ধরে রাখে, এবং প্রতিটি রানেই কোনো token log, commit বা model context-এ ফাঁস হওয়ার সম্ভাবনা থাকে। token-টির scope শুধু loop যে একটি repository-তে কাজ করে, সেটিতে সীমাবদ্ধ রাখুন। সম্ভব হলে agent-এর নিজস্ব shell যে environment দেখে, সেখান থেকে token দূরে রাখুন। production access দেওয়ার আগে AI agent-এর কাছ থেকে secret দূরে রাখার পদ্ধতি পড়ুন। আরও শক্ত সীমানার জন্য পুরো loop-টি একটি প্রতিটি রান শেষে ধ্বংস করতে পারবেন এমন disposable VM-এ চালান। কোন tool চালাবেন, সেটিও কিছুটা সীমানা নির্ধারণ করে। তাই নিজে কতটা isolation তৈরি করবেন তা ঠিক করার আগে নিজের machine-এ Claude Code-এর সঙ্গে Cowork-এর managed sandbox-এর তুলনা পড়া উপযোগী।

যাচাই: যে gate loop-কে নিরাপদ করে

এটাই loop এবং শুধু command টাইপ করা একটি 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"

set -euo pipefail ওই script-এ বাস্তব কাজ করে। -e না থাকলে ব্যর্থ git fetch উপেক্ষিত হয় এবং run stale origin/main-এর বিরুদ্ধে চলতে থাকে। -u না থাকলে variable name-এর typo একটি empty string-এ expand হয়। তখন cleanup স্পষ্টভাবে ব্যর্থ না হয়ে ভুল path-এর বিরুদ্ধে চলে। শেষ লাইনে ইচ্ছাকৃতভাবে --force নেই। run-এর ফলে tree-তে untracked বা uncommitted file থাকলে git সেটি সরাতে অস্বীকার করে। এরপর -e push-এর পরে error দিয়ে run শেষ করে, কারও commit না করা কাজ নীরবে মুছে ফেলে না।

if ! npm test block-টিই মূল ধারণা। আপনি ইতিমধ্যে যে check-কে বিশ্বাস করেন, যেমন test suite বা type checker, তার exit code নির্ধারণ করে branch push হবে, নাকি ধ্বংস হবে। gate ছাড়া loop এমন কাজ তৈরি করে যা review করার সময় কারও নেই। এটি কোনো কাজ না থাকার চেয়েও খারাপ। gate-সহ loop এমন branch তৈরি করে যা মানব contributor-এর branch-কে যে একই মানদণ্ড পেরোতে হয়, সেটি ইতিমধ্যে পেরিয়েছে। gate green হওয়া agent কতটা code পরিবর্তন করেছে সে সম্পর্কে কিছু বলে না। তাই check-এর সঙ্গে এমন একটি স্থায়ী নির্দেশনা যুক্ত করা উপযোগী, যেমন যে নিয়ম agent-কে কাজ করা সবচেয়ে ছোট পরিবর্তনটি নিতে বাধ্য করে। এতে diff এত ছোট থাকে যে review-এর খরচ কম থাকে।

এমন gate বেছে নিন যা সৎভাবে ব্যর্থ হয়। empty diff-এ যে test suite pass করে, সেটি loop-কে শেখায় যে কিছু না করাই সফলতা। দুর্বল test-সহ repository দুর্বল loop তৈরি করে। তাই জনপ্রিয় repository-গুলোতে "loop লিখুন"-এর আগে "codebase-কে agent-ready করুন" বলা হয়। আপনার suite শুধু line-গুলো execute না করে সত্যিই regression ধরতে পারবে কি না জানতে চাইলে mutation testing সেই প্রশ্নের উত্তর দেয়। আর যে agent আপনাকে diff পড়তে না বলে আবার চালানো যায় এমন evidence report ফেরত দেয় সেই উত্তরকে এমন কিছুতে পরিণত করে যা আপনি নিজেই নিশ্চিত করতে পারেন।

Budget: একটি run কী থামাবে

যে agent অনির্দিষ্টকাল retry করে, তার bill-এরও কোনো সীমা থাকে না। প্রতিটি loop-এর জন্য wall-clock ceiling নির্ধারণ করুন এবং তা TimeoutStartSec দিয়ে enforce করুন; আপনার script-এ retry count রাখুন; provider account-এ spend cap প্রয়োগ করুন। এরপর প্রতিটি run-এর খরচ log করুন, যাতে invoice আসার আগেই loop-এর খরচ বাড়তে শুরু করলে তা বুঝতে পারেন। সবসময় চালু থাকা agent VPS-এর খরচ নিয়ন্ত্রণ accounting-এর দিকটি ব্যাখ্যা করে। turn-এর মধ্যে agent যে context বহন করে তা পরিচালনা করা per-run cost কমানোর সবচেয়ে বড় একক উপায়টি ব্যাখ্যা করে। কারণ কোনো loop প্রতি 30 মিনিটে একই repository আবার পড়লে, প্রতি 30 মিনিটেই তার জন্য খরচ হয়।

খরচের কারণেই সাধারণত একটি দীর্ঘ session-এর চেয়ে loop বেশি কার্যকর। নতুন করে শুরু হওয়া, একটি নির্দিষ্ট ছোট কাজ করা এবং exit করা একটি run তার context ছোট রাখে। 8 ঘণ্টা খোলা থাকা একটি session তার ইতিহাসে আগের প্রতিটি ভুল বহন করে এবং প্রতিটি turn-এ সম্পূর্ণ transcript-এর জন্য খরচ করে।

trending repository-গুলো যে pattern-গুলোকে নিয়মে পরিণত করেছে

loop-engineering repository-তে আটটি production pattern-এর তালিকা আছে (2026-10-27 অনুযায়ী)। এগুলোকে manifesto হিসেবে নয়, বরং একটি menu হিসেবে পড়া বেশি উপযোগী। Daily triage। একটি thin loop, যা GitHub Action হিসেবে চলে এবং কোনো state file রাখে না। একটি pull-request babysitter, যা review comment-এর জন্য অপেক্ষা করে এবং তার উত্তর দেয়। একটি continuous-integration sweeper, যা failed build সংগ্রহ করে। একটি dependency sweeper। একটি changelog drafter। Post-merge cleanup। Issue triage।

এগুলোর মিল হলো, প্রতিটির কাজ সীমিত এবং স্পষ্ট gate রয়েছে। "Fix the failing build"-এর এমন একটি pass condition আছে যা machine পড়তে পারে। "Improve the codebase"-এর এমন pass condition নেই, তাই এটি কখনও loop হয় না। এটি schedule-সহ একটি mess-এ পরিণত হয়।

এগুলোর আরেকটি মিল হলো লিখিত record। উভয় repository state-কে conversation-এর বাইরে repository-এর file-এ পাঠায়: কী চালানো হয়েছে, কী পাওয়া গেছে এবং কী সিদ্ধান্ত নেওয়া হয়েছে। এই file-ই loop-এর memory। এর কারণেই দ্বিতীয় loop প্রথমটির কাজ আবার নতুন করে আবিষ্কার না করে তার ওপর কাজ করতে পারে। এটি পরে agent-এর কাজ audit করারও পদ্ধতি, কারণ run শেষ হওয়ার সঙ্গে সঙ্গে model-এর context আর থাকে না। Live coordination একটি পৃথক channel। একই box-এ চলমান অবস্থায় একটি Claude Code session অন্য একটি session-কে কাজ দিতে পারে। তবে ওই আদান-প্রদানের কোনো কিছুই কোনো session-এর পরে টিকে থাকে না। তাই পরে পড়ে দেখার মতো অংশ হিসেবে file-টি থেকেই যায়।

লুপ যেখানে ব্যর্থ হয়

ব্যর্থতাগুলো সাধারণ, এবং বিভিন্ন team-এ একইভাবে বারবার ঘটে।

• কোনো gate নেই। Output জমতে থাকে, কেউ review করে না, আস্থা নষ্ট হয়, এবং loop বন্ধ করে দেওয়া হয়।
• Overlap। একই branch-এ দুটি run চলে, অথবা একই working tree-তে দুটি agent কাজ করে। এতে conflict তৈরি হয়, যা agent পরে resolve করার চেষ্টা করে।
• নীরব drift। Check ব্যর্থ হওয়ার মতো যথেষ্ট কঠোর নয়, তাই loop সফল হতে থাকে।
• সীমাহীন scope। ব্যস্ত repository-তে প্রতিটি commit-এ trigger হওয়া একটি trigger এক দিনের মধ্যেই খরচের সমস্যায় পরিণত হয়।

প্রতিটির একই সমাধান: job ছোট করুন, check আরও নির্দিষ্ট করুন, এবং run-এর log রাখুন। Pass condition এক বাক্যে বর্ণনা করতে না পারলে job-টি এখনো automated করার জন্য প্রস্তুত নয়।

শব্দভান্ডার না জেনেও শুরু করুন

আপনার কোনো framework দরকার নেই। একটি ছোট always-on Linux server, এমন একটি git repository যার test suite ব্যর্থ হওয়ার কথা থাকলে ব্যর্থ হয়, একটি systemd timer এবং তাতে if থাকা একটি shell script মিলেই একটি সম্পূর্ণ loop তৈরি করে। বেশিরভাগ মানুষের এখান থেকেই শুরু করা উচিত, কারণ কোনো tool বেছে নেওয়ার আগে চালিয়ে দেখলে design-এর প্রশ্নগুলোর উত্তর পাওয়া যায়। একটি loop স্থিতিশীল হয়ে গেলে দ্বিতীয়টি চালু করতে মূলত আরেকটি timer এবং আরেকটি worktree-ই যথেষ্ট। প্রাথমিক setup-এর জন্য VPS-এ coding AI agent কীভাবে চালাবেন দেখুন। আর agent-টিকেই আপনার নিয়ন্ত্রণাধীন hardware-এ চালাতে চাইলে বর্তমান self-hosted AI agent-এর বিকল্পগুলো দেখুন।

FAQ

Loop engineering কি prompt engineering থেকে আলাদা?

Prompt engineering একটি message অপ্টিমাইজ করে: wording, উদাহরণ এবং output format। Loop engineering message-কে ঘিরে থাকা cycle অপ্টিমাইজ করে: যে trigger run শুরু করে, যে sandbox-এ এটি চলে, যে check output গ্রহণ বা প্রত্যাখ্যান করে এবং যে budget cycle শেষ করে। Loop-এর ভেতরে এখনও একটি ভালো prompt প্রয়োজন। তবে প্রতিদিন tune করার মূল বিষয় আর prompt থাকে না, কারণ gate এবং trigger ফলাফলে বেশি প্রভাব ফেলে।

Agent loop তৈরি করতে কি framework প্রয়োজন?

না। একটি systemd timer, প্রতি run-এর জন্য একটি git worktree, test command দিয়ে শেষ হওয়া একটি shell script এবং provider account-এ একটি spend cap—এই সংজ্ঞার প্রতিটি অংশের জন্য যথেষ্ট। একাধিক loop চালানোর সময় framework scheduling interface, shared memory format এবং multi-agent routing যোগ করে, যা উপকারী। তবে প্রথম loop তৈরির জন্য framework বাধ্যতামূলক নয়।

Codebase harness কী?

এটি এমন উপাদানগুলোর সমষ্টি, যা কোনো human উপস্থিত না থাকলেও agent-কে repository-তে কাজ করতে দেয়: one-command setup, non-interactively চলা এবং স্পষ্টভাবে fail করা test, একটি linter এবং change deploy বা preview করার পদ্ধতি। Loop engineering-এর মতো এই term-টিও 2026 সালের একই repository wave থেকে এসেছে। ব্যবহারিক পরীক্ষা সহজ: নতুন কোনো human contributor যদি একটি command দিয়ে clone থেকে green test পর্যন্ত যেতে না পারে, agent-ও পারবে না।

Agent loop-কে বড় bill তৈরি করা থেকে কীভাবে আটকাব?

তিন জায়গায় cap নির্ধারণ করুন। উপরের মতো Type=oneshot systemd unit-এ TimeoutStartSec সেট করুন, যাতে আটকে থাকা run বন্ধ হয়ে যায়। Type=simple service-এ এর সমতুল্য হলো RuntimeMaxSec। Success না হওয়া পর্যন্ত loop না চালিয়ে script-এর ভেতরে retry-এর সর্বোচ্চ সংখ্যা নির্ধারণ করুন। API account-এ একটি hard spend limit সেট করুন, কারণ এটিই একমাত্র ceiling যার সীমা agent যুক্তি দিয়ে অতিক্রম করতে পারে না। এরপর প্রতি run-এর cost লগ করুন। কারণ কোনো loop-এর cost দ্বিগুণ হলে সাধারণত তার scope নীরবে বেড়ে গেছে।

কোন job-গুলোকে প্রথমে loop-এ রূপ দেওয়া উপযুক্ত?

Machine-readable pass condition এবং ছোট blast radius আছে এমন job বেছে নিন। Red build ঠিক করা, dependency update করা এবং changelog পুনরায় তৈরি করা এর মধ্যে পড়ে, কারণ test suite বা diff দিয়ে ফলাফল যাচাই করা যায়। Refactoring বা design-এর মতো open-ended কাজ এখনও উপযুক্ত নয়। কারণ gate যাচাই করার মতো কিছু থাকে না। Gate ছাড়া loop review debt তৈরি করার ব্যয়বহুল পদ্ধতি।