একজন জুনিয়র developer AI assistant-কে অপরিচিত library ব্যবহার করতে বলতে পারেন, কাজের কোড পেতে পারেন, তারপর এগিয়ে যেতে পারেন। feature প্রস্তুত হয়ে যেতে পারে, অথচ developer এখনো বুঝতে নাও পারেন—কেন এটি কাজ করছে। পরের বার কোড ভেঙে গেলে, চাহিদা বদলালে বা assistant-এর প্রস্তাবিত সংশোধন নিরাপদ কি না কাউকে ঠিক করতে হলে এই ফারাকটি গুরুত্বপূর্ণ হয়ে ওঠে।
Software engineer Alexandru Nedelcu এই উদ্বেগ তুলেছেন তাঁর ২২ সেপ্টেম্বরের প্রবন্ধে। তাঁর যুক্তি, developer-রা কোড পড়া, বিকল্প বাছা ও ভুলের দায় নেওয়ার মধ্য দিয়ে বিচারবুদ্ধি গড়ে তোলেন। কিছু প্রতিষ্ঠান AI-বিরোধী নীতি প্রচার করবে—এমন পূর্বাভাস তাঁর মতামত, শিল্পজুড়ে দেখা পরিবর্তনের প্রমাণ নয়। জানুয়ারিতে প্রকাশিত আলাদা একটি পরীক্ষা শেখার প্রশ্নটিকে নির্দিষ্ট ও যাচাইযোগ্য করে: AI-সহায়তায় কাজ শেষ করার পরপরই programmer-রা কী বুঝতে পেরেছিলেন? Anthropic-এর গবেষণা-সারাংশ
বড় পরিবর্তন
- কী বদলেছে: AI-এর সাহায্যে তার যুক্তি না বুঝেই তৈরি software জমা দেওয়া সহজ। নতুন developer কাজটি ব্যাখ্যা বা ঠিক করতে যে গুরুত্বপূর্ণ সিদ্ধান্তের অনুশীলন দরকার, তার আগেই AI implementation লিখে দিতে পারে।
- কেন গুরুত্বপূর্ণ: ব্যবস্থাপকরা এখন বেশি কাজ করাতে পারেন, কিন্তু এতে সেই পথ দুর্বল হতে পারে, যার মধ্য দিয়ে জুনিয়র কর্মীরা ভবিষ্যতের ব্যর্থতার কারণ খুঁজে বের করতে শেখেন। অপরিচিত ধারণা জড়িত কাজে ঝুঁকি বেশি; পরিচিত কাজে সহায়তা তবুও উপকারী হতে পারে।
- কী লক্ষ করবেন: দলগুলো কাজ শেষ করাকেই শেখার অংশ হিসেবে ধরতে পারে এবং AI-সহায়তায় তৈরি কাজ ব্যাখ্যা, debug ও পরিবর্তনের জন্য সময় রাখতে পারে। এমন হলে নিয়োগের অনুশীলন ও coding product-এ গতির পাশাপাশি দেখানো বোঝাপড়ারও মূল্য থাকতে পারে।
কাজ শেষ হওয়া আর দক্ষতা শেখা আলাদা ফল
একটি ৫২ জন programmer-কে নিয়ে randomised controlled study-তে অংশগ্রহণকারীরা Trio নামের একটি অপরিচিত Python library ব্যবহার করে দুটি coding task শেষ করেন। অর্ধেক coding environment-এ AI assistant পেয়েছিলেন, বাকিরা পাননি। পরে quiz হবে—এ কথা তাঁদের জানানো হয়েছিল। কাজ শেষে সঙ্গে সঙ্গেই নেওয়া quiz-এ ধারণা, কোড পড়া ও debugging যাচাই করা হয়।
AI-সহায়তায় কাজ করা দলের গড় score ছিল ৫০%, আর AI ছাড়া কাজ করা দলের ৬৭%—ব্যবধান ১৭ percentage point, আপেক্ষিকভাবে ১৭% হ্রাস নয়। Debugging প্রশ্নে ব্যবধান সবচেয়ে বড় ছিল। AI দল গড়ে প্রায় দুই মিনিট আগে কাজ শেষ করেছিল, তবে সময়ের এ পার্থক্য পরিসংখ্যানগতভাবে তাৎপর্যপূর্ণ ছিল না। এগুলো এক library-তে অল্প সময়ের অভিজ্ঞতা ও সঙ্গে সঙ্গে নেওয়া পরীক্ষার ফল; developer-এর career বা production system-এর মানের মাপকাঠি নয়। গবেষকদের ফল ও সীমাবদ্ধতা
অংশগ্রহণকারীরা assistant কীভাবে ব্যবহার করেছেন, গবেষকেরা সেটিও দেখেছেন। কেউ কেউ কোড লেখা ও debugging-এর বেশির ভাগ assistant-কে দিয়েছেন; অন্যরা ব্যাখ্যা চেয়েছেন বা ধারণাগুলো নিজে বোঝার চেষ্টা করেছেন। সক্রিয়ভাবে বেশি অংশ নেওয়া গোষ্ঠীগুলোর score সাধারণত ভালো ছিল, তবে ছোট এই গোষ্ঠীগুলো পরে শনাক্ত করা হয়। AI পাওয়া বা না পাওয়ার জন্য অংশগ্রহণকারীদের random করা হয়েছিল; নির্দিষ্ট কথোপকথনের ধরন বেছে দেওয়া হয়নি। ব্যাখ্যা চাওয়া শিক্ষার্থীকে সাহায্য করতে পারে, কিন্তু কোনো এক prompt বা workflow শেখার ব্যবধান ঠেকায়—এ গবেষণা তা প্রমাণ করে না। গবেষণাপত্রের সংলাপ বিশ্লেষণ
ভুল করাই প্রায়ই সেই মুহূর্ত, যখন নতুন developer বোঝেন library কী ধরে নিয়েছে। Assistant যদি প্রথম implementation এবং সেটি ঠিক করার দায়—দুটোই নিয়ে নেয়, তবে developer ওই অনুমানগুলো কম দেখতে পারেন। Debugging-এ ব্যবধানের একটি সম্ভাব্য ব্যাখ্যা এটি।
গতি তবুও গুরুত্বপূর্ণ, আর কাজের ধরন উত্তর বদলে দেয়
অন্য পরিস্থিতিতে AI-সহায়তায় coding দ্রুতও হয়েছে। GitHub Copilot-এর একটি controlled experiment-এ ৯৫ জন পেশাদার স্বতন্ত্র contractor-কে JavaScript HTTP server তৈরির কাজ দেওয়া হয়েছিল। কাজ শেষ করা ব্যক্তিদের মধ্যে Copilot দল গড়ে প্রায় ৭১ মিনিটে কাজ করেছে, আর control দলের লেগেছে প্রায় ১৬১ মিনিট—কাজ শেষ করতে সময় কমেছে ৫৫.৮%। programmer-রা পরে কী শিখেছেন, গবেষকেরা তা পরীক্ষা করেননি। এটি নির্দিষ্ট পরিসরের implementation task, অপরিচিত library-র পরিচয় ও পরে বোঝাপড়ার পরীক্ষা নয়।
দুই ফলই ব্যবস্থাপকের কাজে লাগতে পারে। অভিজ্ঞ developer AI দিয়ে পুনরাবৃত্তিমূলক কাজ দ্রুত শেষ করলে বাঁচানো সময় বাস্তব লাভ হতে পারে। নতুন system শেখার কাজে দ্রুত ফল আর গভীর বোঝাপড়া আলাদাভাবে যাচাই করা দরকার। AI পুরোপুরি নিষিদ্ধ করলে সম্ভাব্য লাভ হাতছাড়া হবে, কিন্তু মানুষ কাজটির তদারকি করতে কীভাবে শিখবে—তার উত্তর মিলবে না।
Nedelcu-র প্রবন্ধটি পরীক্ষার গণ্ডি ছাড়িয়ে যায়। তাঁর যুক্তি, রক্ষণাবেক্ষণযোগ্যতা কয়েক মাস বা বছরে বোঝা যায় এবং ভুলের দায় নেওয়ার মাধ্যমে অভিজ্ঞতা তৈরি হয়। গবেষণাটি দীর্ঘমেয়াদি maintenance মাপেনি, কিংবা AI ব্যবহারকারীরা শেখা পুরোপুরি বন্ধ করে দেন—এটিও দেখায়নি। তাঁর উপযোগী প্রশ্নটি প্রতিষ্ঠানকে নিয়ে: দল যদি অনুশীলনের কাজ দ্রুত অন্যের হাতে দিতে শুরু করে, ভবিষ্যতের problem-solver-রা অনুশীলন পাবেন কোথায়? Nedelcu-র প্রবন্ধ
কোড চালানোর পর শিক্ষার্থীকে কিছু প্রমাণ করতে বলুন
একটি ব্যবহারিক উপায় হলো নতুন কর্মীকে AI-সহায়তায় করা কাজ দেওয়া, তারপর শেখা হয়েছে বলে গণ্য করার আগে স্বাধীনভাবে ছোট একটি যাচাই করানো। এটি আমাদের প্রস্তাবিত অনুশীলন; কোনো গবেষণায় পরীক্ষিত intervention নয়:
- ব্যাখ্যা করুন: assistant-কে না জিজ্ঞেস করেই কোডের অপরিচিত অংশটি কেন কাজ করে, সেটি কী ধরে নিয়েছে এবং কোন পরিস্থিতিতে ব্যর্থ হবে—বলতে হবে। সিনিয়র engineer করা বাস্তব পরিবর্তনের সঙ্গে সম্পর্কিত একটি অনুসারী প্রশ্ন করতে পারেন।
- ত্রুটি নির্ণয় করুন: নিরাপদ test branch-এ ছোট, বাস্তবসম্মত একটি failure ঘটান। শিক্ষার্থীকে তার কারণ খুঁজে বের করতে এবং কোন লক্ষণ আকর্ষণীয় কিন্তু ভুল সমাধানটি বাতিল করেছে তা বলতে বলুন। লক্ষ্য হলো যুক্তি বোঝা, command মুখস্থ করা নয়।
- পরিবর্তনের সঙ্গে মানিয়ে নিন: একটি requirement বদলান, তারপর শিক্ষার্থীকে implementation ও test সংশোধন করতে বলুন। তিনি AI ব্যবহার করতে পারেন, তবে নতুন আচরণের যুক্তি দিতে হবে এবং আর কী পরীক্ষা বাকি তা জানাতে হবে।
যেমন, কোনো assistant নতুন asynchronous কাজ লিখে দিলে reviewer জিজ্ঞেস করতে পারেন, মাঝপথে cancel করলে কী ঘটবে। developer-কে প্রক্রিয়াটি ব্যাখ্যা করতে এবং বদলানো requirement পরীক্ষা করতে পারা উচিত। শুধু code review ত্রুটি ধরতে পারে, কিন্তু পরের ত্রুটি সামলানোর ক্ষমতা শিক্ষার্থীর মধ্যে তৈরি না-ও করতে পারে। প্রস্তাবিত অনুশীলনটি জিজ্ঞেস করে, দেওয়া কোডের সঙ্গে জ্ঞানও এসেছে কি না।
এর অর্থ প্রতিটি নিয়মিত ticket-কে পরীক্ষা বানানো নয়। দল অপরিচিত library, বারবার হওয়া failure বা পরে যে কাজে কোনো junior সহকর্মীর দায়িত্ব আসবে—সেসব ক্ষেত্রে এই অনুশীলন রাখতে পারে। এতে কাজের সময় এবং system বোঝেন এমন reviewer লাগে। ব্যবস্থাপনা যদি শুধু merge হওয়া কাজ ও বাঁচানো সময় গোনে, তবে এই খাতগুলোতেই প্রথম কাটছাঁট হতে পারে। এতে আজকের উৎপাদন বাড়লেও প্রশিক্ষণের সমস্যা আরও কঠিন হবে।
শিক্ষানবিশির প্রশ্ন নিয়োগ ও product design-এও পৌঁছায়
জুনিয়র ভূমিকায় প্রায়ই কাজ শেষ করা এবং তত্ত্বাবধানে অনুশীলন—দুটিই থাকে। কোনো প্রার্থী চমৎকারভাবে feature শেষ করলেন, কিন্তু কীভাবে ভেবে সিদ্ধান্ত নিয়েছেন তা দেখালেন না—এ অবস্থায় AI ভারসাম্য বদলে দেয়। ঝকঝকে repository-কে স্বাধীন দক্ষতার প্রমাণ না ধরে নিয়োগদাতারা প্রার্থীকে ছোট কাজ ব্যাখ্যা ও পরিবর্তন করতে বলতে পারেন। এটি নিয়োগের জন্য প্রস্তাবিত উপায়, বর্তমান নিয়োগ-প্রবণতার প্রমাণ নয়। এতে সেই দক্ষতাই যাচাই করা উচিত, যা ভূমিকাটির সত্যিই দরকার—প্রত্যেক প্রার্থীকে tool ছাড়া কাজ করানো নয়।
Coding product-গুলোর সামনেও একই ধরনের পছন্দ আছে। কোনো assistant দ্রুত উত্তরকে অগ্রাধিকার দিতে পারে; অথবা অনুমান যাচাই, ধারণাগত প্রশ্ন করা এবং সমাধান দেখানোর আগে পরিবর্তন পরীক্ষা সহজ করতে পারে। গবেষণায় দেখা কথোপকথনের ধরন দ্বিতীয় নকশাটি পরীক্ষা করার কারণ দেয়, যদিও কোনো নির্দিষ্ট interface ভালো শেখায়—এটি তারা প্রমাণ করেনি। নিয়োগদাতাদের কেনাকাটার প্রশ্নটিও একই: কোনো tool কি কর্মীকে ফল পর্যালোচনা ও পরিবর্তন করতে শেখায়, নাকি শুধু কত code তৈরি করে সেটিই দেখায়?
ছোট একটি quiz দিয়ে পাঁচ বছর পর কে বিশেষজ্ঞ হবেন তা বলা যায় না। তবে অপরিচিত কাজে গ্রহণ করা implementation যে বোঝাপড়ার প্রমাণের বিকল্প নয়, তা এটি দেখাতে পারে। স্বয়ংক্রিয়তার পাশাপাশি পরের প্রজন্মকে দক্ষ করতে চাওয়া দলকে অনুশীলনের সুযোগ রাখতে হবে এবং উত্তর বদলালে মানুষ কী করতে পারে, তা যাচাই করতে হবে।
