16 ਨਵੰ 2025·8 ਮਿੰਟ
ਸਾਫ਼ ਆਰਕੀਟੈਕਚਰ ਲਈ ਪ੍ਰੰਪਟਿੰਗ ਪੈਟਰਨ — ਘੱਟ ਰੀਰਾਈਟਸ
ऐसे प्रॉम्प्ट पैटर्न सीखੋ ਜੋ AI को साफ़ आवश्यकताएँ, मॉड्यूलर डिजाइन और टेस्टेबल कोड की ओर मार्गदर्शित करें—जिस से रिफैक्टर और रीराइट साइकल घटਦੇ ਹਨ।
ऐसे प्रॉम्प्ट पैटर्न सीखੋ ਜੋ AI को साफ़ आवश्यकताएँ, मॉड्यूलर डिजाइन और टेस्टेबल कोड की ओर मार्गदर्शित करें—जिस से रिफैक्टर और रीराइट साइकल घटਦੇ ਹਨ।
ਇਸ ਪੋਸਟ ਵਿੱਚ “ਸਾਫ਼ ਆਰਕੀਟੈਕਚਰ” ਦਾ ਮਤਲਬ ਕਿਸੇ ਖਾਸ ਫਰੇਮਵਰਕ ਜਾਂ ਪੂਰਨ ਡਾਇਗ੍ਰਾਮ ਨਾਲ ਨਹੀਂ ਹੈ। ਇਸਦਾ ਮਤਲਬ ਹੈ ਕਿ ਤੁਸੀਂ ਸਿਸਟਮ ਨੂੰ ਆਸਾਨੀ ਨਾਲ ਸਮਝਾ ਸਕਦੇ ਹੋ, ਬਦਲਾਅ ਕਰ ਸਕਦੇ ਹੋ ਬਿਨਾਂ ਗੈਰ-ਸੰਬੰਧਿਤ ਹਿੱਸਿਆਂ ਨੂੰ ਤੋੜੇ, ਅਤੇ ਵਿਹਾਰ ਨੂੰ ਬੈਰਹੀਟ ਟੈਸਟਾਂ ਤੋਂ ਬਿਨਾਂ ਵੀ ਪੁਸ਼ਟੀ ਕਰ ਸਕਦੇ ਹੋ।
ਸਪਸ਼ਟਤਾ ਦਾ ਮਤਲਬ ਹੈ ਕਿ ਸਿਸਟਮ ਦਾ ਉਦੇਸ਼ ਅਤੇ ਰੂਪ ਇਕ ਛੋਟੀ ਵਰਣਨਾ ਤੋਂ ਸਾਹਮਣੇ ਆਉਂਦੇ ਹਨ: ਇਹ ਕੀ ਕਰਦਾ ਹੈ, ਕੌਣ ਇਸਨੂੰ ਵਰਤਦਾ ਹੈ, ਕਿਹੜਾ ਡੇਟਾ ਹੈ, ਅਤੇ ਕੀ ਕਦੇ ਨਹੀਂ ਕਰਨਾ ਚਾਹੀਦਾ। AI-ਸਹਾਇਤ ਕੰਮ ਵਿੱਚ, ਸਪਸ਼ਟਤਾ ਇਹ ਵੀ ਹੈ ਕਿ ਮਾਡਲ ਲੋੜਾਂ ਨੂੰ ਇਸ ਤਰ੍ਹਾਂ ਦੁਹਰਾਉਂਦਾ ਹੈ ਜਿਸ 'ਤੇ ਤੁਸੀਂ ਸਵੀਕਾਰ ਕਰ ਸਕੋ।
ਮਾਡਿਊਲਰਿਟੀ ਦਾ ਮਤਲਬ ਹੈ ਕਿ ਜ਼ਿੰਮੇਵਾਰੀਆਂ ਦੇ ਸਾਫ਼ ਸਰਹੱਦ ਹੁੰਦੇ ਹਨ। ਹਰ ਮਾਡਿਊਲ ਦਾ ਇੱਕ ਕੰਮ ਹੁੰਦਾ ਹੈ, ਇਨਪੁਟ/ਆਉਟਪੁਟ, ਅਤੇ ਦੂਜੇ ਮਾਡਿਊਲਾਂ ਦੀਆਂ ਅੰਦਰੂਨੀ ਜ਼ਾਣਕਾਰੀਆਂ ਘੱਟ ਤੋਂ ਘੱਟ। ਜਦੋਂ AI ਕੋਡ ਬਣਾਉਂਦਾ ਹੈ, ਮਾਡਿਊਲਰਿਟੀ ਉਹੀ ਚੀਜ਼ ਹੈ ਜੋ ਕਾਰੋਬਾਰੀ ਨਿਯਮਾਂ ਨੂੰ controllers, UI ਅਤੇ ਡੇਟਾ ਐਕਸੈਸ 'ਚ ਚੁੱਕਣ ਤੋਂ ਰੋਕਦੀ ਹੈ।
ਟੈਸਟੇਬਲਿਟੀ ਦਾ ਮਤਲਬ ਹੈ ਕਿ ਆਰਕੀਟੈਕਚਰ "ਇਹ ਕੰਮ ਕਰਦਾ ਹੈ" ਸਾਬਤ ਕਰਨਾ ਸਸਤਾ ਬਣਾਉਂਦੀ ਹੈ। ਕਾਰੋਬਾਰੀ ਨਿਯਮ ਪੂਰੇ ਰਨਿੰਗ ਸਿਸਟਮ ਬਿਨਾਂ ਟੈਸਟ ਕੀਤੇ ਜਾ ਸਕਦੇ ਹਨ, ਅਤੇ ਇੰਟੀਗ੍ਰੇਸ਼ਨ ਟੈਸਟਾਂ ਕੁਝ ਕਾਂਟਰੈਕਟਾਂ 'ਤੇ ਧਿਆਨ ਕੇਂਦਰਤ ਕਰਦੀਆਂ ਹਨ ਬਜਾਏ ਹਰ ਕੋਡ ਪਾਥ ਦੇ।
ਰੀਰਾਈਟ ਆਮ ਤੌਰ 'ਤੇ "ਮੁੱਦੇ ਵਾਲੇ ਕੋਡ" ਦੀ ਵਜ੍ਹਾ ਨਾਲ ਨਹੀਂ ਹੁੰਦੇ—ਇਹਨਾਂ ਦੀ ਵਜ੍ਹਾ ਹੁੰਦੀ ਹੈ ਗੈਰ-ਮੌਜੂਦ ਪਾਬੰਦੀਆਂ, ਧੂੜ-ਭਰਾ ਸਕੋਪ, ਅਤੇ ਲੁਕਵੇਂ ਅਨੁਮਾਨ। ਉਦਾਹਰਣਾਂ:
ਏਆਈ ਇਸ ਫੇਲਿਅਰ ਮੋਡ ਨੂੰ ਤੇਜ਼ ਕਰ ਸਕਦਾ ਹੈ ਕਿਉਂਕਿ ਇਹ ਤੇਜ਼ੀ ਨਾਲ ਵਿਸ਼ਵਾਸੀ ਨਤੀਜੇ ਬਣਾਉਂਦਾ ਹੈ, ਜੋ ਢਿਲ੍ਹੇ ਨਿਰਧਾਰਾਂ 'ਤੇ ਨਿਰਭਰ ਹੋ ਕੇ ਕੰਮ ਸਕੂ ਦੇਂਦਾ ਹੈ।
ਅੱਗੇ ਦਿੱਤੇ ਪੈਟਰਨ ਅਨੁਕੂਲ ਕਰਨ ਯੋਗ ਟੈਮਪਲੇਟਾਂ ਹਨ, ਜਾਦੂਈ ਪ੍ਰੰਪਟ ਨਹੀਂ। ਉਨ੍ਹਾਂ ਦਾ ਅਸਲ ਮਕਸਦ ਇਹ ਹੈ ਕਿ ਸ਼ੁਰੂ ਵਿੱਚ ਸਹੀ ਗੱਲਬਾਤ ਨੂੰ ਮਜ਼ਬੂਤ ਕੀਤਾ ਜਾਵੇ: ਪਾਬੰਦੀਆਂ ਸਪਸ਼ਟ ਕਰੋ, ਵਿਕਲਪਾਂ ਦੀ ਤੁਲਨਾ ਕਰੋ, ਅਨੁਮਾਨਾਂ ਦਸਤਾਵੇਜ਼ ਕਰੋ, ਅਤੇ ਕਾਂਟਰੈਕਟਾਂ ਨਿਰਧਾਰਿਤ ਕਰੋ। ਜੇ ਤੁਸੀਂ ਇਹ ਸੋਚ ਛੱਡ ਦਿੰਦੇ ਹੋ, ਮਾਡਲ ਖ਼ੁਸ਼ੀ-ਖ਼ੁਸ਼ੀ ਖਾਲੀਆਂ ਭਰ ਦੇਵੇਗਾ—ਅਤੇ ਅੱਗੇ ਖਰਚ ਤੁਹਾਨੂੰ ਭਰਨਾ ਪਏਗਾ।
ਤੁਸੀਂ ਇਨ੍ਹਾਂ ਨੂੰ ਸਾਰੇ ਡੈਲੀਵਰੀ ਚੱਕਰ 'ਚ ਵਰਤੋਂਗੇ:
ਜੇ ਤੁਸੀਂ vibe-coding ਵਰਕਫਲੋ ਵਰਤ ਰਹੇ ਹੋ (ਜਿੱਥੇ ਸਿਸਟਮ ਚੈਟ ਰਾਹੀਂ ਜਨਰੇਟ ਅਤੇ ਇਟਰੇਟ ਹੁੰਦਾ ਹੈ), ਇਹ ਚੈਕਪੁਆਇੰਟ ਹੋਰ ਵੀ ਮਹੱਤਵਪੂਰਣ ਹੋ ਜਾਂਦੇ ਹਨ। ਉਦਾਹਰਣ ਲਈ, Koder.ai ਵਿੱਚ ਤੁਸੀਂ ਇੱਕ "ਪਲੈਨਿੰਗ ਮੋਡ" ਲੂਪ ਚਲਾ ਸਕਦੇ ਹੋ ਤਾਂ ਜੋ React/Go/PostgreSQL ਕੋਡ ਜਨਰੇਟ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਲੋੜਾਂ ਅਤੇ ਕਾਂਟਰੈਕਟ ਲੌਕ ਕੀਤੇ ਜਾਣ, ਫਿਰ ਅਨੁਮਾਨ ਬਦਲਣ 'ਤੇ ਸਨੇਪਸ਼ੌਟ/ਰੋਲ ਬੈਕ ਵਰਤ ਕੇ ਸੁਰੱਖਿਅਤ ਤੌਰ 'ਤੇ ਇਟਰੇਟ ਕੀਤਾ ਜਾ ਸਕੇ—ਬਿਨਾਂ ਹਰ ਬਦਲਾਅ ਨੂੰ ਰੀਰਾਈਟ ਵਿੱਚ ਬਦਲੇ।
ਪੈਟਰਨ ਸਭ ਤੋਂ ਕੀਮਤੀ ਹਨ ਜਦੋਂ ਉਹ ਫੈਸਲਾ-ਚੱਕਰ ਨੂੰ ਘਟਾਉਂਦੇ ਹਨ। ਚਾਲ ਇਹ ਹੈ ਕਿ ਉਨ੍ਹਾਂ ਨੂੰ ਛੋਟੇ, ਦੁਹਰਾਏ ਜਾਣ ਵਾਲੇ ਚੈਕਪੌਇੰਟ ਵਜੋਂ ਵਰਤੋਂ—ਕੋਡਿੰਗ ਤੋਂ ਪਹਿਲਾਂ, ਡਿਜ਼ਾਈਨ ਦੌਰਾਨ, ਅਤੇ ਸਮੀਖਿਆ ਦੌਰਾਨ—ਤਾਂ ਜੋ AI ਐਸੇ ਆਰਟੀਫੈਕਟ ਬਣਾਏ ਜੋ ਤੁਸੀਂ ਦੁਬਾਰਾ ਵਰਤ ਸਕੋ, ਨਾ ਕਿ ਵਧੇਰੇ ਪਾਠ ਜੋ ਤੁਹਾਨੂੰ ਛਾਣਨਾ ਪਵੇ।
ਕੋਡਿੰਗ ਤੋਂ ਪਹਿਲਾਂ: ਇੱਕ "ਸਮਨਵੇਸ਼" ਲੂਪ ਚਲਾਓ ਤਾਂ ਕਿ ਲਕਸ਼, ਯੂਜ਼ਰ, ਪਾਬੰਦੀਆਂ, ਅਤੇ ਸਫਲਤਾ ਮੈਟਰਿਕ ਪੁਸ਼ਟੀ ਹੋਣ।
ਡਿਜ਼ਾਈਨ ਦੌਰਾਨ: ਉਹ ਪੈਟਰਨ ਵਰਤੋ ਜੋ ਸਪਸ਼ਟ ਟਰੇਡ-ਆਫ਼ ਮੂਹਿਆ ਕਰਵਾਉਂਦੇ ਹਨ (ਉਦਾਹਰਨ: ਵਿਕਲਪ, ਖ਼ਤਰੇ, ਡੇਟਾ ਸਰਹੱਦ) ਜਦੋਂ ਤੁਸੀਂ ਇੰਪਲੀਮੈਂਟੇਸ਼ਨ ਸ਼ੁਰੂ ਕਰੋ।
ਸਮੀਖਿਆ ਦੌਰਾਨ: ਇੱਕ ਚੈਕਲਿਸਟ-ਸਟਾਈਲ ਪ੍ਰੰਪਟ ਵਰਤੋ ਤਾਂ ਕਿ ਖ਼ਾਲੀਆਂ (ਐਜ ਕੇਸ, ਮਾਨੀਟਰਿੰਗ, ਸੁਰੱਖਿਆ, ਕਾਰਗੁਜ਼ਾਰੀ) ਤਿਆਗ ਦੀਆਂ ਖ਼ਾਮੀਆਂ ਨੂੰ ਛੇਤੀ ਪਕੜਿਆ ਜਾ ਸਕੇ।
ਛੋਟੇ ਅਤੇ ਸਥਿਰ ਇਨਪੁਟ ਬੰਡਲ ਨਾਲ ਤੁਸੀਂ ਵਧੀਆ ਨਤੀਜੇ ਲੈ ਸਕਦੇ ਹੋ:
ਜੇ ਤੁਹਾਨੂੰ ਕੁਝ ਨਹੀਂ ਪਤਾ, ਤਾਂ ਖੁੱਲ੍ਹ ਕੇ ਕਹੋ ਅਤੇ ਮਾਡਲ ਨੂੰ ਅਨੁਮਾਨਾਂ ਦੀ ਸੂਚੀ ਬਣਾਉਣ ਲਈ ਕਿਹਾ ਜਾਵੇ।
"ਡਿਜ਼ਾਈਨ ਦੀ ਵਿਆਖਿਆ ਕਰੋ" ਦੀ ਥਾਂ, ਐਸੇ ਆਰਟੀਫੈਕਟ ਮੰਗੋ ਜੋ ਤੁਸੀਂ ਡੌਕਸ ਜਾਂ ਟਿਕਟਾਂ ਵਿੱਚ ਪੇਸਟ ਕਰ ਸਕੋ:
10–15 ਮਿੰਟ ਦੇ ਲੂਪ ਕਰੋ: ਪ੍ਰੰਪਟ → ਸਕਿਮ → ਤਿੱਖਾ ਕਰੋ। ਹਮੇਸ਼ਾ ਸਵੀਕਾਰਤਾ ਮਾਪਦੰਡ ਸ਼ਾਮਲ ਕਰੋ (ਡਿਜ਼ਾਈਨ ਕਬੂਲ ਕਰਨ ਲਈ ਕੀ ਸੱਚ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ), ਫਿਰ ਮਾਡਲ ਨੂੰ ਆਪਣੇ ਆਪ ਨੂੰ ਉਨ੍ਹਾਂ ਦੇ ਖ਼ਿਲਾਫ਼ ਚੈੱਕ ਕਰਨ ਲਈ ਕਹੋ। ਇਸ ਤਰ੍ਹਾਂ ਪ੍ਰਕਿਰਿਆ ਲੰਬੇ ਸਮੇਂ ਦੀ ਨਿਰਮਾਣ-ਚੱਕਰ ਨਹੀਂ ਬਣਦੀ ਅਤੇ ਅੱਗੇ ਦੇ ਸੈਕਸ਼ਨਾਂ ਦੇ ਪੈਟਰਨ ਤੇਜ਼ੀ ਨਾਲ ਲਾਗੂ ਹੋ ਜਾਂਦੇ ਹਨ।
ਬਹੁਤੇ "ਆਰਕੀਟੈਕਚਰ ਰੀਰਾਈਟ" diagrams ਦੀ ਨਾੜ ਨਹੀਂ ਹੁੰਦੇ—ਉਹ ਉਸ ਗਲਤ (ਜਾਂ ਅਧੂਰੇ) ਪ੍ਰਸ਼ਨ ਲਈ ਸਹੀ ਚੀਜ਼ ਬਣਾਉਣ ਕਾਰਨ ਹੁੰਦੇ ਹਨ। ਜਦੋਂ ਤੁਸੀਂ 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 ਵਿੱਚ ਪੇਸਟ ਕਰੋ, ਹਿੱਸੇਦਾਰਾਂ ਕੋਲੋਂ ਤੇਜ਼ ਹاں/ਨਾ ਲਓ, ਅਤੇ ਫਿਰ ਹੀ ਆਰਕੀਟੈਕਚਰ 'ਤੇ ਅੱਗੇ ਵਧੋ। ਇਹ ਇਕ ਕਦਮ ਸਭ ਤੋਂ ਆਮ ਕਾਰਨ ਨੂੰ ਰੋਕਦਾ ਹੈ: ਉਹ ਫੀਚਰ ਬਣਾਉਣਾ ਜੋ ਅਸਲ ਵਿੱਚ ਕਦੇ ਲੋੜੀਂਦੇ ਹੀ ਨਹੀਂ ਸਨ।
ਜਦੋਂ ਤੁਸੀਂ ਟੂਲਾਂ ਤੋਂ ਸ਼ੁਰੂ ਕਰਦੇ ਹੋ ("ਸਾਨੂੰ event sourcing ਵਰਤਣਾ ਚਾਹੀਦਾ ਹੈ?"), ਤਾਂ ਅਕਸਰ ਤੁਸੀਂ ਆਰਕੀਟੈਕਚਰ ਲਈ ਡਿਜ਼ਾਈਨ ਕਰਦੇ ਹੋ ਨ ਕਿ ਯੂਜ਼ਰ ਲਈ। ਇੱਕ ਤੇਜ਼ ਰਾਹ ਸਾਫ ਬਣਤਰ ਵੱਲ ਹੈ: ਮਾਡਲ ਨੂੰ ਪਹਿਲਾਂ ਯੂਜ਼ਰ ਯਾਤਰਾਵਾਂ ਸਧੀ ਭਾਸ਼ਾ ਵਿੱਚ ਵੇਰਣ ਕਰਨ ਲਈ ਕਹੋ, ਅਤੇ ਫਿਰ ਉਹਨਾਂ ਯਾਤਰਾਵਾਂ ਨੂੰ ਕੰਪੋਨੈਂਟ, ਡੇਟਾ, ਅਤੇ APIs 'ਚ ਤਰਜਮਾ ਕਰੋ।
ਇਸਨੂੰ ਇੱਕ ਸ਼ੁਰੂਆਤੀ ਟੈਮਪਲੇਟ ਵਜੋਂ ਵਰਤੋ:
ਫਿਰ ਪੁੱਛੋ:
“Describe the step-by-step flow for each action in plain language.”
“Provide a simple state diagram or state list (e.g., Draft → Submitted → Approved → Archived).”
“List non-happy-path scenarios: timeouts, retries, duplicate requests, cancellations, and invalid inputs.”
ਜਦੋਂ ਫਲੋਜ਼ ਸਪਸ਼ਟ ਹੋ ਜਾਂਦੇ ਹਨ, ਤਾਂ ਤੁਸੀਂ ਮਾਡਲ ਨੂੰ ਇਹ ਮੈਪ ਕਰਨ ਲਈ ਕਹਿ ਸਕਦੇ ਹੋ:
ਇਸ ਤੋਂ ਬਾਅਦ ਹੀ ਤੁਸੀਂ ਆਰਕੀਟੈਕਚਰ ਸਕੈਚ ਦੀ ਮੰਗ ਕਰੋ (ਸੇਵਾਵਾਂ/ਮਾਡਿਊਲ, ਸਰਹੱਦ, ਅਤੇ ਜ਼ਿੰਮੇਵਾਰੀਆਂ) ਜੋ ਸਿੱਧੇ ਤੌਰ 'ਤੇ ਫਲੋ ਕਦਮਾਂ ਨਾਲ ਜੁੜੇ ਹੋਣ।
ਅੰਤ ਵਿੱਚ ਮਾਡਲ ਨੂੰ ਹਰ ਯਾਤਰਾ ਲਈ acceptance criteria ਵਿੱਚ ਬਦਲਣ ਲਈ ਕਹੋ:
ਇਹ ਪੈਟਰਨ ਰੀਰਾਈਟ ਘਟਾਉਂਦਾ ਹੈ ਕਿਉਂਕਿ ਆਰਕੀਟੈਕਚਰ ਯੂਜ਼ਰ ਬਿਹੇਵਿਅਰ ਤੋਂ ਵੱਧਦਾ ਹੈ—ਨ ਕਿ ਟੈਕ ਮੰਨਿਆਂ ਤੋਂ।
ਜ਼ਿਆਦਾਤਰ ਆਰਕੀਟੈਕਚਰ ਰੀਵਰਕ "ਖਰਾਬ ਡਿਜ਼ਾਈਨ" ਕਰਕੇ ਨਹੀਂ ਹੁੰਦੇ—ਉਹ ਲੁਕਵੇਂ ਅਨੁਮਾਨਾਂ ਕਰਕੇ ਹੁੰਦੇ ਹਨ ਜੋ ਗਲਤ ਸਾਬਤ ਹੋ ਜਾਂਦੇ ਹਨ। ਜਦੋਂ ਤੁਸੀਂ 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:
ਇੱਕ ਤੁਲਨਾ ਮਾਡਲ (ਅਤੇ ਤੁਹਾਨੂੰ) ਅਣਜਾਣ ਅਨੁਮਾਨਾਂ ਦਾ ਪਤਾ ਲਗਾਉਂਦੀ ਹੈ: ਕਿੱਥੇ ਸਟੇਟ ਰਹਿੰਦੀ ਹੈ, ਸੇਵਾਵਾਂ ਕਿਵੇਂ ਗੱਲਬਾਤ ਕਰਦੀਆਂ ਹਨ, ਕਿਹੜਾ ਸੁੰਕਲਨ synchronous ਹੋਣਾ ਚਾਹੀਦਾ ਅਤੇ ਕਿਹੜਾ ਲੇਟ ਕੀਤਾ ਜਾ ਸਕਦਾ।
ਕ੍ਰਾਈਟੇਰੀਆ ਟੇਬਲ ਮਹੱਤਵਪੂਰਨ ਹੈ ਕਿਉਂਕਿ ਇਹ ਮਸਲਿਆਂ ਨੂੰ "microservices vs monolith" ਵਰਗੀਆਂ ਰਾਏ ਤੋਂ ਬੰਨ੍ਹ ਕੇ ਰੱਖਦਾ ਹੈ। ਇਹ ਫੈਸਲਾ ਉਸ ਚੀਜ਼ ਨਾਲ ਜੁੜਿਆ ਹੈ ਜੋ ਤੁਸੀਂ ਅਸਲ ਵਿੱਚ ਚਾਹੁੰਦੇ ਹੋ—ਤੇਜ਼ੀ ਨਾਲ ਸ਼ਿਪ ਕਰਨਾ, ਓਪਰੇਸ਼ਨਲ ਓਵਰਹੈਡ ਘਟਾਉਣਾ, ਜਾਂ ਭਰੋਸੇਯੋਗਤਾ ਬਿਹਤਰ ਕਰਨਾ।
"ਇਸ 'ਤੇ ਨਿਰਭਰ ਹੈ" ਇਹ ਜਵਾਬ ਕਬੂਲ ਨਾ ਕਰੋ। ਇੱਕ ਸਪਸ਼ਟ ਸਿਫਾਰਸ਼ ਮੰਗੋ ਅਤੇ ਉਹਨਾਂ ਖਾਸ ਪਾਬੰਦੀਆਂ ਨੂੰ ਦਰਸਾਓ ਜੋ ਉਹ ਅਪਟਿਮਾਈਜ਼ ਕਰਦੀ ਹੈ।
ਨਾਲ ਹੀ "ਅਸੀਂ ਇਸ ਇਟਰੇਸ਼ਨ ਵਿੱਚ ਕੀ ਨਹੀਂ ਬਣਾਉਂਦੇ" ਬਾਰੇ ਜ਼ੋਰ ਦਿਓ। ਉਦਾਹਰਣ: "ਕੋਈ multi-region failover ਨਹੀਂ," "ਕੋਈ plugin ਸਿਸਟਮ ਨਹੀਂ," "ਕੋਈ 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" ਮਾਡਿਊਲ ਪ੍ਰਸਤਾਵਿਤ ਕਰਦਾ ਹੈ ਜਾਂ ਕਾਰੋਬਾਰੀ ਨਿਯਮ controllers ਵਿੱਚ ਰੱਖਦਾ ਹੈ, ਤਾਂ ਵਾਪਸ ਪੁੱਛੋ: "ਫੈਸਲਾ-ਬਨਾਉਣ ਨੂੰ domain ਮਾਡਿਊਲ ਵਿੱਚ ਮੂਵ ਕਰੋ ਅਤੇ adapters ਨੂੰ ਪਤਲਾ ਰੱਖੋ।"
ਜਦੋਂ ਤੁਸੀਂ ਇਸਨੂੰ ਪੂਰਾ ਕਰ ਲੈਂਦੇ ਹੋ, ਤੁਹਾਡੇ ਕੋਲ ਐਸੇ ਸਰਹੱਦ ਹੁੰਦੇ ਹਨ ਜੋ ਨਵੀਆਂ ਲੋੜਾਂ ਨੂੰ ਜ਼ਿਆਦਾ ਅਮਲਯੋਗ ਬਣਾਉਂਦੇ ਹਨ—ਕਿਉਂਕਿ ਬਦਲਾਅਾਂ ਦਾ ਇੱਕ ਸਾਫ ਘਰ ਹੁੰਦਾ ਹੈ ਅਤੇ ਡਿਪੈਂਡੇੰਸੀ ਨਿਯਮ ਗੈਰ-ਇਚਛਿਤ coupling ਨੂੰ ਰੋਕਦੇ ਹਨ।
ਇੰਟੀਗ੍ਰੇਸ਼ਨ ਰੀਵਰਕ ਅਕਸਰ "ਬੁਰੇ ਕੋਡ" ਨਾਲ ਨਹੀਂ ਹੁੰਦਾ—ਇਹ ਅਸਪਸ਼ਟ ਕਾਂਟ੍ਰੈਕਟਾਂ ਨਾਲ ਹੁੰਦਾ ਹੈ। ਜੇ ਡੇਟਾ ਮਾਡਲ ਅਤੇ API ਸ਼ੇਪ ਬਾਅਦ ਵਿੱਚ ਨਿਰਧਾਰਤ ਕੀਤੀਆਂ ਜਾਂਦੀਆਂ ਹਨ, ਤਾਂ ਹਰ ਟੀਮ (ਜਾਂ ਹਰ ਮਾਡਿਊਲ) ਵੱਖ-ਵੱਖ ਤਰੀਕੇ ਨਾਲ ਖਾਲੀਆਂ ਪੂਰੀਆਂ ਕਰਦੀ ਹੈ, ਅਤੇ ਅਗਲੇ ਸਪ੍ਰਿੰਟ ਵਿੱਚ ਤੁਸੀਂ mismatch ਕਰਕੇ ਰਿਕਾਂਸਾਈਲ ਕਰਦੇ ਹੋ।
ਸ਼ੁਰੂ ਕਰੋ ਇਨਟਰਫੇਸਾਂ ਲਈ ਕਾਂਟ੍ਰੈਕਟ ਮੰਗ ਕੇ ਪਹਿਲਾਂ ਕਿ ਤੁਸੀਂ ਫਰੇਮਵਰਕ, ਡੇਟਾਬੇਸ ਜਾਂ ਮਾਇਕਰੋਸਰਵਿਸਜ਼ 'ਤੇ ਚਰਚਾ ਕਰੋ। ਇੱਕ ਸਪਸ਼ਟ ਕਾਂਟ੍ਰੈਕਟ ਇੱਕ ਸਾਂਝਾ ਰੈਫਰੰਸ ਬਣਦਾ ਹੈ ਜੋ UI, ਬੈਕਐਂਡ ਅਤੇ ਡੇਟਾ ਪਾਇਪਲਾਈਨਾਂ ਨੂੰ ਮਿਲਦਾ ਹੈ।
ਇਹ ਸਵੇਰੇ ਪ੍ਰੰਪਟ ਆਪਣੇ AI ਸਹਿਯੋਗੀ ਨਾਲ ਵਰਤੋ:
ਫਿਰ ਤੁਰੰਤ ਪੁੱਛੋ:
ਤੁਸੀਂ ਨਿਰਧਾਰਤ ਆਰਟੀਫੈਕਟ ਚਾਹੁੰਦੇ ਹੋ, ਨਾ ਕਿ ਸਿਰਫ਼ 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"}
}
}
ਮਾਡਲ ਨੂੰ ਐਸੇ ਨਿਯਮ ਕਹਿਣ ਲੱਗੋ: “Additive fields ਬਿਨਾਂ ਵਰਜ਼ਨ ਬੰਪ ਕੀਤੇ ਠੀਕ ਹਨ; rename ਕਰਨ ਲਈ /v2 ਲੋੜੀਦਾ ਹੈ; ਕਲਾਇੰਟਾਂ ਨੂੰ ਅਣਜਾਣ ਫੀਲਡ ਅਣਦੇਖਾ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ।” ਇਹ ਇਕ ਕਦਮ ਚੁਪਕੇ-ਚੁਪਕੇ-breaking ਚੇੰਜਾਂ ਨੂੰ ਰੋਕਦਾ ਹੈ—ਅਤੇ ਓਹ ਰੀਰਾਈਟ ਜੋ ਬਾਅਦ ਵਿੱਚ ਆਉਂਦੇ ਹਨ ਉਹ ਘਟ ਜਾਂਦੇ ਹਨ।
ਆਰਕੀਟੈਕਚਰ ਉਹਨਾਂ ਲਈ ਰੀਰਾਈਟ ਹੁੰਦੇ ਹਨ ਜਦੋਂ "ਹੈਪੀ-ਪਾਥ" ਡਿਜ਼ਾਈਨ ਸੱਚੇ ਟ੍ਰੈਫਿਕ, ਫਲੇਕੀ dependencies, ਅਤੇ ਅਣਉਮੀਦ ਯੂਜ਼ਰ ਵਿਹਾਰਾਂ ਨਾਲ ਮਿਲਦਾ ਹੈ। ਇਹ ਪੈਟਰਨ ਭਰੋਸੇਯੋਗਤਾ ਨੂੰ ਇੱਕ ਨਿਰਧਾਰਤ ਡਿਜ਼ਾਈਨ ਆਉਟਪੁੱਟ ਬਣਾਉਂਦਾ ਹੈ ਨਾ ਕਿ ਲਾਂਚ ਬਾਅਦ ਦਾ ਸਕ੍ਰੈਂਬਲ।
ਇਸਨੂੰ ਆਪਣੇ ਚੁਣੇ ਹੋਏ ਆਰਕੀਟੈਕਚਰ ਵੇਰਨੇ ਦੇ ਨਾਲ ਵਰਤੋ:
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, ਅਤੇ background jobs। ਫਿਰ ਨਿਜੀ ਫੈਸਲੇ ਮੰਗੋ:
ਪ੍ਰੰਪਟ ਨੂੰ ਇਸ ਨਾਲ ਖਤਮ ਕਰੋ: “Return a simple checklist we can review in 2 minutes.” ਇੱਕ ਚੰਗਾ ਚੈਕਲਿਸਟ ਦਾਂਤਾਂ ਵਿੱਚ ਸ਼ਾਮਲ ਹੁੰਦਾ ਹੈ: dependency timeouts ਸੈੱਟ, retries ਬਾਉਂਡ ਹੋਏ, create/charge actions ਲਈ 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.” ਇਹ ਸਪਸ਼ਟਤਾ ਮਜ਼ਬੂਤ ਕਰਦਾ ਅਤੇ ਲੁਕਵੇਂ 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”
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.
"Cleaner architecture" ਇੱਥੇ ਇਸਦਾ ਮਤਲਬ ਹੈ ਕਿ ਤੁਸੀਂ:
ਏਆਈ-ਸਹਾਇਤ ਕੰਮ ਵਿੱਚ, ਇਸਦਾ ਇਹ ਵੀ ਮਤਲਬ ਹੈ ਕਿ ਮਾਡਲ ਲੋੜਾਂ ਨੂੰ ਇਸ ਤਰੀਕੇ ਨਾਲ ਦੁਬਾਰਾ ਕਹਿ ਸਕੇ ਜਿਸ 'ਤੇ ਤੁਸੀਂ ਸਵੀਕਾਰ ਕਰਦੇ ਹੋ।
ਏਆਈ ਤੇ ਆਧਾਰਿਤ ਵਿਕਾਸ ਤੇਜ਼ ਕੋਡ ਅਤੇ ਡਿਜ਼ਾਈਨ ਬਣਾਉਂਦਾ ਹੈ, ਜਿਸ ਕਾਰਨ ਅਕਸਰ ਤੁਸੀਂ ਅਧੂਰੀ ਪਾਬੰਦੀਆਂ ਅਤੇ ਲੁਕਵੇਂ ਅਨੁਮਾਨਾਂ 'ਤੇ ਨਿਰਭਰ ਹੋ ਕੇ ਕੰਮ ਕਰਦੇ ਹੋ। ਇਹ ਗਤੀ ਉਹਨਾਂ ਟ੍ਰੀਗਰਾਂ ਨੂੰ ਜ਼ਿਆਦਾ ਤੇਜ਼ੀ ਨਾਲ ਵਧਾ ਸਕਦੀ ਹੈ ਜਿਵੇਂ:
ਇਸਦਾ ਹੱਲ "ਕਮ ਏਆਈ" ਨਹੀਂ—ਸਗੋਂ ਐਸੇ ਪ੍ਰੰਪਟਾਂ ਦਾ ਉਪਯੋਗ ਹੈ ਜੋ ਸ਼ੁਰੂ ਵਿਚ ਹੀ ਪਾਬੰਦੀਆਂ, ਕਾਂਟ੍ਰੈਕਟ ਅਤੇ ਅਨੁਮਾਨਾਂ ਨੂੰ ਸਾਹਮਣੇ ਲਿਆਉਂਦੇ ਹਨ।
ਪੈਟਰਨਾਂ ਨੂੰ ਛੋਟੇ, ਦੁਹਰਾਏ ਜਾਣ ਵਾਲੇ ਚੈੱਕਪੌਇੰਟ ਵਜੋਂ ਵਰਤੋ ਜੋ ਮੁਲਤਵੀ ਨਹੀਂ ਹੁੰਦੇ ਅਤੇ ਕਿਰਿਆਸ਼ੀਲ ਨਤੀਜੇ ਦੇਂਦੇ ਹਨ:
ਇੱਤਲਾਂ 10–15 ਮਿੰਟ ਦੇ ਛੋਟੇ ਲੂਪ ਰੱਖੋ: ਪ੍ਰੰਪਟ → ਸਕਿਮ → ਤਿੱਖਾ ਕਰੋ → ਸਵੈ-ਚੈੱਕ (ਐਕਸੈਪਟੈਂਸ ਮਾਪਦੰਡਾਂ ਦੇ ਖ਼ਿਲਾਫ਼)।
ਛੋਟੀ, ਲਗਾਤਾਰ ਇੰਪੁੱਟ ਪੈਕ ਲਿਆਓ:
ਜੇਕਰ ਕੁਝ ਅਣਜਾਣ ਹੋਵੇ, ਉਹ ਖੁੱਲ੍ਹ ਕੇ ਦੱਸੋ ਅਤੇ ਮਾਡਲ ਨੂੰ ਅਨੁਮਾਨਾਂ ਦੀ ਸੂਚੀ ਬਣਾਉਣ ਲਈ ਕਿਹਾ ਜਾਵੇ।
ਕੁਝ ਐਸੇ ਨਤੀਜੇ ਮੰਗੋ ਜੋ ਸਿੱਧੇ ਦਸਤਾਵੇਜ਼ਾਂ ਜਾਂ ਟਿਕਟਾਂ ਵਿੱਚ ਚਿਪਕਾਏ ਜਾ ਸਕਣ:
ਇਹ AI ਆਉਟਪੁੱਟ ਨੂੰ ਕਾਰਗਰ ਬਣਾਉਂਦਾ ਹੈ ਅਤੇ "ਲੋਸਟ ਕਾਂਟੈਕਸਟ" ਕਾਰਨ ਹੋਣ ਵਾਲੀ ਰੀਰਾਈਟ ਘਟਾਉਂਦਾ ਹੈ।
ਮਾਡਲ ਨੂੰ ਇੱਕ ਲੱਗਾਤਾਰ ਇੰਟਰਵਿਊਅਰ ਵਜੋਂ ਵਰਤੋ:
ਆਰੰਭ roles ਅਤੇ actions ਨਾਲ ਕਰੋ, ਫਿਰ ਮੰਗੋ:
ਫਲੋਜ਼ ਸਪੱਸ਼ਟ ਹੋਣ ਤੋਂ ਬਾਅਦ, ਉਹਨਾਂ ਨੂੰ ਫੈਸਲਿਆਂ ਨਾਲ ਮੇਪ ਕਰੋ: ਕਿੱਥੇ ਵੈਲਿਡੇਸ਼ਨ ਹੋਣੀ ਚਾਹੀਦੀ, ਕਿੱਥੇ ਕਾਰੋਬਾਰੀ ਨਿਯਮ ਲਾਗੂ ਹੁੰਦੇ, ਕਿੱਥੇ idempotency ਲੋੜੀਂਦੀ। ਫਿਰ ਇਹਨਾਂ ਫਲੋਜ਼ ਨੂੰ Given/When/Then ਟੈਸਟਮਾਮੇਟਰੀ ਕਰਾਈਟੇਰੀਆ ਵਿੱਚ ਬਦਲੋ।
LLM ਜਦੋਂ خلا ਭਰਦਾ ਹੈ ਤਾਂ ਉਹ ਸੰਭਾਵਨਾਤਮਕ ਅਨੁਮਾਨ ਭਰ ਸਕਦਾ ਹੈ। ਇੱਕ assumption log ਉਹਨਾਂ ਅਨੁਮਾਨਾਂ ਨੂੰ ਪਹਿਲਾਂ ਸਪਸ਼ਟ ਕਰਵਾਉਂਦਾ ਹੈ।
ਹਰ assumption ਲਈ ਮੰਗੋ:
ਨਾਲ ਹੀ "ਕੀ ਚੀਜ਼ ਤੁਹਾਡੇ ਜਵਾਬ ਨੂੰ ਬਦਲ ਸਕਦੀ ਹੈ?" ਦੇ 5 ਟ੍ਰਿਗਰ ਵੀ ਮੰਗੋ (ਜਿਵੇਂ ਵਰਤੋਂਕਾਰ ਵੋਲਿਊਮ, ਲੈਟੰਸੀ ਟਾਰਗਟ, ਕੰਪਲਾਇੰਸ).
ਮਾਡਲ ਨੂੰ 2–3 ਵੱਖ-ਵੱਖ ਆਟਿਕਟੈਕਚਰਸ ਪ੍ਰਸਤਾਵਿਤ ਕਰਨ ਲਈ ਮਜਬੂਰ ਕਰੋ ਅਤੇ ਇੱਕ ਸਰਚਿਤ ਟੇਬਲ ਵਿੱਚ ਉਹਨਾਂ ਦੀ ਤੁਲਨਾ ਕਰੋ (ਜਟਿਲਤਾ, ਭਰੋਸਾ, ਟਾਈਮ-ਟੂ-ਸ਼ਿਪ, ਸਕੇਲਬਿਲਟੀ, ਲਾਗਤ).
ਮੰਗੋ: ਇੱਕ ਸਪੱਸ਼ਟ ਸਿਫਾਰਸ਼ ਜੋ ਤੁਹਾਡੇ ਨਿਯਮਾਂ ਨੂੰ ਧਿਆਨ ਵਿੱਚ ਰੱਖੇ ਅਤੇ "ਇਸ ਇਟਰੇਸ਼ਨ ਵਿੱਚ ਅਸੀਂ ਇਹ ਨਹੀਂ ਬਣਾਉਂਦੇ" ਦੀ ਸੂਚੀ।
ਇਸ ਤਰ੍ਹਾਂ ਪਹਿਲੀ ਮਨੁੱਖੀ ਪਸੰਦੀਦਾ ਵਿਕਲਪ ਠੋਸ ਮਨਜ਼ੂਰੀ ਥਾਂ ਨਹੀਂ ਲੈਂਦਾ ਅਤੇ ਸਕੋਪ-ਵਿਸਤਾਰ ਰੋਕਦਾ ਹੈ।
ਕਾਂਟ੍ਰੈਕਟ-ਫਰਸਟ ਪਹੁੰਚ ਇੰਟੀਗ੍ਰੇਸ਼ਨ ਰੀਵਰਕ ਨੂੰ ਘਟਾਉਂਦੀ ਹੈ ਕਿਉਂਕਿ ਡੇਟਾ ਆਕਾਰ ਅਤੇ ਅਨੁਕੂਲਤਾ ਨਿਯਮ ਸਪੱਸ਼ਟ ਰੱਖੇ ਜਾਂਦੇ ਹਨ।
ਮੰਗੋ:
/v2 ਬਿਨਾ ਬਗੈਰ ਸ਼ਾਮਲ ਹੋ ਸਕਦੇ; ਨਾਮ-ਬਦਲ v2 ਮੰਗੇ; ਕਲਾਇੰਟ ਅਣਜਾਣ ਫੀਲਡ ਨੂੰ ਅਣਦੇਖਾ ਕਰਨ)ਇਹ ਇਕ ਸਾਂਝਾ ਰਿਫਰੰਸ ਆਰਟਿਫੈਕਟ ਬਨਦਾ ਹੈ ਜੋ UI, ਬੈਕਐਂਡ ਅਤੇ ਇंटीਗ੍ਰੇਸ਼ਨਾਂ ਨੂੰAligned ਰੱਖਦਾ ਹੈ।