লুপ ইঞ্জিনিয়ারিং।
লেখক: Addy Osmani
সংকলন: পেগি, ব্লকবিটস

সম্পাদকীয় নোট: AI কোডিং এজেন্টের ব্যবহার পদ্ধতি এখন মানুষের হাতে প্রম্পট লেখা এবং ধাপে ধাপে কাজ এগিয়ে নেওয়ার পরিবর্তে, মানুষ লুপ ডিজাইন করছেন যাতে সিস্টেমটি নিয়মিতভাবে এজেন্টগুলি স্কেডিউল করতে পারে। অ্যাডি ওসম্যানির বলা লুপ ইঞ্জিনিয়ারিং-এর মূল বিষয় হলো একটি এমন কাজের প্রবাহ তৈরি করা যা স্বয়ংক্রিয়ভাবে কাজ শনাক্ত করবে, কাজ বণ্টন করবে, ফলাফল পরীক্ষা করবে, অগ্রগতি রেকর্ড করবে এবং পরবর্তী পদক্ষেপ নির্ধারণ করবে।

এই চক্রটি প্রায় পাঁচটি মডিউল দিয়ে গঠিত: Automations (সময়নির্ধারিত আবিষ্কার এবং ট্রায়েজ টাস্ক), Worktrees (একাধিক সমান্তরাল ডেভেলপমেন্ট পরিবেশ বিচ্ছিন্ন করা), Skills (প্রকল্পের জ্ঞান এবং দলের অভ্যাস সঞ্চয় করা), Plugins/Connectors (GitHub, Linear, Slack, ডেটাবেস ইত্যাদি বাস্তব টুলগুলির সাথে সংযোগ), Sub-agents (কর্মকর্তা এবং পরীক্ষককে পৃথক করা), এবং Markdown ফাইল বা Linear বোর্ডের মতো একটি বাহ্যিক মেমোরি স্তর, যা অবস্থা এবং অগ্রগতি সংরক্ষণের জন্য ব্যবহৃত হয়।

লুপ ইঞ্জিনিয়ারিং-এর অর্থ শুধুমাত্র "AI-কে কয়েকবার চালানো" নয়, বরং এটি ইঞ্জিনিয়ারদের বিচারক্ষমতাকে সিস্টেম ডিজাইনের প্রাথমিক পর্যায়ে নিয়ে আসে। লুপগুলি ডেভেলপারদের কাজের লিভারেজকে উল্লেখযোগ্যভাবে বাড়িয়ে তুলতে পারে, কিন্তু এগুলি যাচাই, বুঝতে এবং বিচার করার প্রয়োজনীয়তা প্রতিস্থাপন করে না। প্রকৃত ঝুঁকি লুপ ব্যবহারের মধ্যে নয়, বরং লুপকে কোড এবং সিস্টেমকে বুঝতে এড়িয়ে চলার যুক্তি হিসাবে ব্যবহার করার মধ্যে। AI-এর সাথে প্রোগ্রামিংয়ের ভবিষ্যতের মূল দক্ষতা হয়তো শুধুমাত্র একটি ভালো Prompt লেখা নয়, বরং নির্ভরযোগ্য, যাচাইযোগ্য এবং টেকসইভাবে চলমান Agent-এর কাজের প্রবাহ ডিজাইন করা।

নিচে মূল পাঠ দেওয়া হল:

লুপ ইঞ্জিনিয়ারিং (Loop engineering) আপনাকে একজন “এজেন্টকে প্রম্পট দেওয়ার” ভূমিকা থেকে প্রতিস্থাপন করছে। আপনাকে একটি সিস্টেম ডিজাইন করতে হবে, যেটি আপনার পরিবর্তে এজেন্টকে প্রম্পট দেবে। এখানে লুপ (loop) বলতে একটি পুনরাবৃত্তি লক্ষ্যকে বোঝায়: আপনি একটি উদ্দেশ্য সংজ্ঞায়িত করেন, এবং AI কাজটি সম্পন্ন হওয়া পর্যন্ত ধারাবাহিকভাবে পুনরাবৃত্তি করে। এটি প্রায় পাঁচটি গঠন অংশ দিয়ে গঠিত, এবং Claude Code এবং Codex এখন এই পাঁচটি গঠন অংশই ধারণ করছে।

আমি বিশ্বাস করি, এটিই হয়তো আমাদের ভবিষ্যতে কোডিং এজেন্টগুলির সাথে সহযোগিতা করার পদ্ধতি। তবে, এসব এখনও প্রাথমিক পর্যায়ে, আমি সন্দেহবাদী হয়েই আছি। আপনার অবশ্যই token খরচের প্রতি সতর্ক থাকতে হবে, কারণ বিভিন্ন ব্যবহারের মডেলের উপর ভিত্তি করে খরচের পার্থক্য অত্যন্ত বড় হতে পারে, বিশেষ করে আপনি যদি 'token-সমৃদ্ধ' হন অথবা 'token-সংকীর্ণ'। আপনার আরও কিছু মেকানিজমের প্রয়োজন হবে, যাতে গুণগত মানের পতন না ঘটে। 'AI-জাতীয় কুৎসিত আউটপুট' (slop) নিয়ে উদ্বেগও যুক্তিসঙ্গত। তবুও, চলুন দেখি, এটা বাস্তবে কী।

@steipete সম্প্রতি একটি বাক্য বলেছিলেন: "আপনাকে আর কোডিং এজেন্টগুলিকে প্রম্পট দেওয়া উচিত নয়। আপনাকে কিছু লুপ ডিজাইন করতে হবে, যেগুলি আপনার এজেন্টগুলিকে প্রম্পট দেবে।" একইভাবে, Anthropic-এর Claude Code-এর প্রধান @bcherny বলেছেন: "আমি এখন Claude-কে প্রম্পট দিচ্ছি না। আমার কাছে অনেকগুলি লুপ চলছে, যেগুলি Claude-কে প্রম্পট দেয় এবং নিজেরাই সিদ্ধান্ত নেয় যে পরবর্তীতে কী করা উচিত। আমার কাজ হলো লুপ লিখা।"

তাহলে, এটার মানে কী?

গত প্রায় দুই বছর ধরে, আপনি কোডিং এজেন্টকে কিছু করাতে চাইলে, মূলত একটি ভালো প্রম্পট লিখে যথেষ্ট পরিমাণ প্রেক্ষাপট প্রদান করতেন। আপনি একটি বাক্য লিখতেন, ফলাফলটি পড়তেন, তারপর পরবর্তী বাক্যটি লিখতেন। এজেন্টটি ছিল একটি টুল, এবং আপনি সবসময় সেই টুলটি ধরে রেখেছিলেন, একের পর এক এটিকে এগিয়ে দিচ্ছিলেন। এই পর্যায়টি কিছুটা শেষ হয়েছে, অন্তত কিছু মানুষের মতে এটি শেষ হয়ে যাচ্ছে।

এখন আপনি একটি ছোট সিস্টেম তৈরি করছেন: এটি নিজেই কাজ খুঁজে পাবে, কাজ বণ্টন করবে, ফলাফল পরীক্ষা করবে, সম্পন্নতা রেকর্ড করবে, এবং পরবর্তী পদক্ষেপ কী হওয়া উচিত তা নির্ধারণ করবে। অর্থাৎ, আপনি এই সিস্টেমকে এজেন্টকে চালানোর জন্য ব্যবহার করছেন, এবং নিজেকে বারবার প্রম্পট দেওয়ার পরিবর্তে। আমি আগে এর “প্রতিবেশী” — agent harness engineering (এজেন্ট হারনেস ইঞ্জিনিয়ারিং), যা একটি একক এজেন্টের জন্য রানটাইম পরিবেশ তৈরি করে; এবং factory model (ফ্যাক্টরি মডেল), যা সফটওয়্যার তৈরির সিস্টেম। Loop engineering harness-এর উপরের স্তর। এটি harness-এর মতো, কিন্তু টাইমারের উপর ভিত্তি করে চলে, ছোট সহায়কদের তৈরি করে,এবং নিজেকেই খাওয়ায়।

আমার জন্য আশ্চর্যজনক বিষয় হলো, এখন এটি শুধুমাত্র "টুলস লেভেল" এর সমস্যা নয়। এক বছর আগে, যদি আপনি একটি লুপ চাইতেন, তাহলে আপনাকে অসংখ্য bash স্ক্রিপ্ট লিখতে হতো এবং সেই স্ক্রিপ্টগুলোকে চিরকাল মেইনটেইন করতে হতো। সেগুলো ছিল আপনার নিজস্ব জিনিস, এবং শুধুমাত্র আপনারই। এখন, এই উপাদানগুলো সরাসরি পণ্যের মধ্যে বিল্ট-ইন হয়ে গেছে। স্টেইনবার্গার যেসব ক্ষমতা তালিকাভুক্ত করেছেন, সেগুলো প্রায় প্রতিটি Codex অ্যাপ্লিকেশনের সাথে মিলে যায়, এবং Claude Code-এরও প্রায় একইভাবে। যখন আপনি বুঝতে পারবেন যে এদের আকৃতি একই, তখন আপনি আর কোনটি ব্যবহার করবেন—এই বিষয়ে চিন্তা-ভাবনা করবেন না, বরং একটি লুপ ডিজাইন করবেন: আপনি যেকোনোটির মধ্যে বসুন, এটি চলতেই থাকবে।

পাঁচটি গঠন এবং কিছু ব্যাখ্যা

একটি লুপের জন্য পাঁচটি জিনিস প্রয়োজন, একটি তথ্য সংরক্ষণের জায়গা সহ। আমি প্রথমে তালিকা করছি, তারপর প্রতিটির সাথে মেলানোর চেষ্টা করছি।

প্রথমত, Automations (অটোমেশন টাস্ক): পরিকল্পিতভাবে ট্রিগার হয়, স্বয়ংক্রিয়ভাবে আবিষ্কার এবং বিভাজন করে।

দ্বিতীয়ত, ওয়ার্কট্রিস: দুটি সমান্তরালভাবে কাজ করা এজেন্টকে একে অপরের ফাইলগুলির সাথে সংঘর্ষে পড়তে দেয় না।

তৃতীয়, দক্ষতা (Skills): প্রকল্পের জ্ঞান লিখে রাখুন, যাতে বুদ্ধিমান এজেন্ট প্রতিবার অনুমান করতে না পারে।

চতুর্থ, প্লাগইন এবং কানেক্টর: স্মার্ট এজেন্টকে আপনি যে টুলগুলি ইতিমধ্যে ব্যবহার করছেন তার সাথে যুক্ত করুন।

পঞ্চম, সাব-এজেন্টস (সাব-অ্যাজেন্ট): একটি পরিকল্পনা প্রস্তাব করার জন্য দায়ী, অন্যটি পরিকল্পনা পরীক্ষা করার জন্য দায়ী।

এবং ষষ্ঠ জিনিসটি: মেমোরি (স্মৃতি)। এটি একটি মার্কডাউন ফাইল হতে পারে, একটি লিনিয়ার বোর্ড হতে পারে, অথবা যেকোনো স্বাধীন জায়গা যা একক কথোপকথনের বাইরে “সম্পন্ন কাজ” এবং “পরবর্তী পদক্ষেপ” সংরক্ষণ করে। এটি মনে হতে পারে যেন গুরুত্বপূর্ণ নয়, কিন্তু এটিই প্রতিটি দীর্ঘস্থায়ী বুদ্ধিমত্তা দ্বারা ব্যবহৃত একই কৌশল। আমি long-running agents-এও বিস্তারিতভাবে লিখেছি: মডেল প্রতিবার চলার মধ্যে ভুলে যায়, তাই মেমোরি কনটেক্সটের বদলে ডিস্কের উপরে রাখা দরকার। বুদ্ধিমত্তা ভুলে যাবে, কিন্তু কোড রিপোজিটরি ভুলবে না।

এখন, দুটি পণ্যই এই পাঁচটি গঠন অংশ সহ রয়েছে।

এদের নামকরণ কিছুটা ভিন্ন, কিন্তু ক্ষমতাগুলি মূলত একই। নিচে আমি একে একে ব্যাখ্যা করছি, কারণ সত্যি বলতে কি, একটি লুপ চূড়ান্তভাবে স্থিতিশীলভাবে চলছে নাকি চুপচাপ বিভিন্ন জায়গায় পানি ফুঁড়ে দিচ্ছে, সেটা বিস্তারিতেই নির্ভর করে।

অটোমেশন হল সেই জিনিস যা লুপকে শুধুমাত্র আপনার একবার হাতে চালানো একটি একক কাজ থেকে সত্যিকারের লুপে পরিণত করে। Codex অ্যাপে, আপনি অটোমেশন ট্যাবে একটি অটোমেশন তৈরি করতে পারেন, প্রজেক্টটি নির্বাচন করুন, এটি কী প্রম্পট চালাবে, এটি কতবার চলবে, এবং এটি আপনার লোকাল চেকআউটে চলবে নাকি ব্যাকগ্রাউন্ড worktree-এ। সমস্যা শনাক্তকৃত রানগুলি Triage inbox-এ চলে যায়, আর সমস্যা না পাওয়া রানগুলি স্বয়ংক্রিয়ভাবে আর্কাইভ হয়ে যায়, যা খুবই ভালো। OpenAI-এর অভ্যন্তরেও এটি দৈনিক issue分流, CI-এর ব্যর্থতার কারণগুলির সারসংক্ষেপ, commit summary-এর জন্য, এবং গতসপ্তাহে কেউ যোগ করা bug-এর ট্র্যাকিংয়ের মতো枯燥但必要的কাজগুলির জন্য ব্যবহার করা হয়। অটোমেশনগুলি skill-কেও invoke করতে পারে, তাই আপনি repetitive tasks-কে maintainableভাবে রাখতে পারেন: $skill-name-কে triggerকরুন, ১টি plan-এর মধ্যে ১টি wall of text-কে pasteকরবেন না, যা ১দিনেরও বেশি time-এ updateহবেনা।

Claude Code একই ফলাফল অর্জন করে, কিন্তু পথ ভিন্ন: এটি স্কেডিউলিং এবং hooks এর মাধ্যমে এটি করে। আপনি /loop ব্যবহার করে নির্দিষ্ট ব্যবধানে একটি প্রম্পট বা কমান্ড চালাতে পারেন, অথবা একটি cron টাস্ক সেট করতে পারেন, অথবা স্মার্ট এজেন্টের জীবনচক্রের কিছু নোডে hooks ব্যবহার করে shell কমান্ড ট্রিগার করতে পারেন। যদি আপনি চান যে এটি আপনার ল্যাপটপ বন্ধ করার পরও চলতে থাকুক, তাহলে সমগ্র সিস্টেমটিকে GitHub Actions-এর উপরে পুশ করুন। ধারণাটি সম্পূর্ণভাবে একই: আপনি একটি স্বয়ংসম্পূর্ণ টাস্ক সংজ্ঞায়িত করেন, এটিকে একটি গতি দেন, এবং ফলাফলগুলি আপনার কাছে আসতে দেন, যাতে আপনাকে সবকিছুর জন্য ঘুরেবেড়াতে হয়না।

একটি আরও গুরুত্বপূর্ণ সেশন-ভিত্তিক প্রিমিটিভ রয়েছে যা এই নিবন্ধের প্রকৃত আলোচ্য বিষয়ের সাথে আরও কাছাকাছি। /loop হল একটি নির্দিষ্ট গতিতে পুনরাবৃত্তি হয়; /goal তখন পর্যন্ত চলতে থাকে যতক্ষণ না আপনি যে শর্তটি লিখেছেন তা প্রকৃতপক্ষে পূরণ হয়। প্রতিটি চক্রের পরে, একটি আলাদা ছোট মডেল দ্বারা নির্ধারণ করা হয় যে কাজটি সম্পন্ন হয়েছে কিনা, তাই কোড লেখা এজেন্টটি নিজেকেই স্কোর দেয় না। আপনি একটি শর্ত দিতে পারেন, যেমন: “test/auth-এর সমস্ত টেস্ট পাস হয়েছে, এবং lint-এর কোনো ত্রুটি নেই,” এবং তারপরে চলে যাবেন। Codex-এও একই ক্ষমতা রয়েছে, যা /goal-এর নামেই। এটি চক্রগুলির মধ্যে কাজ করতে থাকবে, যতক্ষণ না একটি verifiable-স্টপিং-শর্টসহীয়াতা (যাচাইযোগ্য-বন্ধ-শর্ত)পূরণহয়,এবংপজ,পুনরায়শুরুএবংপরিষ্কারকরারসমর্থনকরে।একইপ্রিমিটিভ,দুটিইটুলে।এটিইহলপুনঃপুনঃআবির্ভূতপ্যাটার্ন।

সুতরাং, অটোমেশনগুলি কাজগুলিকে উপরে আনার দায়িত্ব বহন করে। লুপের বাকি অংশগুলি এই কাজগুলি প্রক্রিয়াকরণের দায়িত্ব বহন করে।

যখন আপনি একাধিক এজেন্ট চালান, তখন ফাইল সংঘাত ব্যর্থতার কারণ হয়ে দাঁড়ায়। দুটি এজেন্ট একই ফাইলে একসাথে লিখলে, এটি মূলত দুইজন ইঞ্জিনিয়ারের মধ্যে যে সমস্যা হয়, যারা একে অপরের সাথে যোগাযোগ না করে একই লাইনের কোড পরিবর্তন করছে। git worktree এই সমস্যার সমাধান করে। এটি একটি স্বতন্ত্র শাখায় একটি আলাদা কাজের ডিরেক্টরি, কিন্তু একই কোড রিপোজিটরির ইতিহাসকে শেয়ার করে, তাই একটি এজেন্টের পরিবর্তনগুলি ভৌতভাবে অন্য এজেন্টের checkout-এর সাথে সংঘর্ষে পড়বে না।

কোডেক সরাসরি ওয়ার্কট্রি সমর্থন অন্তর্ভুক্ত করে, তাই একাধিক থ্রেড একই রিপোজিটরি একসাথে প্রক্রিয়া করতে পারে বিভ্রান্তি ছাড়া। ক্লাউড কোডও git worktree ব্যবহার করে একই পৃথকীকরণ অর্জন করতে পারে: আপনি --worktree ফ্ল্যাগ ব্যবহার করে একটি স্বতন্ত্র চেকআউটে একটি সেশন খুলতে পারেন, অথবা subagent-এ isolation: worktree সেট করতে পারেন, যাতে প্রতিটি সাব-অ্যাজেন্ট একটি নতুন চেকআউট পায় এবং শেষে স্বয়ংক্রিয়ভাবে পরিষ্কার হয়। আমি the orchestration tax-এ এই বিষয়টির মানবিক দিকটি লিখেছি: worktrees যন্ত্রগত সংঘাতকে দূর করে, কিন্তু আপনি এখনও সীমাবদ্ধ। আপনি একসাথে কতগুলি ইন্টেলিজেন্ট অ্যাজেন্ট চালাতে পারবেন, তা নির্ধারণ করে না টুলগুলি, বরং আপনার review bandwidth (পর্যালোচনা ব্যান্ডউইথ)।

স্কিল হল একটি মেকানিজম যা আপনাকে প্রতিবার সেশনে একই প্রজেক্টের কনটেক্সট আবার আবার ব্যাখ্যা করতে দেয় না। দুটি টুলই একই ফরম্যাট ব্যবহার করে: একটি ফোল্ডার, যার ভিতরে একটি SKILL.md ফাইল থাকে যা বর্ণনা এবং মেটাডেটা সংরক্ষণ করে; এছাড়াও ঐচ্ছিক স্ক্রিপ্ট, রেফারেন্স এবং রিসোর্স ফাইল থাকতে পারে। Codex আপনি $ বা /skills ব্যবহার করলে একটি skill চালায়, এবং আপনার টাস্কটি সেই skill-এর বর্ণনা মেলে তখনও অটোমেটিকভাবে চালায়। এইজন্যই একটি সংক্ষিপ্ত, সরল বর্ণনা, প্রায়শই একটি চতুর, ঝলমলে বর্ণনার চেয়ে ভালো। Claude Code-ও একইভাবে কাজ করে, আমি agent skills-এর মধ্যে এই প্যাটার্নটি লিখেছি।

দক্ষতা হল সেই জিনিস যা ইচ্ছাকে আবার আবার আপনার শক্তি খরচ করতে দেয় না। আমি intent debt-এ বলেছি, প্রতিটি সেশনের শুরুতে এজেন্টটি কুল স্টার্ট হয়, আপনার ইচ্ছায় যদি কোনো ফাঁক থাকে, তাহলে এটি সেই ফাঁকগুলি আত্মবিশ্বাসের সাথে অনুমান করে পূরণ করবে। দক্ষতা হল এই ইচ্ছাগুলিকে বাইরে লিখে রাখা: প্রকল্পের চুক্তি, বিল্ডিং ধাপগুলি, “আমরা এটি এখনও করি না কারণ আগে এই দুর্ঘটনাটি ঘটেছিল” — এগুলি সবই একবারের জন্য একটি জায়গায় লিখে রাখা, যেখানে প্রতিবার এজেন্টটি চলার সময় পড়বে। দক্ষতা ছাড়া, loop-এর প্রতিটি চক্রেই আপনার সম্পূর্ণ প্রকল্পটি শূন্য থেকে আবার উপসংহারে পৌঁছাতে হবে; দক্ষতা থাকলে, এটি ঠিক যেন চক্রবৃদ্ধির মতো।

একটি বিষয় পরিষ্কার করা দরকার: skill হল ফরম্যাটিং লেখা, আর plugin হল বিতরণের পদ্ধতি। যখন আপনি একাধিক কোড রিপোজিটরির মধ্যে একটি skill শেয়ার করতে চান বা কয়েকটি skill একসাথে প্যাকেজ করতে চান, তখন আপনি তাদের একটি plugin-এ প্যাকেজ করেন। Codex-এও এভাবে, Claude Code-এও এভাবে।

একটি ফাইল সিস্টেম দেখার জন্য মাত্র একটি ছোট লুপ। Connectors MCP-এর উপর ভিত্তি করে তৈরি, যা স্মার্ট এজেন্টকে আপনার ইস্যু ট্র্যাকার পড়তে, ডাটাবেস কুয়েরি করতে, staging API কল করতে বা Slack-এ মেসেজ পাঠাতে সক্ষম করে। Codex এবং Claude Code উভয়ই MCP সমর্থন করে, তাই আপনি যদি একটির জন্য connector লিখেন, তবে সাধারণত অন্যটিতেও এটি ব্যবহার করা যায়। Plugins connectors এবং skills-কে একসাথে প্যাকেজ করে, যাতে আপনার টিমমেটরা সমস্ত কিছু মনে করে পুনরায় গঠন না করেই একবারেই সম্পূর্ণ কনফিগারেশন ইনস্টল করতে পারে।

এটি হলো “একটি এজেন্ট আপনাকে বলছে ‘এটি ঠিক করার উপায়’” এবং “একটি লুপ নিজেই PR খুলে, Linear ticket সংযুক্ত করে, এবং CI সফল হলে চ্যানেলে নোটিফিকেশন পাঠায়”-এর মধ্যে পার্থক্য। Connectors-এর গুরুত্ব হলো এটি লুপকে আপনার বাস্তব পরিবেশে কাজ করতে দেয়, শুধু এটি বলে না যে “যদি আমি করতে পারতাম, আমি এটি করতাম”।

একটি লুপের মধ্যে, সবচেয়ে কার্যকরী কাঠামোগত ডিজাইন হল লেখক এবং পরীক্ষককে আলাদা করা। কোড লেখার মডেলটি নিজের অ্যাসাইনমেন্টকে মূল্যায়ন করার সময় খুব সহজেই অত্যধিক উদার হয়ে পড়ে। একটি ভিন্ন নির্দেশনা সহ, কখনও কখনও ভিন্ন মডেল ব্যবহার করে এমন একটি বুদ্ধিমত্তা, প্রথম বুদ্ধিমত্তার দ্বারা উপেক্ষিত সমস্যাগুলি ধরতে পারে।

কোডেক শুধুমাত্র আপনি যখন চাইবেন, তখনই সাবএজেন্ট তৈরি করবে, যেগুলি সমান্তরালে চলবে এবং ফলাফলগুলি একটি উত্তরে একত্রিত করবে। আপনি .codex/agents/ এ TOML ফাইল ব্যবহার করে নিজের এজেন্টগুলি সংজ্ঞায়িত করতে পারেন: প্রতিটি এজেন্টের নাম, বর্ণনা, নির্দেশাবলী এবং ঐচ্ছিক মডেল এবং যুক্তিগত শক্তি থাকবে। অতএব, আপনার সুরক্ষা পরীক্ষক হতে পারে একটি উচ্চ যুক্তিগত শক্তির শক্তিশালী মডেল, আর আপনার অনুসন্ধানকারী হতে পারে একটি দ্রুত, শুধু-পড়ার হালকা মডেল। Claude Code-ও .claude/agents/ এর মধ্যে সাবএজেন্ট এবং এজেন্ট টিমসের মাধ্যমে এই সমান ক্ষমতা প্রদান করে, যাতে একাধিক এজেন্ট পরস্পরের মধ্যে কাজ হস্তান্তর করতে পারে। উভয়েরই সবচেয়ে সাধারণভাবে বিভাজন: একটি এজেন্ট অনুসন্ধান করে, একটি এজেন্ট বাস্তবায়ন করে, এবং একটি এজেন্ট স্পেসিফিকেশনঅনুযায়ী যাচাই করে।

আমি এই মতামতটি দুইবার ব্যাখ্যা করেছি: একবার code agent orchestra-এ এবং আরেকবার adversarial code review-এ। এটি loop-এ বিশেষভাবে গুরুত্বপূর্ণ, কারণ loop তখনই চলে যেখানে আপনি দেখছেন না, তাই আপনি যে বিশ্বস্ত verifier (যাচাইকারী) পেয়েছেন, সেটিই হল আপনার চলে যাওয়ার একমাত্র কারণ। Subagents প্রতিটি agent-এর নিজস্ব মডেল কল এবং টুল কলের কারণে আরও বেশি token খরচ করে, তাই আপনাকে শুধুমাত্র সেই জায়গাগুলিতে ব্যবহার করা উচিত যেখানে "দ্বিতীয় মতামতের জন্য প্রিমিয়াম দেওয়ার মূল্য" আছে। এটিই Claude Code-এর /goal-এর নীচের স্তরের কাজ: loop-এর শেষ হয়েছে কিনা তা কাজটি করা agent-এর পরিবর্তে একটি নতুন মডেল দ্বারা নির্ধারণ। অর্থাৎ, it applies the separation of "maker" and "checker" directly to the stopping condition itself.

একটি লুপ কী দেখতে হয়

এই জিনিসগুলো একসাথে জোড়া লাগালে, একটি একক থ্রেড একটি ছোট কন্ট্রোল প্যানেলে পরিণত হয়। নিচে আমি যে কাঠামোটি প্রায়শই ব্যবহার করি।

প্রতিদিন সকালে, একটি অটোমেশন কোড রিপোজিটরিতে চলে। এর প্রম্পট একটি ট্রায়েজ স্কিল কল করে, যেটি গতকালের CI ব্যর্থতা, খোলা ইসুগুলি এবং সাম্প্রতিক কমিটগুলি পড়ে এবং ফাইলের মধ্যে একটি মার্কডাউন ফাইল বা Linear বোর্ডে আবিষ্কারগুলি লিখে। প্রতিটি প্রক্রিয়াকরণযোগ্য সমস্যার জন্য, থ্রেডটি একটি আইসোলেটেড ওয়ার্কট্রি খোলে, একটি সাব-এজেন্টকে প্রতিকারের প্রস্তাব তৈরির জন্য পাঠায়, এবং পরবর্তীতে দ্বিতীয় সাব-এজেন্টকে প্রজেক্টের স্কিলস এবং বিদ্যমান টেস্টগুলির ভিত্তিতে এই প্রস্তাবটি পরীক্ষা করার জন্য পাঠায়।

কানেক্টরগুলি এই লুপকে নিজেই PR খুলতে এবং টিকেট আপডেট করতে সক্ষম করে। যা কিছু লুপ পরিচালনা করতে পারবে না, তা ট্রায়েজ ইনবক্সে চলে যায়, যেখানে আমি এটি পরিচালনা করি। স্ট্যাটাস ফাইলটি সম্পূর্ণ সিস্টেমের কাঁকড়া: এটি কী চেষ্টা করা হয়েছে, কী সফল হয়েছে এবং কী এখনও অসম্পূর্ণ রয়েছে তা মনে রাখে। তাই, পরবর্তী দিনের সকালের রানটি আজকের থামানোর জায়গা থেকেই চলতে থাকে।

আপনি যা করেছেন তা বুঝুন। আপনি শুধু একটি ডিজাইন করেছেন। সেই ধাপগুলি আপনি নিজে একে একে প্রম্পট দেননি। এটাই স্টেইনবার্গারের বাক্যের বাস্তব সংস্করণ। এবং একই loop কোডেক্সেও চলতে পারে, ক্লাউড কোডেও চলতে পারে, কারণ উপাদানগুলি নিজেই একই।

লুপ এখনও আপনার জন্য কিছু করবে না

লুপ এর কাজের পদ্ধতি পরিবর্তন হয়েছে, কিন্তু এটি আপনাকে কাজ থেকে বাদ দেয় না। বাস্তবে, লুপ শক্তিশালী হওয়ার সাথে সাথে, তিনটি সমস্যা আরও তীব্র হয়ে উঠেছে, সহজ হয়নি।

যাচাই এখনও তোমার উপর নির্ভর করে। একটি অনুপস্থিত ভাবে চলমান লুপ হয়তো অনুপস্থিতভাবেই ভুল করছে। তুমি verifier sub-agent এবং maker কে আলাদা করেছ, যাতে লুপটি "সম্পন্ন" বলার কিছুটা অর্থ থাকে। তবুও, "সম্পন্ন" হলো একটি দাবি, একটি প্রমাণ নয়। AI-এর যুগে code review-এ আমি একই বাক্যটি বারবার পুনরাবৃত্তি করছি: তোমার দায়িত্ব হলো তুমি যে কোডটি কার্যকর বলে নিশ্চিত করেছ, সেটি প্রদান করা।

আপনি যদি এটিকে নিজের হাতে ছেড়ে দেন, তাহলে আপনার নিজের বোঝাপড়াও ধীরে ধীরে ক্ষয়ে যাবে। যত দ্রুত লুপ আপনার নিজের লেখা নয় এমন কোড প্রদান করে, আপনার বাস্তব বোঝাপড়া এবং সিস্টেমে বাস্তবে বিদ্যমান জিনিসের মধ্যে পার্থক্য তত বেড়ে যায়। এটিই comprehension debt (বোঝাপড়ার ঋণ)। যদি আপনি লুপের উৎপাদিত জিনিসগুলি পড়েন না, তাহলে একটি সুসংগঠিত লুপ শুধুমাত্র এই ঋণকে আরও দ্রুত বাড়িয়ে তুলবে।

এবং হ্যাঁ, সবচেয়ে স্বাচ্ছন্দ্যপূর্ণ অবস্থানটিই সম্ভবত সবচেয়ে বিপজ্জনক অবস্থান। যখন লুপটি নিজেই চলতে পারে, তখন তোমার নিজের বিচার গঠন বন্ধ করে দেওয়া সহজ, এবং এটি যা কিছুই ফিরিয়ে দেয়, তা শুধুমাত্র গ্রহণ করা। আমি এটিকে কগনিটিভ সারেন্ডার (cognitive surrender) বলি। যদি তুমি বিচারশক্তি নিয়ে লুপটি ডিজাইন করো, তবে এটি ঔষধ; যদি তুমি চিন্তা এড়ানোর জন্যই লুপটি ডিজাইন করো, তবে এটি ত্বরণকারী। একই কাজ, সম্পূর্ণ বিপরীত ফলাফল আনতে পারে।

লুপ তৈরি করুন, কিন্তু এখনও ইঞ্জিনিয়ার হয়ে থাকুন

আমি মনে করি, এটি আমাদের ভবিষ্যতের কাজের বিকাশের দিকনির্দেশ করে। তবুও, যদি আমি নিজে কোডটি পরীক্ষা না করি বা সম্পূর্ণরূপে অটোমেশন লুপের উপর নির্ভর করি কোড ঠিক করার জন্য, তাহলে আমার পণ্যের মান ক্ষতিগ্রস্ত হবে। আমি একটি নিচের দিকের স্পাইরালে পড়ে যাওয়ার সম্ভাবনা রাখি: নিজেকে আরও গভীরে খনন করতে থাকা।

সুতরাং, আপনি নিশ্চিতভাবে আপনার নিজস্ব লুপ তৈরি করতে পারেন, কিন্তু মনে রাখবেন যে সরাসরি আপনার স্মার্ট এজেন্টকে প্রম্পট দেওয়াও কার্যকর। কী হলো সঠিক ভারসাম্য খুঁজে পাওয়া।

লুপের ফলাফল প্রত্যেকের জন্য ভিন্ন হবে। দুজন মানুষ সম্পূর্ণ একই লুপ তৈরি করতে পারে, কিন্তু সম্পূর্ণ বিপরীত ফলাফল পেতে পারে। একজন এটি ব্যবহার করে তার গভীরভাবে বুঝতে পারা কাজে গতি বাড়াতে; অন্যজন এটি ব্যবহার করে কাজটি বুঝতেই এড়িয়ে চলতে। লুপ এই দুটির মধ্যের পার্থক্য জানে না। তুমি জানো।

এটাই কারণ যে লুপ ডিজাইন প্রম্পট ইঞ্জিনিয়ারিংয়ের চেয়ে সহজ নয়, বরং কঠিন। চারনির অর্থ এই নয় যে কাজটি সহজ হয়ে গেছে, বরং লিভারেজ পয়েন্টটি সরে গেছে।

লুপ তৈরি করুন। কিন্তু শুধু শুরু বাটন চাপার দায়িত্ব বহন করে নয়, একজন যিনি এখনও ইঞ্জিনিয়ার হতে চান তার মতো এটি তৈরি করুন।

[原文链接]

লিউডং ব্লকবিটসে চাকরির জন্য ক্লিক করুন

লিউডোং ব্লকবিটসের অফিসিয়াল সম্প্রদায়ে যোগ দিন:

টেলিগ্রাম সাবস্ক্রিপশন গ্রুপ：https://t.me/theblockbeats

টেলিগ্রাম কমিউনিটি: https://t.me/BlockBeats_App

টুইটার অফিসিয়াল অ্যাকাউন্ট:https://twitter.com/BlockBeatsAsia