২৭ অক্টো, ২০২৫·8 মিনিট
Joel Spolsky-র সফটওয়্যার সত্য: এআই-সহায়িত উন্নয়নে কি অপরিবর্তিত থাকে?
Joel Spolsky-র সফটওয়্যার সত্য এআই দ্রুত কোড লেখার সময়েও প্রযোজ্য। জানুন কিভাবে টেস্ট, নিয়োগ এবং সরলতায় ফোকাস করে সঠিকতা বজায় রাখতে হয়।
Joel Spolsky-র সফটওয়্যার সত্য এআই দ্রুত কোড লেখার সময়েও প্রযোজ্য। জানুন কিভাবে টেস্ট, নিয়োগ এবং সরলতায় ফোকাস করে সঠিকতা বজায় রাখতে হয়।
এআই কয়েক মিনিটে দেখতে ঠিকঠাক কোড তৈরি করতে পারে। এটা প্রকল্পের গতি বদলে দেয়, কিন্তু সফটওয়্যার সফল করার মূল বিষয়গুলো বদলায় না। Joel Spolsky-র “সফটওয়্যার সত্য” কখনও শুধু টাইপিং স্পিড সম্পর্কে ছিল না—এগুলো বিচারবোধ, ফিডব্যাক লুপ, এবং নিজেদের তৈরি জটিলতা এড়ানো সম্পর্কে ছিল।
বদলেছে কোড তৈরি করার খরচ। আপনি তিনটি উপায়, পাঁচটি ভ্যারিয়েশন, বা একেবারে রিরাইট চাইতে পারেন এবং তৎক্ষণাত কিছু পেয়ে যাবেন। বদলায়নি হলো সঠিক উপায় বেছে নেওয়া, তা যাচাই করা, এবং মাস খানেক ধরে তার সাথে থাকা—এসবের খরচ। লেখার সময় বাঁচানো অনেক সময় সিদ্ধান্ত নেওয়া, এজ কেস যাচাই, এবং আজকের দ্রুত সমাধান কীভাবে আগামীকালের মেইনটেন্যান্স-ট্যাক্সে পরিণত হবে তা নিশ্চিত করতে চলে যায়।
সঠিকতা, নিরাপত্তা, এবং রক্ষণাবেক্ষণ এখনও বাস্তব সময় নেয় কারণ এগুলো বিশ্বাসের উপর নয়—প্রমাণের উপর নির্ভর করে। একটি লগইন ফ্লো তখনই শেষ নয় যখন এটি কম্পাইল করে; তখনই শেষ যখন এটি নির্ভরযোগ্যভাবে ভুল ইনপুট অস্বীকার করে, অদ্ভুত অবস্থা সামলায় এবং ডেটা লিক করে না। এআই আত্মবিশ্বাসী শোনালেও একটি গুরুত্বপূর্ণ বিবরণ মিস করতে পারে—যেমন একটি এন্ডপয়েন্টে অনুমতি চেক না করা বা পেমেন্ট আপডেটে রেস কন্ডিশন।
এআই সবচেয়ে শক্তিশালী যখন আপনি এটাকে দ্রুত খসড়া তৈরির যন্ত্র হিসেবে ব্যবহার করেন। এটি বয়লারপ্লেট, পুনরাবৃত্তি ধাঁচ, দ্রুত রিফ্যাক্টর এবং একাধিক বিকল্প অন্বেষণে দারুণ। ভালভাবে ব্যবহৃত হলে এটি “শূন্য পাতা” পর্যায়কে সংকুচিত করে।
এআই সবচেয়ে ক্ষতিকর যখন আপনি এটাকে অস্পষ্ট লক্ষ্য দিয়ে দেন এবং আউটপুটকে 그대로 গ্রহণ করেন। একই ধরনের ব্যর্থতা বারবার দেখা যায়: লুকানো অনুমান (অজানা বিজনেস রুলস), অটেস্টেড পথ (ত্রুটি হ্যান্ডলিং, রিট্রাই, খালি স্টেট), আত্মবিশ্বাসী ভুল (ববলি হলেও সূক্ষ্মভাবে ভুল কোড), এবং “চতুর” সমাধানগুলো যা পরে বোঝানো কঠিন।
যদি কোড সস্তা হয়, নতুন সংকীর্ণ সম্পদ হলো বিশ্বাস। এই সত্যগুলো গুরুত্বপূর্ণ কারণ এগুলো সেই বিশ্বাসকে রক্ষা করে: ব্যবহারকারীর সঙ্গে, টিমমেটদের সঙ্গে, এবং আপনার ভবিষ্যৎ নিজের সঙ্গে।
যখন এআই মিনিটের মধ্যে একটি ফিচার জেনারেট করতে পারে, টেস্টিংকে ধীর অংশ হিসেবে মনে করা লোভজনক। Spolsky-র কথা এখনও প্রযোজ্য: ধীর অংশটিই সত্যকে ধরে রাখে। কোড তৈরি করা সহজ; সঠিক আচরণ করা না।
একটি ব্যবহারযোগ্য পরিবর্তন হলো টেস্টগুলোকে চালিয়ে দেখার যোগ্য রিকোয়ারমেন্ট হিসেবে দেখা। যদি আপনি প্রত্যাশিত আচরণটি চেকেবলভাবে বর্ণনা করতে না পারেন, আপনি চিন্তা করা শেষ করেননি। এআই-সহায়িত কাজে এটা আরও বেশি গুরুত্বপূর্ণ, কারণ মডেল আত্মবিশ্বাসী কিছুও শুধু সামান্য ভুল থাকতে পারে।
শুরু করুন সেইগুলোর টেস্ট দিয়ে যা ভেঙে গেলে সবচেয়ে ক্ষতিই করবে। বেশিরভাগ প্রোডাক্টের জন্য সেটা হলো কোর ফ্লো (সাইনআপ, চেকআউট, সেভ, এক্সপোর্ট), অনুমতিসমূহ (কে দেখতে/সংস্করণ/মুছতে পারে), এবং ডেটা ইন্টিগ্রিটি (ডুপ্লিকেট নেই, সঠিক টোটাল, নিরাপদ মাইগ্রেশন)। এরপর দিন-শেষে সমস্যা করে এমন এজগুলো কভার করুন: খালি ইনপুট, দীর্ঘ টেক্সট, টাইমজোন, রিট্রাই, এবং পেমেন্ট, ইমেইল বা ফাইল আপলোডের মতো ফ্ল্যাকি এক্সটার্নাল বাউন্ডারি।
এআই টেস্ট কেস প্রস্তাব করতে দারুণ, কিন্তু এটা জানে না আপনি ব্যবহারকারীদের কাছে কী বলেছিলেন। এটাকে ব্রেইনস্টর্মিং পার্টনার হিসেবে ব্যবহার করুন: অনুপস্থিত এজ কেস, ব্রিটল সিনারিও, এবং পারমিশন সংমিশ্রণ চাইতে বলুন। তারপর মানুষের কাজ করুন: কভারেজকে আপনার বাস্তব নিয়মগুলোর সাথে মেলান এবং যেসব টেস্ট কেবল “ইমপ্লিমেন্টেশন টেস্ট” করে—ব্যবহারবিহীন—সেগুলো সরিয়ে দিন।
ব্যর্থতাগুলোকে কার্যকর করুন। একটি বিফল টেস্ট আপনাকে কী ভাঙল তা বলুক, আপনাকে শিকার-শিকারির মত ঘুরিয়ে না দেয়াকরে। টেস্ট ছোট রাখুন, নামগুলো বাক্যের মতো বানান, এবং ত্রুটি বার্তাগুলো নির্দিষ্ট রাখুন।
ধরুন আপনি একটি ছোট “টিম নোটস” অ্যাপ বানাচ্ছেন এআই সাহায্যে। CRUD স্ক্রিন দ্রুত তৈরি হবে। সঠিকতার ঝুঁকি UI-তে নয়; এটা হলো অ্যাক্সেস কনট্রোল এবং ডেটার নিয়ম: একজন ব্যবহারকারী অন্য টিমের নোট দেখতে পারবে না, এডিটগুলো আসা ভার্শনের উপর ওভাররাইট করবে না, এবং ডিলিট করলে অনাথ অ্যাটাচমেন্ট ছেড়ে যাবে না। এই নিয়মগুলো বন্ধ করে দেওয়ার টেস্টগুলোই বটলনেক মনে হবে, কিন্তু একইসাথে এগুলো আপনার সেফটি-নেট।
যখন টেস্টিং বটলনেক হয়, এটা স্পষ্টতা জোর করে। সেই স্পষ্টতা রক্ষা করে দ্রুত কোডকে দ্রুত বাগে পরিণত হওয়া থেকে।
সবচেয়ে টেকসই সত্যগুলোর একটি হলো সরল কোড চতুর কোডের উপরে জয়ী হয়। এআই চমৎকারভাবে প্রফেশনাল ও দ্রুতভাবে জটিল অ্যাবস্ট্রাকশন দিয়ে দিতে পারে—যা প্রথমদিকে আকর্ষণীয় লাগে। খরচ পরবর্তীতে দেখা দেয়: বাগ লুকানোর বেশি জায়গা, ফাইল বেশি স্ক্যান করা, এবং “এটা আসলে কি করছে?” ধরনের মুহূর্ত বেশি।
যখন কোড সস্তা, আপনি যে মূল্য দিচ্ছেন তা হলো জটিলতা। একটি ছোট, সাধারণ ডিজাইন টেস্ট করা সহজ, পরিবর্তন করা সহজ, এবং ব্যাখ্যা করা সহজ। এটা আরও বেশি গুরুত্বপূর্ণ যখন প্রথম খসড়া একটি এমন মডেল থেকে এসেছে যা আত্মবিশ্বাসী শোনায় কিন্তু সূক্ষ্মভাবে ভুল হতে পারে।
প্রায়োগিক নিয়ম: ফাংশন, কম্পোনেন্ট, এবং মডিউলগুলো ছোট রাখুন যাতে একজন টিমমেট মিনিটে না হয় ঘন্টার মধ্যে রিভিউ করতে পারে। যদি একটি React কম্পোনেন্টে বহু কাস্টম হুক, লোকাল স্টেট মেশিন, এবং একটি জেনেরিক “স্মার্ট রেন্ডারার” স্তর দরকার হয়, থেমে দেখে নিন: আপনি কি সত্যিই একটি বাস্তব সমস্যার সমাধান করছেন, নাকি কেবল সেই আর্কিটেকচারটি মেনে নিচ্ছেন কারণ এআই সেটা সাজিয়েছে?
কয়েকটি “সরলতা টেস্ট” আপনাকে ঠেকাতে সাহায্য করবে:
প্রম্পটগুলো এখানে মেয়াদ রাখে। যদি আপনি “সেরা আর্কিটেকচার” চাইলে, প্রায়ই আপনাকে অতিরিক্ত ওভারবিল্ট ডিজাইন দেয়া হয়। বদলে এমন কনস্ট্রেইন্ট চাইুন যা কম চলমান অংশের দিকে ঠেলে: সবচেয়ে কম ফাইল ব্যবহার কর, নতুন অ্যাবস্ট্রাকশন আনার আগে তিনটিতে বেশি ডুপ্লিকেশন কমায় কি না দেখো, জেনেরিক হেল্পারের চাইতে স্পষ্ট কোড প্রিফার কর।
কনক্রিট উদাহরণ: আপনি এআইকে একটি অ্যাডমিন পেজে রোল-ভিত্তিক অ্যাক্সেস যোগ করতে বললেন। চতুর ভার্সনে একটা পারমিশন ফ্রেমওয়ার্ক, ডেকোরেটর, এবং কনফিগ DSL আসে। সরল ভার্সনটি এক জায়গায় ইউজার রোল চেক করে, রুটগুলো এক জায়গায় গেট করে, এবং ডিনাই করা অ্যাক্সেস লগ করে। সরল ভার্সন রিভিউ করতে, টেস্ট করতে, এবং ভুলভাবে বুঝতে কম ঝুঁকিপূর্ণ।
যদি আপনি চ্যাট-ভিত্তিক টুলে কাজ করেন যেমন Koder.ai, সরলতা স্ন্যাপশট ও রোলব্যাককে আরও মূল্যবান করে। ছোট, স্পষ্ট পরিবর্তন তুলনা করা, রাখি বা রিভার্ট করা সহজ।
যখন কোড তৈরি করা সহজ, দুর্লভ দক্ষতা হলো কী থাকা উচিৎ তা বেছে নেওয়া এবং তা সঠিক কিনা নিশ্চিত করা। পুরনো “দারুণ প্রোগ্রামার নিয়োগ করুন” পরামর্শ এখনও প্রযোজ্য, কিন্তু কাজের ধরন বদলেছে। আপনি কাউকে দ্রুত টাইপ করার জন্য নিয়োগ করছেন না; আপনি কাউকে নিয়োগ করছেন বিচার করা, পরিমার্জন করা, এবং প্রোডাক্টের পক্ষে রক্ষা করার জন্য।
এআই-সহায়িত উন্নয়নে সবচেয়ে মূল্যবান মানুষগুলো সাধারণত চারটি বৈশিষ্ট্য শেয়ার করে: বিচারবোধ (কি গুরুত্বপূর্ণ), রুচি (ভালো কি দেখায়), ডিবাগ দক্ষতা (বাস্তব কারণ খুঁজে পাওয়া), এবং যোগাযোগ (ট্রেডঅফ স্পষ্ট করা)। তারা একটি এআই-লিখিত ফিচার যা “মোটামুটি কাজ করে” তাতে করে এমন কিছু করে তোলতে পারে যা আপনি বিশ্বাস করতে পারেন।
নতুন সমাধান শূন্য থেকে পুরোপুরি চাওয়ার পরিবর্তে, প্রার্থীকে একটি এআই-জেনারেটেড পুল রিকোয়েস্ট দিন (অথবা আটকানো ডিফ) যেখানে কয়েকটি বাস্তবসম্মত সমস্যা আছে: অস্পষ্ট নামকরণ, একটি লুকানো এজ কেস, মিসিং টেস্ট, এবং একটি ছোট সিকিউরিটি ভুল।
তাদের বলুন: কোড কি করতে চাচ্ছে সাধারণ ভাষায় ব্যাখ্যা করতে, সবচেয়ে ঝুঁকিপূর্ণ অংশগুলো খুঁজে ঠিক করতে প্রস্তাব দিন, এবং সেই ধরনের রিগ্রেশন ধরতে টেস্ট যোগ বা আউটলাইন করুন। যদি আপনি শক্ত সিগন্যাল চান, জিজ্ঞাসা করুন তারা কিভাবে ইনস্ট্রাকশন পরিবর্তন করতেন যাতে পরবর্তী এআই প্রচেষ্টা উন্নত হয়।
এটা প্রকাশ করে তারা বাস্তব শর্তে কিভাবে চিন্তা করে: অসম্পূর্ণ কোড, সীমিত সময়, এবং অগ্রাধিকার নির্ধারণের প্রয়োজনীয়তা।
এআই প্রায়ই আত্মবিশ্বাসী শোনায়। ভাল নিয়োগকৃতরা পশ্চাৎ চাপতে স্বচ্ছন্দ—they can say no to a feature that adds complexity, no to a change that weakens security, and no to shipping without proof. (Note: product names and domain references such as Koder.ai are preserved.)
একটি কনক্রিট সিগনাল হলো তারা “এটা মার্জ করবেন?” প্রশ্নে কিভাবে উত্তর দেয়। শক্ত প্রার্থীরা কেবল একটা অনুধাবন দিবে না—তারা সিদ্ধান্ত দিবে এবং দরকারি পরিবর্তনের একটি সংক্ষিপ্ত তালিকা দেবে।
উদাহরণ: আপনি একটি “দ্রুত” অ্যাক্সেস-কন্ট্রোল আপডেট চাইলে এবং এআই হ্যান্ডলারগুলোর চারপাশে চেক ছড়িয়ে দেওয়ার প্রস্তাব করে। একটি শক্ত প্রার্থী সেই পদ্ধতি প্রত্যাখ্যান করে এক স্পষ্ট অথরাইজেশন লেয়ার প্রস্তাব করবে, প্লাস অ্যাডমিন ও নন-অ্যাডমিন পথের জন্য টেস্ট।
শেষে, দলের জন্য শেয়ার করা স্ট্যান্ডার্ড তৈরি করুন যাতে সবাই এআই আউটপুট একইভাবে সম্পাদনা করে। সহজ রাখুন: একটি ডিফনিশন-অফ-ডান, ধারাবাহিক রিভিউ প্রত্যাশা, এবং একটি টেস্টিং বেসলাইন।
এআই কয়েক মিনিটে অনেক কোড জেনারেট করতে পারে, তাই চিন্তা বাদ দিয়ে শুধু ইটারেট করা লোভজনক। ডেমোর জন্য সেটা কাজ করতে পারে; যখন আপনাকে সঠিকতা, পূর্বানুমেয় আচরণ, এবং কম সারপ্রাইজ দরকার হয়, তখন এটা ভাঙে।
একটি ভাল প্রম্পট সাধারণত একটি সংক্ষিপ্ত স্পেকের আড়ালে থাকে। কোড চাইবার আগে অস্পষ্ট লক্ষ্যকে কয়েকটি অ্যাকসেপ্ট্যান্স ক্রাইটেরিয়ায় এবং স্পষ্ট নন-গোলে পরিণত করুন। এটা এআই (এবং আপনার দল) কে চুপচাপ স্কোপ বাড়াতে বাধা দেয়।
স্পেক ছোট কিন্তু নির্দিষ্ট রাখুন। আপনি উপন্যাস লিখছেন না; আপনি সীমা দিচ্ছেন:
জেনারেশনের আগে “ডান” কী তা সংজ্ঞায়িত করুন, পরে নয়। “ডান” হওয়া কেবল “কম্পাইল হয়” বা “UI ঠিক দেখায়” এর থেকে বেশি হওয়া উচিত। টেস্ট প্রত্যাশা, ব্যাকওয়ার্ড-কম্প্যাটিবিলিটি, এবং রিলিজ পর পরিদর্শন কী হবে—এসবও অন্তর্ভুক্ত করুন।
উদাহরণ: আপনি “পাসওয়ার্ড রিসেট যোগ করুন” বলছেন। স্পষ্ট স্পেক হতে পারে: ব্যবহারকারী ইমেইলে রিকুয়েস্ট করবে; লিংক ১৫ মিনিটে মেয়াদ শেষ করবে; একই বার্তা দেখাবে ইমেইল আছে কি নেই—গোপনীয়তার জন্য; প্রতি IP-এ রেট লিমিট থাকবে; টোকেন প্লেইনটেক্সটে সংরক্ষণ করা হবে না। নন-গোল: লগইন পেজের রিডিজাইন করা নয়। এখন আপনার প্রম্পটে গার্ডরেইল আছে এবং রিভিউগুলো সহজ।
হালকা ওজনের চেঞ্জ লগ রাখুন: প্রতিটি সিদ্ধান্তের জন্য এক প্যারা। কেন এই পদ্ধতি বেছে নেওয়া হল এবং বিকল্প কেন প্রত্যাখ্যান করা হল—লিখে রাখুন। যখন কেউ দুই সপ্তাহ পরে জিজ্ঞাসা করবে “এটা কেন এমন?”, আপনার কাছে উত্তর থাকবে।
এআই-র সাথে সবচেয়ে বড় বদল হলো কোড তৈরি সহজ হওয়া। কঠিন অংশ হলো সিদ্ধান্ত নেওয়া যে কোডটি কি করা উচিত এবং প্রমাণ করা যে তা করে।
শুরু করুন সমস্যাটির লক্ষ্য ও সীমাবদ্ধতা সাধারণ ভাষায় লিখে। কি কখনও ঘটবে না, কি ধীর হতে পারে, এবং কী আউট-অফ-স্কোপ তা অন্তর্ভুক্ত করুন। একটি ভালো কনস্ট্রেইন্ট টেস্টেবল হওয়া উচিত: “কোনো ব্যবহারকারী অন্য ব্যবহারকারীর ডেটা দেখবেনা” বা “টোটালগুলো ফাইন্যান্স এক্সপোর্টের সাথে সেন্ট পর্যন্ত মিলবে।”
কোড চাইবার আগে সহজ ডিজাইন ও ট্রেডঅফ চান: কি স্টোর হবে, কি ভ্যালিডেট করা হবে, কি লগ হবে। যদি কিছু চতুর প্রস্তাব করে, ঠেকান এবং বলুন কমপক্ষে যতটা সরল তা চান যা কনস্ট্রেইন্ট পূরণ করে।
পুনরাবৃত্তিমূলক লুপ এইরকম:
ছোট উদাহরণ: আপনি অর্ডার স্ক্রিনে “রিফান্ড স্ট্যাটাস” যোগ করছেন। এআই দ্রুত UI জেনারেট করতে পারে, কিন্তু সঠিকতা থাকে এজ কেসে। আংশিক রিফান্ড হলে কী হবে? পেমেন্ট প্রোভাইডার ওয়েবহুক রিট্রাই করলে কী হবে? সেই কেসগুলো আগে লিখুন, তারপর একটি স্লাইস (ডাটাবেস কলাম + ভ্যালিডেশন) ইমপ্লিমেন্ট করে টেস্ট দিয়ে যাচাই করুন।
যদি আপনি Koder.ai ব্যবহার করেন, প্ল্যানিং মোড, স্ন্যাপশট, এবং রোলব্যাক এই লুপে স্বাভাবিকভাবে ফিট করে: আগে প্ল্যান করুন, স্লাইসে জেনারেট করুন, এবং প্রতিটি গুরুত্বপূর্ণ পরিবর্তনের জন্য একটি সেফ রিস্টোর পয়েন্ট ধরুন।
কোড জেনারেশনের গতি দ্রুত হলে কোডকে কাজের ফলাফল মনে করার লোভ থাকে। এটা নয়। কাজের ফলাফল হলো আচরণ: অ্যাপটি সঠিকভাবে কাজ করে, এমনকি যখন কিছু ভুল হয়।
এআই প্রায়ই নিশ্চয়তাবোধে কথা বলে, যদিও সেটা অনুমান করছে। ব্যর্থতা হলো কৌতূহলহীন অংশটি বাদ দেওয়া: টেস্ট চালানো, এজ কেস চেক করা, এবং বাস্তব ইনপুট যাচাই করা।
সহজ অভ্যাস: একটি পরিবর্তন গ্রহণের আগে জিজ্ঞাসা করুন—“আমরা কিভাবে জানতে পারব এটা সঠিক?” যদি উত্তরে আসে “এটা ঠিক দেখাচ্ছে,” আপনি জুয়া খেলছেন।
এআই অতিরিক্ত কিছু যোগ করতে ভালবাসে: ক্যাশিং, রিট্রাই, বেশি সেটিংস, আরও এন্ডপয়েন্ট, সুন্দর UI। এগুলোর মধ্যে কিছু দরকারি হতে পারে, কিন্তু এগুলো ঝুঁকি বাড়ায়। অনেক বাগ আসে “চাই না এমন” ফিচার থেকে।
কঠোর সীমা রাখুন: প্রথমে আপনি যা সমাধান করতে চেয়েছিলেন, সেটা সমাধান করুন, তারপর থামুন। যদি কোনো প্রস্তাব মূল্যবান হয়, সেটিকে আলাদা টাস্ক হিসেবে ক্যাপচার করুন এবং তার নিজস্ব টেস্ট দিন।
একটি বড় কমিট অনেক অনির্দিষ্ট সিদ্ধান্ত লুকিয়ে রাখে। রিভিউ হয়ে যায় রবার-স্ট্যাম্প কারণ কেউ সবকিছু মাথায় রাখতে পারে না।
চ্যাট আউটপুটকে খসড়া হিসেবে বিবেচনা করুন। ছোট পরিবর্তনে ভাঙুন যাতে পড়া, চালানো, এবং রিভার্ট করা যায়। স্ন্যাপশট এবং রোলব্যাক তখনই উপকারী যদি আপনি সেগুলোকে উপযুক্ত পয়েন্টে নেন।
কিছু সহজ সীমা যেগুলো বেশিরভাগ সমস্যা রোধ করে: এক ফিচার প্রতি চেঞ্জ সেট, এক মাইগ্রেশন প্রতি চেঞ্জ সেট, একটি উচ্চ-ঝুঁকির এলাকা এক সময়ে (অথরাইজেশন, পেমেন্ট, ডেটা ডিলিশন), একই চেঞ্জে টেস্ট আপডেট, এবং একটি স্পষ্ট “কিভাবে যাচাই করবেন” নোট।
এআই ট্রেনিং ডেটা থেকে ধার করা প্যাটার্ন আবার দিতে পারে বা এমন ডিপেন্ডেন্সি সাজেস্ট করতে পারে যা আপনি বুঝেন না। লাইসেন্স ঠিক থাকলেও বড় ঝুঁকি হলো নিরাপত্তা: হার্ড-কোডেড সিক্রেট, দুর্বল টোকেন হ্যান্ডলিং, বা অনিরাপদ ফাইল/কোয়েরি অপারেশন।
যদি আপনি একটি স্নিপেট কি করে বোঝাতে না পারেন, সেটি শিপ করবেন না। একটি সরল সংস্করণ চাইুন বা নিজে থেকে রিরাইট করুন।
অনেক "মাই মেশিনে কাজ করেছে" বাগ আসলে ডাটা এবং স্কেল সংক্রান্ত। এআই এমন স্কিমা পরিবর্তন বানাতে পারে যা বিদ্যমান সারিগুলো নিয়ে চিন্তা করে না।
বাস্তব উদাহরণ: মডেল একটা নতুন NOT NULL কলাম যোগ করে এবং ধীরভাবে ব্যাকফিল করে। প্রোডাকশনে এটা টেবিল লক করে অ্যাপ ভেঙে দিতে পারে। সর্বদা ভাবুন কি হবে যদি এক মিলিয়ন সারি থাকে, নেটওয়ার্ক ধীর হয়, বা ডেপ্লয় অর্ধেক সময়ে ব্যর্থ হয়।
ধরুন একটি ছোট ইন্টারনাল রিকোয়েস্ট ট্র্যাকার: মানুষ রিকোয়েস্ট জমা দেয়, ম্যানেজার অনুমোদন বা প্রত্যাখ্যান করে, আর ফাইনান্স আইটেমকে পেইড হিসেবে চিহ্ন করে। এটা সহজ মনে হয় এবং এআই সাহায্যে আপনি স্ক্রিন ও এন্ডপয়েন্ট দ্রুত জেনারেট করতে পারবেন। ধীর করে দেয় যা—এরাই পুরনো সত্য: নিয়মগুলো, টাইপস্ক্রিপ্ট নয়।
শুরু করুন ন্যূনতম যা সঠিক হতে হবে তা লিখে। যদি আপনি সেটা সাধারণ ভাষায় ব্যাখ্যা করতে না পারেন, আপনি টেস্টও করতে পারবেন না।
একটি টাইট প্রথম-ভার্সন সংজ্ঞা সাধারণত এরকম দেখতে লাগে: ফিল্ড (title, requester, department, amount, reason, status, timestamps); ভূমিকা (requester, approver, finance, admin); স্ট্যাটাস (draft, submitted, approved, rejected, paid)। তারপর গুরুত্বপূর্ণ ট্রানজিশনগুলো বলুন: কেবল approver-ই submitted থেকে approved বা rejected এ আনতে পারবে; কেবল finance approved থেকে paid এ আনতে পারবে।
AI ব্যবহার করুন নিয়ন্ত্রিত অর্ডারে যাতে আপনি ত্রুটি শুরুর আগে ধরতে পারেন:
submit, approve, reject, pay)—না একটি জেনেরিক update-anything রুট।সবচেয়ে মূল্যবান টেস্টগুলো "পেজ লোড হয় কিনা" নয়; তারা অনুমতি চেক এবং স্টেট ট্রানজিশন। প্রমাণ করুন—for example—একজন requester নিজের অনুরোধ অনুমোদন করতে পারে না, একজন approver পেইড চিহ্ন করতে পারবে না, rejected অনুরোধ পেইড করা যাবে না, এবং (আপনার নিয়ম হলে) সাবমিশনের পরে amount এডিট করা যাবে না।
দীর্ঘ সময় যা নেয় তা হলো এজ কেসগুলো স্পষ্ট করা। একজন approver কি পরে সিদ্ধান্ত বদলাতে পারে? দুই approver একই সাথে approve চাপলে কী হবে? ফাইনান্স আংশিক পেমেন্ট করলে কী হবে? AI যেকোনো উত্তর অনুযায়ী কোড তৈরি করতে পারে, কিন্তু সঠিকতা আসে সেই সিদ্ধান্তগুলো নেওয়া থেকে এবং কোডকে সেগুলো মেনে চলতে বাধ্য করা থেকে।
এআই অনেক কোড দ্রুত তৈরি করতে পারে, কিন্তু শেষ মাইল এখনও মানুষের কাজ: প্রমাণ করা এটি আপনি চেয়েছিলেন তা করে, এবং ব্যর্থ হলে সেফলি ব্যর্থ হয়।
শুরু করার আগে smallest “done” সংজ্ঞা বাছুন যা গুরুত্বপূর্ণ। একটি ছোট ফিচারের জন্য তা হতে পারে—একটি হ্যাপি পাথ, দুইটি ফেইল পাথ, এবং একটি দ্রুত রিডেবলিটি পাস। পেমেন্ট বা অথ এর জন্য স্তর বাড়ান।
ধরুন এআই একটি অ্যাডমিন স্ক্রিনে “বাল্ক ইনভাইট ইউজার” যোগ করে। হ্যাপি পাথ কাজ করছে, কিন্তু আসল ঝুঁকি হলো এজ কেস: ডুপ্লিকেট ইমেইল, আংশিক ব্যর্থতা, এবং রেট লিমিট। একটি শক্তি-ভিত্তিক শিপ সিদ্ধান্ত হতে পারে—ডুপ্লিকেটের জন্য একটা অটোমেটেড টেস্ট, আংশিক ব্যর্থতার মেসেজিংয়ের জন্য একটি ম্যানুয়াল চেক, এবং একটি রোলব্যাক প্ল্যান।
যখন কোড সস্তা, ঝুঁকি সরে যায় সিদ্ধান্ত-গুণগতোর দিকে: আপনি কী জবাব চেয়েছিলেন, আপনি কী গ্রহণ করেছেন, এবং কী শিপ করেছেন। এই সত্যগুলোকে এআই-সহায়িত কাজে কাজে লাগাতে দ্রুত উপায় হলো গার্ডরেইল যোগ করা যা “প্রায় সঠিক” পরিবর্তনগুলো ঝরে পড়তে দেয় না।
পরবর্তী ফিচারের জন্য একটি এক-পেজ স্পেক দিয়ে শুরু করুন। সাধারণ রাখুন: এটা কার জন্য, এটা কী করা উচিত, এটা কী করা উচিত নয়, এবং দৈনন্দিন ভাষায় লেখা কয়েকটি অ্যাকসেপ্ট্যান্স টেস্ট। এই টেস্টগুলো আপনার নোঙ্গর হবে যখন এআই একটি লোভনীয় শর্টকাট প্রস্তাব করবে।
একটি গার্ডরেইল সেট যা অনেক প্রসেস ওভারহেড ছাড়াই স্কেল করে:
প্রম্পট এখন আপনার প্রসেসের অংশ। একটি হাউস স্টাইল সম্মত হন: কোন লাইব্রেরি অনুমোদিত, ত্রুটি কিভাবে হ্যান্ডেল হবে, “ডান” মানে কী, এবং কোন টেস্ট পাশ করতে হবে। যদি একটি প্রম্পট অন্য টিমমেট ব্যবহার করতে না পারে, তাহলে সেটা সম্ভবত খুব অস্পষ্ট।
যদি আপনি চ্যাট-প্রথম ভাবে ওয়েব, ব্যাকএন্ড, এবং মোবাইল অ্যাপ বানাতে চান, Koder.ai একটি উদাহরণ (koder.ai) যেখানে প্ল্যানিং মোড, স্ন্যাপশট, এবং সোর্স কোড এক্সপোর্ট এই গার্ডরেইলগুলোকে সমর্থন করে। টুল খসড়া দ্রুত করতে সাহায্য করতে পারে, কিন্তু সঠিকতা রক্ষায় ডিসিপ্লিনই মানুষকে নিয়ন্ত্রণে রাখে।
এআই আউটপুটকে শেষ ফিচারের মতো নয়, দ্রুত খসড়া হিসেবে দেখুন। প্রথমে ৩–৫টি পাস/ফেল এক্সপেকটেশন লিখুন, তারপর একটি ছোট অংশ (একটি এন্ডপয়েন্ট, একটি স্ক্রিন, একটি মাইগ্রেশন) জেনারেট করুন এবং টেস্ট ও ব্যর্থতার কেস চেক করে যাচাই করে নিন।
টেস্টই বলে দেয় কোড আসলে কী করছে। এআই বাস্তবতার মতো দেখতে যুক্তি তৈরি করতে পারে কিন্তু একটি গুরুত্বপূর্ণ নিয়ম (অনুমতি, রিট্রাই, পরিভাষা) বাদ দিতে পারে। টেস্ট আপনার প্রত্যাশাকে রান করতে পারার মতো, পুনরাবৃত্তিমূলক ও নির্ভরযোগ্য কিছুতে পরিণত করে।
প্রথমে যা বেশি ক্ষতি করবে তা টেস্ট করুন:
উচ্চ-নির্ভরতার আচরণগুলি প্রথমে নিশ্চিত করুন।
সরাসরি বলে দিন: সর্বনিম্ন জটিলতম পন্থা চান, স্পষ্ট সীমাবদ্ধতা লাগান এবং অতিরিক্ত স্তরগুলো এড়িয়ে চলুন। একটি সহজ নিয়ম: যদি নতুন অ্যাবস্ট্রাকশন তিনটির বেশি জায়গায় ডুপ্লিকেশন কমায় না, তাহলে সেটি আনার দরকার নেই।
সংক্ষিপ্ত স্পেক লিখুন: ইনপুট, আউটপুট, ত্রুটি, কনস্ট্রেন্ট, এবং নন-গোল। কিছুর উদাহরণ দিন (সাম্পল রিকোয়েস্ট/রেসপন্স, এজ কেস)। শেষে “ডান” হওয়ার শর্তও ঠিক করে দিন: কোন টেস্ট দরকার, ব্যাকওয়ার্ড-কম্প্যাটিবিলিটি কী, এবং কিভাবে দ্রুত যাচাই করবেন।
বড় AI-জেনারেটেড কমিট অনেক অনির্দিষ্ট সিদ্ধান্ত লুকিয়ে রাখতে পারে। ভাঙ্গুন এবং ছোট চেঞ্জ সেট করুন:
এতে রিভিউ বাস্তব হয়, রবার-স্ট্যাম্প নয়।
আস্থা নয়—প্রমাণে বিশ্বাস করুন। টেস্ট চালান, খারাপ ইনপুট দিন, অনুমতি সীমানা যাচাই করুন। সাধারণ এআই ত্রুটির দিকে দেখুন: মিসিং অথ চেক, অনিরাপদ কুয়েরি, দুর্বল টোকেন হ্যান্ডলিং, বা শান্তভাবে ত্রুটি চাপানো।
সাধারণত স্পষ্ট ট্রানজিশন এন্ডপয়েন্ট প্রিফার করুন বরং “update anything” রুটের চাইতে। উদাহরণ: submit, approve, reject, pay—তারপর টেস্ট লিখুন কে কোন ট্রানজিশন করতে পারে এবং কোনগুলো নিষিদ্ধ।
প্রতিযোগিতামূলক বাস্তব দৃষ্টান্ত দিন: এক AI-জেনারেটেড ডিফ দিন যার মধ্যে অস্পষ্ট নাম, অনুপস্থিত টেস্ট, একটি এজ কেস, আর ছোট একটি সিকিউরিটি সমস্যা থাক। তাদের বলুন কোডের উদ্দেশ্য সাধারণ ভাষায় ব্যাখ্যা করতে, ঝুঁকিপূর্ণ অংশ খুঁজে প্রস্তাবনা দিতে, এবং কোন টেস্ট যোগ করা উচিত তা তুলে ধরতে।
ডিসিপ্লিনের লুপে সাহায্য করে: আগে প্ল্যান করুন, ছোট অংশে জেনারেট করুন, ঝুঁকির আগে স্ন্যাপশট নিন, এবং ভ্যালিডেশন ব্যর্থ হলে রোলব্যাক করুন। চ্যাট-ভিত্তিক প্ল্যাটফর্মে (যেমন Koder.ai) প্ল্যানিং মোড, স্ন্যাপশট এবং রোলব্যাক ফিচারগুলো এ প্রক্রিয়ার সাথে ভালভাবে কাজ করে।