গত মাসে, একটি AI অ্যাসিস্ট্যান্ট একটি প্রোডাকশন প্রজেক্টের জন্য একটি Python স্ক্রিপ্ট তৈরি করে দিয়েছিল। আউটপুটটি কোনো ত্রুটি ছাড়াই চলেছে। ডেটাগুলোও সঠিক ছিল। কিন্তু ম্যানুয়াল রিভিউ করার পর দেখা গেল যে, ডাটাবেস কলের মধ্যে একটি N+1 query pattern লুকিয়ে ছিল। একটি ছোট ডেটাসেটের জন্য কোডটি ঠিকঠাক কাজ করেছিল। কিন্তু হাজার হাজার রেকর্ডের ক্ষেত্রে এটি স্কেল করলে অ্যাপ্লিকেশনটি প্যারেন্ট অবজেক্টগুলোর জন্য একটি কুয়েরি করবে এবং তারপর সম্পর্কিত ডেটার জন্য হাজার হাজার ফলো-আপ কুয়েরি করবে। এর ফলে একটি ভয়াবহ পারফরম্যান্স বিপর্যয় (performance cliff) ঘটবে যা কোনো ইউনিট টেস্ট দিয়ে ধরা সম্ভব হবে না।
এটাই আধুনিক সফটওয়্যার ডেভেলপমেন্টের বাস্তবতা। AI টুলগুলো এখন এমন গতিতে কোডিং, ডিবাগিং এবং আর্কিটেকচারাল পরামর্শ দিচ্ছে যা কোনো মানুষের পক্ষে সম্ভব নয়। এই গতিটি বাস্তব। তবুও এটি আপনার কাজের ধরনকে মৌলিকভাবে বদলে দিচ্ছে। আপনাকে এখন আর মূলত সিনট্যাক্স টাইপ করার জন্য বেতন দেওয়া হয় না। আপনাকে বেতন দেওয়া হয় অডিট করতে, আর্কিটেক্ট করতে এবং ঠিক এই ধরণের অদৃশ্য ফাঁদগুলো ধরতে।
"লজিক্যাল কিন্তু ভুল" এর নীরব বিপদ
AI-জেনারেটেড কোড প্রায়শই সঠিক মনে হয় কারণ এটি কম্পাইল হয়, চলে এবং প্রত্যাশিত মান প্রদান করে। উপরিভাগে এর লজিক ঠিক মনে হলেও, গভীরে এটি নিঃশব্দে ত্রুটিপূর্ণ হতে পারে।
রেগুলার এক্সপ্রেশন (regular expressions)-এর কথা ধরা যাক। একটি AI আপনাকে এমন একটি প্যাটার্ন দিতে পারে যা ইংরেজিতে ইমেল অ্যাড্রেস বা আইডেন্টিফায়ার নিখুঁতভাবে মেলানোর জন্য কাজ করে। কিন্তু সেই একই এক্সপ্রেশন যদি জার্মান উমলাউট (umlauts), আরবি স্ক্রিপ্ট বা ইউনিকোড নরমালাইজেশনের এজ কেসগুলোর (edge cases) ক্ষেত্রে ব্যবহার করা হয়, তবে এটি নিঃশব্দে ব্যর্থ হবে। কোডটি এমনভাবে ভুল নয় যা কোনো এরর বা এক্সেপশন (exception) থ্রো করবে; এটি কেবল বাস্তব জগতের বৈধ ডেটাগুলোকে বাদ দিয়ে দেয়।
ডাটাবেস কুয়েরির ক্ষেত্রেও একই রকম ঝুঁকি রয়েছে। একটি AI এমন একটি PostgreSQL কুয়েরি লিখতে পারে যা টেস্টিংয়ের সময় সঠিক রো (rows) প্রদান করে, কিন্তু তবুও এটি আপনার টেবিলগুলোকে ডেড টাপল (dead tuples) দিয়ে ফুলিয়ে দিতে পারে, ইনডেক্স ব্যবহার এড়িয়ে যেতে পারে, অথবা সিকোয়েন্সিয়াল স্ক্যান (sequential scans) বাধ্য করতে পারে যা প্রোডাকশন ওয়ার্কলোডকে অচল করে দেয়। একটি ডেমো ডেটাসেটে যা কাজ করে এবং বাস্তব লোডের অধীনে যা কাজ করে, তা দুটি ভিন্ন বিষয়। মেশিন ল্যাটেন্সি (latency) অনুভব করতে পারে না। এটি ক্লাউড বিল পরিশোধ করে না।
লেখা থেকে যাচাই করার দিকে পরিবর্তন
মূল পরিবর্তনটি হলো "আমি এটি কীভাবে লিখব?" থেকে "আমি এটি কীভাবে যাচাই করব?"—এই দিকে সরে আসা। যখন AI প্রথম ড্রাফটটি তৈরি করে দেয়, তখন আপনার মনোযোগ বা কগনিটিভ লোড (cognitive load) পরবর্তী ধাপের দিকে সরে যাওয়া উচিত। আপনাকে কোডটি এমনভাবে পড়তে হবে যেভাবে একজন সিকিউরিটি অডিটর পড়েন, একজন ক্লান্ত লেখক যেভাবে নিজের কাজ দ্রুত চোখ বুলিয়ে যান সেভাবে নয়।
এর জন্য ভিন্ন ধরণের শৃঙ্খলার প্রয়োজন। অটোমেশন বায়াস (Automation bias) একটি বাস্তব সমস্যা। যখন কোনো টুল সাবলীল এবং সিনট্যাক্টিক্যালি নিখুঁত আউটপুট দেয়, তখন মানুষের মস্তিষ্ক শিথিল হয়ে পড়ে। প্রেজেন্টেশনটি মার্জিত দেখে আপনি ধরে নেন যে এটি সঠিক। এই প্রবণতাকে প্রতিরোধ করাই এখন মূল দক্ষতা। যতক্ষণ না প্রমাণিত হচ্ছে, ততক্ষণ আপনাকে প্রতিটি পরামর্শকে একটি হাইপোথিসিস বা অনুমান হিসেবে ধরে নিতে হবে।
মেশিনের সাথে কাজ করা
একটি AI কোডিং অ্যাসিস্ট্যান্ট থেকে দরকারী আউটপুট পাওয়া মানে দ্রুত টাইপ করা নয়। এটি হলো মেশিনের ট্রেনিং ডেটা এবং আপনার নির্দিষ্ট বাস্তবতার মধ্যকার দূরত্ব কমিয়ে আনা। আপনি কিছু সুনির্দিষ্ট অভ্যাসের মাধ্যমে সেই দূরত্ব কমিয়ে আনতে পারেন।
আপনার প্রম্পটগুলোতে সুনির্দিষ্ট হোন। এখানে অস্পষ্টতা কবিতা তৈরি করে না; বরং এটি বাগ (bug) তৈরি করে। "optimize this function" এর মতো প্রম্পট সাধারণ বা জেনেরিক পরামর্শ ডেকে আনে। পরিবর্তে লিখুন, "refactor this Python loop to use a single bulk database update instead of iterated saves।" সুনির্দিষ্টতা সম্ভাবনার ক্ষেত্রকে সংকুচিত করে।
বাস্তব প্রেক্ষাপট (context) প্রদান করুন। আপনি যদি না বলেন, তবে AI জানবে না যে আপনি একটি Kubernetes ক্লাস্টারের ভেতরে PostgreSQL 15-এ Django 4.2 চালাচ্ছেন যেখানে ৩০ সেকেন্ডের একটি কঠোর রিকোয়েস্ট টাইমআউট রয়েছে। আপনার ডিপেন্ডেন্সি ভার্সন, আপনার ইন্টারনাল লাইব্রেরি এবং আপনার অনমনীয় সীমাবদ্ধতাগুলো তাকে জানান। কনটেক্সট কোনো সাজসজ্জা নয়; এটি হলো রক্ষাকবচ (guardrails)।
আপনার নিজস্ব ডকুমেন্টেশনের মাধ্যমে উত্তরগুলোকে ভিত্তি দিন। Retrieval-Augmented Generation বা RAG শুধুমাত্র চ্যাটবটের জন্য কোনো বাগওয়ার্ড নয়। আপনার অ্যাসিস্ট্যান্টকে আপনার আসল API স্পেসিফিকেশন, আপনার আর্কিটেকচার ডিসিশন রেকর্ড এবং আপনার কোডবেস কনভেনশনগুলোর দিকে নির্দেশ করুন। যখন মডেলটি ট্রেনিং ডেটা থেকে অনুমান করার পরিবর্তে আপনার ডকুমেন্টেশন থেকে তথ্য সংগ্রহ করে, তখন সাধারণ পরামর্শ এবং ব্যবহারযোগ্য কোডের মধ্যকার ব্যবধান নাটকীয়ভাবে কমে আসে।
জটিল কাজকে ছোট ছোট আলাদা কাজে ভাগ করুন। এজেন্ট প্যাটার্নগুলো তখনই সবচেয়ে ভালো কাজ করে যখন প্রতিটি ধাপের পরিধি (scope) সীমিত থাকে। একবারে একটি সম্পূর্ণ মাইক্রোসার্ভিস রিফ্যাক্টর করতে বলবেন না। প্রথমে ডেটা স্কিমা (data schema) চান। সেটি যাচাই করুন। তারপর মাইগ্রেশন স্ক্রিপ্ট চান। সেটি যাচাই করুন। এরপর সার্ভিস লেয়ারে যান।