ডেভঅপ্স অগ্রগামী সতর্ক করে: এআই এজেন্ট গ্রহণের জন্য শুধুমাত্র টুলস নয়, সিস্টেম-লেভেলের পরিবর্তন প্রয়োজন

এজেন্ট দ্বারা উত্পাদিত কোড আর ঠিক করবেন না, সেই কোড উত্পাদনকারী সিস্টেমটি ঠিক করুন।

লেখক, উৎস: InfoQ

যদি একজন ডেভেলপার কোনোভাবেই এজেন্ট ব্যবহার করতে পারে না, তাহলে সমস্যাটি ডেভেলপারের নয়, বরং কোম্পানিটি এজেন্টের জন্য কাজ করার মতো কোনো সিস্টেম তৈরি করেনি।

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

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

ডিবয়েসের মতে, এটি সফটওয়্যার ইঞ্জিনিয়ারিংয়ের নির্ধারণমূলক সিস্টেম থেকে অনির্ধারণমূলক, সম্ভাব্যতামূলক সিস্টেম এবং ওয়ার্কফ্লোতে রূপান্তরের অপরিহার্য পরিণতি। এটি শুধুমাত্র প্রযুক্তি নয়, বরং ডেভেলপারদের, দলগুলির এবং সমগ্র সংগঠনের কাজের পদ্ধতিকেও পুনঃগঠন করবে। কিন্তু এই পরিবর্তনটি শুধুমাত্র একজন ইঞ্জিনিয়ারের দ্বারা বা একটি দলের মধ্যেই সীমাবদ্ধ থাকতে পারে না। এটি DevOps-এর মতো, শুধুমাত্র স্কেল করে বাস্তবায়নের পরই এটি প্রকৃতপক্ষে সফল হবে।

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

নিম্নলিখিত মূল বিষয়গুলি:

• এজেন্ট দ্বারা উত্পাদিত কোড আর ঠিক করবেন না, সেই কোড উত্পাদনকারী সিস্টেমটি ঠিক করুন।
• যদি আপনার দলের কেউ এখনও “YOLO” পদ্ধতিতে ভাইব কোডিং করে থাকে, আপনাকে তাৎক্ষণিকভাবে এটি বন্ধ করতে হবে। ইঞ্জিনিয়ারিং প্র্যাকটিস শুধুমাত্র আপনার সিস্টেম বজায় রাখার জন্যই নয়, বরং এজেন্টের নিজের ধারাবাহিক উন্নতির জন্যও অত্যন্ত গুরুত্বপূর্ণ।
• অন্ধকার ফ্যাক্টরি সম্পূর্ণ অন্ধকার নাও হতে পারে, বরং এটি কিছুটা মৃদু আলো রাখতে পারে (dim factory), যার অর্থ আপনাকে নির্ধারণ করতে হবে কোন ফাংশনের জন্য কতটা ঝুঁকি নিতে হবে, সমস্ত ফাংশনই সম্পূর্ণ স্বয়ংক্রিয় হওয়ার জন্য উপযুক্ত নয়।
• যে ব্যক্তি AI কে চরম পর্যায়ে ব্যবহার করতে পারে, শক্তিশালী ইঞ্জিনিয়ারিং দক্ষতা রাখে এবং শেয়ার ও সহযোগিতার প্রতি ইচ্ছুক, তিনিই আপনার খোঁজের মানুষ।
• আপনার প্রতিযোগিতামূলক সুবিধা হল সেই জ্ঞানকে ধরে রাখা, যে জ্ঞানগুলি আপনি এখন skill-এ, Context-এ, এমনকি Harness সীমাবদ্ধতাগুলিতেও প্রবেশ করিয়েছেন।

২০০৯ সালে, অনেকেই আমাকে বলেছিল যে কন্টিনিউয়াস ডেলিভারির ধারণাটি পাগলামি।

2009 সালে, শিল্পটি সাধারণত কয়েক মাস পর একবার বড় সংস্করণ চালু করার পদ্ধতি অনুসরণ করত, এবং সবাই ধরে নিয়েছিল যে প্রকাশের সংখ্যা যত বেশি হবে, ঝুঁকি তত বেশি হবে। এছাড়াও, ডেভেলপমেন্ট এবং অপারেশনের মধ্যে কঠোর বাধা ছিল, কন্টেইনার এবং ক্লাউডের মতো অটোমেশন ইনফ্রাস্ট্রাকচার এখনও পরিপক্ক হয়নি, এবং স্ট্যান্ডার্ডাইজড পাইপলাইন টুলগুলির অভাব ছিল। একইসময়ে, প্রচলিত টেস্টিং এবং পরিবর্তন অনুমোদন প্রক্রিয়াগুলি চালুর আগে সম্ভবত সমস্ত ত্রুটি দূর করার উপর জোর দিত, যখন কন্টিনিউয়াস ডেলিভারি উচ্চ頻率, ধাপে ধাপে, যেকোনো সময় চালুযোগ্য ধারণাটি প্রস্তাব করে, যা সফটওয়্যার চালুর ঝুঁকি, প্রক্রিয়া নিয়ন্ত্রণের সম্পূর্ণ প্রচলিত ধারণাকেই বিপর্যস্ত করেছিল। ফলস্বরূপ, বেশিরভাগ প্রতিষ্ঠানের কাছে, it seemed almost like a fantasy or madness.

এবং এখন, ডার্ক ফ্যাক্টরি আবার একই ধরনের প্রতিবন্ধকতার সম্মুখীন হয়েছে।

টিপ্পণি: অ্যাড ফ্যাক্টরি বলতে এআই-চালিত স্বায়ত্তশাসিত সফটওয়্যার উৎপাদন পদ্ধতিকে বোঝায়, যেখানে মানুষ শুধুমাত্র SPEC প্রবেশ করায়, এআই স্বয়ংক্রিয়ভাবে কোডিং, পরীক্ষা এবং লঞ্চ সম্পন্ন করে, যার ফলে মানুষের কোডের প্রতিটি লাইন পরীক্ষা করার প্রয়োজন হয় না, যা এখনও বহু ইঞ্জিনিয়ারের সহায়তা প্রয়োজন করে এমন প্রচলিত সফটওয়্যার ফ্যাক্টরির থেকে ভিন্ন।

আমি বিভিন্ন প্রসঙ্গে একই বাক্যটি বারবার শুনেছি: “এটি আমাদের এখানে কাজ করে না।” কিন্তু এই বাক্যটির প্রকৃত বার্তা হল প্রযুক্তির অক্ষমতা নয়, বরং “আমাদের এখনও প্রস্তুতি হয়নি।” তারা এটি বাস্তবায়ন করতে চায় না এমন নয়, বরং এখনও সংগঠনের সমগ্র কাঠামো এই মডেলকে সমর্থন করতে পারছে না।

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

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

আমি অনুমান করি আপনাদের মধ্যে বেশিরভাগই কোনো দলের সদস্য হিসেবে কাজ করেন, একা কাজ করেন না, দলগত সহযোগিতা এবং একা Claude Code-এর সাথে টাইপ করা পুরোপুরি ভিন্ন বিষয়।

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

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

পরে একটি ধারণা আবির্ভূত হয় যা নাম পেয়েছে “Context engineering” — এটি ডেভেলপারদের জন্য একটি সহায়ক পথ হিসেবে কাজ করে। এটি বলে যে, এটি শুধুমাত্র Prompt কল করার বিষয় নয়; আপনাকে Prompt-এর পরীক্ষা, মূল্যায়ন, বিতরণ এবং অপ্টিমাইজেশনও করতে হবে, তাই এটিতে সত্যিই কিছুটা ইঞ্জিনিয়ারিংয়ের স্বাদ রয়েছে। কিন্তু সত্যি বলতে কি, অনেক ডেভেলপার এখনও শুধুমাত্র Prompt এবং SPEC-এর সাথেই কাজ করার অনুভূতি করেন, এবং নিজেদেরকে “প্রম্পট অ্যাডমিন”-এ পরিণত হওয়ার অনুভূতি করেন।

কিন্তু আমি বাস্তবায়নে একটি আকর্ষণীয় মোড় লক্ষ্য করেছি। যখন আমরা হারনেস, লুপ এবং সম্পূর্ণ সংগঠনকে আরও উচ্চতর স্বায়ত্তশাসনের দিকে নিয়ে যাওয়া শুরু করি, তখন একটি সম্পূর্ণ নতুন প্রযুক্তিগত পথ খুলে যায়। হঠাৎ করে, ডেভেলপারদেরকে Agent-এর জন্য টুল তৈরি করতে হয়, এবং এটি অনেকের মধ্যে আবারও উত্তেজনা জাগিয়ে তোলে। যারা আগে ভাবত “এটা আমার কাজ নয়”, তারা এখনই উৎসাহিত হয়ে ওঠে। তারা বলে, হ্যাঁ, আমরা এটা করতে পারি! আমরা এই জ্ঞানটি অধিকার করেছি! আমরা প্রোগ্রামিংয়ের মাধ্যমে এই সিস্টেমকে আরও ভালোভাবে গড়ে তুলতে পারি। তাই, যখন আমরা “অ্যাবস্ট্র্যাকশন, অ্যাবস্ট্র্যাকশন, আবারও অ্যাবস্ট্র্যাকশন”-এর কথা বলছিলাম, “শিল্প”-এর অনুভূতি অন্যত্রই পুনরুজ্জীবিত হয়েছিল, এবং আরও অধিক “হার্ডকোর” ইঞ্জিনিয়ারিংয়ের জন্য নতুন জায়গা খুঁজে পেয়েছিল।

অনেকে আমাকে জিজ্ঞাসা করেন: সন্দেহপ্রবণ মানুষদের কীভাবে মোকাবেলা করবেন? আমার উত্তর সবসময় একই: এই মানুষগুলো আসলে আপনার সম্পদ। কারণ তাদের মস্তিষ্কে অসংখ্য অস্পষ্ট জ্ঞান ও বিচারক্ষমতা রয়েছে, আপনাকে এই সবকিছু Agent-এর মধ্যে প্রবেশ করাতে হবে। আপনি তাদেরকে বলতে পারেন: “আপনার সমস্ত জ্ঞান ও সমালোচনা বের করুন,”—এটি Agent এবং Harness-কে আরও ভালো করে তুলবে। যদি আপনি এমন কাউকে দেখেন যে দিনের পর দিন অভিযোগ করে “এইটা তৈরি করা কোডের মান খুবই খারাপ,”—তাহলে তাদেরকে জ্বালানি হিসেবে ব্যবহার করুন, এই রাগ ও সন্দেহকে সিস্টেমটিকে উন্নতির জন্য প্রচলিত শক্তিতে পরিণত করুন।

এখন আমি আমাদের ডেভেলপারদের জন্য একটি পরামর্শ দিচ্ছি: এজেন্ট দ্বারা উত্পাদিত কোড ঠিক করার বদলে, সেই কোড উত্পাদনকারী সিস্টেমটি ঠিক করুন। কয়েক বছর আগে কেউ একটি বাক্য বলেছিলেন: “সেই জিনিসটি তৈরি করবেন না, সেই জিনিসটি তৈরি করতে পারে এমন জিনিসটি তৈরি করুন।” আমরা এখন এই অ্যাবস্ট্রাকশন লেভেলে আছি, Context, Harness, এবং লুপের মাধ্যমে “জিনিস তৈরি করতে পারে” এমন জিনিসটি তৈরি করছি। “Human in the Loop,” “অটো-কমপ্লিট,” “Prompt কল” —এই স্তরেই আটকে থাকা অনেককে নিজেদেরকে সিস্টেম-থিংকিংয়ের দিকে উঠিয়ে নিতে হবে।

আমাদের প্রকৃত লক্ষ্য হলো মানুষের হস্তক্ষেপের সংখ্যা কমানোর জন্য ভালো ইঞ্জিনিয়ারিং প্রথা ব্যবহার করা। শুরুতে, সবাই “vibe coding” করতে ভালোবাসত, একটি Prompt দিয়ে ফলাফল পেয়ে যাওয়া, এবং পরের ধাপে এগিয়ে যাওয়া। কিন্তু এখন আমরা সবচেয়ে বেশি বুঝতে পারছি যে, আমরা শুধু Agent-কে Prompt দিয়ে নির্দেশ দিচ্ছি না, আমরা বলছি: “টেস্টসহ কোড লিখো, ডকুমেন্টেশন আপডেট করো, কোডিং স্ট্যান্ডার্ড মেনে চলো।” আমরা যেসব কথা ভালো ইঞ্জিনিয়ারদের বলতাম, সেগুলোই এখন Agent-এর জন্য অপরিবর্তিতভাবে ব্যবহার করছি। যদি আপনার টিমের কেউ “YOLO (প্রথমেই চালু করে দাও)”—এইরকম অনিয়মিতভাবে vibe coding-এর সাথে জড়িয়ে থাকে, তাহলে আপনাকে তাৎক্ষণিকভাবে এটি বন্ধ করতে হবে। ইঞ্জিনিয়ারিং প্রথা শুধুমাত্র আপনার সিস্টেমটির রক্ষণাবেক্ষণের জন্যই গুরুত্বপূর্ণ নয়, Agent-এরই নিজস্বভাবেই সময়ের সাথে উন্নতিরও।

আমি কিছু অগ্রগামী দলে একটি নতুন রীতি দেখতে পাচ্ছি, যারা এখনও প্ল্যানিং মিটিং এবং রিভিউ মিটিং করে, কিন্তু আলোচনার বিষয়বস্তু সম্পূর্ণ পরিবর্তিত হয়েছে। রিভিউ মিটিংয়ে এখন “কোডে কী সমস্যা হয়েছে?” বলা হয় না, বরং “সিস্টেমে কী সমস্যা হয়েছে?” বলা হয়।

পরিকল্পনা সভায় আমি একটি আকর্ষণীয় বিভাজনও দেখেছি। যেসব কাজের সংজ্ঞা খুব পরিষ্কারভাবে নির্ধারিত এবং পরিসর যথেষ্ট স্পষ্ট, সেগুলোকে সরাসরি Agent-এর কাছে পাঠানো যায়, কারণ Harness-এর ক্ষমতা দিন দিন বাড়ছে এবং এগুলো এই স্পষ্ট কাজগুলো সহজেই প্রক্রিয়া করতে পারে। আর যেসব বিষয়ের সীমানা অস্পষ্ট এবং আলোচনার প্রয়োজন, সেগুলো এখনও মানুষের হাতেই রাখা হয়। তাই পরিকল্পনা সভায় একটি প্রাকৃতিক বিভাজন দেখা গেল: এই কার্ডগুলো Agent-এর প্রবাহের মধ্যে চলে যাবে, আর ওইসব কার্ডগুলোতে আমরা আলোচনা করব।

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

একটি পাশাপাশি প্রভাব রয়েছে: যখন আপনার দলের উৎপাদনশীলতা হঠাৎ বেড়ে যায়, তখন ডাউনস্ট্রিমের মানুষ, যেমন জিটিএম (Go to Market) করা ব্যক্তিরা, তাদের সাথে পাল্লা দিতে পারে না, এমনকি ব্যবহারকারীরাও পাল্লা দিতে পারে না। তাই আপনাকে তাদের সাহায্যের জন্য অটোমেশন ব্যবহার করতে হবে, আপনার ফ্রেমওয়ার্কটি কোডিং পর্যন্তই সীমাবদ্ধ থাকা উচিত নয়, এটি তাদের দিকেও বিস্তৃত হওয়া উচিত। একইভাবে, আপস্ট্রিমের প্রয়োজনীয়তা ইনপুটের ক্ষেত্রেও, যদি প্রয়োজনীয়তা যথেষ্ট দ্রুত আসে না, তবে দলটি আটকে যাবে, এই ধাপগুলিও এই নতুন কাজের প্রবাহের সাথে জড়িয়ে পড়তে হবে।

বর্তমানে বাজারে অসংখ্য ইন্ডিকেটর রয়েছে, যেমন টোকেন খরচ ইত্যাদি। কিন্তু আমি ধীরে ধীরে দুটি প্রকৃত উৎপাদনশীলতা পরিমাপের ইন্ডিকেটরে বিশ্বাস করতে শুরু করেছি। প্রথমটি: আপনি গণনা করুন, একটি কাজ সঠিকভাবে সম্পন্ন করতে Agent-এর জন্য আপনাকে কতবার ম্যানুয়ালি হস্তক্ষেপ করতে হবে? এই সংখ্যা ধারাবাহিকভাবে কমতে থাকা উচিত। আপনার Harness-এর মান, Context-এর মান এবং গাইডলাইনের স্পষ্টতা যতই বাড়বে, এই সংখ্যা ততই কমবে। দ্বিতীয় ইন্ডিকেটরটি হল, যখন আপনি এককভাবে কাজ করা থেকে শেয়ারড সিস্টেমের দিকে যান, তখন একটি মাল্টিপ্লায়ার ইফেক্ট থাকে। আপনি যদি একটি জায়গায় কিছুটা ঠিক করেন, তবে সবাই সেটির সুবিধা পায়। এটি শুধুমাত্র একজনকে ১০গুণ দক্ষতা দেওয়ার কথা নয়, বরং Agent-সিস্টেমের একটি অপ্টিমাইজেশনের ফলে সবারউপরই একটি মাল্টিপ্লায়ার ইফেক্ট ফুটিয়ে তোলে।

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

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

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

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

কিন্তু সমস্যা হলো, যদি যে কেউ এই কেন্দ্রীয় রিপোজিটরিতে যা ইচ্ছা তাই ফেলে দেয়, তাহলে এটি দ্রুত অনিয়ন্ত্রিতভাবে বিস্তৃত হয়ে পড়বে (becomes a sprawl)। উদাহরণস্বরূপ, একটি skill আপলোড করা হলে, কে এটি রক্ষণাবেক্ষণ করবে? আরেকজন একটি অনুরূপ skill fork করল, তাহলে আমি কোনটি বেছে নেব? সুতরাং, কোনো নির্দিষ্ট ক্ষেত্রের জন্য অবশ্যই কারও নিশ্চিতভাবে মালিকানা থাকতে হবে, যিনি নিশ্চিত করবেন যে এটি টেস্টযোগ্য এবং মডিউলার, যাতে অন্যরা এটির উপর ভিত্তি করে Context বা Harness-এর সিকিউরিটি স্ক্যানিং অংশটি বিস্তারিতভাবে বাড়াতে পারে। আপনাকে সংগঠনের ভিতরে যা ইচ্ছা পাঠানোর পরিবর্তে, কেন্দ্রীয়ভাবে এটি পরিচালনা করতে হবে।

সমঝোতা করা কঠিন। এটি tabs এবং spaces-এর বিতর্কের মতো বিখ্যাত নয়, কিন্তু কখনও কখনও এটি ঠিক তেমনই মনে হয়। যদি আপনি দুটি ডেভেলপমেন্ট টিমকে তাদের কাজের পদ্ধতি নিয়ে সমঝোতা করতে বাধ্য করেন, তাহলে এর জন্য অসংখ্য যোগাযোগ এবং মধ্যস্থতার প্রয়োজন হয়। ফলে, শেষপর্যন্ত আপনার একটি পথের বদলে তিনটি বা চারটি পথ থাকবে, যার মধ্যে তারা যেকোনোটি বেছে নিতে পারবে। যদি তারা নিজেদেরই একটি পথ তৈরি করতে চায়, তাহলেও সেটা তাদেরই বাজেটের মধ্যে। কেন্দ্রীয়ভাবে রক্ষণাবেক্ষণকৃত “সহজ পথ”টিই, যা সবাইকে আকর্ষণ করবে।

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

তাই আমার মূল দাবি হল: আমাদের একক ডেভেলপারদের থেকে শুরু করে টিম লেভেলে শেয়ারড কনটেক্সট এবং শেয়ারড কম্পোনেন্টে যেতে হবে, এবং শেষ পর্যন্ত সম্পূর্ণ সংগঠনের ভিতরে “মাল্টিপ্লেয়ার গেম সিস্টেম”-এ পৌঁছাতে হবে। সেখানে গুণিতক প্রভাব বিস্ফোরিত হবে, কারণ আপনার একটি ফ্লাইহুইল থাকবে, যেখানে উন্নতি একসাথে বিভিন্ন দিকে বিকিরিত হতে পারে।

আরও এক স্তর উপরে, ভিপি ইঞ্জিনিয়ারিং এই বিষয়টি কীভাবে চিন্তা করবেন? আমি প্রায় অনুমান করতে পারি যে আপনার সংগঠনে কী ঘটবে: হ্যাকাথন বা লাঞ্চ শেয়ারিং, সফল কেস শেয়ার করা, একটি শেয়ারড স্ল্যাক চ্যানেল তৈরি করা, একটি চ্যাম্পিয়নস প্রোগ্রাম চালু করা। এগুলি সবই সাধারণ ট্রান্সফরমেশন ট্রিকস। আগেও Agile ট্রান্সফরমেশন এটি করেছিল, DevOpsও এটি করেছিল, কিছুই নতুন নয়।

অন্যদিকে, আমরা জানি যে “লাইসেন্স প্রদান, প্রশিক্ষণ দেওয়া, সবাইকে মুক্তভাবে কাজ করতে দেওয়া, হাজারটি ফুল ফোটানো” এই কৌশলটি কখনও সফল হয়নি। হাজারটি ফুলের ফলাফল সাধারণত হাজারটি ঘাস, সব ধরনের ফুল ফোটে কিন্তু কোনোটিই ফল দেয় না। তাই আমি প্রস্তাব করি যে, সংগঠনের পক্ষে স্পষ্টভাবে ক্ষমতা প্রদান করা উচিত, যাতে টিম লিড এবং প্ল্যাটফর্ম টিমরা এই কাজটি করতে পারে। এটি শুধুমাত্র একজন সুপার ব্যক্তির দ্বারা সম্পন্ন হতে পারে না; এটি চালানোর জন্য কাউকে আনুষ্ঠানিকভাবে ক্ষমতা দেওয়া প্রয়োজন।

সাহায্য খোঁজা একটা বড় সমস্যা। বর্তমানে পদবীগুলো সম্পূর্ণ বিশৃঙ্খল—AI পণ্য ইঞ্জিনিয়ার, forward deployed engineer, agentic engineer, AI engineer... এই শব্দগুলোর কোনো বাস্তব অর্থ নেই। আপনি শিরোনাম দিয়ে কারও পরিপক্কতা বুঝতে পারবেন না, কারণ সম্পূর্ণ শিল্পটাই অপরিপক্ক। তবে আপনি যখন চাকরির বিজ্ঞপ্তি দেবেন, তখন এই শব্দগুলো কিছুটা সংকেত দেয়, যা ইচ্ছুকদের আকর্ষণ করে, কিন্তু এটি নিশ্চিত করে না যে তারা প্রকৃতপক্ষে সংশ্লিষ্ট দক্ষতা রাখে। আমি আরও অসাধারণ গল্পও শুনেছি—কিছু প্রার্থী সাক্ষাত্কারের সময় AI-এর মাধ্যমে কানের ভিতরে রিয়েল-টাইমে উত্তর পায়, যখন সাক্ষাত্কারকারী একটি প্রশ্ন করেন, তখন AirPods-এর মধ্যে AI-এর পরামর্শটি শোনা যায়।

তাই আমি শুনেছি যে প্রতিটি কোম্পানি এই ধরনের ইন্টারভিউ পদ্ধতি গ্রহণ করছে। প্রথম ধাপ, একটি অনুশীলন দিন, যাতে তারা AI-এর সাহায্যে সমস্যা সমাধান করতে পারে—যতটা সম্ভব AI-এর উপর নির্ভর করুক। যদি AI তাদের জন্য সমস্যা সমাধান করে দেয়, তবে এটি ঠিকই বোঝায় যে তারা AI-এর সাথে কাজ করতে দক্ষ। দ্বিতীয় ধাপ, তাদেরকে তাদের নিজস্ব সমাধানটি পরীক্ষা করতে বলুন, এবং “আপনি এই সমাধানটি কেন বেছে নিলেন? আপনি কিভাবে এটির সঠিকতা যাচাই করলেন?”—এই প্রশ্নগুলির উত্তর দিতে। এখানে আপনি পরীক্ষা করছেন তাদের পরীক্ষা করার দক্ষতা এবং ইঞ্জিনিয়ারিংয়ের বিচারক্ষমতা। প্রথমাৎ AI-এর ব্যবহারের দক্ষতা, দ্বিতীয়তঃ ইঞ্জিনিয়ারিংয়ের ভিত্তি। তৃতীয়, তাদেরকে কিভাবে সহযোগিতা করছে, শেয়ার করার জন্য প্রস্তুত, খোলা-মনের, নাকি একা-কাজ-করার-ধরনের—সেটাও দেখুন। কিছুদিনের মধ্যেই, AI Agent-এর 시대য়, ।

AI ব্যবহারে অত্যন্ত দক্ষ, শক্তিশালী ইঞ্জিনিয়ারিং দক্ষতা রাখে এবং শেয়ার ও সহযোগিতার প্রতি ইচ্ছুক—এই তিনটি বৈশিষ্ট্যের সমন্বয়ই আপনি খুঁজছেন। ML বা AI শিখেছে এমন কেউ নয়, কোনো ডিকোডিং বিশেষজ্ঞও নয়, বরং একটি মিশ্রণ। আপনি সম্ভবত তিনটি দিকেই পূর্ণাঙ্গ কেউ খুঁজে পাবেন না, কিন্তু এটা কোনো সমস্যা নয়; যেমন, কোনো প্রার্থী একটি দিকে অত্যন্ত শক্তিশালী, কিন্তু অন্যটির জন্য গাইডেন্সের প্রয়োজন। এছাড়াও, এই দক্ষতাগুলিকে “জুনিয়র” বা “সিনিয়র” হিসাবে মিশিয়ে লেবেল দেবেন না—এগুলি ভিন্ন ভিন্ন দক্ষতার মাত্রা, একজন ব্যক্তির AI ব্যবহারের দক্ষতা “সিনিয়র” হতে পারে, কিন্তু সহযোগিতার ইচ্ছা “জুনিয়র”।

ভিপি ইঞ্জিনিয়ারিং বিভাগকে উপরের দিকে জবাবদিহি করতে হবে। আমরা এতগুলি লাইসেন্স কিনেছি, কি আউটপুট প্রমাণ করা যায়? ডেলিভারি দ্রুততর হয়েছে? সম্ভবত প্রতিশ্রুতি আছে, কিন্তু প্রমাণ করা কঠিন। গুণগত মান উন্নত হয়েছে? সেটাও বলা কঠিন। কিন্তু আমি আগে যে দুটি মেট্রিক্সের কথা বলেছিলাম, আপনি দেখাতে পারেন কতটা ইন্টারভেনশন কমেছে, কতটা উন্নতি হয়েছে, এবং রিইউজ রেট কতটা বেড়েছে। “এজেন্ট আছে এবং নেই—এই দুটির মধ্যে কোডিং প্রডাক্টিভিটির” তুলনা করার চেয়ে এটি অনেক বেশি সহজ এবং বেশি প্রামাণিক।

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

আরও একটি বিষয় আছে, দলীয় আকার নিয়ে। এক জন সর্বগুণ সম্পন্ন ব্যক্তি সব কাজ করে ফেলল, এটা হলো চূড়ান্ত স্বপ্ন। কিন্তু তুমি একটু হিসাব করে দেখো: এই মানুষটাকে সাধারণত পরিপূরক দক্ষতার লোকজনের সঙ্গে জুটি বাঁধতে হয়, যেমন প্রোডাক্ট ম্যানেজার বা ডিজাইনার। তারপর তোমাকে আবার ব্যাকআপ কর্মীও ভাবতে হবে, যদি কেউ ছুটিতে যায় তাহলে? এভাবে আবার তিনজনের দলে ফিরে আসা হয়। তারপর হয়তো আরও কাউকে লাগবে প্রোডাকশন আর টিকেট (工单) দেখার জন্য; যদি তুমি সত্যিই ভীষণ দক্ষ হও, তাহলে একই দল এটা বাড়তি দায়িত্ব হিসেবে সামলাতে পারে। কিন্তু একবার তুমি বাগ ঠিক করতে শুরু করলে, নতুন ফিচার করার গতি কমে যাবে। শেষে আছে নতুনরা, তোমাকে তাদের জন্য পথ তৈরি করতে হবে, যেন তারা বুঝতে পারে “ভালো” দেখতে কেমন। তাই আমি এখনও মনে করি, কোনো সংগঠনে আমাদের পক্ষে সত্যিই প্রতিটি দলকে এক–দু’জনের করে ফেলা সম্ভব না।

শেষ পর্যন্ত, ডার্ক ফ্যাক্টরি সম্পূর্ণ অন্ধকার নাও হতে পারে, বরং এটি কিছুটা মৃদু আলো (dim factory) রাখতে পারে, যার অর্থ আপনাকে নির্ধারণ করতে হবে কোন ফাংশনের জন্য কতটা ঝুঁকি নেওয়া উচিত—সব ফাংশনই সম্পূর্ণ স্বয়ংক্রিয়ভাবে প্রযোজ্য নয়। আপনি অডিটের জন্য বেশি বিনিয়োগ করতে পারেন, যেমন: ট্রেসিং—কে কোডটি পরিবর্তন করল? মানুষ নাকি Agent? কোডটি প্রকৃতপক্ষে কার্যকর কিনা তা যাচাইকারীদের দ্বারা পরীক্ষা করুন, এবং স্বয়ংক্রিয় প্রক্রিয়াগুলির ব্যর্থতার সময় পরিস্থিতি-সচেতনতার উপর বিনিয়োগ করুন। সম্পূর্ণ মাইক্রো-ম্যানেজমেন্ট (প্রতিটি লাইনের কোডই মানুষের দ্বারা পরীক্ষিত) থেকে সম্পূর্ণ স্বয়ংক্রিয় অনুমোদন (ধরে নিচ্ছি Agent-এর output-এর সবকিছুই সঠিক)—এটি একটি সম্পূর্ণ স্পেকট্রাম। আপনার করণীয়, বিভিন্ন ধরনের পরিবর্তনের জন্য ঝুঁকির মাত্রা অনুযায়ী ভিন্নভাবে অটোমেশনের মাত্রা নির্বাচন।

আমার মতে, আপনার প্রতিযোগিতামূলক সুবিধা হল সঞ্চিত জ্ঞানকে ধরে রাখা—যে জ্ঞানগুলি আপনি এখন skill, Context, এমনকি Harness সীমাবদ্ধতাগুলিতে প্রবেশ করিয়েছেন। আমার জন্য, এটি প্রকৃতপক্ষে নিরবচ্ছিন্ন ডেলিভারির দিকে নিরবচ্ছিন্ন শিক্ষার দিকে নিয়ে যায়। নিজেকে জিজ্ঞাসা করুন: আমরা কতদ্রুত একটি নতুন জিনিসকে সিস্টেমে প্রবেশ করাতে পারি, এবং একটি পুরানো জিনিসকে বাইরে তুলে নিতে পারি? এটিই আপনার প্রতিক্রিয়াশীলতা। যদি আপনি এই ক্ষমতা নিরবচ্ছিন্নভাবে উন্নত করতে পারেন, তবে প্রশ্নটি আর “আমি কীভাবে সমগ্র সিস্টেমকে আরও বেশি বিশ্বস্ত করব?” নয়, বরং “আমি কি সিস্টেমের অধিকাংশ অংশকেই পরিবর্তন করতে থাকতে পারি, যখনও এটির বিশ্বস্ততা বজায় রাখি?”

যদি শুধু একটি বাক্য নেওয়া হয়, তাহলে সেটি হওয়া উচিত: বিজয়ী হবেন না যিনি একাই কাজ করেন, বরং যারা বিভিন্ন স্তরে সংগঠনকে উন্নত করার কৌশল জানেন।