চ্যাট মডেল আর কোডিং এজেন্ট আলাদা টুল
প্রথমেই আলাদা করে নেওয়া দরকার, কারণ দুটো প্রায়ই গুলিয়ে ফেলা হয়। একটা এজেন্টিক কোডিং টুল আপনার এডিটর বা টার্মিনালে থাকে, আপনার রিপোজিটরি পড়ে, আর ফাইল লেখে। একটা চ্যাট ওয়ার্কস্পেস হলো যেখানে আপনি চিন্তা করেন: আপনি একটা স্ট্যাক ট্রেস পেস্ট করেন, একটা পদ্ধতি নিয়ে তর্ক করেন, একটা ডিফ রিভিউ করেন, এমন একটা লাইব্রেরি বোঝেন যা আপনি আগে কখনো ব্যবহার করেননি, আর ডিজাইন ডকুমেন্ট লেখেন।
বেশিরভাগ ডেভেলপার শেষমেশ দুটোই ব্যবহার করেন, আর চ্যাটের দিকেই মডেল বাছাই সবচেয়ে বেশি গুরুত্বপূর্ণ হয়ে ওঠে, কারণ আপনি ডিফের বদলে যুক্তিটা পড়ছেন। এখানেই তিনটি আলাদা সাবস্ক্রিপশনের জন্য টাকা খরচ করে তিনটি মডেল তুলনা করার যুক্তি হারিয়ে যায়।
| আপনি কী করছেন | মডেলের প্রবণতা | নোট |
|---|---|---|
| কঠিন রিজনিং: কনকারেন্সি, সূক্ষ্ম রেস কন্ডিশন, স্থাপত্যগত সিদ্ধান্ত | Claude আর GPT উল্লেখযোগ্যভাবে ভিন্ন | দুটোকেই জিজ্ঞেস করুন। এখানেই দ্বিতীয় মতামত নিজের খরচ উসুল করে দেয় |
| প্রচলিত ক্ষেত্রে বাস্তবায়নের গতি | GPT | দ্রুত, প্রচলিত ধাঁচের, বয়লারপ্লেট আর কনভার্সনে ভালো |
| বড় অপরিচিত কোডবেস বা দীর্ঘ স্পেক পড়া | Gemini | সবচেয়ে বড় কনটেক্সট উইন্ডো, তাই সিস্টেমের বেশি অংশ একসাথে ধরে |
| একটা ত্রুটি বা ধারণা ব্যাখ্যা করা | যে ব্যাখ্যাটা মনে ধরে | ভিন্ন মডেল ভিন্নভাবে ব্যাখ্যা করে, আর এটাই মূল কথা |
| কঠোর স্ট্রাকচার্ড আউটপুট: কনফিগ, JSON, স্কিমা | GPT | একটা ফরম্যাট হুবহু মেনে চলায় সবচেয়ে নির্ভরযোগ্য |
স্ট্যাক ট্রেস পেস্ট করার চেয়ে ভালো ডিবাগিং প্রম্পট
একটা এরর পেস্ট করে জিজ্ঞেস করলে কী ভুল হয়েছে, তাতে একটা আন্দাজ পাওয়া যায়। আন্দাজটা প্রায়ই ঠিক হয়, আর যখন ভুল হয় তখন আপনি বিশ মিনিট খরচ করেন এমন একটা সমস্যার পেছনে ছুটে যেটা আপনার আসলে নেই। এই প্রম্পটগুলো উত্তরের ধরনটাই বদলে দেয়।
প্রম্পট: সমাধানের আগে অনুমান
এই যে এরর, কোড, আর আমি ইতিমধ্যে যা বাদ দিয়েছি। এখনই আমাকে কোনো সমাধান দেবেন না। সম্ভাব্যতা অনুযায়ী সাজিয়ে চারটা সবচেয়ে সম্ভাব্য কারণ তালিকাভুক্ত করুন, আর প্রতিটির জন্য সবচেয়ে সস্তা একটা চেক যা এটা নিশ্চিত বা বাতিল করবে। এরর: [পেস্ট করুন]। কোড: [পেস্ট করুন]। ইতিমধ্যে বাদ দেওয়া হয়েছে: [তালিকা]।
প্রম্পট: বাগ যা মাঝেমধ্যে ঘটে
এটা মাঝেমধ্যে ব্যর্থ হয়, মোটামুটি [ফ্রিকোয়েন্সি], [শর্তে]। এই যে প্রাসঙ্গিক কোড আর পরিবেশ সম্পর্কে আমি যা জানি। এই নির্দিষ্ট লক্ষণটা তৈরি করতে পারে এমন মাঝেমধ্যে ব্যর্থতার শ্রেণিগুলো তালিকাভুক্ত করুন (টাইমিং, অর্ডারিং, রিসোর্স নিঃশেষ হওয়া, বাহ্যিক নির্ভরতা, রান রানের মধ্যে স্টেট লিকেজ, ক্লক বা টাইমজোন, ক্যাশিং)। প্রতিটির জন্য বলুন আমি যা দিয়েছি তার মধ্যে কোন প্রমাণ এটাকে সমর্থন বা খণ্ডন করে, আর এগুলো আলাদা করতে আমার কী লগ করা উচিত।
প্রম্পট: নেওয়ার আগে সমাধানটা ব্যাখ্যা করুন
এই সমাধানটা কেন কাজ করে, এটা কী ঠিক করে না, আর এটা কী ভাঙতে পারে তা ব্যাখ্যা করুন। যদি প্রকৃত কারণ অন্য কোথাও থাকে আর এটা শুধু লক্ষণের প্যাচ হয়, তাহলে সরাসরি সেটা বলুন।
সেই শেষ প্রম্পটটাই AI সহায়তার সবচেয়ে ব্যয়বহুল ধরনটা ধরে ফেলে: এমন একটা পরিবর্তন যা লক্ষণটা মুছে দেয় অথচ আসল ত্রুটিটা কোডবেসেই থেকে যায়।
একই সমস্যায় দুটি মডেল, যা নিছক কৌশল দেখানো নয়
উত্তরটা যখন স্পষ্ট থাকে, একটা মডেলই যথেষ্ট। এই কৌশলটা তখনই কাজে দেয় যখন আপনি নিশ্চিত নন, আর এটা কাজ করে কারণ মডেলগুলো একই রকম নয়, বরং আলাদা আলাদাভাবে ব্যর্থ হয়।
কাজের কৌশলটা হলো দুটোকেই জিজ্ঞেস করে যেটা পছন্দ হয় সেটা বেছে নেওয়া নয়। বরং একজনকে জিজ্ঞেস করে তার উত্তর অন্যজনের হাতে দেওয়া:
প্রম্পট: উত্তরের বিরুদ্ধ পর্যালোচনা
আরেকজন ইঞ্জিনিয়ার এই সমস্যার জন্য এই সমাধানটা প্রস্তাব করেছেন। এতে কী ভুল আছে তা খুঁজুন: এজ কেসে সঠিকতা, কনকারেন্সি, এরর হ্যান্ডলিং, [স্কেলে] পারফরম্যান্স, অথবা একটা সহজ পদ্ধতি যা বাদ পড়ে গেছে। যদি এটা আসলেই ঠিক হয়, তাহলে অজুহাত বানানোর বদলে সরাসরি সেটা বলুন। সমস্যা: [পেস্ট করুন]। প্রস্তাবিত সমাধান: [পেস্ট করুন]।
দুটো ফলাফলই কাজের। হয় দ্বিতীয় মডেলটা একটা আসল ফাঁক খুঁজে পায়, যা মার্জ করার আগেই এখন আপনি জানেন, নয়তো এটা একমত হয়, যা প্রকৃত প্রমাণ কারণ এর দ্বিমত হওয়ার প্রতিটা কারণ ছিল। একই মডেলের সাথে বারবার চেষ্টা করার সাথে এর তুলনা করুন, যা নিজের সাথেই একমত হতে থাকে।
একই প্যাটার্ন ডিজাইন সিদ্ধান্তের ক্ষেত্রেও প্রযোজ্য:
প্রম্পট: অন্য পক্ষের যুক্তি দিন
আমি [প্রেক্ষাপট আর সীমাবদ্ধতা] এর জন্য [পদ্ধতি A] কে [পদ্ধতি B] এর ওপর বেছে নিচ্ছি। B এর পক্ষে সবচেয়ে জোরালো যুক্তিটা দিন। আমাদের সীমাবদ্ধতা সম্পর্কে কী সত্য হতে হতো যাতে B সঠিক পছন্দ হয়, আর তার কোনোটা কি এখানে সত্যি?
Whizi-এর সাইড-বাই-সাইড তুলনা ঠিক এই কারণেই আছে, আর এটা নথিভুক্ত করা আছে মডেল সাইড বাই সাইড তুলনা করুন-এ।
কোড রিভিউ আর অপরিচিত কোড পড়া
প্রম্পট: কঠোর একজন রিভিউয়ারের মতো ডিফ রিভিউ করুন
এই ডিফটা রিভিউ করুন। ক্রম অনুযায়ী বিভাগ: সঠিকতার বাগ, নিরাপত্তা সমস্যা, অপরিচালিত ব্যর্থতার ধরন, রেস কন্ডিশন, তারপর স্টাইল। প্রতিটা ফাইন্ডিংয়ের জন্য তীব্রতা, নির্দিষ্ট লাইন, আর কেন এটা সাধারণভাবে নয় এখানে গুরুত্বপূর্ণ তা বলুন। ফরম্যাটিং নিয়ে মন্তব্য করবেন না। যদি ডিফটা ঠিক থাকে, তাহলে সেটা বলুন। প্রেক্ষাপট: এই কোডবেসটা [স্ট্যাক আর কনভেনশন] ব্যবহার করে। ডিফ: [পেস্ট করুন]।
প্রম্পট: সদ্য পাওয়া একটা কোডবেস বুঝুন
এই যে প্রধান সোর্স ফাইলগুলো। তৈরি করুন: এন্ট্রি পয়েন্টগুলো, রিকোয়েস্ট থেকে রেসপন্স পর্যন্ত ডেটা ফ্লো, কোন স্টেট শেয়ার করা হয় আর কোথায় সেটা পরিবর্তিত হয়, বাহ্যিক নির্ভরতাগুলো আর প্রতিটা অনুপলব্ধ হলে কী ঘটে, আর জটিলতা আর কাপলিং-এর ভিত্তিতে সবচেয়ে সম্ভাব্য তিনটা অংশ যেখানে বাগ থাকতে পারে। আমি যা দিয়েছি তা থেকে আপনি কী নির্ধারণ করতে পারছেন না তা স্পষ্টভাবে বলুন।
সেই শেষ নির্দেশনাটা যতটা মনে হয় তার চেয়ে বেশি গুরুত্বপূর্ণ। মডেলগুলো আপনি পেস্ট করেননি এমন একটা ফাইলের আচরণ, শুধু নাম দেখে অনুমান করে, খুশিমনে বর্ণনা করে দেবে। অজানা বিষয়ের একটা স্পষ্ট তালিকা জোর করে বের করলে বুঝবেন কী পড়তে হবে।
প্রম্পট: এমন টেস্ট লিখুন যা আপনি ভাবেননি
এই ফাংশনের জন্য টেস্ট কেস লিখুন, এমন ইনপুটের ওপর জোর দিয়ে যা আমি সম্ভবত বিবেচনা করিনি: সীমানা, খালি আর নাল, ইউনিকোড, খুব বড় মান, একযোগে কল, আর ইমপ্লিমেন্টেশনের যেকোনো অন্তর্নিহিত ধারণা। প্রতিটা টেস্টের জন্য বলুন এটা কোন ধারণাটা যাচাই করছে। ফাংশন: [পেস্ট করুন]।
যেসব ব্যর্থতা আসলেই সময় নষ্ট করে
বানানো API। মডেলগুলো আত্মবিশ্বাসের সাথে এমন মেথডের নাম, প্যারামিটার, আর কনফিগারেশন কী তৈরি করে যা আসলে নেই, বিশেষ করে সম্প্রতি বদলানো বা কম প্রচলিত লাইব্রেরির ক্ষেত্রে। সিগনেচারটা দেখতে ঠিকই মনে হবে। অপরিচিত কিছুর ওপর ভিত্তি করে বানানোর আগে আসল ডকুমেন্টেশন দেখে নিন।
আত্মবিশ্বাসের সাথে ভুল সমাধান। টোনে কোনো সংকেত নেই। যে সমাধান আপনার সমস্যা মিটিয়ে দেয় আর যে সমাধান একটা সূক্ষ্ম নতুন সমস্যা তৈরি করে, দুটোই একই আত্মবিশ্বাসের সাথে দেওয়া হয়। সবসময় জিজ্ঞেস করুন পরিবর্তনটা কী ভাঙতে পারে।
পুরনো প্যাটার্ন। ট্রেনিং ডেটা একটা ফ্রেমওয়ার্ক নিয়ে লেখা কোডের পরিমাণের দিকে ঝোঁকে, যা প্রায়ই আগের মেজর ভার্সন। উত্তরটা যদি কয়েক বছর আগের মনে হয়, সম্ভবত সেটাই। প্রম্পটে বলুন আপনি কোন ভার্সনে আছেন।
নিঃশব্দ স্কোপ ক্রিপ। একটা ফিক্স চাইলে প্রায়ই একটা রিফ্যাক্টর পাওয়া যায়। ডিফটা রিভিউযোগ্য রাখতে যোগ করুন যতটা সম্ভব কম পরিবর্তন করুন, আর যা যা পরিবর্তন করেছেন আর কেন তার তালিকা দিন।
সিকিউরিটি থিয়েটার। একটা মডেল আপনার কোডে ভালনারেবিলিটির ধরনগুলো নাম করতে পারে, যা প্রথম পাসের জন্য সত্যিই কাজের, কিন্তু এটা অডিট নয়। এটা আপনার থ্রেট মডেল, আপনার ডিপ্লয়মেন্ট, বা আপনার ডেটার স্পর্শকাতরতা জানে না।
আপনার বাকি টুলিংয়ের সাথে এটা কোথায় বসে
এটা আপনার এডিটর ইন্টিগ্রেশন বা আপনার এজেন্টিক কোডিং টুলের বদলি নয়। এটা সেই তিনটা ব্রাউজার ট্যাবের বদলি যেখানে আপনি উত্তর তুলনা করছিলেন, সাথে সেই দুটো সাবস্ক্রিপশনও যা একসাথে সেই ট্যাবগুলো খোলা রাখতে দরকার ছিল।
বেশিরভাগ ডেভেলপার যে ব্যবহারিক সেটআপে থিতু হন: দ্রুত প্রশ্নের জন্য একটা ডিফল্ট মডেল, একটা দ্বিতীয় মডেল যাতে সুইচ করেন যখন প্রথম উত্তরটা বিশ্বাসযোগ্য মনে হয় না, আর Gemini যখন আপনার একসাথে অনেকটা কোড বা একটা দীর্ঘ স্পেসিফিকেশন মডেলের সামনে রাখা দরকার। সবকিছু একটাই থ্রেডে, যাতে আপনার আগে থেকে তৈরি করা প্রসঙ্গটা সুইচের সময় আবার পেস্ট না করে বহন করা যায়।
আরও গভীর কভারেজের জন্য দেখুন কোডিংয়ের জন্য AI, কোডিং-কেন্দ্রিক বিকল্পের তুলনা, আর Claude কোডিং প্রম্পট প্যাক। Whizi-এর ভেতরে সেই সেটআপ চালানোর খুঁটিনাটি আছে একাধিক মডেল দিয়ে কোড লিখুন আর ডিবাগ করুন-এ।
- ফিক্স চাওয়ার আগে সাজানো অনুমান আর সস্তা চেক চান
- প্রথম মডেলের উত্তর দ্বিতীয় একটার হাতে দিন আর ফাঁকটা খুঁজতে বলুন
- প্রস্তাবিত ফিক্স কী ভাঙতে পারে সবসময় জিজ্ঞেস করুন, আর এটা লক্ষণের প্যাচ কিনা তাও
- পুরনো প্যাটার্ন এড়াতে প্রম্পটে আপনার ভাষা, ফ্রেমওয়ার্ক, আর ভার্সন বলুন
- কোনো অপরিচিত API-এর ওপর ভিত্তি করে বানানোর আগে আসল ডকুমেন্টেশনের সাথে যাচাই করুন
- ডিফ রিভিউযোগ্য রাখতে "যতটা সম্ভব কম পরিবর্তন করুন আর প্রতিটা পরিবর্তনের তালিকা দিন" যোগ করুন
- প্রশ্নটা যদি সাধারণ প্রম্পটে ধরার চেয়ে বেশি কোড জুড়ে থাকে তাহলে বড়-কনটেক্সট মডেল ব্যবহার করুন
প্রায়ই জিজ্ঞাসিত প্রশ্ন
কেন শুধু একটা কোডিং মডেলেই থাকব না?
নিয়মিত কাজের জন্য, একটাই ঠিক আছে। মূল্যটা তখন দেখা যায় যখন আপনি সত্যিই নিশ্চিত নন, কারণ মডেলগুলো একই জায়গায় নয়, আলাদা আলাদা জায়গায় ব্যর্থ হয়। মডেল A-এর প্রস্তাবিত সমাধান মডেল B-এর হাতে দিয়ে ত্রুটি খুঁজতে বললে হয় মার্জ করার আগেই একটা আসল সমস্যা সামনে আসে, নয়তো একটা অর্থপূর্ণ নিশ্চয়তা পাওয়া যায়। একই মডেলের সাথে বারবার চেষ্টা করলে বেশিরভাগ ক্ষেত্রেই নিজের সাথে একমত হওয়াই পাওয়া যায়।
এটা কি একটা এজেন্টিক কোডিং টুলের বদলি?
না, তারা আলাদা সমস্যার সমাধান করে। একটা এজেন্ট আপনার রিপোজিটরিতে থাকে আর ফাইল এডিট করে। একটা চ্যাট ওয়ার্কস্পেস হলো যেখানে আপনি যুক্তি করেন: স্ট্যাক ট্রেস, ডিজাইনের তর্ক, ডিফ রিভিউ, অপরিচিত লাইব্রেরি বোঝা, আর ডিজাইন ডক লেখা। বেশিরভাগ ডেভেলপার দুটোই ব্যবহার করেন, আর চ্যাটের দিকে মডেল বাছাই বেশি গুরুত্বপূর্ণ কারণ আপনি ফলাফলের ডিফের বদলে যুক্তিটা মূল্যায়ন করছেন।
কোডিংয়ের জন্য কোন মডেল সবচেয়ে ভালো?
এটা কাজের ওপর নির্ভর করে, যা সৎ উত্তর আর এই পেজটা থাকার কারণ। প্রচলিত ইমপ্লিমেন্টেশনের কাজে GPT সাধারণত দ্রুত আর বেশি প্রচলিত ধাঁচের হয়। সূক্ষ্ম রিজনিং, অপরিচিত আর্কিটেকচার, আর কেন কিছু একটা নির্দিষ্টভাবে আচরণ করে তা ব্যাখ্যায় Claude সাধারণত বেশি শক্তিশালী। প্রশ্নে একসাথে অনেকটা কোড বা স্পেসিফিকেশন ধরে রাখা দরকার হলে Gemini জেতে। এক সপ্তাহ ধরে আপনার নিজের আসল সমস্যায় এগুলো তুলনা করা যেকোনো বেঞ্চমার্কের চেয়ে ভালো।
আমি কি প্রোপ্রাইটরি কোড পেস্ট করতে পারি?
Whizi আপনার কথোপকথনের ওপর ট্রেন করে না, আর প্রতিটা প্রোভাইডারের ডেটা নীতি সেই মডেল চালু করার আগে পর্যালোচনার জন্য উপলব্ধ থাকে। আপনার নিয়োগকর্তার নীতিই সাধারণত বাধ্যতামূলক সীমাবদ্ধতা আর এটা ব্যাপকভাবে ভিন্ন হয়, তাই সেটা যাচাই করুন। যেখানে সীমাবদ্ধতা প্রযোজ্য, একটা ব্যবহারিক পদ্ধতি হলো সমস্যাটা একটা ন্যূনতম উদাহরণে পুনরুৎপাদন করা যাতে স্ট্রাকচারটা থাকে কিন্তু বিজনেস লজিক থাকে না, যা প্রায়ই আরও ভালো উত্তর দেয়।
এটা সব কিছু আবার লেখা থেকে কীভাবে থামাব?
স্পষ্টভাবে নির্দেশ দিন: যতটা সম্ভব কম পরিবর্তন করুন, বিদ্যমান স্ট্রাকচার আর নামকরণ বজায় রাখুন, আর প্রতিটা লাইন যা পরিবর্তন করেছেন তার একলাইনের কারণসহ তালিকা দিন। অযাচিত রিফ্যাক্টর AI পরামর্শ রিভিউযোগ্য না হওয়ার প্রধান কারণ, আর ডিফ সীমাবদ্ধ রাখলে আপনি যুক্তি দিয়ে বুঝতে পারা একটা পরিবর্তন আর প্রথম থেকে আবার পড়তে হওয়া একটা পরিবর্তনের মধ্যে পার্থক্য তৈরি করে।