১৬ নভে, ২০২৫·8 মিনিট
পরিষ্কার সফ্টওয়্যার আর্কিটেকচার ও কম রিরাইটের জন্য প্রম্পটিং প্যাটার্ন
AIকে নিয়মিত প্রম্পট দিয়ে স্পষ্ট রিকোয়ারমেন্ট, মডুলার ডিজাইন, এবং টেস্টযোগ্য কোড তৈরি করতে শিখুন—ফলে রিফ্যাক্টর ও রিরাইট কমবে।
AIকে নিয়মিত প্রম্পট দিয়ে স্পষ্ট রিকোয়ারমেন্ট, মডুলার ডিজাইন, এবং টেস্টযোগ্য কোড তৈরি করতে শিখুন—ফলে রিফ্যাক্টর ও রিরাইট কমবে।
এই পোস্টে “পরিষ্কার আর্কিটেকচার” মানে কোনো নির্দিষ্ট ফ্রেমওয়ার্ক বা পারফেক্ট ডায়াগ্রাম নয়। এর মানে—আপনি সিস্টেমটি সহজভাবে ব্যাখ্যা করতে পারবেন, তা বদলালে অপর অংশ ভাঙবে না, এবং নায়কের মত টেস্ট না করে সহজে আচরণ যাচাই করা যাবে।
স্পষ্টতা মানে সিস্টেমের উদ্দেশ্য ও আকার সংক্ষিপ্ত বর্ণনায় স্পষ্ট: এটি কী করে, কে ব্যবহার করে, কী ডেটা নিয়ে কাজ করে, এবং কী কখনো করা যাবেনা। AI-সহায়ক কাজেও স্পষ্টতা মানে মডেলটি রিকোয়্যারমেন্টগুলো এমনভাবে পুনরায় বলবে যা আপনি সই করে দিতে রাজি হবেন।
মডুলারিটি মানে দায়িত্বগুলো পরিষ্কার সীমানায় রাখা। প্রতিটি মডিউলের কাজ থাকে নির্দিষ্ট, ইনপুট/আউটপুট থাকে স্পষ্ট, এবং অন্য মডিউলের ভেতরের জিনিস খুব কম জানা লাগে। যখন AI কোড জেনারেট করে, মডুলারিটি prevents করে ব্যবসায়িক নিয়মগুলোকে কন্ট্রোলার, UI, এবং ডেটা এক্সেস জায়গায় ছড়িয়ে পড়া থেকে।
টেস্টযোগ্যতা মানে আর্কিটেকচার "প্রমাণ করো এটা কাজ করে"-কে সস্তা করে। ব্যবসায়িক নিয়মগুলো পুরো সিস্টেম ছাড়া টেস্ট করা যায়, আর ইন্টিগ্রেশন টেস্টগুলো কয়েকটি কনট্রাক্টের দিকে ফোকাস করে, প্রতিটি কোড পথ নয়।
রিরাইট সাধারণত “ব্যাড কোড” না থেকে ঘটে—এগুলো ঘটে কারণ অপূর্ণ কনস্ট্রেইন্ট, অস্পষ্ট স্কোপ, এবং লুকানো অনুমান। উদাহরণ:
AI এই ব্যর্থতা মোডকে দ্রুততর করতে পারে—কারণ তা তাত্ক্ষণিকভাবে বিশ্বাসযোগ্য আউটপুট দেয়, ফলে মানুষ অস্থিতশীল ভিত্তির ওপর দ্রুত তৈরি করে ফেলে।
এসব প্যাটার্ন হচ্ছে অ্যাডাপ্ট করার টেমপ্লেট, জাদু নয়। মূল উদ্দেশ্য হচ্ছে সঠিক কথাবার্তা আগেই বাধ্য করা: কনস্ট্রেইন্ট স্পষ্ট করা, অপশন তুলনা করা, অনুমান ডকুমেন্ট করা, এবং কনট্রাক্ট নির্ধারণ করা। যদি আপনি সেই চিন্তাটা বাদ দেন, মডেল আনন্দের সঙ্গে ফাঁকে ভরিয়ে দেবে—আর পরে আপনি তার মূল্য চুকাবেন।
আপনি এগুলো পুরো ডেলিভারি চক্র জুড়ে ব্যবহার করবেন:
যদি আপনি ভিব-কোডিং ওয়ার্কফ্লো (vibe-coding) ব্যবহার করেন—যেখানে চ্যাটের মাধ্যমে সিস্টেম জেনারেট ও ইটারেট হয়—তবে এই চেকপয়েন্টগুলো আরো জরুরি। উদাহরণস্বরূপ, Koder.ai-এ আপনি “planning mode” লুপ চালিয়ে রিকোয়্যারমেন্ট ও কনট্রাক্ট লক করে React/Go/PostgreSQL কোড জেনারেট করার আগে, তারপর স্ন্যাপশট/রোলব্যাক ব্যবহার করে অনুমান বদলালে নিরাপদে ইটারেট করতে পারেন—প্রতিটি চেঞ্জকে রিরাইটে পরিণত না করে।
প্রম্পটিং প্যাটার্নগুলো সবচেয়ে মূল্যবান যখন এগুলো ডিসিশন চর্ন কমায়। চালাকিটা হলো এগুলোকে সংক্ষিপ্ত, পুনরাবৃত্তি যোগ্য চেকপয়েন্ট হিসেবে ব্যবহার করা—কোড করার আগে, ডিজাইন করার সময়, এবং রিভিউ-এর সময়—তাতে AI এমন আর্টিফ্যাক্ট উৎপাদন করে যা আপনি পুনঃব্যবহার করতে পারেন, না যে শুধু বাড়তি টেক্সট যা আপনাকে ছাঁটতে হবে।
কোডের আগে: একবার “অ্যালাইনমেন্ট” লুপ চালান যাতে লক্ষ্য, ব্যবহারকারী, কনস্ট্রেইন্ট, ও সাফল্য মেট্রিক কনফার্ম হয়।
ডিজাইনের সময়: স্পষ্ট ট্রেডঅফ জোর দেয় এমন প্যাটার্ন ব্যবহার করুন (উদা., বিকল্প, ঝুঁকি, ডেটা সীমা) ইমপ্লিমেন্ট করার আগে।
রিভিউয়ের সময়: চেকলিস্ট-স্টাইল প্রম্পট ব্যবহার করে গ্যাপ ধরুন (এজ কেস, মনিটরিং, সিকিউরিটি, পারফরম্যান্স) যাহাতে পরিবর্তন সস্তা অবস্থায় থাকে।
একটি ছোট, ধারাবাহিক ইনপুট বান্ডল দিয়ে আপনি ভালো আউটপুট পাবেন:
যদি কিছু না জানা থাকে, স্পষ্টভাবে বলুন এবং AI-কে অনুমান তালিকাভুক্ত করতে বলুন।
“ডিজাইন ব্যাখ্যা কর” বলার বদলে এমন আর্টিফ্যাক্ট অনুরোধ করুন যা ডকস বা টিকেটে পেস্ট করা যাবে:
10–15 মিনিটের লুপ করুন: প্রম্পট → স্কিম → টাইটেন। সবসময় অ্যাপসেপ্ট্যান্স ক্রাইটেরিয়া অন্তর্ভুক্ত করুন (ডিজাইন গ্রহণযোগ্য হওয়ার শর্ত), তারপর AI-কে সেগুলোর বিরুদ্ধে নিজের উত্তর চেক করতে বলুন। এতে প্রক্রিয়াটা অশেষ রিডিজাইনে পরিণত হয় না এবং পরের সেকশনের প্যাটার্ন দ্রুত প্রয়োগযোগ্য হয়।
অধিকাংশ আর্কিটেকচার রিরাইট ডায়াগ্রামের ত্রুটি নয়—এগুলি ঘটে যখন সঠিক জিনিস ভুল বা অসম্পূর্ণ প্রোবলেমের জন্য তৈরি করা হয়। যখন আপনি প্রথমে LLM ব্যবহার করেন, আর্কিটেকচার চাওয়ার বদলে তাকে অস্পষ্টতা উন্মোচন করতে বলুন।
মডেলকে রিকোয়ারমেন্ট ইন্টারভিউয়ার হিসেবে ব্যবহার করুন। আপনার লক্ষ্য একটি সংক্ষিপ্ত, অগ্রাধিকারভিত্তিক স্পেক পাওয়া যা আপনি কেউকে ডিজাইন, ডাটাবেস, বা API কমিট করার আগে কনফার্ম করতে পারেন।
নিচের কপি-পেস্ট টেমপ্লেটটি পুনরায় ব্যবহার করুন:
You are my requirements analyst. Before proposing any architecture, do this:
1) Ask 10–15 clarifying questions about missing requirements and assumptions.
- Group questions by: users, workflows, data, integrations, security/compliance, scale, operations.
2) Produce a prioritized scope list:
- Must-have
- Nice-to-have
- Explicitly out-of-scope
3) List constraints I must confirm:
- Performance (latency/throughput targets)
- Cost limits
- Security/privacy
- Compliance (e.g., SOC2, HIPAA, GDPR)
- Timeline and team size
4) End with: “Restate the final spec in exactly 10 bullets for confirmation.”
Context:
- Product idea:
- Target users:
- Success metrics:
- Existing systems (if any):
(এই কোড-ফেন্সের ভিতরের অংশ অ্যালটার না করে রাখুন।)
আপনি এমন প্রশ্ন চাইবেন যা সিদ্ধান্ত জোর করে (নন-জেনেরিক “আর বলুন”), এবং এমন একটি must-have তালিকা যা আপনার টাইমলাইনে সত্যিই সম্পন্ন করা যায়।
“10 বুলেট” রিস্টেটমেন্টকে চুক্তি হিসেবে ব্যবহার করুন: এটিকে টিকেটে/PRD-তে পেস্ট করুন, স্টেকহোল্ডারদের দ্রুত হ্যাঁ/না নিন, তারপরই আর্কিটেকচারে এগোন। এই এক ধাপ সবচেয়ে সাধারণ জিনিস রোধ করে: অপ্রয়োজনীয় ফিচার তৈরির কারণে পরে হওয়া রিফ্যাক্টর।
যখন আপনি সরাসরি টুল দিয়ে শুরু করেন ("আমরা ইভেন্ট সোর্সিং ব্যবহার করব?”), আপনি প্রায়শই আর্কিটেকচারের জন্য ডিজাইন করতে শুরু করেন না বরং ইউজারের জন্য ডিজাইন করা দরকার। দ্রুত পথ হলো AI-কে প্রথমে সাধারণ ভাষায় ইউজার জার্নি বর্ণনা করাতে, তারপর সেগুলোকে কম্পোনেন্ট, ডেটা, ও API-তে ট্রান্সলেট করা।
এই কপি-পেস্ট স্টার্টিং পয়েন্ট ব্যবহার করুন:
তারপর বলুন:
“প্রতিটি অ্যাকশনের জন্য step-by-step ফ্লো বর্ণনা করুন সরল ভাষায়।”
“একটি সহজ স্টেট ডায়াগ্রাম বা স্টেট লিস্ট দিন (যেমন Draft → Submitted → Approved → Archived)।”
“নন‑হ্যাপি‑পাথ তালিকা দিন: টাইমআউট, রিট্রাই, ডুপ্লিকেট অনুরোধ, ক্যানসেলেশন, এবং ইনভ্যালিড ইনপুট।”
ফ্লোগুলো পরিষ্কার হলে AI-কে ম্যাপ করতে বলুন:
এরপরই আর্কিটেকচারের খসড়া (সার্ভিস/মডিউল, সীমা, ও দায়িত্ব) চাইুন, সরাসরি সেই ফ্লো স্টেপগুলোর সাথে মেলিয়ে।
শেষে AI-কে বলুন প্রতিটি জার্নি Given/When/Then আকারে কনভার্ট করতে:
এই প্যাটার্ন রিরাইট কমায় কারণ আর্কিটেকচার ইউজার আচরণ থেকে বাড়ে—টেক-অনুমান থেকে নয়।
বেশিরভাগ আর্কিটেকচার রিকভাবে বদলানো হয় লুকানো অনুমানের কারণে। যখন আপনি LLM‑কে আর্কিটেকচার চান, এটি প্রায়শই ফাঁকগুলো বিশ্বাসযোগ্য অনুমান দিয়ে ভর্তি করে দেয়। একটি Assumption Log সেই অনুমানগুলোকে আগে থেকেই দৃশ্যমান করে, যখন বদল সস্তা।
আপনার লক্ষ্য হলো আপনি যা দিয়েছেন এবং মডেল কী অনুমান করেছে আলাদা করে দেখানো। এই প্রম্পট প্যাটার্ন ব্যবহার করুন:
Template prompt “Before proposing any solution: list your assumptions. Mark each as validated (explicitly stated by me) or unknown (you inferred it). For each unknown assumption, propose a fast way to validate it (question to ask, metric to check, or quick experiment). Then design based only on validated assumptions, and call out where unknowns could change the design.”
সংক্ষিপ্ত রাখুন যাতে লোকেরা আসলে ব্যবহার করে:
একটি লাইন যোগ করুন যাতে মডেল বলে তার টিপিং‑পয়েন্ট:
এই প্যাটার্ন আর্কিটেকচারকে শর্তসাপেক্ষ ডিসিশনের সেটে পরিণত করে। আপনি শুধু একটি ডায়াগ্রাম পাবেন না—আপনি একটি মানচিত্র পাবেন যা বলে কোন কিছু কনফার্ম না করলে ডিজাইন বদলাতে পারে।
AI টুলগুলো একক “সেরা” ডিজাইন তৈরি করতে ভাল—কিন্তু সেটি প্রায়ই প্রথম বৈধ অপশন মাত্র। পরিষ্কার আর্কিটেকচার সাধারনত তখনই আসে যখন আপনি তুলনা জোর দেন, যতক্ষণ বদল সস্তা।
একটি প্রম্পট ব্যবহার করুন যা একাধিক আর্কিটেকচার এবং গঠনবদ্ধ ট্রেডঅফ টেবিল চায়:
Propose 2–3 viable architectures for this project.
Compare them in a table with criteria: complexity, reliability, time-to-ship, scalability, cost.
Then recommend one option for our constraints and explain why it wins.
Finally, list “what we are NOT building” in this iteration to keep scope stable.
Context:
- Users and key journeys:
- Constraints (team size, deadlines, budget, compliance):
- Expected load and growth:
- Current systems we must integrate with:
(কোড-ফেন্সের ভিতরের অংশ অপরিবর্তিত রাখুন।)
তুলনা মডেল (আর আপনাকেও) বাধ্য করে গোপন অনুমানগুলো—কোথায় state থাকে, সার্ভিসগুলো কিভাবে কথা বলে, কী synchronous থাকা উচিত—উন্মোচন করতে।
ক্রাইটেরিয়া টেবিল গুরুত্বপূর্ণ, কারণ এটি “মাইক্রোসার্ভিস বনাম মনোলিথ” মত আলোচনা‑ভিত্তিক বিতর্ককে বন্ধ করে দেয় এবং সিদ্ধান্ত আপনার আসল চাহিদার সাথে জোড়ায়: দ্রুত শিপ করা, অপারেশনাল ওভারহেড কমানো, বা নির্ভরযোগ্যতা বাড়ানো—যেটা আপনার কাছে বেশি গুরুত্বপূর্ণ।
“It depends” মানবেন না। একটি পরিষ্কার সুপারিশ চাহুন এবং কোন কনস্ট্রেইন্ট সেটটি অপ্টিমাইজ করে সেটা বলুন।
এছাড়াও জোর দিন “এখন আমরা কি বানাচ্ছি না”—উদাহরণ: “No multi-region failover”, “No plugin system”, “No real-time notifications.” এটা আর্কিটেকচারকে অপ্রয়োজনীয় ব্যাপারে বর্ধিত হওয়া থেকে রোধ করে—এবং পরে স্কোপ বদলালে হঠাৎ রিরাইট আটকায়।
অধিকাংশ রিরাইট ঘটে কারণ বাউন্ডারি অস্পষ্ট: সবকিছুই “সবকিছুর সাথে ছোঁয়াশা”, আর ছোট পরিবর্তনগুলো কোডবেস জুড়ে ছড়িয়ে পড়ে। এই প্যাটার্নটি এমন প্রম্পট ব্যবহার করে যা কাউকে স্পষ্ট মডিউল মালিকানা নির্ধারণ করতে বাধ্য করে, বাস্তবায়ন বা ফ্রেমওয়ার্ক নিয়ে তর্ক করার আগে।
AI-কে বলুন মডিউল এবং দায়িত্ব সংজ্ঞায়িত করতে, এবং প্রতিটির জন্য স্পষ্টভাবে কি নয় তা বলাও। তারপর ইন্টারফেস (ইনপুট/আউটপুট) এবং ডিপেন্ডেন্সি নিয়ম চাইুন—বিল্ড প্ল্যান বা ইমপ্লিমেন্টেশন ডিটেইলস নয়।
এটি ব্যবহার করুন যখন আপনি নতুন ফিচার স্কেচ করছেন বা মেসি এলাকাটি রিফ্যাক্টর করতে যাচ্ছেন:
List modules with:
For each module, define interfaces only:
Dependency rules:
Future change test: Given these likely changes: <list 3>, show which single module should absorb each change and why.
আপনি এমন মডিউল চাইবেন যা একজন সহকর্মীকে এক মিনিটে বলে বোঝানো যায়। যদি AI “Utils” মডিউল প্রস্তাব করে বা ব্যবসায়িক নিয়মগুলো কন্ট্রোলারে রাখে, বলুন: “ডিসিশন‑মেকিং ডোমেন মডিউলে টেনে নাও এবং অ্যাডাপ্টারগুলো পাতলা রাখো।”
শেষ করলে আপনার কাছে এমন সীমারেখা থাকবে যা নতুন রিকোয়ারমেন্ট টিকে সহ্য করে—কারণ পরিবর্তনগুলোর স্পষ্ট বাড়ি আছে এবং ডিপেন্ডেন্সি নিয়ম দুর্ঘটনাক্রমে কাপলিং আটকায়।
ইন্টিগ্রেশন রিওয়ার্ক প্রায়শই “খারাপ কোড” থেকে নয়—এটি স্পষ্ট কনট্রাক্ট না থাকায় হয়। যদি ডেটা মডেল ও API শেপগুলো পরে ঠিক করা হয়, প্রতিটি দল/মডিউল বিভিন্নভাবে ফাঁক পূরণ করে, এবং পরের স্প্রিন্টে আপনি হ্যান্ডশেক মেলাতে ব্যয় করবেন।
শুরুতেই কনট্রাক্টের জন্য প্রম্পট করুন, তারপর ফ্রেমওয়ার্ক, ডেটাবেস বা মাইক্রোসার্ভিস নিয়ে আলোচনা করুন। একটি স্পষ্ট কনট্রাক্ট UI, ব্যাকএন্ড, ও ডেটা পাইপলাইনকে সঙ্গত রাখে।
শাইন ইয়ারলি এই প্রম্পটটি আপনার AI অ্যাসিস্ট্যান্টের কাছে ব্যবহার করুন:
তারপর সঙ্গে সঙ্গে বলুন:
আপনি কংক্রিট আর্টিফ্যাক্ট চাইবেন, বড়‑বড় লেখা নয়। উদাহরণ:
Subscription
এবং একটি API খসড়া:
POST /v1/subscriptions
{
"customer_id": "cus_123",
"plan_id": "pro_monthly",
"start_date": "2026-01-01"
}
201 Created
{
"id": "sub_456",
"status": "active",
"current_period_end": "2026-02-01"
}
422 Unprocessable Entity
{
"error": {
"code": "VALIDATION_ERROR",
"message": "start_date must be today or later",
"fields": {"start_date": "in_past"}
}
}
(উপরের কোড ব্লকগুলো অরিজিনাল ইংরেজি অবস্থায় রাখা হয়েছে—অনুবাদ করবেন না।)
AI-কে বলুন যেমন নিয়ম স্টেট করতে: “অ্যাডিটিভ ফিল্ডগুলো ভার্সন বাম্প ছাড়া যোগ করা যাবে; রিনেম করলে /v2 দরকার; ক্লায়েন্টরা অজানা ফিল্ডগুলো উপেক্ষা করবে।” এই এক ধাপ চুপচাপ ব্রেকিং চেঞ্জগুলো রোধ করে—এবং পরের রিরাইটগুলো ঠেকায়।
আর্কিটেকচারগুলো রিরাইট হয় যখন “হ্যাপি পাথ” ডিজাইন বাস্তব ট্রাফিক, ফ্লাকি নির্ভরতা, এবং অপ্রত্যাশিত ব্যবহারকারীর আচরণের সম্মুখীন হয়। এই প্যাটার্ন রিলায়াবিলিটিকে একটি স্পষ্ট ডিজাইন আউটপুটে পরিণত করে, পোস্ট‑লঞ্চ স্ক্রাম্বল নয়।
নির্বাচিত আর্কিটেকচার বর্ণনার সঙ্গে এটি ব্যবহার করুন:
List failure modes; propose mitigations; define observability signals.
For each failure mode:
- What triggers it?
- User impact (what the user experiences)
- Mitigation (design + operational)
- Retries, idempotency, rate limits, timeouts considerations
- Observability: logs/metrics/traces + alert thresholds
ফোকাস রাখুন যে ইন্টারফেসগুলো ফেল হতে পারে: এক্সটার্নাল APIs, ডাটাবেস, কিউ, auth provider, এবং ব্যাকগ্রাউন্ড জব। তারপর কংক্রিট ডিসিশন চাইুন:
প্রম্পট শেষ করুন: “Return a simple checklist we can review in 2 minutes.” একটি ভালো চেকলিস্টে থাকবে: dependency timeouts সেট করা, retries সীমাবদ্ধ, idempotency ক্রিয়ান্বিত, backpressure/rate limiting আছে, graceful degradation পথ সংজ্ঞায়িত।
ইভেন্টগুলো ইউজারের মুহূর্তগুলোর চারপাশে নামকরণ করুন (সিস্টেম‑ইনটার্নাল ছাড়াও): “user_signed_up”, “checkout_submitted”, “payment_confirmed”, “report_generated”。প্রতিটির জন্য চাইুন:
এটি রিলায়াবিলিটিকে এমন একটি ডিজাইন আর্টিফ্যাক্টে রূপান্তর করে যা কোড হওয়ার আগে যাচাই করা যায়।
AI-সহায়ক ডিজাইন প্রায়শই খুব শীঘ্র “সম্পূর্ণ” আর্কিটেকচার তৈরির উৎসাহ দেয়—ফলে রিরাইট হওয়ার সুযোগ বাড়ে। সমাধানটি সহজ: পরিকল্পনাকে বাধ্য করুন সবচেয়ে ছোট ব্যবহারযোগ্য স্লাইস দিয়ে—একটি যা ভ্যালু দেয়, ডিজাইন প্রমাণ করে, এবং ভবিষ্যৎ অপশন খোলা রাখে।
আপনি যখন মনে করেন সলিউশন রিকোয়ারমেন্টের চেয়ে দ্রুত বাড়ছে, এই টেমপ্লেটটি ব্যবহার করুন:
Template: “Propose the smallest usable slice; define success metrics; list follow-ups.”
মডেলকে বলুন উত্তর দিন:
দ্বিতীয় নির্দেশ যোগ করুন: “Give a phased roadmap: MVP → v1 → v2, and explain what risk each phase reduces.” এটি পরের আইডিয়াগুলো দৃশ্যমান রাখে কিন্তু প্রথম রিলিজে চাপায় না।
উদাহরণ ফলাফল:
এই প্যাটার্নের সবচেয়ে শক্ত লাইন: “List what is explicitly out of scope for MVP.” ব্যতিক্রমগুলো আর্কিটেকচারের সিদ্ধান্তকে প্রাথমিক জটিলতা থেকে রক্ষা করে।
ভালো ব্যতিক্রম দেখায়:
শেষে: “Convert the MVP into tickets, each with acceptance criteria and dependencies.” এটি স্পষ্টতা জোর করে এবং লুকানো কাপলিং উন্মোচিত করে।
একটি শক্ত টিকেট ব্রেকডাউন সাধারণত অন্তর্ভুক্ত করে:
আপনি চাইলে মডেলকে আপনার টিম ফরম্যাটে আউটপুট করতে বলুন (উদাহরণ: Jira-style ফিল্ড) এবং পরের ফেজগুলো আলাদা ব্যাকলগ হিসেবে রাখুন।
আর্কিটেকচার drift রোধ করার সহজ উপায় হলো ডিজাইন চাইবার আগে টেস্ট বাধ্য করা। যখন আপনি LLM‑কে acceptance tests‑এর সাথে শুরু করতে বলেন, এটি আচরণ, ইনপুট, আউটপুট, এবং এজকেসগুলো নামতেই করে—যা মিসিং রিকোয়ারমেন্টকে প্রকাশ করে এবং ইমপ্লিমেন্টেশনকে পরিষ্কার মডিউল বাউন্ডারির দিকে ঠেলে।
প্রতিটি কম্পোনেন্ট ডিজাইন করার আগে gate প্রম্পট হিসেবে এটি ব্যবহার করুন:
পরে বলুন: “Group the tests by module responsibility (API layer, domain logic, persistence, external integrations). For each group, specify what is mocked and what is real.”
এটি LLM‑কে tangled ডিজাইন থেকে দূরে ঠেলে। যদি এটি ব্যাখ্যা করতে না পারে কোথায় integration tests শুরু হয়, আপনার আর্কিটেকচার সম্ভবত এখনও পরিষ্কার নয়।
চাহুন: “Propose a test data plan: fixtures vs factories, how to generate edge cases, and how to keep tests deterministic. List which dependencies can use in-memory fakes and which require a real service in CI.”
আপনি প্রায়ই আবিষ্কার করবেন একটি “সরল” ফিচার আসলে একটি কনট্রাক্ট, একটি সিড ডেটাসেট, বা স্থির ID প্রয়োজন—এগুলো এখনই খুঁজে পাওয়া ভাল, রিরাইটের চেয়ে।
একটি হালকা চেকলিস্ট দিয়ে শেষ করুন:
ডিজাইন রিভিউ শুধু কোড হওয়ার পরে হওয়া উচিত নয়। AI দিয়ে আপনি একটি “pre-mortem review” চালাতে পারেন আপনার আর্কিটেকচারের খসড়ায় (এমনকি যদি তা মাত্র কয়েক প্যারাগ্রাফ এবং কথায়‑ডায়াগ্রামও হয়) এবং কনক্রীট দুর্বলতা তালিকা পেতে পারেন যখনো এগুলো রিরাইটে পরিণত হয় না।
একটা সোজাসুজি রিভিউয়ার স্ট্যান্স নিয়ে specificity বাধ্য করুন:
Prompt: “Act as a reviewer; list risks, inconsistencies, and missing details in this design. Be concrete. If you can’t evaluate something, say what information is missing.”
আপনার ডিজাইন সামারি, কনস্ট্রেইন্ট (বাজেট, টাইমলাইন, টিম স্কিল), এবং যেকোনো নন‑ফাংশনাল রিকোয়ারমেন্ট (লেটেন্সি, অ্যাভেইলিবিলিটি, কমপ্লায়েন্স) পেস্ট করুন।
রিভিউ তখনই কাজে লাগে যখন ফিডব্যাক কনক্রিট হয়। অনুরোধ করুন একটি প্রায়োরিটাইজড ফিক্স তালিকা:
Prompt: “Give me a prioritized punch list. For each item: severity (Blocker/High/Medium/Low), why it matters, suggested fix, and the smallest validation step.”
এটি সিদ্ধান্ত‑রেডি টাস্ক দেয় না যে কেবল বিতর্ক—ফলে কাজ দ্রুত করা যায়।
একটি কাজে লাগার মতো বল প্রেরণা হলো একটি সরল স্কোর:
Prompt: “Assign a rewrite risk score from 1–10. Explain the top 3 drivers. What would reduce the score by 2 points with minimal effort?”
আপনি নির্ভুলতা খুঁজছেন না—আপনি চাইছেন সবচেয়ে রিরাইট‑প্রোন অনুমানগুলোকে উন্মোচন করা।
অবশেষে, রিভিউকে স্কোপ সম্প্রসারণে পরিণত করাকে রোধ করুন:
Prompt: “Provide a diff plan: minimal changes needed to reach the target design. List what stays the same, what changes, and any breaking impacts.”
প্রতিটি ইটারেশনে এই প্যাটার্নটি চালালে, আপনার আর্কিটেকচার ছোট, রিভার্সিবল ধাপে বিকশিত হবে—আর বড় সমস্যা আগে ধরা পড়বে।
এই প্যাকটি হালকা ওয়ার্কফ্লো হিসেবে ব্যবহার করুন যা প্রতিটি ফিচারে পুনরাবৃত্তি করা যায়। ধারণা হলো প্রম্পটগুলোকে চেইন করা যাতে প্রতিটি ধাপ এমন একটি আর্টিফ্যাক্ট উত্পাদন করে যা পরের ধাপ পুনরায় ব্যবহার করতে পারে—এতে “হারানো প্রসঙ্গ” এবং অপ্রত্যাশিত রিরাইট কমে।
প্রায়শই দলগুলো এই চেইনটিকে একটি পুনরাবৃত্ত “ফিচার রেসিপি” হিসেবে প্রয়োগ করে। যদি আপনি Koder.ai ব্যবহার করে তৈরি করেন, একই স্ট্রাকচার চ্যাট-চালিত বিল্ড প্রসেসে খাপ খায়: আর্টিফ্যাক্টগুলো এক জায়গায় ক্যাপচার করুন, প্রথম কাজ করা স্লাইস জেনারেট করুন, তারপর স্ন্যাপশট দিয়ে ইটারেট করুন যাতে পরীক্ষা রিভার্সিবল থাকে। যখন MVP রেডি, আপনি সোর্স কোড এক্সপোর্ট বা কাস্টম ডোমেইন সহ ডিপ্লয়/হোস্ট করতে পারবেন—গুরুত্বপূর্ণ যখন আপনি AI-সহায়ক ডেলিভারির গতি চান কিন্তু নিজেকে এক পরিবেশে লক করতে চান না।
SYSTEM (optional)
You are a software architecture assistant. Be practical and concise.
Guardrail: When you make a recommendation, cite the specific lines from *my input* you relied on by quoting them verbatim under “Input citations”. Do not cite external sources or general industry claims.
If something is unknown, ask targeted questions.
1) REQUIREMENTS CLARIFIER
Context: <product/system overview>
Feature: <feature name>
My notes: <paste bullets, tickets, constraints>
Task:
- Produce: (a) clarified requirements, (b) non-goals, (c) constraints, (d) open questions.
- Include “Input citations” quoting the exact parts of my notes you used.
2) ARCHITECTURE OPTIONS
Using the clarified requirements above, propose 3 architecture options.
For each: tradeoffs, complexity, risks, and when to choose it.
End with a recommendation + “Input citations”.
3) MODULAR BOUNDARIES
Chosen option: <option name>
Define modules/components and their responsibilities.
- What each module owns (and does NOT own)
- Key interfaces between modules
- “Input citations”
4) DATA & API CONTRACTS
For each interface, define a contract:
- Request/response schema (or events)
- Validation rules
- Versioning strategy
- Error shapes
- “Input citations”
5) TEST-FIRST ACCEPTANCE
Write:
- Acceptance criteria (Given/When/Then)
- 5–10 critical tests (unit/integration)
- What to mock vs not mock
- “Input citations”
6) RELIABILITY + DESIGN REVIEW
Create:
- Failure modes list (timeouts, partial failure, bad data, retries)
- Observability plan (logs/metrics/traces)
- Review checklist tailored to this feature
- “Input citations”
(কোড ফেন্সগুলো অপরিবর্তিত রাখুন।)
If you want a deeper companion, see /blog/prompting-for-code-reviews. If you’re evaluating tooling or team rollout, /pricing is a practical next stop.
“পরিষ্কার আর্কিটেকচার” এই গাইডে মানে হলো আপনি করতে পারেন:
AI-সহায়িত কাজেও এর মানে হলো মডেলটি এমনভাবে রিকোয়্যারমেন্ট ধারাবাহিকভাবে ফিরিয়ে দিতে পারবে, যেন আপনি তাঁকে সই করে দেবেন।
AI দ্রুত বিশ্বাসযোগ্য কোড ও ডিজাইন তৈরি করতে পারে, যা সহজেই অনুমতি ছাড়া সিদ্ধান্ত এবং লুকানো অনুমান-এর ওপর নির্মিত হতে পারে। এই দ্রুততা নিচের মতো রিরাইট-ট্রিগারগুলো বাড়িয়ে দিতে পারে:
সমাধান হলো AI কমানো নয় — বরং প্রম্পটে এমন বাধ্যতামূলক নির্দেশ রাখা যাতে শীঘ্রই কনস্ট্রেইন্ট, কনট্রাক্ট ও অনুমান প্রকাশ পায়।
এগুলোকে ছোট, পুনরাবৃত্তি যোগ্য চেকপয়েন্ট হিসেবে ব্যবহার করুন—যা পুনরায় ব্যবহারযোগ্য আর্টিফ্যাক্ট দেয় (নোট কাগজ নয়):
ইটারেশন রাখুন 10–15 মিনিটের: প্রম্পট → দ্রুত স্কিম → টাইটেন → অ্যাকসেপ্ট্যান্স ক্রাইটেরিয়ার বিরুদ্ধে স্ব-চেক।
একটি ছোট, ধারাবাহিক ইনপুট বান্ডল নিয়ে আসুন:
যদি কিছু না জানা থাকে, স্পষ্টভাবে বলুন এবং মডেলকে অনুমানগুলো তালিকাভুক্ত করতে বলুন।
AI-কে বলুন এমন আউটপুট দিন যা সরাসরি ডকস বা টিকেটে পেস্ট করা যাবে:
এটি AI আউটপুটকে কার্যকর রাখে এবং “হারানো প্রসঙ্গ”-এর ফলে হওয়া রিয়ার্কগুলো কমায়।
মডেলকে একটি রিকোয়ারমেন্ট ইন্টারভিউয়ার হিসেবে ব্যবহার করুন। করান:
প্রথমে রোল ও অ্যাকশন নিয়ে শুরু করুন, তারপর মডেলকে বলুন:
ফ্লোগুলি পরিষ্কার হলে ম্যাপ করুন কোথায় ভ্যালিডেশন শেষ হয়, ব্যবসায়িক নিয়ম কোথায় থাকে, এবং কোথায় আইডেম্পোটেন্সি দরকার। সব শেষে প্রতিটি ফ্লো-কে Given/When/Then এক্সেপ্টেন্স ক্রাইটেরিয়ায় রূপান্তর করুন।
LLM‑গুলো অনুশংস্য অনুমান করে ফেলে যদি আপনি স্পষ্টভাবে জোর না দেন যে কোনগুলো সত্য আর কোনগুলো অনুমান। একটি Assumption Log বানান যা আলাদা করে:
প্রতিটি আইটেমের জন্য রাখুন:
মডেলকে বাধ্য করুন একাধিক আর্কিটেকচার প্রস্তাব করতে এবং একটি গঠনযুক্ত ট্রেডঅফ টেবিল দেখাতে:
একটি তুলনা গোপন অনুমানগুলো উন্মোচন করে এবং সিদ্ধান্তকে আপনার প্রকৃত লক্ষ্যগুলোর সাথে সংযুক্ত করে—ফলে অপ্রত্যাশিত স্কোপ প্রসারণ কমে।
চুক্তি‑ফার্স্ট পদ্ধতি ইন্টিগ্রেশন রিওয়ার্ক কমায় কারণ এটি ডেটা শেপ ও কম্প্যাটিবিলিটি নিয়মগুলো স্পষ্ট করে। বলুন মডেলকে:
UI, ব্যাকএন্ড ও ইন্টিগ্রেশন একই কনট্রাক্ট আর্টিফ্যাক্ট ভাগ করলে পরে মেলাতে কম সময় লাগবে।
যে 10-বুলেট রিস্টেটমেন্টকে কনট্রাক্ট হিসেবে ধরে নিন এবং স্টেকহোল্ডারদের দ্রুত হ্যাঁ/না নিন—তার পরেই ডিজাইন শুরু করুন।
এবং বলুন “আপনার উত্তর কবে বদলে যাবে?”—উদাহরণ: ভলিউম, লেটেন্সি, কমপ্লায়েন্স। এটি ডিজাইনকে শর্তসাপেক্ষ করে এবং রিরাইট-বিরোধী করে।