Meta যখন এই সপ্তাহে Muse Code চালু করল, শিরোনামে ছিল প্রতিযোগিতামূলক অবস্থান নির্ধারণ: ডেভেলপারদের কর্মপ্রবাহ দখলের লড়াইয়ে Claude Code, Codex এবং Cursor-এর সঙ্গে যোগ দেওয়া আরেকটি টার্মিনাল-ভিত্তিক কোডিং এজেন্ট। কিন্তু Mark Zuckerberg-এর নিজের টুল-বর্ণনার মধ্যে লুকিয়ে আছে তাদের জন্য আরও আকর্ষণীয় একটি সংকেত, যারা জীবিকা হিসেবে কোড লেখেন বা পর্যালোচনা করেন।
“কোনো কাজ যথেষ্ট বড় হলে, সেটি বিচ্ছিন্ন worktree-তে সমান্তরালভাবে কাজ করা আলাদা sub-agent-দের মধ্যে ছড়িয়ে পড়ে,” Muse Code-এর বড় কাজ মোকাবিলার পদ্ধতি বর্ণনা করতে Zuckerberg লিখেছেন। “আপনার working copy-তে কখনো হাত দেওয়া হয় না। পরীক্ষায় আমরা কোনো সংঘর্ষ ছাড়াই একটি গেমের ছয়টি ফিচার একসঙ্গে তৈরি করিয়েছিলাম।”
এটি কোনো ফিচারের বর্ণনা নয়। এটি একটি কাজের বর্ণনা — আপনার জন্য।
“বিচ্ছিন্ন worktree” আসলে কী বোঝায়
একটি git worktree একই repository-এর একাধিক branch একসঙ্গে আলাদা directory-তে checkout করতে দেয়, ফলে একটি checkout অন্যটির কাজে বাধা না দিয়ে কাজের একাধিক ধারা এগিয়ে যেতে পারে। Meta-র বর্ণনা অনুযায়ী, Muse Code এই ব্যবস্থাই ব্যবহার করে একাধিক sub-agent-কে একই সময়ে কোড লেখাতে, আপনার সক্রিয় working copy বা একে অন্যের ফাইলে হাত না দিয়েই। এটি একটি যুক্তিসঙ্গত engineering সিদ্ধান্ত: file-level সংঘর্ষই বহু-agent দ্বন্দ্বের সবচেয়ে সহজে যান্ত্রিকভাবে প্রতিরোধযোগ্য ধরন, তাই সেগুলো যান্ত্রিকভাবেই ঠেকিয়ে model-কে প্রকৃত coding-এর দিকে মনোযোগ দেওয়ার সুযোগ দেওয়া হয়।
যে শব্দটি লক্ষ্য করার মতো, তা হলো “fans out।” একজন human developer ছয়টি parallel worktree-কে এমন ছয়টি code stream হিসেবে দেখেন না, যেগুলো একটির পর একটি হাতে পরীক্ষা করতে হবে — বরং ছয়টি stream প্রায় একই সময়ে তার ডেস্কে এসে পড়ে, এবং প্রতিটির জন্য একটি সিদ্ধান্ত দরকার: এটি কি যুক্ত হবে, পুনরায় কাজ করা দরকার কি না, অথবা অন্য কোনো worktree-তে sibling agent সদ্য যা করেছে তার সঙ্গে এর সংঘর্ষ হচ্ছে কি না।
যে দক্ষতাটি আসলে বদলে যাচ্ছে
গত কয়েক বছর ধরে AI-সহায়িত coding-এর প্রধান মডেল ছিল কথোপকথনমূলক এবং একক: একজন developer, একজন assistant, একটি back-and-forth thread, যা তৈরি হওয়ার প্রায় real time-এই পর্যালোচনা করা হয়। সেই দক্ষতা — ভালোভাবে prompt করা, মুহূর্তেই খারাপ পরামর্শ ধরে ফেলা, বারবার পরিমার্জন করা — এখনও প্রয়োজনীয়। কিন্তু Muse Code-এর নকশা যে দক্ষতাকে সর্বোত্তম করার চেষ্টা করছে, সেটি তা নয়। Sub-agent-দের মধ্যে কাজ ছড়িয়ে দেওয়া ধরে নেয় যে আপনি ইতিমধ্যেই কাজের অন্য একটি পদ্ধতিতে চলে গেছেন: শুরুতেই একটি কাজকে স্বাধীনভাবে চলতে পারে এমন অংশে ভাগ করা, তারপর একজন agent-কে ধাপে ধাপে পরিচালনা করার বদলে একসঙ্গে একাধিক agent-এর শেষ করা (বা আংশিক শেষ করা) output পর্যালোচনা করা।
এটি chatbot-এর সঙ্গে split-screen-এ pair programming করার চেয়ে sprint-কে একটি ছোট দলের মধ্যে ভাগ করে দেওয়া tech lead হওয়ার কাছাকাছি। পৃথক coding সিদ্ধান্তগুলোর চেয়ে decomposition (আপনি কি কাজটি সত্যিই স্বাধীন অংশের ভিত্তিতে ভাগ করেছেন?) এবং review pass (ছয়টি parallel diff প্রত্যেকটি আলাদাভাবে সঠিক এবং সম্মিলিতভাবে সঙ্গতিপূর্ণ কি না, তা কি আপনি দ্রুত বুঝতে পারেন?) বেশি গুরুত্বপূর্ণ।
Isolation সংঘর্ষ সমাধান করে, সামঞ্জস্য নয়
বিষয়টি নিয়ে একটু ভাবা দরকার, কারণ এটি সহজেই চোখ এড়িয়ে যায়: বিচ্ছিন্ন worktree দুটি agent-কে একই ফাইল overwrite করা থেকে আটকায়। কিন্তু দুটি agent-কে স্বাধীনভাবে একই কাজ করার দুটি ভিন্ন পদ্ধতি উদ্ভাবন করা থেকে আটকায় না — যেমন দ্বিতীয় একটি date-formatting helper, দ্বিতীয় একটি retry wrapper, বা একই API route-এর duplicate — কারণ কোনো agent-ই দেখতে পায়নি অন্যজন কী তৈরি করছে। Git isolation হলো file-system-এর নিশ্চয়তা, design-এর নিশ্চয়তা নয়। যে reviewer ছয়টি worktree আবার একত্র করেন, তিনিই একমাত্র checkpoint যেখানে duplicate abstraction, অসঙ্গত naming convention, অথবা ভিন্ন data shape ধরে নেওয়া দুটি feature ধরা পড়ে। parallel output-এর পরিমাণ যদি মনোযোগ দিয়ে পড়ার ক্ষমতাকে ছাড়িয়ে যায় এবং সেই reviewer যদি diff-গুলো কেবল চোখ বুলিয়ে দেখেন, তাহলে এটাই সেই ধরনের বিচ্যুতি যা শেষ পর্যন্ত production-এ চলে যায়।
Fan-out tool স্বাভাবিক হয়ে গেলে “code review” বলতে কী বোঝাবে, তা এটি নতুনভাবে ভাবতে বাধ্য করে: কোনো একটি diff-এর line-by-line inspection কম (agent-এর syntax সাধারণত ঠিকই থাকে), আর cross-diff reconciliation বেশি — AI-উৎপাদিত কাজের parallel stream-গুলো shared convention, shared data model এবং shared error handling নিয়ে একে অপরের সঙ্গে একমত কি না, তা পরীক্ষা করা।
আসলে যে দিকে এগোনো উচিত
এর কোনোটির জন্যই বিশেষভাবে Muse Code দরকার নেই — একই fan-out pattern প্রধান coding agent-গুলোর মধ্যেই দেখা যাচ্ছে, যা ইঙ্গিত করে এটি এক vendor-এর ওপর নির্ভর করা বাজি নয়, বরং default architecture হয়ে উঠছে। আপনি যে tool-ই ব্যবহার করুন না কেন, এখন থেকেই অনুশীলন করার মতো কয়েকটি বাস্তব বিষয় হলো:
- যে task spec পরিষ্কারভাবে ভাগ করা যায়, তা লিখুন। Parallel কাজ চাইবার আগে নিজেকে জিজ্ঞেস করুন, অংশগুলো সত্যিই স্বাধীন কি না — তারা কি একই file, একই shared constant, একই API contract-এ হাত দিচ্ছে? যদি হ্যাঁ হয়, তাহলে এটি ছয়টি parallel agent-এর কাজ নয়; এটি একজন agent-এর sequential-ভাবে কাজ করার, অথবা আগে shared অংশগুলো আপনি নিজে আলাদা করে দেওয়ার কাজ।
- diff point-এ নয়, merge point-এ review করার অনুশীলন করুন। পাশাপাশি একাধিক শেষ করা branch টেনে এনে “এগুলো কি একে অপরের সঙ্গে সামঞ্জস্যপূর্ণ?” জিজ্ঞেস করতে অভ্যস্ত হন, শুধু “প্রতিটি আলাদাভাবে সঠিক কি না?” নয়।
- আপনার git worktree-এর মৌলিক বিষয়গুলো জানুন। আপনি যে tool-গুলো ব্যবহার করেন, সেগুলো যদি তাদের অভ্যন্তরীণ ব্যবস্থা এভাবে ব্যাখ্যা করতে শুরু করে, তাহলে worktree কী নিশ্চয়তা দেয় এবং কী দেয় না, তা বোঝা output-কে বিশ্বাস করা — অথবা সঠিক কারণে অবিশ্বাস করা — উভয়ের জন্যই ন্যূনতম প্রয়োজনীয় জ্ঞান।
- shared জিনিসগুলোর ownership স্পষ্টভাবে নির্ধারণ করুন। Constants, schema, shared utility, naming convention। Fan-out শুরু হওয়ার আগে এগুলোর যত বেশি নির্দিষ্ট করে দেবেন, পরে reconciliation-এর কাজ তত কম হবে।
Muse Code-এর মতো tool থেকে সবচেয়ে বেশি সুবিধা পাবেন তারা নয়, যারা সবচেয়ে ভালো prompt করেন। বরং তারা, যারা নীরবে একটি ছোট, দ্রুতগতির, মাঝে মাঝে এলোমেলো দলের নেতৃত্ব দিতে দক্ষ হয়ে উঠেছেন — এমনকি সেই দলের প্রতিটি সদস্যই যখন একটি model।
