ভাইব কোডিং বদলে দিয়েছে কারা কার্যকর দেখায় এমন অ্যাপ্লিকেশন তৈরি করতে পারে। একটি প্রম্পট স্ক্রিন তৈরি, API সংযোগ এবং একটি বিশ্বাসযোগ্য ওয়ার্কফ্লো সাজিয়ে দিতে পারে, তার আগেই একটি প্রচলিত ইঞ্জিনিয়ারিং দল তাদের প্রথম ডিজাইন রিভিউ শেষ করতে পারে।
এই গতি নিয়োগ ও ডেলিভারির ক্ষেত্রে একটি নতুন সমস্যা তৈরি করেছে: কোনো ডেমো আর সফটওয়্যার ভালো—এর শক্তিশালী প্রমাণ নয়। নিয়োগদাতারা ক্রমশ কঠিন একটি প্রশ্ন করবেন: ইনপুট অগোছালো হলে, নির্ভরশীলতাগুলো ব্যর্থ হলে, ব্যবহারকারীরা একই কাজ বারবার করলে এবং অন্তর্নিহিত মডেল বদলে গেলে—এই AI-নির্মিত সিস্টেম কি সঠিকভাবে আচরণ করতে পারে?
উত্তরটি আসবে এমন একটি গুণমানের মানদণ্ড থেকে, যা বাহ্যিক পরিশীলনের চেয়ে নিয়মানুবর্তী সফটওয়্যার যাচাইয়ের সঙ্গে বেশি সাদৃশ্যপূর্ণ। যারা আলাদা করে নজরে পড়বেন, তারা শুধু AI কোডিং টুল কী তৈরি করেছে তা দেখাবেন না। তারা দেখাবেন কীভাবে সেটি পরীক্ষা করেছেন, এটি নিরাপদভাবে কী করতে পারে না, এবং কীভাবে তারা নিশ্চিত হয়েছেন যে একটি পরিবর্তনে অন্য কিছু ভেঙে যায়নি।
বেঞ্চমার্ক হলো প্রমাণ, লিডারবোর্ডের স্কোর নয়
ওপেন-সোর্স কোডিং-এজেন্ট বেঞ্চমার্কগুলো কার্যকর সূচনাবিন্দু দেয়, কিন্তু এগুলো ভিন্ন ভিন্ন সক্ষমতা পরিমাপ করে। SWE-bench বাস্তব GitHub ইস্যু এবং রিপোজিটরি স্ন্যাপশট ব্যবহার করে, তাই রক্ষণাবেক্ষণের কাজের সঙ্গে এটি প্রাসঙ্গিক। Terminal-Bench কমান্ড-লাইন ইন্টারঅ্যাকশন পরীক্ষা করে। SlopCodeBench এবং ProgramBench-সহ তালিকাভুক্ত অন্যান্য বেঞ্চমার্ক জেনারেট করা কোড ও এজেন্টের আচরণের ভিন্ন ভিন্ন দিক লক্ষ্য করে।
এই বেঞ্চমার্কগুলো টুলের তুলনা করতে বা একটি বেসলাইন নির্ধারণ করতে সাহায্য করতে পারে, কিন্তু নিয়োগদাতাদের কোনো একক স্কোরকে প্রোডাকশনের জন্য প্রস্তুত থাকার প্রমাণ হিসেবে বিবেচনা করার বিষয়ে সতর্ক থাকা উচিত। একটি মডেল রিপোজিটরির ইস্যু সমাধান করলেও অনিরাপদ অনুমোদন-লজিক তৈরি করতে পারে। একটি এজেন্ট টার্মিনাল কাজ সম্পন্ন করলেও দীর্ঘ ওয়ার্কফ্লো জুড়ে স্টেট সংরক্ষণে ব্যর্থ হতে পারে। একটি পরিশীলিত ওয়েব অ্যাপ্লিকেশন সফল পরিস্থিতির ডেমো পাস করলেও পুনরায় চেষ্টা বা ডুপ্লিকেট পেমেন্ট ভুলভাবে পরিচালনা করতে পারে।
তাই একটি বিশ্বাসযোগ্য পোর্টফোলিও বা অভ্যন্তরীণ রিভিউতে কাজ-নির্দিষ্ট একটি মূল্যায়ন সেট থাকা উচিত। সেই সেটে প্রতিনিধিত্বশীল বাগ রিপোর্ট, সাধারণ ব্যবহারকারীর যাত্রাপথ, ত্রুটিপূর্ণ ইনপুট, অনুমতির সীমা, নির্ভরশীলতার ব্যর্থতা এবং আগে ঠিক করা রিগ্রেশন থাকতে পারে। প্রতিটি ক্ষেত্রে স্পষ্ট প্রত্যাশিত ফলাফল থাকা উচিত, শুধু দেখতে ঠিক এমন একটি স্ক্রিনশট নয়।
AI-নির্মিত সফটওয়্যারের জন্য ন্যূনতম টেস্ট প্যাক
একটি ছোট অ্যাপ্লিকেশনের জন্য জটিল গবেষণাগার ছাড়াই একটি কার্যকর গুণমান প্যাক তৈরি করা যায়:
- অ্যাকসেপ্ট্যান্স টেস্ট: সফল ও অসফল ফলাফলসহ সবচেয়ে গুরুত্বপূর্ণ ওয়ার্কফ্লোগুলোর ব্যবহারকারীর দৃশ্যমান আচরণ যাচাই করুন।
- ইউনিট ও ইন্টিগ্রেশন টেস্ট: ব্যবসায়িক নিয়মগুলো আলাদাভাবে পরীক্ষা করুন এবং ডেটাবেস, API, কিউ ও অথেন্টিকেশন প্রত্যাশিতভাবে একসঙ্গে কাজ করছে কি না নিশ্চিত করুন।
- নেগেটিভ টেস্ট: অনুপস্থিত, ত্রুটিপূর্ণ, অতিরিক্ত বড়, ডুপ্লিকেট এবং অননুমোদিত ইনপুট পাঠান। AI-উৎপাদিত কোড প্রম্পটে দেখানো পথটিতে প্রায়ই সবচেয়ে শক্তিশালী দেখায়, তাই অনুরোধ না করা পথগুলোই গুরুত্বপূর্ণ।
- রিগ্রেশন টেস্ট: আবিষ্কৃত প্রতিটি ত্রুটিকে একটি স্থায়ী পরীক্ষায় রূপান্তর করুন। কোনো ত্রুটি ঠিক করার পর ডেমো সবুজ দেখালেই যথেষ্ট নয়, যদি পরের জেনারেট করা পরিবর্তনে একই ব্যর্থতা ফিরে আসতে পারে।
- নিরাপত্তা যাচাই: অ্যাক্সেস কন্ট্রোল, গোপন তথ্য ব্যবস্থাপনা, ইনজেকশন প্রতিরোধ, নির্ভরশীলতার দুর্বলতা এবং অবিশ্বস্ত কনটেন্ট টুল কল বা বিশেষাধিকারপ্রাপ্ত কাজকে প্রভাবিত করতে পারে কি না পরীক্ষা করুন।
- অপারেশনাল যাচাই: টাইমআউট, পুনঃচেষ্টা, আইডেমপোটেন্সি, লগিং, অ্যালার্ট এবং কোনো নির্ভরশীলতা অনুপলব্ধ হলে নিরাপদ আচরণ যাচাই করুন।
এটি Stack Overflow-এর একটি এজেন্টিক সফটওয়্যার ডেভেলপমেন্ট লাইফ সাইকেল বিষয়ক বিবরণে বর্ণিত QA-ইঞ্জিনিয়ারিং মানসিকতার কাছাকাছি। গুরুত্বপূর্ণ পরিবর্তনটি সাংস্কৃতিক: AI কোড লেখার পর গুণমান নিশ্চয়তা কোনো চূড়ান্ত পরিদর্শন নয়। দ্রুত জেনারেশনকে ব্যবহারের জন্য যথেষ্ট নিরাপদ করে তোলে যে কাঠামো, সেটিই গুণমান নিশ্চয়তা।
শুধু আউটপুট নয়, অর্কেস্ট্রেশনও পরীক্ষা করুন
সফটওয়্যারে AI এজেন্ট থাকলে সাধারণ অ্যাপ্লিকেশন টেস্ট প্রয়োজনীয় হলেও যথেষ্ট নয়। সিস্টেম ব্যর্থ হতে পারে কারণ মডেল কোনো অনুরোধ ভুল বুঝেছে, কিন্তু এটাও হতে পারে যে চারপাশের অর্কেস্ট্রেশন প্রসঙ্গ হারিয়েছে, কোনো টুল দুবার কল করেছে, ত্রুটিপূর্ণ স্ট্রাকচার্ড আউটপুট গ্রহণ করেছে, অথবা কখনো শেষ হয়নি।
ডাইজেস্টে সুপারিশ করা প্রি-ডিপ্লয়মেন্ট রিগ্রেশনের ক্ষেত্রগুলো একটি ব্যবহারিক চেকলিস্ট: প্রসঙ্গ হারানো, টুলের আইডেমপোটেন্সি, প্রম্পট ইনজেকশন, স্ট্রাকচার্ড আউটপুট, অসমাপ্ত থাকা, রিট্রিভাল গ্রাউন্ডিং এবং স্টেট পুনঃস্থাপন। এগুলো পরীক্ষাযোগ্য ইঞ্জিনিয়ারিং বৈশিষ্ট্য।
উদাহরণস্বরূপ, একটি টেস্ট একই অনুরোধ দুবার চালিয়ে নিশ্চিত করতে পারে যে দ্বিতীয় প্রচেষ্টায় ডুপ্লিকেট অর্ডার তৈরি হয় না। আরেকটি টেস্ট কোনো ওয়ার্কফ্লোর মাঝপথে এজেন্টকে থামিয়ে, পুনরায় চালু করে এবং যাচাই করতে পারে যে এটি কোনো অপরিবর্তনীয় কাজ পুনরাবৃত্তি না করে বৈধ অবস্থা থেকে এগিয়ে যায়। একটি রিট্রিভাল টেস্টে সিস্টেমকে কেবল অনুমোদিত উৎসের সেট থেকে তথ্য উদ্ধৃত বা ফেরত দিতে বলা যেতে পারে। একটি স্ট্রাকচার্ড-আউটপুট টেস্ট অবৈধ প্রতিক্রিয়া সরবরাহ করে নিশ্চিত করতে পারে যে অ্যাপ্লিকেশন সেটিকে বৈধ ডেটা হিসেবে নীরবে গ্রহণ না করে নিরাপদভাবে প্রত্যাখ্যান করছে।
দীর্ঘমেয়াদি ও বহু-এজেন্ট সিস্টেমের বিশেষভাবে স্পষ্ট ব্যর্থতার রেকর্ড দরকার। দীর্ঘ ইন্টারঅ্যাকশন চেইনে কোন এজেন্ট ব্যর্থতা ঘটিয়েছে এবং কোন পর্যায়ে ঘটিয়েছে তা শনাক্ত করা কঠিন হতে পারে বলে গবেষকেরা স্বয়ংক্রিয় ব্যর্থতা-নির্ধারণ নিয়ে কাজ করছেন। ব্যবহারিকভাবে, দলগুলোর গোপনীয়তার কথা বিবেচনা করে টুল কল, ইনপুট, আউটপুট, মডেলের সংস্করণ, টাইমস্ট্যাম্প, স্টেট পরিবর্তন এবং চূড়ান্ত সিদ্ধান্ত একটি অডিট ট্রেইলে সংরক্ষণ করা উচিত। সেই প্রমাণ ছাড়া একটি লাল টেস্ট আপনাকে জানায় যে কিছু ব্যর্থ হয়েছে, কিন্তু কোথা থেকে ঠিক করা শুরু করবেন তা জানায় না।
পুনরুৎপাদনযোগ্যতা ক্যারিয়ারে সুবিধা এনে দেবে
AI-উৎপাদিত কোড পরিবর্তনশীল। পুনরায় চালালে ভিন্ন বাস্তবায়ন তৈরি হতে পারে; মডেল আপডেট হলে আচরণ বদলাতে পারে; কোনো প্রোভাইডার বিভ্রাট রাউটিং বা লেটেন্সি পরিবর্তন করতে পারে। তাই নিয়োগদাতারা এমন প্রার্থীদের মূল্য দেবেন, যারা মূল্যায়ন পুনরাবৃত্তিযোগ্য করে তুলতে পারেন।
এর অর্থ হলো সম্ভব হলে মডেলের স্ন্যাপশট নির্দিষ্ট করে রাখা, প্রম্পট ও কনফিগারেশন রেকর্ড করা, প্ল্যাটফর্ম অনুমতি দিলে র্যান্ডমনেস নিয়ন্ত্রণ করা এবং যেসব কাজের ফলাফল পরিবর্তিত হয় সেগুলোর জন্য একাধিক ট্রায়াল চালানো। ডাইজেস্টে বিশেষভাবে পিন করা স্ন্যাপশট, যেখানে সম্ভব কম বা শূন্য টেম্পারেচার এবং কনফিডেন্স-বাউন্ডেড CI/CD গেটকে কার্যকর সুরক্ষা হিসেবে উল্লেখ করা হয়েছে।
একটি ব্যবহারিক প্রতিবেদনে অন্তত তিনটি ফলাফল আলাদা করা উচিত:
- পাসের হার: কতগুলো কেস সফল হয়েছে।
- সামঞ্জস্য: বারবার চালানোর ক্ষেত্রে একই কেস কত ঘন ঘন সফল হয়।
- গুরুত্বের মাত্রা: ব্যর্থতাগুলো কেবল বাহ্যিক সৌন্দর্যগত, অসুবিধাজনক, ডেটা-ক্ষতিকর, নিরাপত্তাসংশ্লিষ্ট, নাকি অনিরাপদ কোনো বাহ্যিক পদক্ষেপ ঘটাতে সক্ষম—তা।
২০টির মধ্যে ১৯টি কম-ঝুঁকির ফরম্যাটিং যাচাইয়ে উত্তীর্ণ একটি সিস্টেম ২০টির মধ্যে ১৮টি কেসে উত্তীর্ণ এমন একটি সিস্টেমের চেয়ে আবশ্যিকভাবে ভালো নয়, যদি দ্বিতীয়টি কখনোই অনুমোদনের সীমা অতিক্রম না করে। ব্যর্থতার পরিণতি অনুযায়ী গুণমানের মানদণ্ডে তাদের যথাযথ গুরুত্ব দিতে হবে।
মানবীয় পর্যালোচনার লক্ষ্য হওয়া উচিত ঝুঁকি, প্রতিটি লাইন নয়
উন্নততর অটোমেশনের উদ্দেশ্য হলো AI-উৎপাদিত প্রতিটি টোকেন মানুষকে আবার পড়তে বাধ্য করা নয়। এর উদ্দেশ্য হলো সেই সিদ্ধান্তগুলোর দিকে মানুষের মনোযোগ পরিচালিত করা, যেগুলোর নিষ্পত্তি পরীক্ষা দিয়ে পুরোপুরি করা যায় না।
পর্যালোচকদের authentication ও authorization, ডেটা সংরক্ষণ, আর্থিক বা চুক্তিভিত্তিক পদক্ষেপ, গোপনীয়তা, মাইগ্রেশন, ত্রুটি পুনরুদ্ধার, তৃতীয় পক্ষের অনুমতি, এবং এমন পরিবর্তনের দিকে মনোযোগ দেওয়া উচিত যা সিস্টেমের নিজস্ব মূল্যায়ন হারনেসকে প্রভাবিত করে। কোনো এজেন্টের ক্ষেত্রে, সে কোন কোন টুল কল করতে পারে, প্রতিটি টুল কোন ডেটায় প্রবেশাধিকার পায়, এবং অপরিবর্তনীয় কোনো পদক্ষেপের আগে অনুমোদন প্রয়োজন কি না—এসবও পর্যালোচনা করা উচিত।
দৃশ্যমান ডিফ, অনুমোদন-প্রক্রিয়া, সংরক্ষিত কথোপকথন এবং অডিট লগ—সহযোগিতামূলক AI কোডিং সম্পর্কে Slack Code-এর বর্ণনায় উল্লিখিত বৈশিষ্ট্যগুলো—একটি বৃহত্তর প্রত্যাশার দিকে ইঙ্গিত করে: সফটওয়্যার কীভাবে তৈরি হয়েছে, তার ইতিহাস গুরুত্বপূর্ণ হবে। একজন পর্যালোচক যেন অনুরোধটি বুঝতে পারেন, তৈরি করা পরিবর্তন পরীক্ষা করতে পারেন, পরীক্ষার প্রমাণ দেখতে পারেন এবং ডিপ্লয়মেন্ট কে অনুমোদন করেছে তা শনাক্ত করতে পারেন।
এই রেকর্ড নিছক আমলাতন্ত্র নয়। এটি একটি চমকপ্রদ ডেমোকে এমন একটি নিয়ন্ত্রিত পরিবর্তন থেকে আলাদা করে, যা অন্য কেউ রক্ষণাবেক্ষণ করতে পারে।
পোর্টফোলিও বা সাক্ষাৎকারে কী রাখবেন
প্রার্থীদের জন্য সবচেয়ে শক্তিশালী প্রদর্শন হলো এমন একটি ছোট সিস্টেম, যেখানে গুণমানের বিবরণ ইচ্ছাকৃতভাবে দৃশ্যমান। রিপোজিটরি, সেটআপের নির্দেশনা, আর্কিটেকচারের নোট, পরীক্ষার কমান্ড, প্রতিনিধিত্বমূলক টেস্ট কেস, জানা সীমাবদ্ধতা এবং একটি সংক্ষিপ্ত ব্যর্থতার প্রতিবেদন অন্তর্ভুক্ত করুন। পাওয়া গেছে এবং রিগ্রেশন টেস্টে রূপান্তর করা হয়েছে—এমন এক বা দুটি বাগ দেখান। কোন মডেল বা কোডিং এজেন্ট ব্যবহার করা হয়েছে তা ব্যাখ্যা করুন, তবে টুলটিকে প্রকৌশলগত সিদ্ধান্তগুলোর লেখক হিসেবে উপস্থাপন করবেন না।
অ্যাপ্লিকেশনটি কোনো এজেন্ট ব্যবহার করলে, টুলের অনুমতি, স্টেট মডেল, রিট্রাই নীতি, সমাপ্তির শর্ত এবং মানবীয় অনুমোদনের ধাপগুলো নথিভুক্ত করুন। এটি রিট্রিভাল ব্যবহার করলে, উৎসগুলো কীভাবে নির্বাচন করা হয় এবং প্রমাণ অনুপস্থিত থাকলে কী ঘটে তা দেখান। এটি বাহ্যিক পরিষেবা কল করলে, টাইমআউট ও ডুপ্লিকেট অনুরোধের আচরণ প্রদর্শন করুন।
একটি মাত্র সফল রেকর্ডিং থেকে নির্ভরযোগ্যতার দাবি করবেন না। যাচাইযোগ্য দাবিটি বরং এমন শোনাবে: “এই 12টি পরিস্থিতির 30টি রেকর্ড করা রান জুড়ে, সিস্টেমটি 28টিতে গ্রহণযোগ্যতার মানদণ্ড পূরণ করেছে; দুটি ব্যর্থতার সঙ্গে অস্পষ্ট তারিখের ইনপুট জড়িত ছিল, এবং উভয়টিই নথিভুক্ত করা হয়েছে।” সংখ্যাটি নিজে পদ্ধতি, সীমারেখা এবং কী কী এখনো পরীক্ষা করা হয়নি সে বিষয়ে সততার চেয়ে কম গুরুত্বপূর্ণ।
দ্রুততার নতুন সংজ্ঞা
AI প্রথম সংস্করণ তৈরি করার খরচ কমায়। সেই সংস্করণটি আস্থার যোগ্য কি না তা জানার খরচ দূর করে না। বরং দ্রুততর জেনারেশন মূল্যায়নকে আরও গুরুত্বপূর্ণ করে তুলতে পারে, কারণ ডিপ্লয়মেন্টের মাঝখানে আরও বেশি অপর্যালোচিত পরিবর্তন জমা হতে পারে।
‘ভাইব-কোডিং’-পরবর্তী পেশাজীবীকে যে চক্রের ভিত্তিতে মূল্যায়ন করা হবে তা হলো: আচরণ নির্ধারণ করা, কোড তৈরি বা পরিবর্তন করা, বাস্তবসম্মত ও প্রতিকূল পরিস্থিতি পরীক্ষা করা, উচ্চ-ঝুঁকির সিদ্ধান্ত পরিদর্শন করা, ব্যর্থতা নথিভুক্ত করা এবং প্রমাণ না হারিয়ে সিস্টেম উন্নত করা। বেঞ্চমার্ক সক্ষমতা তুলনা করতে সাহায্য করতে পারে। QA অনুশীলন নির্ধারণ করে, সেই সক্ষমতা নির্ভরযোগ্য সফটওয়্যারে পরিণত হবে কি না।
তাই গুণমানের মানদণ্ড হলো না “AI দিয়ে কি আপনি একটি অ্যাপ বানাতে পারেন?” বরং “অ্যাপটি কী করে তা কি আপনি প্রমাণ করতে পারেন, এটি কখন তা করা বন্ধ করে তা শনাক্ত করতে পারেন, এবং এমন সীমা নকশা করতে পারেন যা কোনো ব্যর্থতাকে ঘটনা হয়ে উঠতে বাধা দেয়?”
