কীভাবে AI-উত্পাদিত কোড শুরুতেই ফ্রেমওয়ার্ক লক-ইন কমাতে সাহায্য করে

প্রারম্ভিক পণ্যের জন্য ফ্রেমওয়ার্ক লক-ইন কী বোঝায়

ফ্রেমওয়ার্ক লক-ইন ঘটে যখন আপনার পণ্য এমনভাবে বিশেষ কোনো ফ্রেমওয়ার্ক (বা ভেন্ডর প্ল্যাটফর্ম) এর সাথে আবদ্ধ হয়ে যায় যে পরে তা পরিবর্তন করা কোম্পানি রিরাইটের মতো মনে হয়। এটা শুধু “আমরা React ব্যবহার করছি” বা “আমরা Django বেছে নিয়েছি” নয়। সমস্যা তখন শুরু হয় যখন ফ্রেমওয়ার্কের কনভেনশনগুলো সবকিছুতে ছড়িয়ে পড়ে—ব্যবসায়িক নিয়ম, ডেটা এক্সেস, ব্যাকগ্রাউন্ড জব, অথেনটিকেশন, এমনকি ফাইল নামকরণ পর্যন্ত—এবং তখন ফ্রেমওয়ার্কটাই অ্যাপ হয়ে যায়।

সাধারণ ভাষায় লক-ইন কেমন দেখায়

একটি লক-ইন কোডবেসে প্রায়ই ব্যবসায়িক সিদ্ধান্তগুলো ফ্রেমওয়ার্ক-নির্দিষ্ট ক্লাস, ডেকোরেটর, কন্ট্রোলার, ORM, এবং মিডলওয়্যার-এর মধ্যে এমবেডেড থাকে। ফলাফল: এমনকি ছোট পরিবর্তনও (যেমন অন্য ওয়েব ফ্রেমওয়ার্কে স্যুইচ করা, ডেটাবেস লেয়ার বদলা, বা একটি সার্ভিস ভাগ করা) বড়, ঝুঁকিপূর্ণ প্রকল্পে পরিণত হতে পারে।

লক-ইন সাধারণত তখনই হয় যখন প্রথম দিকে দ্রুততার জন্য “শুধু ফ্রেমওয়ার্ক অনুসরণ কর” রুট নেওয়া হয়। এটা নিজে ভুল নয়—ফ্রেমওয়ার্কগুলোই আপনাকে দ্রুত কাজ করতে সাহায্য করে। সমস্যাটি শুরু হয় যখন ফ্রেমওয়ার্ক প্যাটার্নগুলো আপনার পণ্য ডিজাইন হয়ে যায়, বাস্তবায়নের বিশদ না হয়েই।

কেন প্রারম্ভিক-পণ্য সবচেয়ে বেশি ঝুঁকিতে থাকে

প্রারম্ভিক পণ্যগুলো চাপের মধ্যে তৈরি: আপনি আইডিয়া যাচাই করতে দৌড়াচ্ছেন, রিকোয়ারমেন্ট সপ্তাহে পরিবর্তিত হচ্ছে, এবং একটি ছোট দল অনবোর্ডিং থেকে বিলিং পর্যন্ত সবকিছু সামলাচ্ছে। এমন পরিবেশে কপি-পেস্ট প্যাটার্ন গ্রহণ করা, ডিফল্ট মান মেনে নেওয়া, এবং স্ক্যাফোল্ডিংকে স্ট্রাকচার নির্ধারণ করতে দেওয়া যৌক্তিক।

কিন্তু এই প্রথমের শর্টকাটগুলো দ্রুত জমে যায়। “MVP-প্লাস” পর্যায়ে পৌঁছলে আপনি দেখতে পারেন যে একটি গুরুত্বপূর্ণ প্রয়োজন (মাল্টি-টেন্যান্ট ডাটা, অডিট ট্রেইল, অফলাইন মোড, নতুন ইন্টিগ্রেশন) মূল ফ্রেমওয়ার্ক পছন্দের সাথে ভারী বাঁকানো ছাড়া ফিট করা যাচ্ছে না।

আসল লক্ষ্য: অপরিবর্তনীয় সিদ্ধান্ত বিলম্ব করানো

এটা ফ্রেমওয়ার্কগুলোকে চিরকালের জন্য এড়িয়ে চলা সম্পর্কে নয়। লক্ষ্য হলো পর্যাপ্ত সময় খুলে রাখা যতক্ষণ না আপনি বুঝতে পারেন আপনার পণ্য বাস্তবে কী চায়। ফ্রেমওয়ার্কগুলোকে প্রতিস্থাপনযোগ্য উপাদান হিসেবে রাখুন—সেখানে কোর নিয়মগুলো থাকার বদলে বাস্তবায়নের বিবরণ হিসেবে রাখুন।

AI-উত্পাদিত কোড কোথায় উপযোগী (এবং কোথায় নয়)

AI-উত্পাদিত কোড লক-ইন কমাতে সাহায্য করতে পারে যদি এটি পরিষ্কার সিম—ইন্টারফেস, অ্যাডাপ্টার, ভ্যালিডেশন, এবং টেস্ট—স্ক্যাফোল্ড করে, যাতে দ্রুত কাজ করতে গিয়ে আপনাকে প্রতিটি ফ্রেমওয়ার্ক সিদ্ধান্ত “বেক ইন” করতে না হয়।

কিন্তু AI আপনার স্থাপত্য আপনি কেমন হবে তা বেছে নিতে পারে না। যদি আপনি এটাকে “ফিচার তৈরি কর” বলে দেন বিনা সীমাবদ্ধতায়, এটি প্রায়ই ফ্রেমওয়ার্কের ডিফল্ট প্যাটার্নগুলোর অনুকরণ করবে। এখনও আপনিই দিশা নির্ধারণ করবেন: ব্যবসায়িক লজিক আলাদা রাখুন, ডিপেন্ডেন্সি বিচ্ছিন্ন করুন, এবং পরিবর্তনের জন্য ডিজাইন করুন—এমনকি দ্রুত শিপ করার সময়ও।

যদি আপনি কোনো AI ডেভেলপমেন্ট এনভায়রনমেন্ট ব্যবহার করেন (শুধু ইন-এডিটর সহায়তা নয়), এমন ফিচার দেখুন যেগুলো এই সীমাবদ্ধতাগুলো প্রয়োগ করা সহজ করে। উদাহরণস্বরূপ, Koder.ai-তে একটি প্ল্যানিং মোড আছে যার মাধ্যমে আপনি প্রথমে বাউন্ডারি স্পেল আউট করতে পারেন (যেমন, “core-এ কোনো ফ্রেমওয়ার্ক ইম্পোর্ট নেই”), এবং এটি সোর্স কোড এক্সপোর্ট সাপোর্ট করে—এভাবে আপনি পোর্টেবিলিটি রক্ষা করতে পারবেন এবং টুলিং সিদ্ধান্ত দ্বারা আটকে যাবেন না।

লক-ইন সাধারণত কীভাবে ঘটে (অকস্মাৎ)

ফ্রেমওয়ার্ক লক-ইন দুঃসাহসিকভাবে একটি ইচ্ছাকৃত সিদ্ধান্ত হিসেবে শুরু করে না। এটি সাধারণত ডজনগুলোর ছোট “শুধু শিপ কর” সিদ্ধান্ত থেকে বাড়ে যা মুহূর্তে নিরীহ মনে হয়, কিন্তু ধীরে ধীরে আপনার কোডবেসে অনুমান হিসেবে গেঁথে যায়।

সাধারণ ট্রিগারগুলো

কিছু প্যাটার্ন বারবার দেখা যায়:

• টাইট কাপলিং: ব্যবসায়িক নিয়ম সরাসরি ফ্রেমওয়ার্ক হেল্পার (requests, sessions, ORM মডেল) কল করে, নিজের পাতলা অ্যাবস্ট্র্যাকশন না রেখে।
• ভেন্ডর-নির্দিষ্ট API: সহজ সমাধানের জন্য বিল্ট-ইন কিউ, অথ, স্টোরেজ, অ্যানালিটিক্স ব্যবহার করা হয়, কিন্তু তার চারপাশে কোনো বাউন্ডারি নেই।
• হ্যাকগুলো স্থায়ী হয়ে যাওয়া: একটি প্রোটোটাইপ শর্টকাট “অস্থায়ী প্রোডাকশন” হয়ে যায়, তারপর কেউ সেটা ছুঁতে চায় না কারণ এটি কাজ করছে।

AI-উত্পাদিত কোড এই দুর্ঘটনাকে দ্রুততর করতে পারে: যদি আপনি “চলমান কোড” চাইবেন, AI প্রায়ই সবচেয়ে আইডিওম্যাটিক, ফ্রেমওয়ার্ক-নেটিভ ইমপ্লিমেন্টেশন দেবে—যা গতির জন্য ভালো, কিন্তু এটি নিরাশ্চর্যভাবে ডিপেন্ডেন্সিগুলো দ্রুত তুলিয়ে ধরতে পারে।

লক-ইন কোথায় লুকায় (উদাহরণসহ)

কিছু হাই-গ্র্যাভিটি এলাকায় লক-ইন গঠন হয়:

• রাউটিং এবং কন্ট্রোলার: রুট প্যারাম এবং মিডলওয়্যার অনুমান জায়গাজায় ছড়িয়ে পড়ে (যেমন, “সবকিছুর কাছে request অবজেক্ট আছে”)।
• অথেনটিকেশন ও অথরাইজেশন: রোল, সেশন, গার্ড এক প্রোভাইডারের ধারণার সাথে বাঁধা থাকলে ভবিষ্যৎ পরিবর্তন কঠিন হয়।
• ডেটা মডেল: ব্যবসার লজিক ORM মডেলগুলোর মধ্যে থাকলে implicit আচরণের জাল চলে আসে যা ঐ ORM-এ নির্দিষ্ট।
• UI কম্পোনেন্ট সিস্টেম: একবার প্রতিটি স্ক্রিন কোনো নির্দিষ্ট কম্পোনেন্ট লাইব্রেরির স্টাইলিং ও স্টেট প্যাটার্নের ওপর নির্ভর করে গেলে, বদলানো মানে রিরাইট।

দুর্ঘটনাজনিত বনাম ইচ্ছাকৃত লক-ইন

লক-ইন সবসময়ই খারাপ নয়। ফ্রেমওয়ার্ক ধার করা এবং সেটিতে ঝুঁকি নেওয়া তখনই ভাল সিদ্ধান্ত হতে পারে যখন গতিই গুরুত্বপূর্ণ। আসল সমস্যা হলো দুর্ঘটনাজনিত লক-ইন—আপনি ইচ্ছাকৃতভাবে প্রতিশ্রুতিবদ্ধ না থেকেও আপনার কোডে পরিষ্কার সিম থাকে না, যেখানে আরেকটি ফ্রেমওয়ার্ক বা মডিউল পরে plug-in হতে পারে।

AI-উত্পাদিত কোড কী করতে পারে (এবং কী পারে না)

AI-উত্পাদিত কোড সাধারণত ChatGPT বা ইন-এডিটর সহায়কদের মতো টুল ব্যবহার করে প্রম্পট থেকে কোড তৈরি করা: একটি ফাংশন, ফাইল স্ক্যাফোল্ড, টেস্ট, রিফ্যাক্টর সাজেশন, বা ছোট ফিচার। এটা দ্রুত প্যাটার্ন-ম্যাচিং প্লাস আপনি যা প্রদান করেছেন তার কনটেক্সট—উপকারী, কিন্তু যাদুকর নয়।

কী ভালো করে (শুরুতে)

প্রোটোটাইপ থেকে MVP-তে যাওয়ার সময় AI সবচেয়ে মূল্যবান হতে পারে সেই সময়সূচীগুলোতে যা আপনার পণ্যের সংজ্ঞা নির্ধারণ করে না:

• স্ক্যাফোল্ডিং: ফোল্ডার সেটআপ, মুল CRUD এন্ডপয়েন্ট, সাধারণ UI কম্পোনেন্ট, কনফিগ ফাইল, এবং বয়লারপ্লেট।
• গ্লু কোড: মডিউলগুলোর মধ্যে ডেটা ম্যাপিং, সার্ভিস ওয়ায়ারিং, ছোট অ্যাডাপ্টার লেখা, এবং পুনরাবৃত্ত রূপান্তর ব্যবস্থাপনা।
• রিফ্যাক্টরস অন রেলস: নাম বদলানো, হেল্পার এক্সট্রাক্ট করা, ফাইল বিভক্ত করা, ডুপ্লিকেশন পরিষ্কার করা—বিশেষ করে আপনি যদি ইতিমধ্যে দিকটা জানেন।

এইভাবে ব্যবহার করলে AI লক-ইন প্রেসার কমাতে পারে কারণ এটি আপনাকে বাউন্ডারির ওপর ফোকাস করতে মুক্তি দেয় (ব্যবসায়িক নিয়ম বনাম ফ্রেমওয়ার্ক গ্লু) বরঞ্চ যেটা ফ্রেমওয়ার্ক সহজ করে তা দ্রুত অনুসরণ করার চাপ দেয় না।

কী করতে পারে না (এবং কোথায় লক-ইন ঢুকে পড়ে)

AI সাধারণত নির্ভরযোগ্যভাবে করতে পারে না:

• আপনার জন্য স্থাপত্য বেছে নেওয়া বা দীর্ঘমেয়াদি রক্ষণাবেক্ষণ ট্রেডঅফ বুঝতে পারা।
• সূক্ষ্ম কাপলিং খুঁজে বের করা (যেমন, ORM মডেলে এমবেড হওয়া ব্যবসায়িক লজিক, ফ্রেমওয়ার্ক-নির্দিষ্ট ডেকোরেটর কথিত স্থানে ছড়িয়ে থাকা)।
• বর্ধনশীল কোডবেসে প্যাটার্নগুলো ধারাবাহিকভাবে বজায় রাখা ছাড়া শক্ত নির্দেশনা।

একটি সাধারণ ব্যর্থতা মোড হলো “এটা কাজ করে” কোড যা সুবিধাজনক ফ্রেমওয়ার্ক ফিচারের ওপর ভারী নির্ভর করে এবং ভবিষ্যৎ মাইগ্রেশন ধীরে ধীরে কঠিন করে তোলে।

সঠিক মানসিকতা: AI আউটপুট হলো একটি খসড়া

AI-উত্পাদিত কোডকে একটি জুনিয়র টিমমেটের প্রথম পাসের মতো মনে করুন: সহায়ক, কিন্তু পর্যালোচনা দরকার। বিকল্প চাইুন, ফ্রেমওয়ার্ক-নিরপেক্ষ সংস্করণ চাইুন, এবং মার্জ করার আগে যাচাই করুন যে কোর লজিক পোর্টেবল রয়েছে।

ব্যবসায়িক লজিককে ফ্রেমওয়ার্ক থেকে আলাদা করুন

যদি আপনি নমনীয় থাকতে চান, আপনার ফ্রেমওয়ার্ক (Next.js, Rails, Django, Flutter ইত্যাদি) কে একটি ডেলিভারি লেয়ার হিসেবে বিবেচনা করুন—ইউআরএল/HTTP রিকোয়েস্ট, স্ক্রিন, রাউটিং, অথ ওয়্যারিং, এবং ডেটাবেস প্লাম্বিং যেগুলো সামলাবে।

আপনার কোর ব্যবসায়িক লজিক হলো যা বদলালেও সত্য থাকা উচিত: প্রাইসিং রুল, ইনভয়েস ক্যালকুলেশন, অর্গানিজেশনাল এলিজিবিলিটি চেক, স্টেট ট্রানজিশন, এবং “শুধু অ্যাডমিনরা ইনভয়েস void করতে পারবে” রকম নীতি। এই লজিক জানা উচিত না যে এটি ওয়েব কন্ট্রোলার, মোবাইল বাটন, বা ব্যাকগ্রাউন্ড জব দ্বারা ট্রিগার হচ্ছে।

সবচেয়ে সহজ সীমানা: ফ্রেমওয়ার্ক কোড আপনার কোডকে কল করবে

কিছুটা প্রতিরোধমূলক নিয়ম:

ফ্রেমওয়ার্ক কোড আপনার কোডকে কল করবে, উল্টো নয়।

ফলে কন্ট্রোলার মেথডটি রুলে ভরে থাকা না করে পাতলা হবে: ইনপুট পার্স করুন → একটি ইউজ-কেস মডিউল কল করুন → রেসপন্স রিটার্ন করুন।

ইউজ-কেস ড্রিভেন মডিউল (এবং AI কিভাবে সাহায্য করে)

AI অ্যাসিস্ট্যান্টকে বলুন যে ব্যবসায়িক লজিককে plain মডিউল আকারে জেনারেট করতে:

• CreateInvoice
• CancelSubscription
• CalculateShippingQuote

এই মডিউলগুলো plain ডেটা (DTOs) গ্রহণ করবে এবং রেজাল্ট বা domain errors রিটার্ন করবে—কোনো রেফারেন্স থাকবে না ফ্রেমওয়ার্ক রিকোয়েস্ট অবজেক্ট, ORM মডেল বা UI উইজেটের।

AI-উত্পাদিত কোড বিশেষ করে উপযোগী যখন আপনি ইতিমধ্যেই হ্যান্ডলারগুলোর ভিতর মিশে থাকা লজিক এক্সট্র্যাক্ট করতে চান। আপনি একটি মেসি এন্ডপয়েন্ট পেস্ট করে বলতে পারেন: “Refactor into a pure CreateInvoice service with input validation and clear return types; keep the controller thin.”

একটি দ্রুত দুর্গন্ধ পরীক্ষাঃ smell test

যদি আপনার ব্যবসায়িক নিয়মগুলো ফ্রেমওয়ার্ক প্যাকেজ ইমপোর্ট করে (রাউটিং, কন্ট্রোলার, React হুকস, মোবাইল UI), আপনি লেয়ার মিশিয়েছেন। উল্টো চিন্তা করুন: ইম্পোর্টগুলো সবসময় ফ্রেমওয়ার্কের দিকে যাবে, এবং আপনার কোর লজিক পরে যখন ডেলিভারি লেয়ার পরিবর্তন করা দরকার হবে তখন পোর্টেবল থাকবে।

অপশন খোলা রাখার জন্য অ্যাডাপ্টার এবং ইন্টারফেস ব্যবহার করুন

অ্যাডাপটার হল ছোট “অনুবাদক” যা আপনার অ্যাপ ও একটি নির্দিষ্ট টুল/ফ্রেমওয়ার্কের মাঝে বসে। কোর কোড আপনার নিজের ইন্টারফেসকে কল করে (সাধারণ কনট্রাক্ট যেমন EmailSender বা PaymentsStore), এবং অ্যাডাপ্টারটি ব্যাখ্যা করে কিভাবে ওই ফ্রেমওয়ার্ক এটি করে।

এটি অপশন খোলা রাখে কারণ টুল বদলানো হলে একটি ফোকাসড পরিবর্তন হয়: অ্যাডাপ্টার বদলান, সম্পূর্ণ প্রোডাক্ট নয়।

অ্যাডাপ্টারগুলো সবচেয়ে গুরুত্বপূর্ণ কোথায়

কিছু জায়গা আছে যেখানে লক-ইন দ্রুত ঢুকে পড়ে:

• ডেটাবেস অ্যাকসেস: ORM বা ডেটাবেস ক্লায়েন্ট র‍্যাপ করুন যাতে আপনার ব্যবসায়িক লজিক কুয়েরি সিনট্যাক্স বা মডেলগুলোর ওপর নির্ভর না করে।
• HTTP ক্লায়েন্ট: ভেন্ডর SDK বা নির্দিষ্ট HTTP লাইব্রেরি HttpClient / ApiClient-এর পেছনে লুকান।
• কিউ এবং ব্যাকগ্রাউন্ড জব: SQS, RabbitMQ, Redis queues, বা ফ্রেমওয়ার্ক-নির্দিষ্ট জব রানারের মধ্যে পার্থক্য অ্যাবস্ট্র্যাক্ট করুন।
• ফাইল/স্টোরেজ: লোকাল ডিস্ক বনাম S3/GCS এবং তাদের অথ, পাথ, আপলোড সেমানটিকস আলাদা করে রাখুন।

যদি এই কলগুলো কোডবেস জুড়ে ছড়ানো থাকে, মাইগ্রেশন হচ্ছে “সবকিছু স্পর্শ করা।” অ্যাডাপ্টার দিলে এটা হচ্ছে “একটি মডিউল বদলানো।”

AI কিভাবে সাহায্য করে: জোড়া জোড়া দ্রুত জেনারেট করা

AI-উত্পাদিত কোড এখানে দুর্দান্ত: এটি 반복িত স্ক্যাফোল্ডিং তৈরি করতে পারে—একটি ইন্টারফেস + একটি কংক্রিট ইমপ্লিমেন্টেশন।

উদাহরণস্বরূপ প্রম্পট করুন:

• একটি ইন্টারফেস (Queue) যার মেথড আপনার অ্যাপের দরকার (publish(), subscribe())
• একটি ইমপ্লিমেন্টেশন (SqsQueueAdapter) যে নির্বাচিত লাইব্রেরি ব্যবহার করে
• একটি টেস্টের জন্য “ফেক” ইমপ্লিমেন্টেশন (InMemoryQueue)

আপনি এখনও ডিজাইন রিভিউ করবেন, কিন্তু AI বয়লারপ্লেটে কয়েক ঘণ্টা বাঁচাতে পারে।

অ্যাডাপ্টারগুলো পাতলা এবং সুইচেবল রাখুন

ভালো একটি অ্যাডাপ্টার বিরক্তিকরভাবে সাধারণ: ন্যূনতম লজিক, পরিষ্কার এরর, এবং কোনো ব্যবসায়িক নিয়ম নেই। যদি অ্যাডাপ্টারটা খুব স্মার্ট হয়ে ওঠে, আপনি শুধু লক-ইনকে আরেক জায়গায় সরিয়ে ফেলেছেন। ব্যবসায়িক লজিক কোরে রাখুন; অ্যাডাপ্টারকে প্রতিস্থাপনযোগ্য পাইপলাইন হিসেবে ধরে রাখুন।

প্রথমে কনট্র্যাক্ট জেনারেট করুন: স্কিমা, টাইপ, এবং ভ্যালিডেশন

ফ্রেমওয়ার্ক লক-ইন প্রায়ই একটি সরল শর্টকাট থেকে শুরু হয়: আপনি UI বানান, সেটি যে ডেটাবেস বা API আকার সুবিধাজনক সেটার সঙ্গে সরাসরি ওয়্যার করেন, এবং পরে দেখতে পান প্রতিটি স্ক্রিন একই ফ্রেমওয়ার্ক-নির্দিষ্ট ডাটা মডেল ধরে নেয়।

একটি “কনট্র্যাক্ট-ফার্স্ট” পদ্ধতি সেই অর্ডার উল্টে দেয়। এটির আগে যে কনট্র্যাক্টগুলো আপনার পণ্য নির্ভর করবে সেগুলো নির্ধারণ করুন—রিকোয়েস্ট/রেসপন্স আকার, ইভেন্ট, এবং কোর ডাটা স্ট্রাকচার। ভাবুন: “CreateInvoice কেমন দেখতে হবে?” এবং “Invoice কি নিশ্চিত করে?”—কোনো কনট্রোলার কিভাবে সিরিয়ালাইজ করে সেটা না।

একটি কন্ট্রোলারের আগে স্কিমা শুরু করুন

একটি পোর্টেবল স্কিমা ফরম্যাট (OpenAPI, JSON Schema, বা GraphQL schema) ব্যবহার করুন। এটি আপনার পণ্যের স্থিতিস্থাপক কেন্দ্রবিন্দু হয়ে যাবে—ভবিষ্যতে UI Next.js থেকে Rails-এ গেলে বা API REST থেকে অন্যকিছুতে গেলে এই কেন্দ্রস্থিরতা বজায় রাখবে।

AI বিরক্তিকর (কিন্তু গুরুত্বপূর্ণ) গ্লু জেনারেট করবে

স্কিমা তৈরির পর AI-উত্পাদিত কোড বিশেষভাবে উপযোগী কারণ এটি স্ট্যাক জুড়ে সামঞ্জস্যপূর্ণ আর্টিফ্যাক্ট তৈরি করতে পারে:

• টাইপ/ইন্টারফেস (TypeScript types, Kotlin data classes ইত্যাদি) স্কিমা থেকে
• রানটাইম ভ্যালিডেটরস (যেমন Zod/Ajv রুলস) যাতে অচল ডেটা আগেই ফিরিয়ে দেওয়া হয়
• টেস্ট ফিক্সচার: বৈধ ও অবৈধ পে-লোড উদাহরণ, এবং আপনি ভাবেন না এমন এজ-কেসগুলো

এতে ফ্রেমওয়ার্ক কাপলিং কমে কারণ আপনার ব্যবসা কোর অভ্যন্তরীণ টাইপ ও যাচাইকৃত ইনপুটের ওপর নির্ভর করে, না ফ্রেমওয়ার্ক রিকোয়েস্ট অবজেক্টের ওপর।

ধীরে পরিবর্তনের জন্য কনট্র্যাক্ট ভার্সন করুন

কনট্র্যাক্টগুলোকে প্রোডাক্ট ফিচারের মতো আচরণ করুন: সেগুলো ভার্সন করুন। এমনকি হালকা ভার্সনিং (/v1 বনাম /v2, অথবা invoice.schema.v1.json) আপনাকে ফিল্ডগুলো ধাপে ধাপে পরিবর্তন করতে দেয়। আপনি দুইটি ভার্সন সাপোর্ট করতে পারেন পরিবর্তনের সময়ে, কনট্রাক্টগুলো ধরে রেখে ফ্রেমওয়ার্ক বদলের সময় সহজ করে।

AI ব্যবহার করে টেস্ট দিয়ে সেফটি নেট বানান

টেস্টগুলো লক-ইন প্রতিরোধ করার সেরা টুলগুলোর একটি—কারণ ভাল টেস্টগুলো আচরণ বর্ণনা করে, ইমপ্লিমেন্টেশন নয়। যদি আপনার টেস্ট স্যুট স্পষ্টভাবে বলে “এই ইনপুট হলে এই আউটপুট দরকার”, আপনি পরবর্তীতে ফ্রেমওয়ার্ক বদলালেও অনেকটা আত্মবিশ্বাস নিয়ে পরিবর্তন করতে পারবেন। কোড বদলান যাবে; আচরণ বদলাতে পারবে না।

টেস্ট কেন লক-ইন কমায়

ফ্রেমওয়ার্ক লক-ইন প্রায়ই ঘটে যখন ব্যবসায়িক নিয়ম ফ্রেমওয়ার্ক কনভেনশনের সাথে জট বাঁধে। একটি শক্ত ইউনিট টেস্ট সেট সেই নিয়মগুলোকে উজ্জ্বল করে দেয় এবং সেগুলোকে পোর্টেবল করে তোলে। মাইগ্রেশনের সময় (বা শুধু রিফ্যাক্টরের সময়) আপনার টেস্ট প্রমাণ করে যে আপনি পণ্য ভাঙেননি।

AI আপনাকে সঠিক কিছু টেস্ট জেনারেট করতে সাহায্য করে

AI বিশেষভাবে কাজে লাগে:

• ব্যবসায়িক নিয়মের চারপাশের ইউনিট টেস্ট (প্রাইসিং, এলিজিবিলিটি, পারমিশন, স্টেট ট্রানজিশন)
• দ্রুত গতিতে ভুলে যাওয়া এজ-কেস (খালি ইনপুট, টাইমজোন, রাউন্ডিং, ডুপ্লিকেট সাবমিশন)
• বাগ রিপোর্ট থেকে রিগ্রেশন টেস্ট (“এটি আগেই ফেল করত; আর কখনো ফেল করবে না”)

প্রাকটিক্যাল ওয়ার্কফ্লো: একটি ফাংশন পেস্ট করুন + সংক্ষিপ্ত নিয়ম লিখুন, তারপর AI-কে টেস্ট কেস প্রস্তাব করতে বলুন—বাউন্ডারি সহ এবং “বিতর্কিত” ইনপুটগুলোও। আপনি এখনও কেসগুলো রিভিউ করবেন, কিন্তু AI দ্রুত আরও ক্ষেত্র কভার করতে সাহায্য করবে।

একটি টেস্ট পিরামিড লক্ষ করুন (টাওয়ার নয়)

ফ্রেমওয়ার্ক-ফ্লেক্সিবল থাকতে, বহু ইউনিট টেস্ট, কিছু ইন্টিগ্রেশন টেস্ট, এবং কয়েকটি end-to-end টেস্ট রাখুন। ইউনিট টেস্ট দ্রুত, সস্তা এবং কোনো একক ফ্রেমওয়ার্কে খুব কম বাঁধা।

সম্ভব হলে ফ্রেমওয়ার্ক-ভারী টেস্ট হেল্পার এড়ান

আপনার টেস্ট যদি একটি পূর্ণ ফ্রেমওয়ার্ক বুট দাবি করে, কাস্টম ডেকোরেটর বা হেভি মকিং ইউটিলিটি ব্যবহার করে যা কেবল একটি ইকোসিস্টেমে কাজ করে—তবে আপনার টেস্ট নিজেই ধীরে ধীরে লক-ইন হয়ে যাবে। পিউর ফাংশন ও ডোমেইন সার্ভিসের বিরুদ্ধে সাদাসিধা assertion প্রিফার করুন এবং ফ্রেমওয়ার্ক-স্পেসিফিক ওয়্যারিং টেস্টগুলোকে ছোট ও আলাদা রাখুন।

স্ট্যাক কন্ডেন্স না করে দ্রুত প্রোটোটাইপ করুন

প্রারম্ভিক পণ্যগুলোকে পরীক্ষা-নিরীক্ষার মতো আচরণ করা উচিত: একটা ছোট কিছু বানান, মাপুন কি হচ্ছে, তারপর শেখার ওপর ভিত্তি করে দিক পরিবর্তন করুন। ঝুঁকি হলো আপনার প্রথম প্রোটোটাইপ চাপেই “পণ্য” হয়ে যেতে পারে, এবং প্রথম স্ট্যাক পছন্দগুলো পরে undo করা ব্যয়বহুল হয়ে ওঠে।

প্রোটোটাইপগুলোকে ডিসপোজেবল পরীক্ষায় পরিণত করুন

AI-উত্পাদিত কোড বিভিন্ন ভ্যারিয়েশন দ্রুত পরীক্ষা করতে উপযুক্ত: React-এ একটি অনবোর্ডিং ফ্লো বনাম সার্ভার-রেন্ডার করা সংস্করণ, দুইটি পে-মেন্ট প্রোভাইডার, অথবা একই ফিচারের জন্য বিভিন্ন ডেটা মডেল। AI মিনিটে কাজযোগ্য স্ক্যাফোল্ডিং উত্পাদন করতে পারে, তাই আপনি প্রথম শিপ করা স্ট্যাকের উপর কোম্পানি বাজি না রেখে অপশন তুলনা করতে পারেন।

কিন্তু মূল বিষয় হলো অভিপ্রায়: প্রোটোটাইপগুলোকে অস্থায়ী লেবেল দিন, এবং প্রথমে ঠিক করে রাখুন তারা কী জিজ্ঞাসার উত্তর দেবে (যেমন, “ব্যবহারকারীরা ধাপ ৩ সম্পন্ন করে কি?” বা “এই ওয়ার্কফ্লো বোঝা সহজ কি?”)। উত্তর পেলে প্রোটোটাইপ কাজ শেষ করেছে।

সময়বদ্ধ করুন, তারপর সচেতনভাবে বাদ দিন

একটি সংক্ষিপ্ত সময়বক্স সেট করুন—প্রায় ১–৩ দিন—প্রোটোটাইপ তৈরি ও টেস্ট করার জন্য। সময়বক্স শেষ হলে একটি সিদ্ধান্ত নিন:

• Discard: কোড বাদ দিন এবং শুধুমাত্র শেখা রাখুন।
• Rebuild: নির্বাচিত পদ্ধতিটিকে পরিষ্কারভাবে পুনর্নির্মাণ করুন, প্রোটোটাইপকে রেফারেন্স হিসেবে ব্যবহার করে।

এতে “প্রোটোটাইপ গ্লু” (দ্রুত সমাধান, কপি-পেস্টেড স্নিপেট, ফ্রেমওয়ার্ক-স্পেসিফিক শর্টকাট) দীর্ঘমেয়াদী কাপলিংতে পরিণত হওয়ার ঝুঁকি কমে।

ইটারেশনের সঙ্গে সিদ্ধান্ত অনুপুঙ্খভাবে নথিভুক্ত করুন

আপনি যেমন কোড জেনারেট ও টুইক করবেন, একটি হালকা সিদ্ধান্ত লগ রাখুন: আপনি কী চেষ্টা করেছেন, কী পরিমাপ করেছেন, এবং কেন আপনি একটি দিক বেছে নিয়েছেন (বা প্রত্যাখ্যান করেছেন)। সীমাবদ্ধতাগুলোও ধরুন (“বিদ্যমান হোস্টিং এ চলতে হবে”, “পরবর্তীতে SOC2 লাগবে” ইত্যাদি)। /docs বা প্রজেক্ট README-তে একটি সহজ পৃষ্ঠা যথেষ্ট—এটি ভবিষ্যৎ পরিবর্তনগুলোকে পরিকল্পিত iteration-এ পরিণত করে, না যে কষ্টসাধ্য রিরাইটে।

গভীর কাপলিং রোধ করতে অল্প অল্প রিফ্যাক্টর করুন

প্রারম্ভিক পণ্যগুলো সাপ্তাহিকভাবে বদলে: নামকরণ, ডেটা আকার, এমনকি “একটি ইউজার” কি মানে—এইসব বদলে যায়। যদি আপনি রিফ্যাক্টর করার জন্য অপেক্ষা করেন বিকাশের পরে, আপনার ফ্রেমওয়ার্ক পছন্দগুলো কোর ব্যবসায়িক লজিকে জমে যাবে।

AI-উত্পাদিত কোড আপনাকে আগেই রিফ্যাক্টর করতে সাহায্য করতে পারে কারণ এটি পুনরাবৃত্ত, কম-ঝুঁকিপূর্ণ এডিটে ভালো: ধারাবাহিকভাবে নাম বদলানো, হেল্পার এক্সট্রাক্ট করা, ফাইল পুনর্গঠন করা, এবং পরিষ্কার বাউন্ডারি তৈরি করা। সঠিকভাবে ব্যবহার করলে, এটা কাপলিংকে কাঠামোগত হওয়ার আগেই কমায়।

উচ্চ-মূল্যবান রিফ্যাক্টর লক্ষ্য (যেখানে লক-ইন লুকায়)

শুরু করুন সেই পরিবর্তনগুলো দিয়ে যা পরবর্তীতে কোর আচরণকে সহজে সরাতে সাহায্য করবে:

• সার্ভিস বাউন্ডারি: “ব্যবসা কী করে” তা সার্ভিসগুলোতে (যেমন BillingService, InventoryService) এক্সট্র্যাক্ট করুন যা কন্ট্রোলার, ORM মডেল, বা ফ্রেমওয়ার্ক রিকোয়েস্ট অবজেক্ট ইমপোর্ট করে না।
• DTOs / ভিউ মডেল: ইনপুট/আউটপুটের জন্য plain ডাটা শেপ ব্যবহার করুন, ফ্রেমওয়ার্ক মডেল পাস না করে। মানচিত্রকরণ এজ-এ রাখুন।
• এরর হ্যান্ডলিং: কোডবেস জুড়ে ছড়িয়ে থাকা ফ্রেমওয়ার্ক-স্পেসিফিক এক্সসেপশনগুলোর বদলে নিজের এরর টাইপ ব্যবহার করুন (যেমন NotFound, ValidationError) এবং সেগুলোকে বাউন্ডারিতে ট্রান্সলেট করুন।

ছোট, উল্টে নেওয়া যোগ্য ধাপ (প্রতিটি ধাপের পরে টেস্ট)

ইনক্রিমেন্টালি রিফ্যাক্টর করুন:

1. আপনি যা স্পর্শ করতে যাচ্ছেন তার ওপর টেস্ট যোগ করুন বা আপডেট করুন।
2. AI-কে একটি একক পরিবর্তন (নাম বদলানো, এক্সট্র্যাক্ট, চালানো) করতে বলুন এবং ডিফ ব্যাখ্যা চাও।
3. ফورا টেস্ট চালান; সব পাস করলে পরের ধাপ শুরু করুন।

“এক পরিবর্তন + সব টেস্ট পাস” রিদম AI-কে সাহায্যী রেখে drift ঠেকায়।

বড় রিরাইট এড়ান

সমগ্র রিপোতে “আধুনিকী কর” জিজ্ঞাসা করে AI-কে বড় রিফ্যাক্টর করতে বলবেন না। বড় জেনারেটেড রিফ্যাক্টরগুলো স্টাইল পরিবর্তনের সাথে আচরণগত পরিবর্তন মিশিয়ে দিতে পারে, ফলে বাগ ধরা কঠিন হয়। যদি ডিফটা রিভিউ করা কঠিন হয়, তা বিশ্বাস করার মত নয়।

আপনি হয়তো কখনো মাইগ্রেট না করলেও মাইগ্রেশন পরিকল্পনা করুন

মাইগ্রেশন পরিকল্পনা করা হতাশাবাদী নয়—এটা একটি ইনস্যুরেন্স। প্রারম্ভিক পণ্য দ্রুত দিক বদলে: আপনি হয়তো ফ্রেমওয়ার্ক বদলাবেন, মনোলিথ ভাগ করবেন, বা “ভালো-পর্যায়ের” অথ থেকে কমপ্লায়েন্ট কিছুতে জাবেন। যদি আপনি এক্সিট ধ্যান-ধারণা রেখে ডিজাইন করেন, সাধারণত শেষমেশ পরিষ্কার বাউন্ডারি পাবেন এমনকি যদি সেখানে থেকেই থাকেন।

কোন অংশগুলো পরে সরাতে সবচেয়ে কষ্টসাধ্য

একটি মাইগ্রেশন সাধারণত ব্যর্থ হয় (বা ব্যয়বহুল হয়) যখন সবচেয়ে entangled অংশগুলো সর্বত্র ছড়ানো থাকে:

• স্টেট ম্যানেজমেন্ট: UI স্টেট ব্যবসায়িক নিয়মে ঢুকে পড়া, বা ফ্রেমওয়ার্ক-নির্দিষ্ট স্টোরগুলো সূত্রস্বরূপ হওয়া।
• ডেটা লেয়ার: ORM মডেল API কনট্র্যাক্ট হিসেবেও ব্যবহৃত হলে, কুয়েরি স্ক্যাটার্ড করা স্ক্রিন জুড়ে, এবং মাইগ্রেশন ফ্রেমওয়ার্ক কনভেনশনের ওপর নির্ভরশীল হলে।
• অথ ও পারমিশন: সেশন হ্যান্ডলিং, মিডলওয়্যার, এবং অথরাইজেশন চেক কন্ট্রোলার/কম্পোনেন্ট জুড়ে ছড়িয়ে থাকলে।

এই অঞ্চলগুলো চটকে যায় কারণ তারা বহু ফাইল স্পর্শ করে, এবং ছোট অনিয়মগুলো মিলিয়ে বড় সমস্যা তৈরি করে।

AI কিভাবে বাস্তবসম্মত মাইগ্রেশন প্ল্যান ড্রাফট করতে সাহায্য করে

AI-উত্পাদিত কোড এখানে কার্যকর—মাইগ্রেশন “করার” জন্য নয়, বরং রূপরেখা তৈরি করার জন্য:

• আপনার স্ট্যাক অনুযায়ী একটি মাইগ্রেশন চেকলিস্ট ড্রাফট করুন (রাউটস, স্টেট, ডাটা মডেল, অথ ফ্লো)। শুরু করার জন্য একটি টেমপ্লেট ব্যবহার করুন যেমন /blog/migration-checklist।
• একটি ইনক্রিমেন্টাল সিকোয়েন্স প্রস্তাব করুন (“প্রথমে অথ স্থানান্তর করুন, তারপর ডাটা অ্যাকসেস, তারপর UI”), সাথে কি স্থিতিশীল রাখতে হবে (contracts, IDs, ইভেন্ট নাম)।
• একটি রিস্ক টেবিল জেনারেট করুন (কি ভাঙতে পারে, কিভাবে সনাক্ত করবেন, রোলব্যাক ধাপ) যা আপনি ইস্যুতে বদলে দিতে পারেন।

মূল কথা হলো ধাপ ও অপরিবর্তিত বিষয় জিজ্ঞাসা করুন, শুধু কোড নয়।

“স্ট্র্যাংগলার” পাথ তৈরি করুন

সবকিছু রিরাইট করার বদলে নতুন একটি মডিউল পুরোনোর পাশে রান করুন:

• নতুন সার্ভিস/মডিউল তৈরী করুন একই এক্সটার্নাল কনট্র্যাক্ট (স্কিমা, এন্ডপয়েন্ট, ইভেন্ট) রেখে।
• ট্রাফিকের ছোট একটি শতাংশ—বা একটি ফিচার—নতুন পথে রুট করুন।
• কভারেজ বাড়ান যতক্ষণ না পুরোনো মডিউল একটি পাতলা শেল হয়ে যায় যেটা মুছে ফেলা যাবে।

এই পন্থা তখনই ভাল কাজ করে যখন আপনার কাছে পূর্বেই পরিষ্কার বাউন্ডারি থাকে। উদাহরণ ও প্যাটার্নের জন্য দেখুন /blog/strangler-pattern এবং /blog/framework-agnostic-architecture।

আপনি যদি কখনো মাইগ্রেট না করেন, তবুও আপনি উপকৃত হবে: কম লুকানো ডিপেন্ডেন্সি, পরিষ্কার কনট্র্যাক্ট, এবং কম অপ্রত্যাশিত টেক ডেবট।

AI-উৎপাদিত কোডের জন্য ব্যবহারিক গার্ডরেল

AI দ্রুত অনেক কোড শিপ করতে পারে—এবং এটি একটি ফ্রেমওয়ার্কের অনুমানগুলো সারাবিশ্বে ছড়াতে পারে যদি আপনি সীমা না দেন। লক্ষ্য হচ্ছে “কম বিশ্বাস করা” নয়, বরং পর্যালোচনা করা সহজ এবং দুর্ঘটনাক্রমে কোর পণ্যকে নির্দিষ্ট স্ট্যাকে coupling করা কঠিন করে তোলা।

লুকানো লক-ইন প্রতিরোধে রিভিউ চেকগুলো

প্রতি PR-এ একটি সংক্ষিপ্ত, পুনরাবৃত্তিযোগ্য চেকলিস্ট ব্যবহার করুন যখন AI-সহায়ক কোড থাকে:

• কোর মডিউলগুলোতে ফ্রেমওয়ার্ক টাইপ নেই (না Request, DbContext, ActiveRecord, Widget ইত্যাদি)। কোর কোড আপনার টার্মে কথা বলুক: Order, Invoice, UserId।
• গ্লোবাল ও সিঙ্গলটন যতটা কম সম্ভব। যদি এটি প্যারামিটার দিয়ে তৈরি করা যায় না, তা টেস্ট করতে কঠিন এবং মুভ করতেও কঠিন।
• ডিপেন্ডেন্সি ভিতরের দিকে ইঙ্গিত করে। UI/API লেয়ার কোর ইমপোর্ট করতে পারে; কোর UI/API বা ফ্রেমওয়ার্ক প্যাকেজ ইমপোর্ট করবে না।
• সিরিয়ালাইজেশন এজ-এ থাকে। JSON/HTTP/ফর্ম ডেটা রূপান্তর এজ-এ হওয়া উচিত, কোর লজিকে নয়।

AI অনুসরণ করতে পারে এমন হালকা মানদণ্ড

মানদণ্ডগুলো সহজ রাখুন যাতে আপনি প্রয়োগ করতে পারবেন:

• core/, adapters/, app/ (বা অনুরূপ) মতো ফোল্ডার বাউন্ডারি ডিফাইন করুন এবং নিয়ম: “core-এ শূন্য ফ্রেমওয়ার্ক ইম্পোর্ট।”
• ইন্টারফেস-সংকেতিত নামকরণ ব্যবহার করুন: *Service (ব্যবসায়িক লজিক), *Repository (ইন্টারফেস), *Adapter (ফ্রেমওয়ার্ক গ্লু)।
• একটি ডিপেন্ডেন্সি রুলিং টুল (বা ছোট স্ক্রিপ্ট) যোগ করুন যা নিষিদ্ধ ইম্পোর্ট ধরা পড়ে বিল ব্যর্থ করে।

প্রম্পট হাইজিন: সীমাবদ্ধতা স্পষ্ট করুন

AI-কে কোড চাইলে অবশ্যই দিন:

• টার্গেট ফোল্ডার (উদাহরণ: “/core-এর জন্য কোড জেনারেট করুন, কোনো ফ্রেমওয়ার্ক ইম্পোর্ট নয়”),
• অনুমোদিত ডিপেন্ডেন্সি,
• পছন্দ করা ইন্টারফেস স্টাইলের ছোট উদাহরণ।

এই জায়গাতেই AI প্ল্যাটফর্মগুলো যেগুলো explicit “plan then build” ওয়ার্কফ্লো দেয় সাহায্য করে। উদাহরণস্বরূপ Koder.ai-তে আপনি এই সীমাবদ্ধতাগুলো প্ল্যানিং মোডে বর্ণনা করতে পারেন এবং তারপর কোড জেনারেট করতে পারেন, স্ন্যাপশট ও রোলব্যাক ব্যবহার করে বড় ডিফগুলো রিভিউযোগ্য রাখার জন্য।

enforcement অটোমেট করুন শুরুর দিক থেকেই

প্রথম দিনেই ফরম্যাটার/লিন্টার এবং একটি বেসিক CI চেক সেটআপ করুন। (একটি সাধারণ “lint + test” পাইপলাইনই যথেষ্ট)। কাপলিং ধরা পড়ুক ততক্ষণে, আগে না যে এটি “প্রকল্প কিভাবে কাজ করে” হয়ে যায়।

চেকলিস্ট: প্রথম ৯০ দিনে নমনীয় থাকা

ফ্রেমওয়ার্ক-ফ্লেক্সিবল থাকা মানে ফ্রেমওয়ার্ক এড়ানো নয়—এটা দ্রুততার জন্য তাদের ব্যবহার করা কিন্তু এক্সিট খরচগুলো পূর্বানুমানযোগ্য করে রাখা। AI-উত্পাদিত কোড আপনাকে দ্রুত সরাতে সাহায্য করবে, কিন্তু নমনীয়তা আসে সেই জায়গাগুলো থেকে যেখানে আপনি সিমগুলো রাখেন।

লক-ইন বিলম্ব করতে থাকা চারটি মূল কৌশল

শুরু থেকেই এই চার কৌশল মাথায় রাখুন:

• ব্যবসায়িক লজিককে ফ্রেমওয়ার্ক থেকে আলাদা করুন: প্রাইসিং রুল, অনবোর্ডিং রুল, পারমিশন plain মডিউলে রাখুন যা ফ্রেমওয়ার্ক-স্পেসিফিক প্যাকেজ ইমপোর্ট করবে না।
• অ্যাডাপটার ও ইন্টারফেস ব্যবহার করুন: ফ্রেমওয়ার্ক, ডেটাবেস, কিউ, অথ, ইমেইলকে প্রতিস্থাপনযোগ্য “প্লাগ” হিসেবে ধরুন। আপনার অ্যাপ একটা ইন্টারফেস কল করে; একটি অ্যাডাপ্টার তা ইমপ্লিমেন্ট করে।
• প্রথমে কনট্র্যাক্ট জেনারেট করুন: স্কিমা/টাইপ/ভ্যালিডেশন (উদাহরণ: রিকোয়েস্ট/রেসপন্স শেপ) এন্ডপয়েন্ট ওয়্যারিংয়ের আগে নির্ধারণ করুন। AI কনসিস্টেন্ট টাইপ ও ভ্যালিডেটর স্ক্যাফোল্ডিংয়ে দুর্দান্ত।
• AI-কে সেফটি নেট গঠনে ব্যবহার করুন টেস্ট দিয়ে: ব্যবসায়িক নিয়মের চারপাশে উচ্চ-সিগন্যাল ইউনিট টেস্ট এবং কিছু ইন্টিগ্রেশন টেস্ট—এগুলো রিফ্যাক্টর/মাইগ্রেশন সত্যি করা সহজ করে।

সপ্তাহ ১ চেকলিস্ট (দ্রুত এবং ব্যবহারিক)

এইগুলো কোডবেস বড় হওয়ার আগে সম্পন্ন করার লক্ষ্য রাখুন:

1. একটি /core (অথবা অনুরূপ) ফোল্ডার তৈরি করুন যা ব্যবসায়িক লজিক রাখবে এবং কোনো ফ্রেমওয়ার্ক ইম্পোর্ট থাকবে না।
2. API এবং ডোমেইন কনট্র্যাক্ট (স্কিমা/টাইপ) নির্ধারণ করুন এবং ভ্যালিডেটর জেনারেট করুন।
3. স্টোরেজ, অথ, ইমেইল, পেমেন্টস এর জন্য ইন্টারফেসগুলো ডিফাইন করে প্রথম অ্যাডাপ্টার ইমপ্লিমেন্ট করুন।
4. AI-কে বলুন শীর্ষ ৫টি রুলের জন্য ইউনিট টেস্ট জেনারেট করতে (বিলিং, পারমিশন, এলিজিবিলিটি ইত্যাদি) এবং সেগুলো CI-তে চালান।
5. একটি নিয়ম স্থাপন করুন: ফ্রেমওয়ার্ক কোড প্রান্তে (controllers/routes/views) থাকবে, কোর লজিকে নয়।

৯০ দিনের মধ্যে (এক্সিট খরচ বজায় রাখুন)

প্রতি ১–২ সপ্তাহে সিমগুলো পুনরায় দেখুন:

• ন্যাকৃত লজিকগুলোকে কোর সার্ভিসে রিফ্যাক্টর করুন।
• অ্যাডাপ্টার পাতলা রাখুন; “শুধু একটি শর্টকাট” এঞ্জয় না যার ফলে ফ্রেমওয়ার্ক অবজেক্ট কোরে ফুটে উঠবে।
• যখন AI কোড জেনারেট করে, তা আপনার কনট্র্যাক্ট ও ইন্টারফেস মেনে চলুক এবং সরাসরি কাপলিং থাকলে প্রত্যাখ্যান করুন।

প্রোটোটাইপ থেকে MVP-এ যাওয়া নিয়ে বিকল্প মূল্যায়ন করলে আপনি পরিকল্পনা ও সীমাবদ্ধতা /pricing-এ রিভিউ করতে পারেন।