16 नव॰ 2025·3 मिनट
साफ़ आर्किटेक्चर के लिए प्रॉम्प्टिंग पैटर्न: कम रीराइट्स
ऐसे प्रॉम्प्टिंग पैटर्न सीखें जो AI को स्पष्ट आवश्यकताएँ, मॉड्युलर डिज़ाइन और टेस्टेबल कोड की ओर मार्गदर्शित करते हैं—ताकि रिफैक्टर्स और रीराइट्स कम हों।
ऐसे प्रॉम्प्टिंग पैटर्न सीखें जो AI को स्पष्ट आवश्यकताएँ, मॉड्युलर डिज़ाइन और टेस्टेबल कोड की ओर मार्गदर्शित करते हैं—ताकि रिफैक्टर्स और रीराइट्स कम हों।
इस पोस्ट में “cleaner architecture” का मतलब किसी विशेष फ़्रेमवर्क या परफेक्ट डायाग्राम नहीं है। इसका मतलब है कि आप सिस्टम को सरलता से समझा सकें, बदल सकें बिना अनजान हिस्सों को तोड़े, और बिना हीरोइक टेस्टिंग के व्यवहार सत्यापित कर सकें।
स्पष्टता का मतलब है कि सिस्टम का उद्देश्य और रूप एक छोटी सी व्याख्या से स्पष्ट हो: यह क्या करता है, कौन उपयोग करता है, कौन सा डेटा हैंडल करता है, और क्या कभी नहीं करना चाहिए। AI-सहायिता वाले काम में, स्पष्टता का मतलब यह भी है कि मॉडल आवश्यकताओं को लौटाकर इस तरह बताए कि आप उस पर साइन-ऑफ कर दें।
मॉड्युलैरिटी का मतलब है जिम्मेदारियों की साफ़ सीमाएँ। हर मॉड्यूल का एक काम होता है, इनपुट/आउटपुट होते हैं, और दूसरे मॉड्यूल की इनरवर्किंग का न्यूनतम ज्ञान होता है। जब AI कोड जनरेट करता है, मॉड्युलैरिटी ही उसे बिज़नेस नियमों को controllers, UI और data access में फैलने से रोकती है।
टेस्टेबिलिटी का मतलब है कि आर्किटेक्चर “काम साबित करो” को सस्ता बनाती है। बिज़नेस नियमों को पूरे सिस्टम के बिना टेस्ट किया जा सकता है, और इंटीग्रेशन टेस्ट कुछ अनुबंधों पर केन्द्रित रहते हैं बजाय हर कोड पाथ के।
रीराइट्स अक्सर "बुरे कोड" की वजह से नहीं होते—वे होते हैं गायब प्रतिबंध, धुंधला स्कोप, और छुपी मान्यताओं की वजह से। उदाहरण:
AI इस विफलता मोड को तेज कर सकता है क्योंकि यह तेज़ी से भरोसेमंद आउटपुट देता है, जिससे लोग कम मजबूत आधारों पर जल्दी निर्माण कर देते हैं।
आगे जो पैटर्न्स हैं वे अनुकूलनीय टेम्प्लेट हैं, जादुई प्रॉम्प्ट नहीं। इनका असली उद्देश्य सही बातचीत जल्दी मजबूर करना है: प्रतिबंध साफ करना, विकल्पों की तुलना कराना, मान्यताओं को दस्तावेज़ बनाना और अनुबंध परिभाषित करना। अगर आप यह सोच छोड़ देंगे, तो मॉडल ख़ुशी-खुशी खाली जगह भर देगा—और बाद में आपको उसकी कीमत चुकानी पड़ेगी।
आप इन्हें पूरे डिलिवरी चक्र में इस्तेमाल करेंगे:
यदि आप "vibe-coding" वर्कफ़्लो इस्तेमाल कर रहे हैं (जहाँ सिस्टम चैट के जरिए जनरेट और इटरेट होता है), तो ये चेकपॉइंट्स और भी ज्यादा मायने रखते हैं। उदाहरण के लिए, Koder.ai में आप एक “planning mode” लूप चला सकते हैं ताकि React/Go/PostgreSQL को जनरेट करने से पहले आवश्यकताएँ और अनुबंध लॉक कर दिए जाएँ—फिर स्नैपशॉट/रोलबैक का उपयोग करके जब मान्यताएँ बदलें तब सुरक्षित रूप से इटरेट कर सकें—बिना हर बदलाव को रीराइट में बदलवाए।
प्रॉम्प्टिंग पैटर्न सबसे ज़्यादा तब मूल्यवान होते हैं जब वे निर्णय-चक्रीयता घटाएँ। चाल यह है कि उन्हें छोटे, दोहराने योग्य चेकपॉइंट्स के रूप में इस्तेमाल करें—कोड करने से पहले, डिज़ाइन करते हुए, और रिव्यू के दौरान—ताकि AI ऐसे आर्टिफ़ैक्ट दे जो आप पुन: उपयोग कर सकें, न कि अतिरिक्त टेक्स्ट जिसे छानना पड़े।
कोडिंग से पहले: एक alignment लूप चलाएँ ताकि लक्ष्य, उपयोगकर्ता, बाध्यताएँ, और सफलता मानदंड पक्के हों।
डिज़ाइन के दौरान: ऐसे पैटर्न प्रयोग करें जो स्पष्ट ट्रेडऑफ बोलने को मजबूर करें (विकल्प, जोखिम, डेटा सीमाएँ) इससे पहले कि आप इम्प्लीमेंटेशन शुरू करें।
रिव्यू के दौरान: चेकलिस्ट-स्टाइल प्रॉम्प्ट का उपयोग कर के गैप्स पकड़ें (एज केस, मॉनिटरिंग, सिक्योरिटी, परफॉर्मेंस) जब बदलाव अभी भी सस्ते हों।
एक छोटा, सुसंगत इनपुट बंडल बेहतर आउटपुट देगा:
यदि आपको कुछ नहीं पता, तो स्पष्ट कहें और AI से मान्यताओं की सूची माँगें।
“डिज़ाइन समझाइए” की जगह उन आर्टिफ़ैक्ट्स को माँगे जिन्हें आप डॉक या टिकट में चिपका सकें:
10–15 मिनट के लूप करें: प्रॉम्प्ट → स्किम → टाइटन। हमेशा स्वीकार्यता मानदंड शामिल करें (डिज़ाइन कब स्वीकार्य है), फिर AI से खुद-का-चेक करने को कहें। इससे प्रक्रिया अनंत डिज़ाइन में बदलने से बचती है और अगले पैटर्न्स तेज़ी से लागू होते हैं।
ज़्यादातर “आर्किटेक्चर रीराइट्स” खराब डायग्राम से नहीं होते—वे गलत (या अधूरी) समस्या के लिए सही चीज़ बनाने से होते हैं। जब आप LLM का जल्दी उपयोग करें, तो पहले आर्किटेक्चर न माँगें। उससे अस्पष्टताएँ उजागर करने को कहें।
मॉडल को आवश्यकताओं का इंटरव्यूअर बनाइए। आपका लक्ष्य एक छोटी, प्राथमिकताबद्ध स्पेक हो जिसे आप किसी भी मॉड्यूल डिज़ाइन, DB चुनाव या 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 में पेस्ट करें, स्टेकहोल्डर्स से तेज़ हाँ/ना लें, और तभी आर्किटेक्चर पर आगे बढ़ें। यह एक कदम सबसे आम कारण को रोकता है: ऐसे फीचर्स बनाना जो सचमुच जरूरी ही नहीं थे।
## पैटर्न 2: पहले user journeys, फिर तकनीकी चुनाव
जब आप टूल्स से शुरू करते हैं ("हमें event sourcing इस्तेमाल करना चाहिए?"), तो आप अक्सर आर्किटेक्चर के लिए ही डिज़ाइन कर लेते हैं बजाय उपयोगकर्ता के लिए। एक तेज़ रास्ता यह है कि AI से पहले user journeys सामान्य भाषा में लिखवाएँ, और तभी उन यात्राओं को कम्पोनेंट्स, डेटा और APIs में बदलें।
### एक सरल journey-first प्रॉम्प्ट टेम्पलेट
कॉपी-पेस्ट स्टार्टिंग पॉइंट:
- **Roles:** user / admin / system
- **Key actions:** हर रोल क्या करने की कोशिश करता है
- **Edge cases:** क्या गलत हो सकता है (अमान्य इनपुट, परमिशन गायब, आंशिक पूरा होना)
फिर कहें:
1) “Describe the step-by-step flow for each action in plain language.”
2) “Provide a simple state diagram or state list (e.g., Draft → Submitted → Approved → Archived).”
3) “List non-happy-path scenarios: timeouts, retries, duplicate requests, cancellations, and invalid inputs.”
### यात्राओं को निर्णयों में बदलना (बिना आगे कूदे)
एक बार फ्लो स्पष्ट हो जाएँ, तब AI से इन्हें टेक्निकल विकल्पों में मैप करने के लिए कहें:
- कहाँ **वैलिडेशन** चाहिए और कहाँ **बिज़नेस नियम** लागू होंगे?
- किन स्टेप्स में **idempotency** चाहिए (सुरक्षित रिट्राइ)?
- कौन सा डेटा **स्टोर** करना चाहिए, क्या निकाला जा सकता है, और किसे ऑडिट ट्रेल चाहिए?
फिर ही आर्किटेक्चर स्केच माँगे (सर्विसेज/मॉड्यूल, सीमाएँ, जिम्मेदारियाँ) जो सीधे फ्लो स्टेप्स से जुड़े हों।
### फ्लोज़ को टेस्टेबल एक्सेप्टेंस क्राइटेरिया में बदलें
AI से अनुरोध करें कि वह हर यात्रा को ऐसे एक्सेप्टेंस क्राइटेरिया में बदले जिन्हें आप टेस्ट कर सकें:
- “Given/When/Then प्रत्येक स्टेप और फ़ेल्योर केस के लिए.”
- “सिस्टम क्या रिटर्न या डिस्प्ले करे?”
- “क्या लॉग होना चाहिए, और किसे रिट्राइ ट्रिगर करना चाहिए बनाम यूज़र-फेसिंग एरर?”
यह पैटर्न रीराइट्स को घटाता है क्योंकि आर्किटेक्चर उपयोगकर्ता के व्यवहार से बढ़ता है—ना कि टेक्नोलॉजी के अनुमानों से।
## पैटर्न 3: Surprise रीराइट रोकने के लिए Assumption Log
अधिकांश आर्किटेक्चर रीवर्क बिगड़ने की वजह खराब डिज़ाइन नहीं बल्कि छुपी हुई मान्यताएँ हैं जो गलत निकलती हैं। जब आप 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.”
### एक पुन:उपयोग योग्य “assumption log” फॉर्मैट
इसे छोटा रखें ताकि लोग वाकई उपयोग करें:
- **Assumption:** …
- **Status:** validated / unknown
- **Why it matters:** किस निर्णय को प्रभावित करता है
- **How to validate:** प्रश्न, चेक, या स्पाइक
- **If wrong, likely change:** आप क्या रिडिज़ाइन करेंगे
### “What would change your answer?” ट्रिगर
एक लाइन जोड़ें जो मॉडल को उसके टिपिंग पॉइंट बताने के लिए मजबूर करे:
- “List 5 triggers: **what would change your answer?** (e.g., user volume, latency targets, compliance needs, data retention rules).”
यह पैटर्न आर्किटेक्चर को शर्तों वाले निर्णयों का नक्शा बनाता है। आपको केवल एक डायग्राम नहीं मिलता—आपको वह मैप मिलता है जिसे कन्फर्म करना आवश्यक है पहले कि आप कमिट करें।
## पैटर्न 4: चुनने से पहले कई आर्किटेक्चर की तुलना कराएँ
AI उपकरण एक "सिंगल बेस्ट" डिज़ाइन देने में अच्छे हैं—पर वह अक्सर सिर्फ पहला संभाव्य ऑप्शन होता है। एक साफ़ आर्किटेक्चर अक्सर तब दिखता है जब आप शुरुआती दौर में तुलना ज़बरदस्ती कराते हैं, जबकि बदलाव सस्ते हों।
### मूल प्रॉम्प्ट टेम्पलेट
ऐसा प्रॉम्प्ट उपयोग करें जो *कई* आर्किटेक्चर माँगे और संरचित ट्रेडऑफ तालिका दे:
```text
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 होना चाहिए, और क्या देरी की जा सकती है।
क्राइटेरिया तालिका महत्वपूर्ण है क्योंकि यह “microservices बनाम monolith” जैसी बहसों को आपसी राय से निकाल कर आपकी प्राथमिकताओं (तेज़ शिपिंग, ऑपरेशनल ओवरहेड घटाना, या विश्वसनीयता बढ़ाना) से जोड़ देती है।
“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.
आप उन मॉड्यूल्स को चाहेंगे जिन्हें आप एक teammate को एक मिनट से कम में समझा सकें। यदि AI “Utils” जैसा मॉड्यूल सुझाता है या बिज़नेस नियम को controllers में रखता है, तो वापस बोलें: "सिद्धांत निर्णय-निर्माण को domain मॉड्यूल में रखें और adapters को पतला रखें।"
जब पूरा हो जाए, आपके पास ऐसी सीमाएँ होंगी जो नई आवश्यकताओं को सहन कर सकें—क्योंकि बदलावों का एक स्पष्ट घर होगा और डिपेंडेंसी नियम आकस्मिक कप्लिंग रोकेंगे।
इंटीग्रेशन रीवर्क अक्सर “खराब कोड” से नहीं होता—यह अस्पष्ट कॉन्ट्रैक्ट्स से होता है। यदि डेटा मॉडल और API शेप बाद में तय होते हैं, तो हर टीम (या मॉड्यूल) खाली जगहों को अलग तरह से भरता है, और अगली स्प्रिंट आप mismatch सुलझाते में बिताते हैं।
पहले कॉन्ट्रैक्ट्स पर फोकस करिए—उसके बाद ही फ़्रेमवर्क, डेटाबेस, या माइक्रोसर्विसेस पर बात करें। एक साफ़ कॉन्ट्रैक्ट UI, बैकएंड और डेटा पाइपलाइंस को संरेखित रखने वाला साझा संदर्भ बन जाता है।
शुरूआत में यह प्रॉम्प्ट इस्तेमाल करें:
फिर तुरंत इसके बाद:
आप konkret आर्टिफ़ैक्ट्स चाहेंगे, न कि लम्बा prose। उदाहरण:
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 से ऐसे नियम बतवाएँ जैसे: “Additive fields बिना वर्शन बम्प के मान्य हैं; नाम बदलना /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
उन इंटरफेसेज़ का नाम लें जो फेल हो सकती हैं: external APIs, database, queues, auth provider, और background jobs। फिर ठोस निर्णय माँगें:
प्रॉम्प्ट को समाप्त करें: “Return a simple checklist we can review in 2 minutes.” एक अच्छा चेकलिस्ट आइटम्स जैसा देगा: dependency timeouts सेट, retries bound किए गए, idempotency create/charge क्रियाओं के लिए लागू, 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.”
AI से कहें कि वह जवाब दे:
एक और निर्देश जोड़ें: “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.” यह स्पष्टता को मज़बूत करता है और छुपे coupling को सामने लाता है।
एक ठोस टिकट ब्रेकडाउन आमतौर पर शामिल करता है:
अगर चाहें, मॉडल से अपनी टीम के फ़ॉर्मैट (जैसे Jira-स्टाइल फ़ील्ड) में आउटपुट माँगें और बाद के चरणों को अलग बैकलॉग रखें।
आर्किटेक्चर को भटकने से रोकने का एक आसान तरीका है कि आप डिज़ाइन माँगने से पहले टेस्ट को ज़रूरी कर दें। जब आप LLM से acceptance tests पहले लिखवाते हैं, तो उसे व्यवहारों, इनपुट/आउटपुट और एज केस को नाम देना पड़ता है। इससे गायब आवश्यकताएँ उजागर होती हैं और इम्प्लीमेंटेशन मॉड्यूल सीमा की ओर झुकता है।
किसी भी कंपोनेंट को डिज़ाइन करने से पहले इस "गेट" प्रॉम्प्ट का उपयोग करें:
फॉलो-अप में कहें: “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 डिज़ाइनों से दूर रखता है जहाँ सब कुछ सब कुछ को छूता है। यदि वह यह समझा ही नहीं पा रहा कि इंटीग्रेशन टेस्ट कहाँ शुरू होते हैं, तो आर्किटेक्चर अभी स्पष्ट नहीं है।
मांगें: “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.”
अक्सर आपको पता चलता है कि एक “सादा” फीचर भी वास्तव में एक कॉन्ट्रैक्ट, एक सीड डेटासेट, या स्थिर IDs माँगता है—यह जानना बेहतर है अब न कि रीराइट में।
एक हल्का चेकलिस्ट मांगे:
डिज़ाइन रिव्यू केवल कोड के बाद नहीं होने चाहिए। AI के साथ आप अपने आर्किटेक्चर ड्राफ्ट (चाहे कुछ पैराग्राफ ही क्यों न हों) पर एक “pre-mortem review” चला कर ठोस कमजोरियाँ लॉन्च से पहले पा सकते हैं।
कठोर रिव्युअर स्टांस से शुरू करें और विशिष्टता ज़ोर दें:
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.”
अपना डिज़ाइन सारांश, कन्ष्ट्रेन्स (बजट, टाइमलाइन, टीम कौशल), और कोई नॉन-फ़ंक्शनल आवश्यकताएँ (लेटेंसी, उपलब्धता, अनुपालन) पेस्ट करें।
रिव्यू तब विफल होता है जब फ़ीडबैक vague हो। एक प्राथमिकता वाली फिक्स सूची माँगें:
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”
यदि आप गहराई चाहते हैं, तो देखें /blog/prompting-for-code-reviews। यदि आप टूलिंग या टीम रोलआउट का मूल्यांकन कर रहे हैं, तो /pricing एक व्यावहारिक अगला कदम है।
“Cleaner architecture” यहाँ का मतलब:
AI-सहायिता वाले काम में इसका मतलब यह भी है कि मॉडल आपके आवश्यकताओं को इस तरह से दोहरा सके जिस पर आप सहमति दे सकें।
AI तेज़ी से विश्वासयोग्य कोड और डिज़ाइन बना सकता है, जिससे लोग कम पुख़्ता मान्यताओं पर जल्दी विकास कर देते हैं। यह गति उन स्थितियों को तेज कर सकती है जिनकी वजह से रीराइट होते हैं, जैसे:
समाधान “कम AI” नहीं बल्कि ऐसे प्रॉम्प्ट हैं जो जल्दी ही बाध्यताएँ, कॉन्ट्रैक्ट और मान्यताएँ सामने लाएँ।
इन पैटर्न्स को छोटी, दुहराने योग्य चेकपॉइंट्स के रूप में इस्तेमाल करें जो पुन:उपयोग योग्य आर्टिफ़ैक्ट बनाते हैं (रिक्त प्रोज़ नहीं):
इटरेशन 10–15 मिनट रखें: प्रॉम्प्ट → स्किम → टाइटनिंग → सेल्फ-चेक।
छोटा, सुसंगत इनपुट बंडल लें:
यदि कुछ अज्ञात है, तो स्पष्ट लिखें और मॉडल से करने के लिए कहें बजाय कि वह ख़ामोशी से अनुमान लगाए।
AI से “डिज़ाइन समझाइए” के बजाय ऐसे आउटपुट माँगें जिन्हें आप सीधा डॉक/टिकट/PR में चिपका सकें:
ये AI आउटपुट को कार्रवाईयोग्य रखते हैं और “लॉस्ट कॉन्टेक्स्ट” से होने वाले रीवर्क को घटाते हैं।
मॉडल को एक आवश्यकताओं के इंटरव्यूअर की तरह इस्तेमाल करें। उसे करें:
रास्ते (user journeys) से शुरू करने पर आर्किटेक्चर उपयोगकर्ता व्यवहार से बढ़ता है, न कि तकनीक से। प्रवाह पहले स्पष्ट करें:
फिर इन प्रवाहों को टेक्निकल निर्णयों से मैप करें (कहाँ वेलिडेशन है, कहाँ बिज़नेस नियम, कहाँ आइडेम्पोटेंसी चाहिए), और अंत में Given/When/Then स्वीकार्यता मानदंड निकालें।
LLM अक्सर खाली जगहों को सम्भाव्य अनुमान से भर देता है। एक assumption log उन अनुमानों को सामने लाता—ताकि गलतफहमियाँ जल्दी पकड़ी जा सकें:
साथ में पूछें: “कौन से ट्रिगर आपके जवाब बदल देंगे?” (उदा. उपयोगकर्ता वॉल्यूम, लेटेंसी, अनुपालन)। इससे डिज़ाइन शर्तों पर निर्भर बनता है और री-राइट जोखिम घटता है।
मॉडल से 2–3 व्यवहार्य आर्किटेक्चर विकल्प माँगें और उन्हें एक तालिका में तुलना कराएं (जटिलता, विश्वसनीयता, शिप का समय, स्केलेबिलिटी, लागत)। फिर:
यह तरीका पहले सम्भाव्य विकल्प को डिफ़ॉल्ट बनने से रोकता और छिपी हुई मान्यताओं को उजागर करता—जिससे स्कोप विस्तार द्वारा होने वाले रीराइट घटते हैं।
कॉन्ट्रैक्ट-फ़र्स्ट से इंटीग्रेशन-रीवर्क कम होता है क्योंकि डेटा मॉडल और API शेप पहले ही स्पष्ट होते हैं। मांगें:
जब UI, बैकएंड और इंटीग्रेशन एक ही कॉन्ट्रैक्ट आर्टिफ़ैक्ट साझा करते हैं, तो बाद में मेल-खाने में कम समय लगता है।
रिलायबिलिटी योजनाओं को डिजाइन आउटपुट का हिस्सा बनायें, न कि पोस्ट-लॉन्च का झंझट। प्रॉम्प्ट में प्रत्येक फेलियर मोड के लिए चाहिये:
अंत में 2 मिनट में रिव्यू करने योग्य चेकलिस्ट मांगे: dependency timeouts, bounded retries, idempotency की मौजूदगी, backpressure/rate limiting, graceful degradation. इससे वास्तविक ट्रैफ़िक पर होने वाले रीराइट्स घटते हैं।
जब AI शुरू से ही acceptance tests माँगे, तो उसे व्यवहार, इनपुट/आउटपुट और एज केस नामने पड़ते हैं—जो गायब आवश्यकताओं को उजागर करता है और मॉड्यूल सीमाएँ साफ़ रखता है।
प्रॉम्प्ट में माँगें:
इससे LLM को tangled डिज़ाइन देने से रोकने में मदद मिलती है—यदि यह नहीं बता सकता कि इंटीग्रेशन टेस्ट कहाँ शुरू होते हैं, तो आर्किटेक्चर अभी स्पष्ट नहीं है।
डिज़ाइन रिव्यू को कोड के बाद नहीं बल्कि पहले चलाएँ। AI से एक सख़्त रिव्युअर स्टांस अपनाने को कहें:
फिर प्रतिक्रिया को एक प्राथमिकता-पंचलिस्ट में बदलवा लें: हर आइटम के लिए Severity (Blocker/High/Medium/Low), क्यों मायने रखता है, सुझाया गया समाधान, और सबसे छोटा वैलिडेशन स्टेप।
अंत में एक “diff plan” माँगे: लक्ष्य डिज़ाइन तक पहुँचने के लिए न्यूनतम बदलाव क्या हैं, क्या रहेगा, क्या बदलेगा, और ब्रेकिन्ग प्रभाव क्या होंगे। इससे आर्किटेक्चर छोटे, उलटने योग्य कदमों में विकसित होता है और बड़े समस्याएँ जल्दी पकड़ी जाती हैं।
उस 10-बुलेट दोहरावे को एक कॉन्ट्रैक्ट मानकर स्टेकहोल्डर्स से जल्दी हाँ/ना लें, फिर ही आर्किटेक्चर पर जाएँ।