AI সহায়ক দিয়ে কোডিং করার সময় ডেভেলপাররা কী ভুল করে?
ডেভেলপাররা AI কোডিং সহায়ক ব্যবহার করার সময় যে সাধারণ ভুলগুলি করে এবং বাগ ও দুর্বলতা শিপ করা এড়ানোর উপায় সম্পর্কে একটি ব্যবহারিক দৃষ্টিভঙ্গি।
Copilot, Claude এবং Cursor-এর মতো AI সহায়কগুলি যে গতিতে কোড লেখা হয় তা পরিবর্তন করেছে। কিন্তু এটি কতটা যত্ন সহকারে পর্যালোচনা করা প্রয়োজন তা পরিবর্তন করেনি। AI-সহায়িত কোডিং থেকে যে ক্ষতি আমি দেখেছি তার বেশিরভাগই মডেলগুলি থেকে নয়, বরং কয়েকটি পুনরাবৃত্তিমূলক অভ্যাস থেকে আসে।
সেগুলি পড়ে দেখার কথা না ভেবে পরামর্শগুলি গ্রহণ করা
সবচেয়ে বড় সমস্যা হল একটি সম্পূর্ণতা ট্যাব-স্বীকার করা কারণ এটি প্রশংসনীয় দেখায় এবং কম্পাইল করে। প্রশংসনীয় মানে সঠিক নয়। আমি একটি পরামর্শকৃত SQL কোয়েরি একটি রিফ্যাক্টরের সময় একটি WHERE ক্লজ নির্বিঘ্নে ড্রপ করতে দেখেছি এবং ব্যক্তি এটি গ্রহণ করেছে কারণ ভেরিয়েবল নামগুলি মিলেছিল। আপনি যদি একটি সহকর্মীর পুল রিকোয়েস্ট পড়ার মতো গতিতে প্রতিটি লাইন পড়ছেন না যা সহায়ক আপনাকে দেয়, তাহলে আপনি এমন কিছু শিপ করতে চলেছেন যা আপনি বুঝতে পারেন না। প্রতিটি পরামর্শকে একজন জুনিয়র ডেভেলপারের কাছ থেকে প্রথম খসড়া হিসাবে বিবেচনা করুন যে ব্যক্তি দ্রুত কিন্তু আপনার কোডবেসের সংগতির কোনো স্মৃতি নেই।
নিরাপত্তা-সংবেদনশীল কোডের জন্য এটির উপর বিশ্বাস করা
AI সহায়কগুলি বিশাল জনসাধারণের কোডে প্রশিক্ষিত, এবং সেই কোডের অনেকটির মধ্যে নিরাপত্তা সমস্যা রয়েছে। একটি দ্রুত ফাইল আপলোড হ্যান্ডলারের জন্য জিজ্ঞাসা করুন এবং আপনি প্রায়শই এমন কিছু পাবেন যাতে এক্সটেনশন চেক নেই, আকার সীমাবদ্ধতা নেই এবং একটি পথ স্ট্রিং সংযোজনের পরিবর্তে os.path.join বা একটি নিরাপদ লাইব্রেরি কল দিয়ে তৈরি। Auth-এর সাথে একই গল্প: সহায়করা localStorage-এ JWTs সংরক্ষণ করার পরামর্শ দিতে পছন্দ করে, বা == এর পরিবর্তে ধ্রুবক-সময়ের তুলনা ব্যবহার করে সিক্রেটের তুলনা করে। এটির কোনো অংশই দূষ্ট নয়, এটি শুধু প্রশিক্ষণ ডেটায় পরিসংখ্যানগতভাবে সাধারণ। প্রমাণীকরণ, ফাইল I/O, deserialization বা SQL টাচ করার যেকোনো কিছুর জন্য, যুক্তিটি নিজেই লিখুন বা AI-এর আউটপুটকে একই হুমকি-মডেলিং প্রশ্নের মাধ্যমে চালান যা আপনি যেকোনো নতুন কোডের জন্য জিজ্ঞাসা করবেন: শত্রুদের ইনপুট দিয়ে কী ঘটে, এই কলটি ব্যর্থ হলে কী ঘটে, অন্য কে এই এন্ডপয়েন্টে পৌঁছাতে পারে।
এটিকে নির্ভরশীলতা এবং API আবিষ্কার করতে দেওয়া
মডেলগুলি সম্পূর্ণ আত্মবিশ্বাসের সাথে প্যাকেজ নাম এবং ফাংশন স্বাক্ষর হ্যালুসিনেট করে। এটি "slopsquatting" সমস্যা — আক্রমণকারীরা নকল প্যাকেজ নাম নিবন্ধন করে যা মডেলগুলি ঘন ঘন পরামর্শ দেয়, তাই একটি যাচাইকৃত pip install বা npm install এমন কিছু টানতে পারে যা আপনার লগিং লাইব্রেরি নয়। একটি সহায়ক সুপারিশ করে এমন যেকোনো নির্ভরশীলতা যোগ করার আগে, এটি PyPI বা npm-এ প্রকৃতপক্ষে বিদ্যমান কিনা তা পরীক্ষা করুন, এর ডাউনলোড সংখ্যা এবং শেষ প্রকাশ তারিখ পরীক্ষা করুন এবং এটি ছোট হলে উৎস স্কিম করুন। API কলের ক্ষেত্রে একই সতর্কতা প্রয়োজন: যদি সহায়ক একটি পদ্ধতির রেফারেন্স দেয় যা আপনি চিনতে পারেন না, এটি বিদ্যমান বলে ধরে নেওয়ার আগে প্রকৃত ডকগুলি পরীক্ষা করুন।
আপনার নিজের কোডের মানসিক মডেল হারানো
আপনি যখন নিজে কোড লেখেন, তখন আপনি কেন প্রতিটি অংশ বিদ্যমান তার একটি মানসিক মানচিত্র তৈরি করেন। যখন আপনি একটি সেশন জুড়ে AI-উৎপন্ন কোডের বড় ব্লক স্বীকার করেন, সেই মানচিত্র দ্রুত পাতলা হয়ে যায়। তারপর একটি বাগ তিন সপ্তাহ পরে দেখা দেয় এবং আপনি এমন কোড ডিবাগ করছেন যা আপনি কখনো সত্যিকারের লেখেননি এবং পুরোপুরি মনে নেই। সমাধান হল AI-উৎপন্ন কোড এড়ানো নয়, বরং মার্জ করার আগে প্রতিটি খণ্ড নিজের কাছে বা একজন টিমম্যাটের কাছে ব্যাখ্যা করার জন্য যথেষ্ট ধীর হওয়া। আপনি যদি বলতে না পারেন কোনো ফাংশন কী করে এবং কেন এটি সেভাবে করে, তাহলে এখনও এটি মার্জ করবেন না।
কোড সম্পর্কে পরীক্ষা এড়িয়ে যাওয়া
AI সহায়তায় লেখা, পর্যালোচনা ও প্রকাশ করেছেন Michal Pilch (CISSP), Korra Studio।
এটি Korra Studio-র নলেজ বেস থেকে একটি নোট — প্ল্যাটফর্মটি প্রতিটি বিষয়কে ১-এর-সাথে-১ মেন্টরিংয়ের সাথে জুড়ে দেয়।
বিনামূল্যে শুরু করুনarrow_forward