साफ़ आर्किटेक्चर के लिए प्रॉम्प्टिंग पैटर्न: कम रीराइट्स

AI-सहायिता वाले काम में “Cleaner Architecture” कैसा दिखता है

इस पोस्ट में “cleaner architecture” का मतलब किसी विशेष फ़्रेमवर्क या परफेक्ट डायाग्राम नहीं है। इसका मतलब है कि आप सिस्टम को सरलता से समझा सकें, बदल सकें बिना अनजान हिस्सों को तोड़े, और बिना हीरोइक टेस्टिंग के व्यवहार सत्यापित कर सकें।

एक व्यावहारिक परिभाषा: स्पष्टता, मॉड्युलैरिटी, टेस्टेबिलिटी

स्पष्टता का मतलब है कि सिस्टम का उद्देश्य और रूप एक छोटी सी व्याख्या से स्पष्ट हो: यह क्या करता है, कौन उपयोग करता है, कौन सा डेटा हैंडल करता है, और क्या कभी नहीं करना चाहिए। AI-सहायिता वाले काम में, स्पष्टता का मतलब यह भी है कि मॉडल आवश्यकताओं को लौटाकर इस तरह बताए कि आप उस पर साइन-ऑफ कर दें।

मॉड्युलैरिटी का मतलब है जिम्मेदारियों की साफ़ सीमाएँ। हर मॉड्यूल का एक काम होता है, इनपुट/आउटपुट होते हैं, और दूसरे मॉड्यूल की इनरवर्किंग का न्यूनतम ज्ञान होता है। जब AI कोड जनरेट करता है, मॉड्युलैरिटी ही उसे बिज़नेस नियमों को controllers, UI और data access में फैलने से रोकती है।

टेस्टेबिलिटी का मतलब है कि आर्किटेक्चर “काम साबित करो” को सस्ता बनाती है। बिज़नेस नियमों को पूरे सिस्टम के बिना टेस्ट किया जा सकता है, और इंटीग्रेशन टेस्ट कुछ अनुबंधों पर केन्द्रित रहते हैं बजाय हर कोड पाथ के।

रीराइट्स क्यों होते हैं (और AI इसे कैसे तेज़ कर सकता है)

रीराइट्स अक्सर "बुरे कोड" की वजह से नहीं होते—वे होते हैं गायब प्रतिबंध, धुंधला स्कोप, और छुपी मान्यताओं की वजह से। उदाहरण:

• एक फीचर एक user type के लिए बनाया जाता है, फिर पता चलता है कि तीन रोल हैं और अलग परमिशन चाहिए।
• प्रदर्शन, ऑडिट लॉगिंग, या डेटा रिटेंशन नियम बाद में सामने आते हैं।
• बाहरी API उम्मीद से अलग व्यवहार करता है, जिससे हर जगह बदलाव करना पड़ता है।

AI इस विफलता मोड को तेज कर सकता है क्योंकि यह तेज़ी से भरोसेमंद आउटपुट देता है, जिससे लोग कम मजबूत आधारों पर जल्दी निर्माण कर देते हैं।

इस गाइड में पैटर्न्स से क्या उम्मीद रखें

आगे जो पैटर्न्स हैं वे अनुकूलनीय टेम्प्लेट हैं, जादुई प्रॉम्प्ट नहीं। इनका असली उद्देश्य सही बातचीत जल्दी मजबूर करना है: प्रतिबंध साफ करना, विकल्पों की तुलना कराना, मान्यताओं को दस्तावेज़ बनाना और अनुबंध परिभाषित करना। अगर आप यह सोच छोड़ देंगे, तो मॉडल ख़ुशी-खुशी खाली जगह भर देगा—और बाद में आपको उसकी कीमत चुकानी पड़ेगी।

ये पैटर्न आपके वर्कफ़्लो में कहाँ फिट होते हैं

आप इन्हें पूरे डिलिवरी चक्र में इस्तेमाल करेंगे:

• प्लानिंग: आवश्यकताओं और सफलता मानदंडों को कसना
• डिज़ाइन: सीमाएँ, डेटा फ्लो, और अनुबंध चुनना
• कोडिंग: जैसे-जैसे इम्प्लीमेंटेशन बढ़े, जिम्मेदारियाँ अलग रखना
• रिव्यू: जोखिम और मिसमैच पकड़ना पहले कि वे रीराइट बनें

यदि आप "vibe-coding" वर्कफ़्लो इस्तेमाल कर रहे हैं (जहाँ सिस्टम चैट के जरिए जनरेट और इटरेट होता है), तो ये चेकपॉइंट्स और भी ज्यादा मायने रखते हैं। उदाहरण के लिए, Koder.ai में आप एक “planning mode” लूप चला सकते हैं ताकि React/Go/PostgreSQL को जनरेट करने से पहले आवश्यकताएँ और अनुबंध लॉक कर दिए जाएँ—फिर स्नैपशॉट/रोलबैक का उपयोग करके जब मान्यताएँ बदलें तब सुरक्षित रूप से इटरेट कर सकें—बिना हर बदलाव को रीराइट में बदलवाए।

पैटर्न्स का इस्तेमाल बिना अतिरिक्त काम बढ़ाए कैसे करें

प्रॉम्प्टिंग पैटर्न सबसे ज़्यादा तब मूल्यवान होते हैं जब वे निर्णय-चक्रीयता घटाएँ। चाल यह है कि उन्हें छोटे, दोहराने योग्य चेकपॉइंट्स के रूप में इस्तेमाल करें—कोड करने से पहले, डिज़ाइन करते हुए, और रिव्यू के दौरान—ताकि AI ऐसे आर्टिफ़ैक्ट दे जो आप पुन: उपयोग कर सकें, न कि अतिरिक्त टेक्स्ट जिसे छानना पड़े।

पैटर्न्स कब इस्तेमाल करें

कोडिंग से पहले: एक alignment लूप चलाएँ ताकि लक्ष्य, उपयोगकर्ता, बाध्यताएँ, और सफलता मानदंड पक्के हों।

डिज़ाइन के दौरान: ऐसे पैटर्न प्रयोग करें जो स्पष्ट ट्रेडऑफ बोलने को मजबूर करें (विकल्प, जोखिम, डेटा सीमाएँ) इससे पहले कि आप इम्प्लीमेंटेशन शुरू करें।

रिव्यू के दौरान: चेकलिस्ट-स्टाइल प्रॉम्प्ट का उपयोग कर के गैप्स पकड़ें (एज केस, मॉनिटरिंग, सिक्योरिटी, परफॉर्मेंस) जब बदलाव अभी भी सस्ते हों।

पहले इनपुट इकट्ठा करें (हल्का रखें)

एक छोटा, सुसंगत इनपुट बंडल बेहतर आउटपुट देगा:

• लक्ष्य: “ख़त्म” होने का क्या अर्थ है (लेटेंसी टार्गेट, UX परिणाम, लागत सीमा)
• उपयोगकर्ता: रोल्स, प्रमुख वर्कफ़्लो, और टॉप पेन पॉइंट्स
• बाध्यताएँ: टेक स्टैक, डेडलाइन, अनुपालन/सुरक्षा जरूरतें
• डेटा & इंटीग्रेशन: स्रोत, ओनरशिप, APIs, थर्ड-पार्टी डिपेंडेंसीज़

यदि आपको कुछ नहीं पता, तो स्पष्ट कहें और AI से मान्यताओं की सूची माँगें।

पुन:उपयोग योग्य आउटपुट फॉर्मैट माँगे

“डिज़ाइन समझाइए” की जगह उन आर्टिफ़ैक्ट्स को माँगे जिन्हें आप डॉक या टिकट में चिपका सकें:

• एक डिसीजन लॉग (विकल्प → फायदे/नुकसान → चुना गया → क्यों)
• एक कम्पोनेंट टेबल (जिम्मेदारियाँ और सीमाएँ)
• एक रिलायबिलिटी/टेस्ट चेकलिस्ट
• एक सरल डायग्राम विवरण (जैसे Mermaid टेक्स्ट)

छोटे लूप में इटरेट करें और एक्सेप्टेंस क्राइटेरिया दें

10–15 मिनट के लूप करें: प्रॉम्प्ट → स्किम → टाइटन। हमेशा स्वीकार्यता मानदंड शामिल करें (डिज़ाइन कब स्वीकार्य है), फिर AI से खुद-का-चेक करने को कहें। इससे प्रक्रिया अनंत डिज़ाइन में बदलने से बचती है और अगले पैटर्न्स तेज़ी से लागू होते हैं।

पैटर्न 1: किसी भी डिज़ाइन से पहले आवश्यकताएँ साफ़ करें

ज़्यादातर “आर्किटेक्चर रीराइट्स” खराब डायग्राम से नहीं होते—वे गलत (या अधूरी) समस्या के लिए सही चीज़ बनाने से होते हैं। जब आप 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.” यह आर्किटेक्चर को उन फीचर्स को गुप्त रूप से विस्तार करने से रोकता जिनके लिए आपने कमिट नहीं किया—और बाद में स्कोप बदलने पर होने वाले रीराइट रोकता है।

पैटर्न 5: मॉड्युलर सीमाएँ और जिम्मेदारी प्रॉम्प्ट्स

ज्यादातर रीराइट्स इसलिए होते हैं क्योंकि सीमाएँ अस्पष्ट थीं: सब कुछ "सब कुछ" को छूता है, और एक छोटा बदलाव पूरे कोडबेस में लहरें भेज देता है। यह पैटर्न ऐसे प्रॉम्प्ट्स का उपयोग करता है जो कोई भी विवरण विमर्श करने से पहले स्पष्ट मॉड्यूल मालिकाना ज़बरदस्ती कराते हैं।

मूल विचार

AI से कहें कि वह मॉड्यूल और जिम्मेदारियाँ परिभाषित करे, साथ में क्या स्पष्ट रूप से नहीं आता हर मॉड्यूल में। फिर इंटरफेसेस (इनपुट/आउटपुट) और डिपेंडेंसी नियम माँगे, न कि बिल्ड प्लान या इम्प्लीमेंटेशन विवरण।

कॉपी-पेस्ट प्रॉम्प्लेट

जब आप नया फीचर स्केच कर रहे हों या किसी गंदे एरिया का रिफैक्टर कर रहे हों, तब यह उपयोग करें:

• Context: <one paragraph about the product/feature>
• Goal: Propose a modular architecture with 4–8 modules.

1. List modules with:

   • Purpose (1 sentence)
   • Responsibilities (3–5 bullets)
   • Non-responsibilities (“does NOT handle…”) (2–3 bullets)

2. For each module, define interfaces only:

   • Inputs (events/requests/data)
   • Outputs (responses/events/side effects)
   • Public API surface (function names or endpoints ok; no internal classes)

3. Dependency rules:

   • Allowed dependencies (A → B)
   • Forbidden dependencies (A ↛ C) with reasoning
   • Where shared types live (and what must never be shared)

4. 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 को पतला रखें।"

जब पूरा हो जाए, आपके पास ऐसी सीमाएँ होंगी जो नई आवश्यकताओं को सहन कर सकें—क्योंकि बदलावों का एक स्पष्ट घर होगा और डिपेंडेंसी नियम आकस्मिक कप्लिंग रोकेंगे।

पैटर्न 6: डेटा & API कॉन्ट्रैक्ट पहले (इंटीग्रेशन रीकवर्क से बचें)

इंटीग्रेशन रीवर्क अक्सर “खराब कोड” से नहीं होता—यह अस्पष्ट कॉन्ट्रैक्ट्स से होता है। यदि डेटा मॉडल और API शेप बाद में तय होते हैं, तो हर टीम (या मॉड्यूल) खाली जगहों को अलग तरह से भरता है, और अगली स्प्रिंट आप mismatch सुलझाते में बिताते हैं।

पहले कॉन्ट्रैक्ट्स पर फोकस करिए—उसके बाद ही फ़्रेमवर्क, डेटाबेस, या माइक्रोसर्विसेस पर बात करें। एक साफ़ कॉन्ट्रैक्ट UI, बैकएंड और डेटा पाइपलाइंस को संरेखित रखने वाला साझा संदर्भ बन जाता है।

कॉन्ट्रैक्ट-फ़र्स्ट प्रॉम्प्ट

शुरूआत में यह प्रॉम्प्ट इस्तेमाल करें:

• Template: “Describe the data model, ownership, and lifecycle for each entity”

फिर तुरंत इसके बाद:

• हर एंटिटी के लिए API कॉन्ट्रैक्ट उदाहरण (requests, responses, error shapes) माँगें
• वर्शनिंग और बैकवर्ड- कम्पैटिबिलिटी अपेक्षाएँ जोड़ें
• फील्ड-स्तर पर वैलिडेशन नियम और एज केस माँगें

“अच्छा” आउटपुट कैसा लगे

आप konkret आर्टिफ़ैक्ट्स चाहेंगे, न कि लम्बा prose। उदाहरण:

• Entity: Subscription
  • Owner: Billing service
  • Lifecycle: created on checkout → active → past_due → canceled (soft-delete after 90 days)
  • Source of truth: billing DB; other services cache read-only copies

और एक 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 माँगता है; क्लाइंट्स अनजान फ़ील्ड्स को इग्नोर करें।” यह एक कदम चुपचाप ब्रेकिंग बदलावों को रोकता—और बाद में होने वाले रीराइट्स को टालता है।

पैटर्न 7: फेल्योर मोड और रिलायबिलिटी चेकलिस्ट

आर्किटेक्चर तभी रीराइट होते हैं जब “हैप्पी पाथ” डिज़ाइन वास्तविक ट्रैफ़िक, फ्लेकी डिपेंडेंसीज़, और अनपेक्षित यूज़र बिहेवियर से मिलते हैं। यह पैटर्न रिलायबिलिटी को स्पष्ट डिज़ाइन आउटपुट बनाता है, न कि पोस्ट-लॉन्च स्क्रैम्बल।

कॉपी/पेस्ट प्रॉम्प्ट टेम्पलेट

अपने चुने हुए आर्किटेक्चर विवरण के साथ यह चलाएँ:

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। फिर ठोस निर्णय माँगें:

• Retries: कब retry करें, कितनी बार, बैकऑफ रणनीति, और कौन से एरर retryable हैं।
• Idempotency: idempotency keys, dedupe विंडो, और कौन सा state replay करने में सुरक्षित है।
• Rate limits: प्रति user/IP/service लिमिट्स, क्लाइंट संदेश, और सर्वर-साइड सुरक्षा।
• Timeouts: हर डिपेंडेंसी के लिए, कुल अनुरोध बजट, और कैंसलेशन propagation।

रिलायबिलिटी चेकलिस्ट आउटपुट

प्रॉम्प्ट को समाप्त करें: “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”。हर एक के लिए माँगे:

• Log fields (user_id, request_id, idempotency_key)
• Metrics (success rate, latency p95/p99, retry count)
• Traces (spans per dependency call)

यह रिलायबिलिटी को एक डिज़ाइन आर्टिफ़ैक्ट बनाता है जिसे आप कोड के बिना ही सत्यापित कर सकते हैं।

पैटर्न 8: MVP स्लाइस प्लानिंग से ओवर-बिल्डिंग रोकें

AI-सहायिता वाले डिज़ाइन में एक सामान्य समस्या यह है कि “पूरा” आर्किटेक्चर जल्दी ही बनवा लिया जाता है। समाधान सरल है: योजना को सबसे छोटे उपयोगी स्लाइस से शुरू कराएँ—जो वैल्यू दे, डिज़ाइन को परखे, और भविष्य के विकल्प खुला रखें।

प्रॉम्प्ट टेम्पलेट

जब समाधान ज़रूरत से तेज़ बढ़ने लगे, यह इस्तेमाल करें:

Template: “Propose the smallest usable slice; define success metrics; list follow-ups.”

AI से कहें कि वह जवाब दे:

• MVP slice: क्या शामिल है ताकि कुछ वास्तविक शिप हो सके
• Success metrics: कैसे पता चलेगा कि यह काम किया (यूज़र-फेसिंग + टेक्निकल)
• Follow-ups: क्या बाद में किया जा सकता है बिना सीखने को रोके

चरणबद्ध रोडमैप (MVP → v1 → v2) माँगे

एक और निर्देश जोड़ें: “Give a phased roadmap: MVP → v1 → v2, and explain what risk each phase reduces.” इससे बाद के आइडियाज़ दिखाई देंगे पर पहले रिलीज़ में उन्हें शामिल नहीं किया जाएगा।

उम्मीद के अनुसार परिणाम:

• MVP कोर वर्कफ़्लो और एक पतला end-to-end पाथ मान्य करता है।
• v1 रिलायबिलिटी को मजबूत करता है और जरूरी उपयोगिता जोड़ता है।
• v2 ब्रॉड्थ बढ़ाता है (अधिक इंटीग्रेशन, एडवांस्ड रोल्स, ऑप्टिमाइज़ेशन)।

MVP के लिए स्पष्ट बाहर रखी चीज़ें माँगे

सबसे प्रभावी लाइन: “List what is explicitly out of scope for MVP.” यह एक्सक्लूजन आर्किटेक्चर निर्णयों को समय से पहले जटिल करने से रोकता है।

अच्छी एक्सक्लूज़न्स दिखती हैं जैसे:

• “No multi-region failover in MVP (log incidents; plan for v2).”
• “No plugin system yet (keep boundaries clean, but ship fixed modules).”
• “Only one payment provider; abstract later if needed.”

योजना को टिकटों में बदलें

अंत में: “Convert the MVP into tickets, each with acceptance criteria and dependencies.” यह स्पष्टता को मज़बूत करता है और छुपे coupling को सामने लाता है।

एक ठोस टिकट ब्रेकडाउन आमतौर पर शामिल करता है:

1. एक पतला end-to-end “happy path”
2. न्यूनतम डेटा मॉडल + API कॉन्ट्रैक्ट
3. बेसिक एरर हैंडलिंग और लॉगिंग
4. एक इंटीग्रेशन पॉइंट (यदि आवश्यक) के साथ स्टब्ड फॉलबैक

अगर चाहें, मॉडल से अपनी टीम के फ़ॉर्मैट (जैसे Jira-स्टाइल फ़ील्ड) में आउटपुट माँगें और बाद के चरणों को अलग बैकलॉग रखें।

पैटर्न 9: टेस्ट-फर्स्ट प्रॉम्प्ट्स जो बेहतर डिज़ाइन बनाते हैं

आर्किटेक्चर को भटकने से रोकने का एक आसान तरीका है कि आप डिज़ाइन माँगने से पहले टेस्ट को ज़रूरी कर दें। जब आप LLM से acceptance tests पहले लिखवाते हैं, तो उसे व्यवहारों, इनपुट/आउटपुट और एज केस को नाम देना पड़ता है। इससे गायब आवश्यकताएँ उजागर होती हैं और इम्प्लीमेंटेशन मॉड्यूल सीमा की ओर झुकता है।

कॉपी-पेस्ट प्रॉम्प्ट टेम्पलेट

किसी भी कंपोनेंट को डिज़ाइन करने से पहले इस "गेट" प्रॉम्प्ट का उपयोग करें:

• Template: “Write acceptance tests first; then propose implementation. You must: (1) list assumptions, (2) name unit vs integration tests, (3) define test data and mocks vs real dependencies, (4) include a definition of done.”

मॉड्यूल के अनुरूप टेस्ट सीमाएँ माँगे

फॉलो-अप में कहें: “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 डिज़ाइनों से दूर रखता है जहाँ सब कुछ सब कुछ को छूता है। यदि वह यह समझा ही नहीं पा रहा कि इंटीग्रेशन टेस्ट कहाँ शुरू होते हैं, तो आर्किटेक्चर अभी स्पष्ट नहीं है।

टेस्ट डेटा रणनीति: brittle सूट से बचें

मांगें: “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 माँगता है—यह जानना बेहतर है अब न कि रीराइट में।

Definition of done (ताकि डिज़ाइन शिप हो)

एक हल्का चेकलिस्ट मांगे:

• Tests passing (unit + integration) और failure cases का अर्थपूर्ण कवरेज
• न्यूनतम डॉक: उपयोग, कॉन्फ़िग, और एक छोटा troubleshooting नोट
• मॉनिटरिंग/अलर्ट्स प्रमुख फेल्योर मोड्स के लिए
• रोलआउट योजना (feature flag, migration steps, rollback)

पैटर्न 10: डिज़ाइन रिव्यू प्रॉम्प्ट्स से समस्याएँ जल्दी पकड़ें

डिज़ाइन रिव्यू केवल कोड के बाद नहीं होने चाहिए। 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.”

अपना डिज़ाइन सारांश, कन्ष्ट्रेन्स (बजट, टाइमलाइन, टीम कौशल), और कोई नॉन-फ़ंक्शनल आवश्यकताएँ (लेटेंसी, उपलब्धता, अनुपालन) पेस्ट करें।

प्रतिक्रिया को actionable punch list में बदलें

रिव्यू तब विफल होता है जब फ़ीडबैक 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?”

आप सटीकता नहीं चाहते—आप सबसे रीराइट-प्रोन मान्यताओं को सामने लाना चाहते हैं।

अंत में एक “diff plan” माँगें

रिव्यू को स्कोप बढ़ाने से रोकें:

Prompt: “Provide a diff plan: minimal changes needed to reach the target design. List what stays the same, what changes, and any breaking impacts.”

जब आप इस पैटर्न को हर इटरेशन पर दोहराते हैं, तो आर्किटेक्चर छोटे, उल्टनीय चरणों में विकसित होता है—और बड़े मुद्दे जल्दी पकड़े जाते हैं।

एक कॉपी-पेस्ट प्रॉम्प्ट पैक और सरल वर्कफ़्लो

इस पैक को ऐसे हल्के वर्कफ़्लो के रूप में इस्तेमाल करें जिसे आप हर फीचर पर दोहरा सकें। विचार यह है कि प्रॉम्प्ट्स को चेन करें ताकि हर कदम एक आर्टिफ़ैक्ट बनाए जिसे अगला कदम पुन: उपयोग करे—इससे “खोया हुआ संदर्भ” और आश्चर्यजनक रीराइट्स कम होते हैं।

6-स्टेप वर्कफ़्लो (इन पैटर्न्स को चेन करें)

1. Requirements (clarify + constraints)
2. Architecture options (compare 2–3 approaches)
3. Boundaries (modules + responsibilities)
4. Contracts (data + APIs)
5. Tests (test-first acceptance + key unit tests)
6. Review (failure modes + design review checklist)

व्यवहार में टीमें अक्सर इस चेन को एक पुनरावृत्त “फीचर रेसिपी” के रूप में लागू करती हैं। यदि आप 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 एक व्यावहारिक अगला कदम है।