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

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

লুপ ইঞ্জিনিয়ারিং হলো একটি 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 অতিক্রম করেছে (July 2026 অনুযায়ী)। এর মূল বক্তব্য: "Stop prompting. Design the loop. Get a score." এটি এই পরিবর্তনকে ছয়টি building block-এ ভাগ করে: scheduling, worktrees, skills, plugins and connectors, sub-agents এবং conversation-এর বাইরে সংরক্ষিত durable memory।

এতে Anthropic-এ Claude Code-এর নেতৃত্বদানকারী Boris Cherny-এর বক্তব্য উদ্ধৃত করা হয়েছে:

আমি আর Claude-কে prompt করি না। Claude-কে prompt করার জন্য আমার loop চলছে।

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

কোনো 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 পেয়ে যাবেন।

ট্রিগার: কোন বিষয় agent চালু করে

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

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-এর গুরুত্ব প্রত্যাশার চেয়ে বেশি। input-এর অপেক্ষায় কোনো agent আটকে গেলে এটি unit-কে অনির্দিষ্টকাল active রাখবে। ফলে timer আর চালু হবে না। journalctl -u agent-loop.service -n 50 দিয়ে একটি run-এর log পড়ুন।

পরিবর্তে cron দিয়ে loop চালালে নিজের overlap guard যোগ করুন। কারণ cron সহজেই দ্বিতীয় কপি চালু করবে:

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

Lock নেওয়া থাকলে flock -n সঙ্গে সঙ্গে status 1 দিয়ে বের হয়। তাই প্রথম run-এর সঙ্গে race না করে দ্বিতীয় run নীরবে বন্ধ হয়ে যায়। এই একই systemd service ও timer setup server-এর যেকোনো দীর্ঘমেয়াদি job-এর ক্ষেত্রে প্রযোজ্য, agent হোক বা না হোক।

সীমারেখা: প্রতিটি run-এর জন্য আলাদা copy দিন

আপনার working tree সম্পাদনা করা কোনো agent আপনার commit না করা কাজ নষ্ট করতে পারে। Git worktree অল্প খরচে এই সমস্যা সমাধান করে: প্রতিটি 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 directory মুছে দেয়, আর git worktree prune যেসব entry-এর directory আর নেই সেগুলো সরিয়ে দেয়। এই পর্যায়ে parallel loop নিরাপদ হয়, কারণ দুটি directory-তে থাকা দুটি branch-এর দুটি agent একে অপরের কাজ overwrite করতে পারে না।

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

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

এটাই 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"

স্ক্রিপ্টে set -euo pipefail বাস্তব কাজ করে। -e না থাকলে ব্যর্থ git fetch উপেক্ষিত হয় এবং run পুরোনো origin/main নিয়ে চলতে থাকে। -u না থাকলে variable name-এর typo একটি empty string-এ expand হয়। তখন cleanup স্পষ্টভাবে ব্যর্থ না হয়ে ভুল path-এ চলে।

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

এমন gate বেছে নিন, যা সঠিকভাবে ব্যর্থ হয়। Empty diff-এও পাস করা test suite loop-কে শেখায় যে কিছু না করাই সাফল্য। দুর্বল test-যুক্ত repository দুর্বল loop তৈরি করে। তাই trending repository-গুলোতে “write the loop”-এর আগে “make the codebase agent-ready” লেখা থাকে। আপনার suite শুধু line-গুলো execute না করে সত্যিই regression ধরতে পারবে কি না জানতে চাইলে mutation testing সেই প্রশ্নের উত্তর দেয়। আর diff পড়তে বলার বদলে পুনরায় চালানো যায় এমন evidence report ফেরত দেয় এমন agent সেই উত্তরকে নিজেরাই যাচাই করার মতো করে তোলে।

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-এর জন্য খরচ করে।

ট্রেন্ডিং repository-গুলো যে pattern নির্ধারণ করেছে

loop-engineering repository-তে production-এর জন্য সাতটি pattern তালিকাভুক্ত আছে। এগুলো manifesto হিসেবে নয়, বরং একটি menu হিসেবে পড়ার মতো। Daily triage। Review comment পর্যবেক্ষণ করে সেগুলোর উত্তর দেওয়া pull-request babysitter। Failed build সংগ্রহ করা continuous-integration sweeper। Dependency sweeper। Changelog-এর খসড়া তৈরি করা। Merge-এর পর cleanup। Issue triage।

এগুলোর সাধারণ বৈশিষ্ট্য হলো, প্রতিটির কাজ সীমিত এবং gate স্পষ্ট। “Failing build ঠিক করুন” — এর pass condition মেশিন পড়তে পারে। “Codebase উন্নত করুন” — এর pass condition নেই। তাই এটি কখনো loop হয় না। এটি schedule-সহ একটি বিশৃঙ্খল কাজে পরিণত হয়।

এগুলোর আরেকটি সাধারণ বৈশিষ্ট্য হলো লিখিত record। উভয় repository conversation-এর বাইরে state নিয়ে 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, example এবং output format অপ্টিমাইজ করে। Loop engineering সেই message-কে ঘিরে থাকা cycle অপ্টিমাইজ করে: run শুরু করার trigger, run চলার sandbox, output গ্রহণ বা প্রত্যাখ্যান করার check, এবং cycle বন্ধ করার budget। Loop-এর ভেতরে এখনও একটি ভালো prompt দরকার। তবে প্রতিদিন prompt-কে প্রধান tuning point হিসেবে বদলাতে হয় না, কারণ gate এবং trigger ফলাফলে বেশি প্রভাব ফেলে।

Agent loop তৈরি করতে কি framework দরকার?

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

Codebase harness কী?

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

বড় bill তৈরি করা থেকে agent loop-কে কীভাবে থামাব?

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

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

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