একটি ছোট আপডেটে কেবল একটি পরিবর্তন কীভাবে করা যায় তা শিখুন—একই সাথে সমালোচনামূলক UI ফ্লো, ব্যবসায়িক নিয়ম, এবং গুরুত্বপূর্ণ আচরণ ফ্রিজ করে রেখে যাতে কিছুই বদলায় না।
একটি “ছোট” পরিবর্তন কয়েকবারই সত্যিই ছোট থাকে। আপনি একটি বোতামের লেবেল সামান্য পরিবর্তন করতে বলেন, এবং হঠাৎ করে একটি পেজ লেআউট বদলে যায়, একটি ফর্ম ভ্যালিডেশন বন্ধ করে, অথবা চেকআউটে একটি ধাপ ভিন্ন আচরণ করতে থাকে। অ্যাপগুলো সংযুক্ত সিস্টেম। UI, লজিক, ডেটা এবং ইন্টিগ্রেশন একে অপরের উপর নির্ভর করে।
একটি সাধারণ কারণ হলো অস্পষ্ট সীমা। যদি অনুরোধে বলা থাকে “সাইনআপ সহজ করুন,” তাহলে নির্মাতা (মানব বা AI) কে সিদ্ধান্ত নিতে হয় “সহজ” বলতে কি বোঝায়। অনুমান করার ফলে অতিরিক্ত সম্পাদনা আসে: ফিল্ডগুলো অপসারণ, ধাপ পরিবর্তন, কপি সামঞ্জস্য বা ভ্যালিডেশন পুনরায় লেখা। আরেকটি কারণ হলো লুকানো নির্ভরতা। একটি ক্ষুদ্র UI পরিবর্তনটি এমন একটি কম্পোনেন্ট ব্যবহার করতে পারে যা পাঁচটি অন্য স্ক্রিনেও আছে।
নিরাপদ ইটারেশন মানে আপনি একমাত্র উদ্দেশ্যপ্রণোদিত উন্নতি পান এবং সবকিছু কার্যত অপরিবর্তিত থাকে। অ-টেকনিক্যাল দলের জন্য তা মানে ওয়ার্কফ্লোটি ব্যবহারকারীদের কাছে একই অনুভূতি দেয়, সাপোর্ট স্ক্রিপ্টগুলো প্রোডাক্টের সাথে মিল রেখে থাকে, এবং রিপোর্টিং মানে ধরে থাকে। টেকনিক্যাল দলের জন্য এটির মানে হঠাৎ করে রাউট, ডেটা আকার, API চুক্তি বা এজ-কেস আচরণ অনাকাঙ্ক্ষিতভাবে না বদলানো।
এটি সম্ভব করতে হলে আপনাকে তা ফ্রিজ করতে হবে যা অনুত্বরণযোগ্য নয়। বাস্তবে, এতে সাধারণত অন্তর্ভুক্ত থাকে সমালোচনামূলক ফ্লো (ব্যবহারকারীরা যে নির্দিষ্ট পদক্ষেপগুলো নেয়), UI ও UX বিবরণ (লেআউট, স্পেসিং, ইন্টারঅ্যাকশন আচরণ), ব্যবসায়িক নিয়ম (মূল্য নির্ধারণ, অনুমতি, ভ্যালিডেশন), ডেটা আচরণ (কি কখন সংরক্ষিত হয়) এবং ইন্টিগ্রেশন (অ্যানালিটিক্স ইভেন্ট, ইমেইল, পেমেন্ট, বাহ্যিক API)।
এই “পরিবর্তন করবেন না” প্রম্পট প্যাটার্নটি অনুমানকে সরিয়ে ঝুঁকি কমায় এবং পরিবর্তনকে স্কোপড রাখে। এটি কোনো সম্পূর্ণ গ্যারান্টি নয়। যদি মূল আচরণ খারাপভাবে সংজ্ঞায়িত থাকে, যদি পরিবর্তনটি শেয়ার্ড কম্পোনেন্ট স্পর্শ করে, বা আপনি ফলাফল যাচাই না করেন, তবে ড্রিফট হতে পারে। লক্ষ্য হলো কম অপ্রত্যাশিততা এবং দ্রুত অনুমোদন।
পরিবর্তন করবেন না প্যাটার্নটি একটি সহজ উপায় এক নির্দিষ্ট আপডেট চাইতে, এবং একসঙ্গে সবকিছু স্পষ্টভাবে লক করে দেওয়ার। আপনি একক পরিবর্তনটি নামবেন, তারপর একটি সংক্ষিপ্ত ফ্রিজ তালিকা লিখবেন সেই অংশগুলোর যা আপডেটের পরে অপরিবর্তিত থাকতে হবে।
এটি গুরুত্বপূর্ণ কারণ মডেলগুলো প্রায়ই সহায়ক হতে চেয়ে রিফ্যাক্টর, রিনেম, ফাইল পুনরায় সংগঠিত বা লজিক “পরিষ্কার” করার চেষ্টা করে যখন তারা কোড স্পর্শ করে। এমনকি যদি আউটপুট কাজ করেও, সেই অতিরিক্ত পরিবর্তনগুলো বাগ অনুপ্রবেশ করতে পারে, আচরণ বদলে দিতে পারে, বা রিভিউকে কঠিন করে তোলে।
এই দুই অনুরোধের তুলনা করুন:
“সেটিংস পেজটা ভালো করুন।” এটি ডিজাইন পরিবর্তন, কপি নতুনকরণ, লেআউট শিফট এবং লজিক টুইকের জন্য আমন্ত্রণ জানায়।
“শুধু লেবেল টেক্সট ‘Phone’ থেকে ‘Mobile phone’ এ পরিবর্তন করুন। লেআউট, ভ্যালিডেশন, বা সেভ আচরণ পরিবর্তন করবেন না।” এটা সংকীর্ণ, টেস্টেবল এবং নিরাপদ।
একটি শক্ত ফ্রিজ তালিকা সাধারণত তিনটি ক্ষেত্র আচ্ছাদন করে:
আপনি যখন এই প্যাটার্নটি একটি চ্যাট-ভিত্তিক বিল্ড টুল যেমন Koder.ai তে ব্যবহার করেন, ইটারেশনগুলো দ্রুত হয় কারণ মডেলটি বিস্তৃত “উন্নতি” করার বদলে একক সম্পাদনার উপর মনোযোগ দেয়।
এই প্যাটার্নটি সবচেয়ে ভাল কাজ করে যখন আপনার অনুরোধ একটি ছোট কন্ট্রাক্টের মত পড়ে: একটি পরিষ্কার লক্ষ্য, একটি ফ্রিজ করা তালিকা কি অপরিবর্তিত থাকবে, এবং কিছু যাচাইকরণ চেক।
এই টেমপ্লেটটি কপি করে বন্ধনীগুলো পূরণ করুন। সংক্ষিপ্ত রাখুন, কিন্তু নির্দিষ্ট রাখুন।
Goal (one sentence):
- Change: [describe the one small change you want]
Context (1-3 sentences):
- Current behavior: [what happens today]
- Desired behavior: [what should happen after]
DO NOT CHANGE (must remain identical):
- Critical flows: [e.g., sign up -> checkout -> receipt stays the same]
- UI/UX that must not move: [e.g., button location, labels, navigation order]
- Business rules: [e.g., pricing, permissions, validation rules]
- Data behavior: [e.g., database schema, stored fields, migration rules]
Constraints (limit drift):
- Scope: [only this screen / only this endpoint / only this component]
- Files/modules (if known): [list a couple, or say “only touch what’s necessary”]
- No refactors: do not rename, reorganize folders, or change formatting beyond the touched lines
Acceptance checks (how I will verify):
1) [a simple before/after check]
2) [a user path that must still work]
3) [a rule that must still hold]
Output requested:
- Provide a brief diff-style summary: what changed, where, and why
- Call out any risk or unclear requirement before implementing
একটি কংক্রিট উদাহরণ: যদি আপনি চেকআউট বাটনের রঙ পরিবর্তন করতে চান, আপনার লক্ষ্য হবে “প্রাইমারি চেকআউট বাটনের রঙ #1A73E8 এ আপডেট করুন।” আপনার DO NOT CHANGE আইটেমগুলো পুরো চেকআউট ফ্লো, বাটন টেক্সট, এবং প্রাইসিং ক্যালকুলেশন ফ্রিজ করা উচিত।
Koder.ai ব্যবহার করলে এই ফরম্যাট রিভিউগুলোকে দ্রুত করে কারণ আপনি গ্রহণযোগ্যতা চেকগুলোর ভিত্তিতে প্রিভিউ ও পরিবর্তন সারাংশ তুলনা করে অনুমোদন করতে পারবেন।
যখন আপনি একটি ছোট পরিবর্তন চান, কেবল “কিছুই ভাঙ্গবেন না” বলবেন না। ঠিক কোন ব্যবহারকারী যাত্রাগুলো একই আচরণ করবে তা নামান, প্রথম ক্লিক থেকে চূড়ান্ত ফলাফল পর্যন্ত। আপনি পুরো অ্যাপ ফ্রিজ করছেন না; আপনি সেসব অংশ ফ্রিজ করছেন যেখানে রিগ্রেশনগুলো সবচেয়ে ক্ষতিকর।
প্রাথমিকভাবে সমালোচনামূলক ফ্লোগুলো সাধারণ ভাষায় তালিকাভুক্ত করুন: লগইন (পাসওয়ার্ড রিসেটসহ), অনবোর্ডিং, চেকআউট, সেটিংস। প্রতিটি ফ্লো জন্য লিখুন “ডান” হওয়ার মানে কি। উদাহরণ: “ব্যবহারকারী ইমেল + পাসওয়ার্ড দিয়ে লগইন করতে পারে, ড্যাশবোর্ডে যায়, এবং রিফ্রেশের পরে সাইন ইন থাকে।”
তারপর তারা যে এজ-কেসগুলো ভুলে যায় সেগুলো লক করুন। ব্যাক বাটন আচরণ হল একটি ক্লাসিক সোর্স: “চেকআউট থেকে ব্যাক করলে কার্টে ফিরে যায় (হোমে নয়), এবং কার্ট আইটেমগুলো থাকে।” ত্রুটি স্টেট (“ভুল পাসওয়ার্ড একই বার্তাটি দেখায়”), খালি স্টেট (“কোন প্রোজেক্ট নেই” হলে একই কপি দেখায়), এবং লোডিং স্টেট (“স্পিনার 200ms-এর মধ্যে আসে, লেআউট ঝাঁকুনি নেই”) উল্লেখ করুন।
পারফরম্যান্স ও সিকিউরিটি সম্পর্কিত প্রত্যাশা গুরুত্বপূর্ণ হলে সেগুলোও ফ্রিজ করুন। যদি আপনি না বলবেন, মডেল অতিরিক্ত অনুরোধ, নতুন লগিং বা অরথ চেক যোগ করে “সुधারার” চেষ্টা করতে পারে।
একটি টাইটভাবে নির্দিষ্ট করার সহজ উপায়:
ডাটা ফ্লো প্রতি আইটেমে এক বাক্যে নির্দিষ্ট করুন। উদাহরণ: “Address কেবল Save চাপা হলে সংরক্ষিত হয়, user profile রেকর্ডে স্টোর হয়, এবং logout/login করার পরে বজায় থাকবে।” এই স্তরের বিশদ স্বয়ংক্রিয় সেভ, নতুন ফিল্ড বা টাইমিং পরিবর্তন প্রতিরোধ করে যা বাস্তব ব্যবহারকারীদের ভাঙতে পারে।
UI ড্রিফট সাধারণত ঘটে কারণ মডেল “সহায়ক” হয়ে স্টাইল, স্পেসিং বা কম্পোনেন্ট স্ট্রাকচার পরিষ্কার করে ফেলে। সমাধানটি ব্যবসায়িক লজিকের মতোই: যা অপরিবর্তিত থাকতে হবে তা নির্দিষ্ট করুন, এবং কেবলমাত্র এক জিনিস পরিবর্তন করার অনুমতি দিন।
দৃশ্যমান স্ট্রাকচার পিন করুন। লেআউট (কলাম/রো, হেডার ও ফুটার প্লেসমেন্ট), স্পেসিং নিয়ম (প্যাডিং, গ্যাপ, অ্যালাইনমেন্ট), এবং কম্পোনেন্ট আচরণ (হোভার, ডিজেবলড স্টেট, লোডিং স্পিনার, ত্রুটি বার্তা) উল্লেখ করুন। যদি কোনো কম্পোনেন্টের একটি নির্দিষ্ট অনুভূতি থাকে, তা স্পষ্টভাবে বলুন: “Button-এর সাইজ, রেডিয়াস, এবং রঙ ঠিক একই থাকতে হবে।”
রেস্পন্সিভ আচরণে স্পষ্ট নিয়ম দরকার। আপনি যদি মোবাইল উল্লেখ না করেন, টুলগুলো এটিকে “উন্নত” করার চেষ্টা করতে পারে। প্রতিটি ব্রেকপয়েন্টে কি হবে তা উল্লেখ করুন: স্ট্যাকিং অর্ডার, হিডেন এলিমেন্ট, ফিক্সড বার এবং ট্যাপ টার্গেট।
কপিও ফ্রিজ করুন। মডেলকে বলুন যে সমস্ত কপি, লেবেল, প্লেসহোল্ডার এবং হেল্পার টেক্সট অপরিবর্তিত থাকতে হবে, কেবলমাত্র আপনি যে স্ট্রিংটি পরিবর্তন করছেন তা বাদ দিয়ে। এটি নীরব পুনঃলিখন প্রতিরোধ করে যা অর্থ বা লেআউট বদলে দিতে পারে।
একটি সংক্ষিপ্ত প্রম্পট যা আপনি একটি চেঞ্জ রিকোয়েস্টে পেস্ট করতে পারেন:
যদি সম্ভব হয়, before/after স্ক্রিনশট চাইুন। স্ক্রিনশট না থাকলে একটি ছোট “UI diff” বর্ণনা (কী সরলেছে, কী রিসাইজ হয়েছে, কী রঙ বদলেছে) চেয়ে নিন যাতে আপনি আত্মবিশ্বাস নিয়ে অনুমোদন করতে পারেন।
ব্যবসায়িক নিয়ম হলো সেই জায়গাগুলো যেখানে একটি ছোট UI পরিবর্তন নিঃশব্দে বড় রিগ্রেশন সৃষ্টি করে। একটি লেবেল আপডেট ভদতে পারে গণনা, স্ট্যাটাস ট্রানজিশন, বা কে কোন রেকর্ড দেখতে পায় তা বদলে দিতে পারে। নিয়ম ও ডেটা আচরণকে ফ্রিজ কনট্র্যাক্ট হিসেবে বিবেচনা করুন।
শুরু করুন কিছু নিয়ম নাম দিয়ে যেগুলো বদলে গেলে সবচেয়ে ক্ষতি হবে। এগুলোকে টেস্টের মত লিখুন: ইনপুট, আউটপুট, এবং কে কি করতে পারবে।
“কীভাবে প্রাইসিং একই রাখবেন” বলার বদলে নির্দিষ্টভাবে বলুন:
ভাষ্যত্ব কমানোর জন্য একটি সংখ্যাসূচক উদাহরণ যোগ করুন। উদাহরণ: “Order subtotal $120, discount 10% (প্রযোজ্য করের আগে), ট্যাক্স 8.25% ডিসকাউন্টকৃত পরিমাণে। প্রত্যাশিত মোট = (120 - 12) * 1.0825 = $116.91। শেষ মোটে 2 দশমিক পর্যন্ত রাউন্ডিং।”
রোল-ভিত্তিক ভিজিবিলিটি উল্লেখ করুন। উদাহরণ: “Support agent অর্ডার স্ট্যাটাস ও কাস্টমারের ইমেল দেখতে পায়, কিন্তু পুরো কার্ড ডিটেইল দেখতে পারবে না। কেবল অ্যাডমিনরা রিফান্ড ইস্যু করতে পারবে।”
ভ্যালিডেশন গুরুত্বপূর্ণ হলে সেগুলো স্পষ্ট করুন: ট্রিগার এবং ব্যবহারকারী-সম্মুখীন বার্তা উল্লেখ করুন: “যদি start date end date-এর পরে হয়, সেভ ব্লক করুন এবং দেখান: ‘End date must be after start date.’ এই লেখাটা পরিবর্তন করবেন না।”
বহির্ভূত উপপ্রভাব ভুলে যাবেন না। যদি আপনি ইমেইল, webhook বা তৃতীয়-পক্ষ API কল পাঠান, কি অপরিবর্তিত থাকবে তা ফ্রিজ করুন: ইভেন্ট নাম, পে-লোড ফিল্ড, টাইমিং (তৎক্ষণাৎ বনাম ডিলেইড), এবং idempotency আচরণ (রিট্রাইতে ডুপ্লিকেট পাঠানো হবে না)।
একটি ক্ষুদ্র আপডেটকে একটি মিনি কন্ট্রাক্ট হিসেবে বিবেচনা করুন। প্যাটার্নটি সবচেয়ে ভাল কাজ করে যখন পরিবর্তন সংকীর্ণ এবং সবকিছু স্পষ্টভাবে ফ্রিজ করা থাকে।
পরিবর্তনটি এক টেস্টেবল বাক্যে লিখুন। উদাহরণ: “Settings পেজে dark mode-enable করার জন্য একটি টগল যোগ করুন” টেস্টেবল। “Settings UI উন্নত করুন” নয়। 30 সেকেন্ডে টেস্ট করতে না পারলে এটা এখনও বিস্তৃত।
যেসব অংশ ড্রিফট হলে খারাপ হবে তাদের জন্য ফ্রিজ লিস্ট লিখুন: ইউজার ফ্লো, মূল UI উপাদান, ব্যবসায়িক নিয়ম, ডেটা আচরণ এবং যেকোনো API বা DB টেবিল যেগুলো অপরিবর্তিত থাকতে হবে।
গ্রহণযোগ্যতা চেক এবং একটি দ্রুত টেস্ট প্ল্যান যোগ করুন। এখানে আপনি “আমার পাশে ঠিক কাজ করে” ধরনের বিস্ময় প্রতিরোধ করবেন। চারটিপরীক্ষা লিখুন: নতুন টগল দেখা যায়, বিদ্যমান সেটিংস এখনও সেভ হয়, এবং পেজের অন্য কিছু নড়েনি ইত্যাদি।
এডিট শুরু করার আগে, সহকারীকে আপনার কনস্ট্রেইন্টগুলো আপনাকে পুনরায় বলার জন্য বলুন। সে কি পরিবর্তন করবে এবং কি অপরিবর্তিত থাকবে তা নিশ্চিত করুক। যদি সারাংশ ভুল হয়, প্রম্পট ঠিক করে তারপরই অনুমতি দিন।
সবচেয়ে ছোট সম্ভাব্য ইমপ্লিমেন্টেশন চাইুন: কোনো রিফ্যাক্টর নয়, নাম পরিবর্তন নয়, ফরম্যাটিং পাস নয়, ডিপেন্ডেন্সি আপগ্রেড নয়। আপনি একটি পরিবর্তন কিনছেন, মেকওভার নয়।
সংক্ষিপ্ত রিভিউ চেকলিস্ট:
এটি বিশেষভাবে Koder.ai তে ভালো কাজ করে: ফ্রিজ লিস্ট Planning Mode-এ পেস্ট করুন, constraints echoed করান, তারপর সবচেয়ে ছোট প্যাচ জেনারেট করান।
অধিকাংশ “ছোট” সম্পাদনা একই কারণে খারাপ হয়: অনুরোধ লক্ষ্যকে সুরক্ষা করে, কিন্তু আচরণকে না। মডেল আপনার লক্ষ্যে পৌঁছাতে পারে এমন নতুন উপায় অবলম্বন করে যা নীরবে স্ক্রীন, লজিক বা ডেটা বদলে দেয়।
একটি সাধারণ ফাঁদ হলো ফলাফলকে ফ্রিজ করা (“অনবোর্ডিং আরও মসৃণ করুন”) বদলে সঠিক ধাপে কি হচ্ছে তা ফ্রিজ করা। আরেকটি হচ্ছে “সবকিছু একই রাখুন” লেখা এবং সিস্টেম জানে ধরে নেওয়া।
সর্বাধিক দেখা ভুলগুলো:
একটি ছোট উদাহরণ: আপনি বলে দেন “বাটন আরও দৃশ্যমান করুন” এবং রঙ ফ্রিজ করেন, কিন্তু ডিজেবলড স্টেট ফ্রিজ করতে ভুলে যান। আপডেটটি বাটন সবসময় এনেবল করে দিতে পারে, যা পরবর্তীতে আচরণ বদলে দেয়।
কী সাহায্য করে: আপনি যা ফ্রিজ করেছেন তা যতটা সম্ভব নির্দিষ্ট করা। গ্রহণের আগে দ্রুত একটি রিগ্রেশন পাস করুন:
যদি এসব কোনোটা আলাদা থাকে, অনুরোধটি অনুপস্থিত ফ্রিজ ডিটেইলের ফল হল, “খারাপ কোডিং” নয়।
একটি সাধারণ নিরাপদ ইটারেশন হলো একটি ছোট UI পলিশ যেখানে ওয়ার্কফ্লো পরিবর্তন করা যাবে না।
পরিস্থিতি: একজন প্রতিষ্ঠাতা একটি সহজ সাইনআপ স্ক্রিন আছে যেখানে একটি সংক্ষিপ্ত ফর্ম (নাম, ইমেল, কোম্পানি সাইজ) এবং একটি প্রাইমারি বোতাম ফর্ম সাবমিট করে এবং ব্যবহারকারীদের ড্যাশবোর্ডে নিয়ে যায়।
সঠিক পরিবর্তন অনুরোধ (এক বাক্যে): “প্রাইমারি বোতামের টেক্সট 'Create account' থেকে 'Continue' এ রিনেম করুন এবং 'Company size' ফিল্ডটি ফ্রি-টেক্সট ইনপুট থেকে একটি ড্রপডাউন এ করুন।”
এখন প্যাটার্নটি প্রয়োগ করুন এবং কি অপরিবর্তিত থাকবে তা ফ্রিজ করুন:
আপনি কয়েক মিনিটে চালাতে পারেন এমন গ্রহণযোগ্যতা চেক:
একটি ভালো সহকারী উত্তর ফ্রিজ করা আইটেমগুলো পুনরায় বলবে, কোনো অস্পষ্টতা নিশ্চিত করবে (যেমন: ড্রপডাউন অপশনগুলো কি হবে এবং কী মান স্টোর হবে), তারপর কেবল সবচেয়ে ক্ষুদ্র কোড/UI পরিবর্তন করবে। এট should also উল্লেখ করবে কী deliberately না টাচ করেছে (রাউটিং, ভ্যালিডেশন লজিক, পে-লোড শেপ)।
একটি “ছোট পরিবর্তন” গ্রহণ করার আগে দ্রুত একটি পাস করুন যা নীরব ড্রিফট খোঁজে। লক্ষ্য পুরো QA নয়; লক্ষ্য হলো নিশ্চিত করা যে আপনি যেগুলো বলেছিলেন “পরিবর্তন করবেন না” তারা একই আছে, শুধু একমাত্র ইচ্ছাকৃত পরিবর্তনটি হয়েছে।
এই চেকগুলো প্রতি বার একই ক্রমে চালান। এটি রিভিউকে শান্ত রাখে এবং রিগ্রেশন খুঁজে পেতে সহজ করে।
যদি কোনো ফ্রিজ করা আইটেম বদলে যায়, রিভার্ট করুন—even যদি অ্যাপ “কাজ-করছে”। বদলে যাওয়া লেবেল, নতুন ফিল্ড, বা সামান্য ভিন্ন নিয়ম ইঙ্গিত করে মডেল অতিরিক্ত স্বাধীনতা নিয়েছে।
পুনরায় অনুরোধটি আরও কড়া কনস্ট্রেইন্ট দিয়ে ইস্যু করুন: এক বাক্যে পুনরায় একক পরিবর্তন বলুন, ফ্রিজ করা ফ্লো ও স্ক্রিন নামভিত্তিক রিস্টেট করুন, এবং যোগ করুন “কোন স্কিমা পরিবর্তন নয়, কোন এন্ডপয়েন্ট পরিবর্তন নয়, X-এর বাইরে কোন আচরণ পরিবর্তন নয়।” Koder.ai ব্যবহার করলে পরিবর্তন পরীক্ষার আগে স্ন্যাপশট নিলে রোলব্যাক এক ধাপে সম্ভব।
যদি আপনি Koder.ai তে বিল্ড করেন, “পরিবর্তন করবেন না” প্রম্পট প্যাটার্নটি অভ্যাস হিসেবে সবচেয়ে ভাল কাজ করে: এক ছোট পরিবর্তন, সবকিছু লক করা, এবং ডিফ দিলে ফিরে যাওয়ার পরিষ্কার উপায়।
পরিবর্তনের আগে Planning Mode-এ স্যুইচ করুন এবং সহকারীকে আপনার স্কোপ সংক্ষেপে পুনরায় বলাতে দিন। এটাকে ২টা জিনিস ফিরে বলান: (1) সঠিক পরিবর্তনটি, এবং (2) একটি পরিষ্কার ফ্রিজ তালিকা (ফ্লো, UI বিবরণ, এবং ব্যবসায়িক নিয়ম যা সরবে না)।
একটি কার্যকর পরিকল্পনা প্রম্পট: “আমার অনুরোধ পুনরায় বলুন। তারপর কী পরিবর্তন করা হবে না তা তালিকাভুক্ত করুন। যদি কিছুই অস্পষ্ট হয়, এডিট শুরু করার আগে প্রশ্ন করুন।”
প্রতিটি পরিবর্তন অনুরোধকে একটি চেকপয়েন্ট হিসেবে আচরণ করুন। পরিবর্তনের আগে একটি স্ন্যাপশট তৈরি করুন, তারপর যাচাই করে আরেকটি স্ন্যাপশট নিন। কিছু ভেসে গেলে রোলব্যাক করা প্যাচ চেয়ে দ্রুত।
উদাহরণস্বরূপ, আপনি React স্ক্রিনে একটি বোতাম লেবেল ঠিক করতে পারেন। পরিবর্তন ক্ষুদ্র মনে হলেও এটি স্পেসিং শিফট করতে, পুনরায় রেন্ডার ট্রিগার করতে, বা অটোমেটেড টেস্ট ভাঙাতে পারে। একটি স্ন্যাপশট তুললে আচরণ তুলনা করে দ্রুত রোলব্যাক করা যায়।
সহজ ওয়ার্কফ্লো:
Koder.ai ওয়েব (React), ব্যাকএন্ড (Go + PostgreSQL), এবং মোবাইল (Flutter) জেনারেট করতে পারে। প্যাটার্ন একই থাকে যদিও কোড ভিন্ন। আচরণ সংজ্ঞায়িত করে ফ্রিজ করুন, কেবল ফাইল নয়।
যদি আপনি একটি ব্যাকএন্ড এন্ডপয়েন্ট পরিবর্তন করছেন, রিকোয়েস্ট/রেসপন্স শেপ, ভ্যালিডেশন নিয়ম এবং ডাটা রাইট ফ্রিজ করুন। মোবাইল স্ক্রিন পরিবর্তন করলে ন্যাভিগেশন অর্ডার, ফিল্ড ডিফল্ট এবং ত্রুটি বার্তা ফ্রিজ করুন। ডাটাবেস লজিক পরিবর্তন করলে বিদ্যমান রো কিসের অর্থ তা ফ্রিজ করে মাইগ্রেশন নিরাপদ রাখুন।
আপনার টেমপ্লেট কপি করুন, আজই একটি ছোট পরিবর্তন চালান, এবং চেকলিস্ট দিয়ে যাচাই করে নিন। প্রতিবার একটিই টেক্সট ব্যবহার করুন এবং পরবর্তী পরিবর্তনের জন্য প্রতিস্থাপন করুন।
Use it whenever you want one specific change and you care that everything else stays the same. It’s especially useful for checkout, auth, billing, or any flow where small drift creates real user issues.
Because parts of an app share components, data, and rules. A tiny UI edit can touch a reused component, which can shift layouts elsewhere, alter validation, or change API payloads without you noticing until later.
Write one clear goal, then list what must remain identical after the change. The key is to freeze behavior (flows, rules, data, integrations) and visible UI details, not just say “don’t break anything.”
Keep it short but specific: critical flows, UI/UX details that must not move, business rules, data behavior, and integrations. If you can’t name what must stay the same, the model has to guess, and guessing causes drift.
Scope it to the smallest area that still protects you. For example, freeze the checkout flow and its shared components, but don’t freeze the entire app if you’re only changing a label on one screen.
Name the journeys step-by-step and define what “done” looks like. Add the common edge cases like back button behavior, error messages, empty states, and refresh behavior so the flow stays identical in the places users notice most.
Explicitly freeze layout structure, spacing, component states (hover/disabled/loading), and all copy except the one string you’re changing. Without that, models may “clean up” styles or rewrite text in ways that change meaning or layout.
Freeze contracts: request/response shapes, validation rules, permissions, calculations, and what gets stored and when. Add one numeric example for sensitive rules like pricing so there’s no interpretation during implementation.
Ask for acceptance checks you can run fast, plus a brief diff-style summary of what changed and where. Then verify the frozen flows end-to-end, trigger at least one error state, and confirm data/integrations didn’t change.
Take a snapshot before the change, run a planning pass that repeats the scope and freeze list, then apply the smallest patch. After verifying, snapshot again so rollback is one step if anything drifted.