15 ਜੂਨ 2025·8 ਮਿੰਟ
AI ਨਾਲ ਬੈਕਐਂਡ ਸਕੀਮਾਂ, API ਅਤੇ ਡਾਟਾ ਮਾਡਲ ਦਿਜ਼ਾਈਨ ਕਰਵਾਉਣਾ
ਜਾਣੋ ਕਿ AI-ਜਨਰੇਟ ਕੀਤੇ ਸਕੀਮਾ ਅਤੇ APIs ਡਿਲੀਵਰੀ ਤੇ ਕਿਵੇਂ ਤੇਜ਼ੀ ਲਿਆਉਂਦੇ ਹਨ, ਕਿੱਥੇ ਫੇਲ ਹੁੰਦੇ ਹਨ, ਅਤੇ ਬੈਕਐਂਡ ਡਿਜ਼ਾਈਨ ਦੀ ਸਮੀਖਿਆ, ਟੈਸਟ ਅਤੇ ਗਵਰਨੈਂਸ ਲਈ ਇੱਕ ਪ੍ਰਾਇਕਟਿਕਲ ਵਰਕਫਲੋ।
ਜਾਣੋ ਕਿ AI-ਜਨਰੇਟ ਕੀਤੇ ਸਕੀਮਾ ਅਤੇ APIs ਡਿਲੀਵਰੀ ਤੇ ਕਿਵੇਂ ਤੇਜ਼ੀ ਲਿਆਉਂਦੇ ਹਨ, ਕਿੱਥੇ ਫੇਲ ਹੁੰਦੇ ਹਨ, ਅਤੇ ਬੈਕਐਂਡ ਡਿਜ਼ਾਈਨ ਦੀ ਸਮੀਖਿਆ, ਟੈਸਟ ਅਤੇ ਗਵਰਨੈਂਸ ਲਈ ਇੱਕ ਪ੍ਰਾਇਕਟਿਕਲ ਵਰਕਫਲੋ।
ਜਦੋਂ ਲੋਕ ਕਹਿੰਦੇ ਹਨ “AI ਨੇ ਸਾਡਾ ਬੈਕਐਂਡ ਡਿਜ਼ਾਈਨ ਕੀਤਾ”, ਉਹ ਅਕਸਰ ਮਤਲਬ ਲੈਂਦੇ ਹਨ ਕਿ ਮਾਡਲ ਨੇ ਕੋਰ ਤਕਨੀਕੀ ਬਲੂਪ੍ਰਿੰਟ ਦਾ ਇੱਕ ਪਹਿਲਾ ਡਰਾਫਟ ਤਿਆਰ ਕੀਤਾ: ਡੇਟਾਬੇਸ ਟੇਬਲਾਂ (ਜਾਂ ਕਲੈਕਸ਼ਨ), ਉਨ੍ਹਾਂ ਦੇ ਰਿਸ਼ਤੇ, ਅਤੇ ਉਹ API ਜੋ ਡੇਟਾ ਪੜ੍ਹਦੇ ਅਤੇ ਲਿਖਦੇ ਹਨ। ਅਮਲੀ ਤੌਰ 'ਤੇ, ਇਹ ਘੱਟ "AI ਨੇ ਸਭ ਕੁਝ ਬਣਾ ਦਿੱਤਾ" ਅਤੇ ਜ਼ਿਆਦਾ "AI ਨੇ ਇੱਕ ਢਾਂਚਾ ਸੁਝਾਇਆ ਜਿਸਨੂੰ ਅਸੀਂ ਲਾਗੂ ਅਤੇ ਸੋਧ ਸਕਦੇ ਹਾਂ" ਹੁੰਦਾ ਹੈ।
ਘੱਟੋ-ਘੱਟ, AI ਜਨਰੇਟ ਕਰ ਸਕਦਾ ਹੈ:
users, orders, subscriptions ਵਰਗੀਆਂ ਟੇਬਲ/ਕਲੈਕਸ਼ਨ ਅਤੇ ਫੀਲਡ ਤੇ ਬੁਨਿਆਦੀ ਟਾਈਪ।AI "ਆਮ" ਪੈਟਰਨ ਅਨੁਮਾਨ ਲਗਾ ਸਕਦਾ ਹੈ, ਪਰ ਜਦੋ ਰਿਕੁਆਇਰਮੈਂਟ ਅਸਪਸ਼ਟ ਜਾਂ ਡੋਮੇਨ-ਖਾਸ ਹੋਣ ਜਾਂ, ਇਹ ਠੀਕ ਮਾਡਲ ਚੁਣਨ ਵਿੱਚ ਭਰੋਸੇਯੋਗ ਨਹੀਂ ਹੁੰਦਾ। ਇਹ ਤੁਹਾਡੇ ਅਸਲ ਨੀਤੀਆਂ ਨਹੀਂ ਜਾਣਦਾ ਜਿਵੇਂ:
cancelled ਵਿਰੁੱਧ refunded ਵਿਰੁੱਧ voided)।AI ਆਉਟਪੁੱਟ ਨੂੰ ਤੇਜ਼, ਬਣਤਰਬੱਧ ਸ਼ੁਰੂਆਤ ਦੇ ਤੌਰ 'ਤੇ ਵੱਖੋ—ਇੱਕ ਐਸਾ ਸਰੀਹਾ ਜੋ ਵਿਕਲਪ ਖੰਗਾਲਣ ਅਤੇ ਛੁਟੀਆਂ ਪਹੁੰਚਣ ਵਿੱਚ ਮਦਦਗਾਰ ਹੈ—ਪਰ ਇਸਨੂੰ ਬਿਨਾਂ ਸੋਧੇ ਸ਼ਿਪ ਕਰਨ ਯੋਗ ਸਪੈਸ ਨਹੀਂ ਸਮਝੋ। ਤੁਹਾਡਾ ਕੰਮ ਹੈ ਸਪਸ਼ਟ ਨਿਯਮ ਅਤੇ ਏਜ ਕੇਸ ਦੇਣਾ, ਫਿਰ AI ਦੇ ਉਤਪਾਦ ਦੀ ਉਸੇ ਤਰੀਕੇ ਨਾਲ ਸਮੀਖਿਆ ਕਰਨੀ ਜਿਵੇਂ ਤੁਸੀਂ ਕਿਸੇ ਜੂਨੀਅਰ ਇੰਜੀਨੀਅਰ ਦੇ ਪਹਿਲੇ ਡਰਾਫਟ ਦੀ ਕਰਦੇ ਹੋ: ਸਹਾਇਕ, ਕਈ ਵਾਰੀ ਪ੍ਰਭਾਵਸ਼ਾਲੀ, ਪਰ ਕਈ ਵਾਰੀ ਸੁਤੰਤਰ ਤਰੀਕੇ ਨਾਲ ਸੁੱਟੇ ਗਲਤ ਹੋ ਸਕਦੇ।
AI ਤੇਜ਼ੀ ਨਾਲ ਸਕੀਮਾ ਜਾਂ API ਡ੍ਰਾਫਟ ਕਰ ਸਕਦਾ ਹੈ, ਪਰ ਇਹ ਉਹ ਗੁੰਮ ਹੋਏ ਤੱਥ ਨਹੀਂ ਬਣਾਉਂਦਾ ਜੋ ਬੈਕਐਂਡ ਨੂੰ ਤੁਹਾਡੇ ਉਤਪਾਦ ਨਾਲ "ਫਿੱਟ" ਬਣਾਉਂਦੇ ਹਨ। ਸਭ ਤੋਂ ਵਧੀਆ ਨਤੀਜੇ ਉਸ ਵੇਲੇ ਮਿਲਦੇ ਹਨ ਜਦੋਂ ਤੁਸੀਂ AI ਨੂੰ ਇੱਕ ਤੇਜ਼ ਜੂਨੀਅਰ ਡਿਜ਼ਾਈਨਰ ਵਾਂਗ ਵਰਤਦੇ ਹੋ: ਤੁਸੀਂ ਸਪਸ਼ਟ ਸੀਮਾਵਾਂ ਦਿੰਦੇ ਹੋ, ਅਤੇ ਇਹ ਵਿਕਲਪ ਸੁਝਾਉਂਦਾ ਹੈ।
ਟੇਬਲ, ਐਂਡਪੋਇੰਟ ਜਾਂ ਮਾਡਲ ਮੰਗਣ ਤੋਂ ਪਹਿਲਾਂ, ਬੁਨਿਆਦੀ ਗੱਲਾਂ ਲਿਖੋ:
ਜਦੋਂ ਰਿਕੁਆਇਰਮੈਂਟ ਧੁੰਧਲੇ ਹੁੰਦੇ ਹਨ, AI ਡਿਫ਼ੌਲਟ ਅਨੁਮਾਨ ਲਗਾਉਂਦਾ ਹੈ: ਹਰ ਥਾਂ ਪਸ਼ਨਲ ਫੀਲਡ, ਜਨਰਿਕ status ਕਾਲਮ, ਅਸਪਸ਼ਟ ਮਾਲਕੀਅਤ, ਅਤੇ ਅਨਗਿਨਤ ਨਾਮਕਰਨ। ਇਹ ਅਕਸਰ ਉਹਨਾਂ ਸਕੀਮਾਂ ਨੂੰ ਜਨਮ ਦਿੰਦਾ ਹੈ ਜੋ ਲੋੜੀਂਦੇ ਵਰਤੋਂ 'ਤੇ ਟੁੱਟ ਜਾਂਦੀਆਂ ਹਨ—ਖ਼ਾਸ ਕਰਕੇ ਪਰਮਿਸ਼ਨ, ਰਿਪੋਰਟਿੰਗ, ਅਤੇ ਏਜ ਕੇਸ (ਰਿਫੰਡ, ਰੱਦ, ਹਿੱਸੇਦਾਰ ਸ਼ਿਪਮੈਂਟ) ਦੇ ਇਲਾਕਿਆਂ ਵਿੱਚ। ਬਾਅਦ ਵਿੱਚ ਤੂੰ ਇਹਦਾ ਭੁਗਤਾਨ ਮਾਈਗ੍ਰੇਸ਼ਨਸ, ਵਰਕਅਰਾਊਂਡ ਅਤੇ ਉਲਝਣ ਭਰੇ APIs ਰੂਪ ਵਿੱਚ ਦੇਖੇਂਗੇ।
ਇਸਨੂੰ ਪ੍ਰਾਂਪਟ ਵਿੱਚ ਚਿਪਕਾਓ ਅਤੇ ਵਰਤੋਂ ਸ਼ੁਰੂ ਕਰੋ:
Product summary (2–3 sentences):
Entities (name → definition):
-
Workflows (steps + states):
-
Roles & permissions:
- Role:
- Can:
- Cannot:
Reporting questions we must answer:
-
Integrations (system → data we store):
-
Constraints:
- Compliance/retention:
- Expected scale:
- Latency/availability:
Non-goals (what we won’t support yet):
-
AI ਉਸ ਵੇਲੇ ਸਭ ਤੋਂ ਵਧੀਆ ਹੁੰਦਾ ਹੈ ਜਦੋਂ ਤੁਸੀਂ ਇਸਨੂੰ ਤੇਜ਼ ਡਰਾਫਟ ਮਸ਼ੀਨ ਵਾਂਗ ਵਰਤਦੇ ਹੋ: ਇਹ ਇੱਕ ਪਹਿਲਾ-ਪਾਸ ਡੇਟਾ ਮਾਡਲ ਅਤੇ ਮਿਲਦਾ-ਜੁਲਾ API ਸਤਹ ਮਿੰਟਾਂ ਵਿੱਚ ਖੜਾ ਕਰ ਸਕਦਾ ਹੈ। ਇਹ ਗਤੀ ਤੁਹਾਡੇ ਕੰਮ ਕਰਨ ਦੇ ਢੰਗ ਨੂੰ ਬਦਲਦੀ ਹੈ—ਨਾ ਕਿ ਕਿਉਂਕਿ ਆਉਟਪੁੱਟ ਜਾਦੂਈ ਤੌਰ 'ਤੇ "ਠੀਕ" ਹੈ, ਪਰ ਇਸ ਲਈ ਕਿ ਤੁਸੀਂ ਤੁਰੰਤ ਕਿਸੇ ਸੰਰਚਨਾ 'ਤੇ ਦੁਹਰਾਅ ਕਰ ਸਕਦੇ ਹੋ।
ਸਭ ਤੋਂ ਵੱਡੀ ਜਿੱਤ cold start ਦੂਰ ਕਰਨਾ ਹੈ। AI ਨੂੰ ਐਨਟਿਟੀਜ਼, ਮੁੱਖ ਯੂਜ਼ਰ ਫਲੋਜ਼, ਅਤੇ ਸੀਮਾਵਾਂ ਦੀ ਛੋਟੀ ਵਿਆਖਿਆ ਦਿਓ, ਅਤੇ ਇਹ ਟੇਬਲ/ਕਲੈਕਸ਼ਨ, ਰਿਸ਼ਤੇ, ਅਤੇ ਇੱਕ ਬੇਸਲਾਈਨ API ਸਤਹ ਸੁਝਾ ਸਕਦਾ ਹੈ। ਇਹ ਖ਼ਾਸ ਤੌਰ 'ਤੇ ਕੀਮਤੀ ਹੈ ਜਦੋਂ ਤੁਹਾਨੂੰ ਜਲਦੀ ਡੈਮੋ ਚਾਹੀਦਾ ਹੋਵੇ ਜਾਂ ਪ੍ਰਭਾਵੀ ਰਿਕੁਆਇਰਮੈਂਟ ਹਲੇ-ਹਲੇ ਬਦਲ ਰਹੇ ਹੋਣ।
ਇਹ ਗਤੀ ਸਭ ਤੋਂ ਜ਼ਿਆਦਾ ਲਾਭਦਾਇਕ ਹੈ:
ਇਨਸਾਨ ਥੱਕ ਜਾਂਦੇ ਹਨ ਅਤੇ ਰੁਖ ਵੀ ਲੈਂਦੇ ਹਨ। AI ਨਹੀਂ—ਇਸਲਈ ਇਹ ਪੂਰੇ ਬੈਕਐਂਡ 'ਚ ਰਵਾਇਤੀ ਫੈਸਲਿਆਂ ਨੂੰ ਦੁਹਰਾ ਕੇ ਕਰਨ ਵਿੱਚ ਸ਼ਾਨਦਾਰ ਹੈ:
createdAt, updatedAt, customerId)/resources, /resources/:id) ਅਤੇ ਪੇਲੋਡਇਹ ਇਕਸਾਰਤਾ ਤੁਹਾਡੇ ਬੈਕਐਂਡ ਨੂੰ ਦਸਤਾਵੇਜ਼, ਟੈਸਟ ਅਤੇ ਹੈਂਡ ਆਫ਼ ਲਈ ਆਸਾਨ ਬਣਾਂਦੀ ਹੈ।
AI ਪੂਰਨਤਾ ਵਿੱਚ ਵੀ ਚੰਗਾ ਹੁੰਦਾ ਹੈ। ਜੇ ਤੁਸੀਂ ਪੂਰੇ CRUD ਸੈੱਟ ਨਾਲ ਆਮ ਓਪਰੇਸ਼ਨਾਂ (search, list, bulk updates) ਮੰਗਦੇ ਹੋ, ਇਹ ਆਮ ਤੌਰ 'ਤੇ ਇੱਕ ਹੋਰ ਵਿਆਪਕ ਸ਼ੁਰੂਆਤੀ ਸਰਫੇਸ ਦਿੰਦਾ ਹੈ ਜੋ ਇੱਕ ਹੌਲੀ ਮਨੁੱਖੀ ਡਰਾਫਟ ਨਾਲ ਮੁਕਾਬਲੇ ਵਿੱਚ ਛੱਡ ਸਕਦਾ ਹੈ।
ਇੱਕ ਆਮ ਤੇਜ਼ ਨਫਾ ਮਿਆਰੀ ਐਰਰ ਫਾਰਮੈਟ ਹੈ: ਹਰ ਥਾਂ ਇੱਕ ਯੂਨੀਫਾਰਮ ਐਰਰ ਐਨਵਲੋਪ (code, message, details). ਭਾਵੇਂ ਤੁਸੀਂ ਬਾਅਦ ਵਿੱਚ ਇਹ ਨੂੰ ਸੋਧੋ, ਸ਼ੁਰੂ ਤੋਂ ਹੀ ਇੱਕ ਆਕਾਰ ਰੱਖਣ ਨਾਲ ਐਡ-ਹਾਕ ਰਿਸਪਾਂਸਾਂ ਦੇ ਮਿਕਸ ਤੋਂ ਬਚਿਆ ਜਾ ਸਕਦਾ ਹੈ।
ਕੁੰਜੀ ਮਨੋਭਾਵ: AI ਨੂੰ ਪਹਿਲੇ 80% ਤੇਜ਼ੀ ਨਾਲ ਪੈਦਾ ਕਰਨ ਦਿਓ, ਫਿਰ ਉਹ 20% ਤੇ ਧਿਆਨ ਦਿਓ ਜਿਸਨੂੰ ਫੈਸਲਾ ਲੋੜਦਾ ਹੈ—ਬਿਜ਼ਨਸ ਨਿਯਮ, ਏਜ ਕੇਸ ਅਤੇ ਮਾਡਲ ਦੇ "ਕਿਉਂ"।
AI-ਜਨਰੇਟ ਕੀਤੀਆਂ ਸਕੀਮਾਂ ਪਹਿਲੀ ਨਜ਼ਰ ਵਿੱਚ "ਸਾਫ਼" ਲੱਗਦੀਆਂ ਹਨ: ਸਾਫ਼ ਟੇਬਲ, ਸਮਝਦਾਰ ਨਾਮ, ਅਤੇ ਰਿਸ਼ਤੇ ਜੋ ਖੁਸ਼ਪਾਤ ਨੂੰ ਮਿਲਦੇ ਹਨ। ਸਮੱਸਿਆਵਾਂ ਆਮ ਤੌਰ 'ਤੇ ਉਹਨਾਂ ਸਮਿਆਂ 'ਤੇ ਉੱਠਦੀਆਂ ਹਨ ਜਦੋਂ ਅਸਲ ਡੇਟਾ, ਅਸਲ ਉਪਭੋਗਤਾ, ਅਤੇ ਅਸਲ ਵਰਕਫਲੋਜ਼ ਸਿਸਟਮ 'ਤੇ ਪ੍ਰਭਾਵ ਪਾਉਂਦੇ ਹਨ।
AI ਦੋ ਧਿਰਾਂ ਵਿੱਚ ਝੁਕ ਸਕਦਾ ਹੈ:
ਇੱਕ ਤੇਜ਼ ਸੁਗੰਧ ਟੈਸਟ: ਜੇ ਤੁਹਾਡੇ ਸਭ ਤੋਂ ਆਮ ਪੇਜ਼ਾਂ ਨੂੰ 6+ joins ਦੀ ਲੋੜ ਹੋ ਰਹੀ ਹੈ, ਤੁਸੀਂ ਓਵਰ-ਨਾਰਮਲਾਈਜ਼ਡ ਹੋ ਸਕਦੇ ਹੋ; ਜੇ ਅਪਡੇਟ ਕਰਨ ਲਈ ਇੱਕੋ ਹੀ ਮੁੱਲ ਬਹੁਤ ਸਾਰੀਆਂ ਕਤਾਰਾਂ ਵਿੱਚ ਬਦਲਣਾ ਪੈ ਰਿਹਾ ਹੈ, ਤਾਂ ਤੁਸੀਂ ਅੰਡਰ-ਨਾਰਮਲਾਈਜ਼ਡ ਹੋ।
AI ਅਕਸਰ ਉਹ "ਬੋਰਿੰਗ" ਲੋੜਾਂ ਨੂੰ ਛੱਡ ਦਿੰਦਾ ਹੈ ਜੋ ਅਸਲ ਬੈਕਐਂਡ ਡਿਜ਼ਾਈਨ ਚਲਾਉਂਦੀਆਂ ਹਨ:
tenant_id ਭੁੱਲ ਜਾਣਾ, ਜਾਂ ਯੂਨੀਕ ਕੰਸਟ੍ਰੇਨਟਸ ਵਿੱਚ ਟੇਨੈਂਟ ਸਕੋਪ ਨਾ ਲਗਾਉਣਾ।deleted_at ਜੋੜਨਾ ਪਰ ਯੂਨੀਕਨੈੱਸ ਨਿਯਮਾਂ ਜਾਂ ਕ્વੈਰੀ ਪੈਟਰਨ ਨੂੰ ਇਸ ਤਰ੍ਹਾਂ ਅਪਡੇਟ ਨਾ ਕਰਨਾ ਕਿ ਡਿਲੀਟ ਕੀਤੀਆਂ ਰਿਕਾਰਡਾਂ ਨੂੰ ਬਾਹਰ ਰੱਖਿਆ ਜਾਵੇ।created_by/updated_by, ਚੇਂਜ ਹਿਸਟਰੀ, ਜਾਂ ਅਮੂਹਤ ਇਵੈਂਟ ਲੋਗਸ ਦੀ ਗ਼ੈਰ-ਮੌਜੂਦਗੀ।AI ਅਨੁਮਾਨ ਲਾ ਸਕਦਾ ਹੈ:
ਇਹ ਗਲਤੀਆਂ ਅਕਸਰ ਅਜੀਬ ਮਾਈਗ੍ਰੇਸ਼ਨਸ ਅਤੇ ਐਪਲੇਕੇਸ਼ਨ-ਸਾਈਡ ਵਰਕਅਰਾਊਂਡਾਂ ਵਜੋਂ ਸਾਹਮਣਾ ਕਰਦੀਆਂ ਹਨ।
ਜ਼ਿਆਦातर ਜਨਰੇਟ ਕੀਤੀਆਂ ਸਕੀਮਾਂ ਇਸ ਗੱਲ ਨੂੰ ਧਿਆਨ ਵਿੱਚ ਨਹੀਂ ਲੈਂਦੀਆਂ ਕਿ ਤੁਸੀਂ ਕਿਵੇਂ ਕੁਐਰੀ ਕਰੋਗੇ:
ਜੇ ਮਾਡਲ ਤੁਹਾਡੇ ਐਪ ਦੀਆਂ 5 ਸਭ ਤੋਂ ਵੱਡੀਆਂ ਕੁਐਰੀਜ਼ ਦਰਸਾ ਨਹੀਂ ਸਕਦਾ, ਇਹ ਉਹਨਾਂ ਲਈ ਭਰੋਸੇਯੋਗ ਤਰੀਕੇ ਨਾਲ ਸਕੀਮਾ ਡਿਜ਼ਾਈਨ ਨਹੀਂ ਕਰ ਸਕਦਾ।
AI ਅਕਸਰ ਇੱਕ ਐਸਾ API ਪੈਦਾ ਕਰਨ ਵਿੱਚ ਹੈਰਾਨ ਕਰ ਦੇਂਦਾ ਹੈ "ਜੋ ਸਟੈਂਡਰਡ ਲੱਗਦਾ ਹੈ"। ਇਹ ਲੋਕਪ੍ਰਿਯ ਫਰੇਮਵਰਕਾਂ ਅਤੇ ਪਬਲਿਕ APIs ਤੋਂ ਜਾਣੇ-ਪਛਾਣੇ ਪੈਟਰਨ ਨੂੰ ਨਕਲ ਕਰੇਗਾ, ਜੋ ਸਮਾਂ ਬਚਾਉਂਦਾ ਹੈ। ਜੋਖਮ ਇਹ ਹੈ ਕਿ ਇਹ ਜ਼ਿਆਦਾ ਤਰ ਉਹ ਚੀਜ਼ਾਂ ਚੁਣ ਸਕਦਾ ਹੈ ਜੋ ਸਹੀ ਲੱਗਦੀਆਂ ਹਨ ਪਰ ਤੁਹਾਡੇ ਉਤਪਾਦ, ਤੁਹਾਡੇ ਡਾਟਾ ਮਾਡਲ ਅਤੇ ਭਵਿੱਖੀ ਬਦਲਾਅ ਲਈ ਠੀਕ ਨਹੀਂ।
ਰਿਸੋਰਸ ਮਾਡਲਿੰਗ ਬੇਸਿਕਸ. ਇੱਕ ਸਪਸ਼ਟ ਡੋਮੇਨ ਦੇਣ 'ਤੇ, AI ਅਕਸਰ ਸਮਝਦਾਰ ਨਾਮ ਅਤੇ URL ਢਾਂਚਾ ਚੁਣਦਾ ਹੈ (ਉਦਾਹਰਨ: /customers, /orders/{id}, /orders/{id}/items)। ਇਹ ਇੱਕਸਾਰ ਨਾਂ-ਨਿਯਮ ਦੋਹਰਾਉਣ ਵਿੱਚ ਵੀ ਚੰਗਾ ਹੁੰਦਾ ਹੈ।
ਆਮ ਐਂਡਪੌਇੰਟ ਸਕੈਫੋਲਡਿੰਗ. AI ਅਕਸਰ ਬੁਨਿਆਦੀ ਚੀਜ਼ਾਂ ਸ਼ਾਮਲ ਕਰਦਾ ਹੈ: ਲਿਸਟ ਬਨਾਮ ਡੀਟੇਲ ਐਂਡਪੌਇੰਟ, create/update/delete ਓਪਰੇਸ਼ਨ, ਅਤੇ ਪ੍ਰਡੀਕਟੇਬਲ ਰਿਕਵੇਸਟ/ਰਿਸਪਾਂਸ ਸ਼ੇਪ।
ਬੇਸਲਾਈਨ ਰਵਾਇਤੀ ਨੀਤੀਆਂ. ਜੇ ਤੁਸੀਂ ਖਾਸ ਤੌਰ 'ਤੇ ਮੰਗੋ, ਉਦੋਂ ਇਹ ਪੇਜ਼ੀਨੇਸ਼ਨ, ਫਿਲਟਰਿੰਗ, ਅਤੇ ਸਰਟਿੰਗ ਨੂੰ ਮਿਆਰੀ ਤਰੀਕੇ ਨਾਲ ਢਾਲ ਸਕਦਾ ਹੈ। ਉਦਾਹਰਨ: ?limit=50&cursor=... (ਕਰਸਰ ਪੇਜ਼ੀਨੇਸ਼ਨ) ਜਾਂ ?page=2&pageSize=25 (ਪੇਜ-ਆਧਾਰਤ), ਨਾਲ ?sort=-createdAt ਅਤੇ ਫਿਲਟਰ ਜਿਵੇਂ ?status=active।
ਲੀਕੀ ਐਬਸਟ੍ਰੈਕਸ਼ਨ. ਇੱਕ ਆਮ ਫੇਲ ਹੈ ਅੰਦਰੂਨੀ ਟੇਬਲਾਂ ਨੂੰ ਸਿੱਧਾ "ਰਿਸੋਰਸ" ਵਜੋਂ ਇਕਸਪੋਜ਼ ਕਰਨਾ, ਖ਼ਾਸ ਕਰਕੇ ਜਦੋਂ ਸਕੀਮਾ ਵਿੱਚ join ਟੇਬਲ, ਡੀਨੋਰਮਲਾਈਜ਼ਡ ਫੀਲਡਸ, ਜਾਂ ਆਡਿਟ ਕਾਲਮ ਹੋਣ। ਇਸ ਨਾਲ /user_role_assignments ਵਰਗੇ ਐਂਡਪੌਇੰਟ ਬਣ ਸਕਦੇ ਹਨ ਜੋ ਇੰਪਲੀਮੈਂਟੇਸ਼ਨ ਦੀ ਵਿਸ਼ੇਸ਼ਤਾ ਦਰਸਾਉਂਦੇ ਹਨ ਅਤੇ ਯੂਜ਼ਰ-ਫਰੈਂਡਲੀ ਨਹੀਂ ਹੁੰਦੇ।
ਅਸਸਥਿਰ ਐਰਰ ਹੈਂਡਲਿੰਗ. AI ਕਈ ਵਾਰੀ ਸ਼ੈਲੀ ਮਿਸ਼੍ਰਿਤ ਕਰ ਸਕਦਾ ਹੈ: ਕਈ ਵਾਰ 200 ਨਾਲ error ਬਾਡੀ, ਕਈ ਵਾਰ 4xx/5xx ਵਰਤੋਂ। ਤੁਹਾਨੂੰ ਇੱਕ ਸਪਸ਼ਟ ਸੰਵਿਧਾਨ ਚਾਹੀਦਾ ਹੈ:
400, 401, 403, 404, 409, 422){ "error": { "code": "...", "message": "...", "details": [...] } })ਵਰਜਨਿੰਗ ਪਿੱਛੇ ਰਹਿ ਜਾਣਾ. ਕਈ AI-ਜਨਰੇਟ ਕੀਤੇ ਡਿਜ਼ਾਈਨ ਵਰਜਨਿੰਗ ਰਣਨੀਤੀ ਨੂੰ ਛੱਡ ਦਿੰਦੇ ਹਨ। ਪਹਿਲੇ ਦਿਨ ਤੋਂ ਫੈਸਲਾ ਕਰੋ ਕਿ ਤੁਸੀਂ path ਵਰਜਨਿੰਗ (/v1/...) ਜਾਂ ਹੈਡਰ-ਅਧਾਰਿਤ ਵਰਜਨਿੰਗ ਵਰਤੋਂਗੇ, ਅਤੇ ਕੀ ਚੀਜ਼ਾਂ breaking change ਗਿਣੀਆਂ ਜਾਣ। ਭਲੇ ਹੀ ਤੁਸੀਂ ਕਦੇ ਵਰਜਨ ਨਾ ਵਧਾਓ, ਨਿਯਮ ਹੋਣ ਨਾਲ ਅਚਾਨਕ ਤੋੜ-ਫੋੜ ਰੁਕਦੀ ਹੈ।
AI ਨੂੰ ਗਤੀ ਅਤੇ ਇਕਸਾਰਤਾ ਲਈ ਵਰਤੋ, ਪਰ API ਡਿਜ਼ਾਈਨ ਨੂੰ ਇੱਕ ਉਤਪਾਦੀ ਇੰਟਰਫੇਸ ਵਜੋਂ ਲਵੋ। ਜੇ ਕੋਈ ਐਂਡਪੌਇੰਟ ਤੁਹਾਡੇ ਡੇਟਾਬੇਸ ਦਾ ਨਕਲ ਕਰਦਾ ਹੈ ਨਾ ਕਿ ਯੂਜ਼ਰ ਦੇ ਮਾਨਸਿਕ ਮਾਡਲ ਦਾ, ਤਾਂ ਇਹ ਸੁਝਾਅ ਦਿੰਦਾ ਹੈ ਕਿ AI ਆਸਾਨ ਜਨਰੇਸ਼ਨ ਲਈ ਅਨੁਕੂਲ ਹੋਇਆ—ਨਾ ਕਿ ਲੰਬੇ ਸਮੇਂ ਦੀ ਵਰਤੋਂ ਲਈ।
AI ਨੂੰ ਤੇਜ਼ ਜੂਨੀਅਰ ਡਿਜ਼ਾਈਨਰ ਵਾਂਗ ਵਰਤੋ: ਡਰਾਫਟ ਪੈਦਾ ਕਰਨ ਵਿੱਚ ਮਹਾਨ, ਅੰਤਿਮ ਪ੍ਰਣਾਲੀ ਲਈ ਜ਼ਿੰਮੇਵਾਰ ਨਹੀਂ। ਟੀਚਾ ਇਹ ਹੈ ਕਿ ਇਸ ਦੀ ਗਤੀ ਵਰਤ ਕੇ ਆਪਣੀ ਆਰਕੀਟੈਕਚਰ ਇरਾਦੇਦਾਰ, ਸਮੀਖਿਆਯੋਗ, ਅਤੇ ਟੈਸਟ-ਚਲਾਏ ਰਹੇ।
ਜੇ ਤੁਸੀਂ ਕਿਸੇ vibe-coding ਟੂਲ ਵਰਗਾ Koder.ai ਵਰਤ ਰਹੇ ਹੋ, ਤਾਂ ਕਾਰਜਾਂ ਦੀ ਵੰਡ ਹੋਰ ਵੀ ਜ਼ਰੂਰੀ ਹੋ ਜਾਂਦੀ ਹੈ: ਪਲੇਟਫਾਰਮ ਤੇਜ਼ੀ ਨਾਲ ਬੈਕਐਂਡ ਡਰਾਫਟ ਅਤੇ ਲਾਗੂ ਕਰ ਸਕਦਾ ਹੈ (ਉਦਾਹਰਨ: Go ਸਰਵਿਸਜ਼ ਨਾਲ PostgreSQL), ਪਰ ਫਿਰ ਵੀ ਤੁਹਾਨੂੰ invariants, ਅਧਿਕਾਰ ਸਰਹੱਦਾਂ, ਅਤੇ ਮਾਈਗ੍ਰੇਸ਼ਨ ਨਿਯਮ ਤੇ ਨਿਰਧਾਰਿਤ ਕਰਨਾ ਲਾਜ਼ਮੀ ਹੈ।
ਕੌਂਸੈਪਟ 'ਤੇ ਧਿਆਨ ਦੇ ਕੇ ਸ਼ੁਰੂ ਕਰੋ: ਡੋਮੇਨ, ਸੀਮਾਵਾਂ, ਅਤੇ "کامیابی ਕੀ ਹੈ" ਬਿਆਨ ਕਰੋ। ਪਹਿਲਾਂ概念ਕ ਮਾਡਲ ਮੰਗੋ (ਐਨਟਿਟੀ, ਰਿਸ਼ਤੇ, invariants), ਨਾ ਕਿ ਤੁਰੰਤ ਟੇਬਲਾਂ।
ਫਿਰ ਨਿਯਤ ਲੂਪ ਵਿੱਚ ਦੋਹਰਾਓ:
ਇਹ ਲੂਪ ਇਸ ਲਈ ਕੰਮ ਕਰਦਾ ਹੈ ਕਿਉਂਕਿ ਇਹ "AI ਸੁਝਾਅ" ਨੂੰ ਐਸੇ ਆਰਟੀਫੈਕਟ ਬਣਾਉਂਦਾ ਹੈ ਜੋ ਸਾਬਤ ਜਾਂ ਰੱਦ ਕੀਤੇ ਜਾ ਸਕਦੇ ਹਨ।
ਤਿੰਨ ਪੱਧਰ ਵੱਖਰੇ ਰੱਖੋ:
AI ਤੋਂ ਇਹਨਾਂ ਨੂੰ ਵੱਖ-ਵੱਖ ਸੈਕਸ਼ਨਾਂ ਵਿੱਚ ਆਉਟਪੁੱਟ ਕਰਨ ਦੀ ਮੰਗ ਕਰੋ। ਜਦੋਂ ਕੁਝ ਬਦਲਦਾ ਹੈ (ਮਿਸਾਲ ਲਈ ਨਵੀਂ status ਜਾਂ ਨਿਯਮ), ਪਹਿਲਾਂ ਕਾਂਸੈਪਚੁਅਲ ਲੇਅਰ ਅਪਡੇਟ ਕਰੋ, ਫਿਰ ਸਕੀਮਾ ਅਤੇ API ਨੂੰ ਪਸੰਦ-ਮੁਤਾਬਕ ਦੋਹਰਾਓ। ਇਹ ਅਣਚਾਹੀ coupling ਘਟਾਉਂਦਾ ਹੈ ਅਤੇ ਪਰਿਵਰਤਨਾਂ ਨੂੰ ਆਸਾਨ ਬਣਾਉਂਦਾ ਹੈ।
ਹਰ ਇਤਰਾਟਨ ਇੱਕ ਟਰੇਲ ਛੱਡੇ: ਛੋਟੇ ADR-ਸਟਾਈਲ ਨੋਟਸ (ਇੱਕ ਪੰਨਾ ਜਾਂ ਘੱਟ) ਜੋ ਕੁਝ ਰੱਖਦੇ ਹਨ:
deleted_at”)ਜਦੋਂ ਤੁਸੀਂ ਫੀਡਬੈਕ ਵਾਪਸ AI ਨੂੰ ਪੇਸਟ ਕਰੋ, ਤਾਂ ਸਬੰਧਤ ਫੈਸਲਾ ਨੋਟ ਸਿੱਧੇ ਸ਼ਬਦਾਂ ਵਿੱਚ ਸ਼ਾਮਲ ਕਰੋ। ਇਸ ਨਾਲ ਮਾਡਲ ਨੂੰ ਪਹਿਲਾਂ ਦੀਆਂ ਚੋਣਾਂ "ਭੁੱਲਣ" ਤੋਂ ਰੋਕਣਾ ਅਤੇ ਤੁਹਾਡੀ ਟੀਮ ਨੂੰ ਮਹੀਨਿਆਂ ਬਾਅਦ ਸਮਝਾਉਣਾ ਆਸਾਨ ਰਹੇਗਾ।
AI ਨੂੰ ਰੁਖ ਕਰਨ ਵਿੱਚ ਸਭ ਤੋਂ ਆਸਾਨ ਹੁੰਦਾ ਹੈ ਜਦੋਂ ਤੁਸੀਂ ਪ੍ਰਾਂਪਟ ਨੂੰ ਏਕ ਨਿਰਧਾਰਿਤ ਸਪੈਸ ਵਾਂਗ ਤਿਆਰ ਕਰੋ: ਡੋਮੇਨ ਨੂੰ ਪਰਿਭਾਸ਼ਿਤ ਕਰੋ, ਸੀਮਾਵਾਂ ਦੱਸੋ, ਅਤੇ ठੋਸ ਆਉਟਪੁੱਟ (DDL, ਐਂਡਪੋਇੰਟ ਟੇਬਲਸ, ਉਦਾਹਰਨ) ਦੀ ਮੰਗ ਕਰੋ। ਲਕਸ਼ "ਸਿਰਜਨਾਤਮਕ ਹੋਵੋ" ਨਹੀਂ—ਲਕਸ਼ "ਸਪਸ਼ਟ ਹੋਵੋ" ਰੱਖੋ।
ਡੇਟਾ ਮਾਡਲ ਅਤੇ ਉਸਨੂੰ ਸਥਿਰ ਰੱਖਣ ਵਾਲੇ ਨਿਯਮ ਮੰਗੋ।
ਜੇ ਤੁਹਾਡੇ ਕੋਲ ਪਹਿਲਾਂ ਹੀ ਕੰਵੈਂਸ਼ਨ ਹਨ, ਉਹ ਵੀ ਦੱਸੋ: ਨਾਮਕਰਨ ਸਟਾਇਲ, ID ਟਾਈਪ (UUID vs bigint), nullable ਨੀਤੀ, ਅਤੇ ਇੰਡੈਕਸਿੰਗ ਉਮੀਦਾਂ।
ਸਿਰਫ਼ ਰੂਟਾਂ ਦੀ ਸੂਚੀ ਨਾ ਮੰਗੋ — ਹਰ ਐਂਡਪੌਇੰਟ ਲਈ ਵਿਸਥਾਰ ਮੰਗੋ।
ਵਿਅਵਹਾਰ ਵਿਵਰਣ ਸ਼ਾਮਲ ਕਰੋ: ਪੇਜ਼ੀਨੇਸ਼ਨ ਸਟਾਈਲ, ਸਰਟਿੰਗ ਫੀਲਡਸ, ਅਤੇ ਫਿਲਟਰਿੰਗ ਕਿਵੇਂ ਕੰਮ ਕਰਦੀ ਹੈ।
ਮਾਡਲ ਨੂੰ ਰੀਲੀਜ਼ ਵਿਚ ਸੋਚਣ ਲਈ ਕਹੋ।
billing_address ਜੋੜ ਰਹੇ ਹਾਂ। ਸੁਰੱਖਿਅਤ ਮਾਈਗ੍ਰੇਸ਼ਨ ਯੋਜਨਾ ਦਿਓ: ਫ਼ਾਰਵਰਡ ਮਾਈਗ੍ਰੇਸ਼ਨ SQL, ਬੈਕਫਿੱਲ ਕਦਮ, ਫੀਚਰ-ਫਲੈਗ ਰੋਲਆਉਟ, ਅਤੇ ਰੋਲਬੈਕ ਰਣਨੀਤੀ। API 30 ਦਿਨ ਲਈ ਕੁੰਪੈਟਬਿਲਿਟੀ ਬਰਕਰਾਰ ਰੱਖੇ; ਪੁਰਾਣੇ ਕਲਾਇੰਟ ਫੀਲਡ ਨੂੰ ਛੱਡ ਸਕਦੇ ਹਨ।”ਧੁੰਧਲੇ ਪ੍ਰਾਂਪਟ ਅਧੂਰੇ ਸਿਸਟਮ ਪੈਦਾ ਕਰਦੇ ਹਨ।
ਜਦੋਂ ਤੁਸੀਂ ਵਧੀਆ ਆਉਟਪੁੱਟ ਚਾਹੁੰਦੇ ਹੋ, ਤਾਂ ਪ੍ਰਾਂਪਟ ਨੂੰ ਤਿੱਖਾ ਕਰੋ: ਨਿਯਮ, ਏਜ ਕੇਸ, ਅਤੇ ਆਉਟਪੁੱਟ ਦੇ ਫਾਰਮੈਟ ਨੂੰ ਨਿਰਧਾਰਤ ਕਰੋ।
AI ਇੱਕ ਵਧੀਆ ਬੈਕਐਂਡ ਡਰਾਫਟ ਤਿਆਰ ਕਰ ਸਕਦਾ ਹੈ, ਪਰ ਇਸਨੂੰ ਸੁਰੱਖਿਅਤ ਤਰੀਕੇ ਨਾਲ ਤਿਆਰ ਕਰਨ ਲਈ ਮਨੁੱਖੀ ਸਮੀਖਿਆ ਲਾਜ਼ਮੀ ਹੈ। ਇਸ ਚੈੱਕਲਿਸਟ ਨੂੰ "ਰਿਲੀਜ਼ ਗੇਟ" ਵਜੋਂ ਵਰਤੋ: ਜੇ ਤੁਸੀਂ ਕਿਸੇ ਆਈਟਮ ਦਾ ਯਕੀਨ ਪੂਰੀ ਤਰ੍ਹਾਂ ਨਾਲ ਨਹੀਂ ਜਤਾ ਸਕਦੇ, ਰੋਕੋ ਅਤੇ ਸੁਧਾਰ ਕਰੋ।
(tenant_id, slug))_id suffixes, timestamps) ਚੁਣੋ ਅਤੇ ਇਕਸਾਰ ਲਾਗੂ ਕਰੋ।ਲਿਖਤ ਰੂਪ ਵਿੱਚ ਨਿਯਮਾਂ ਦੀ ਪੁਸ਼ਟੀ ਕਰੋ:
ਮਰਜ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ, ਇਕ ਤੇਜ਼ "ਹੈਪੀ ਪਾਥ + ਵਧੀਆ ਰਾਹ" ਸਮੀਖਿਆ ਕਰੋ: ਇੱਕ ਸਾਮਾਨੀਕ ਬੇਨਤੀ, ਇੱਕ ਅਣਵੈਧ ਬੇਨਤੀ, ਇੱਕ ਅਣਅਧਿਕ੍ਰਿਤ ਬੇਨਤੀ, ਇੱਕ ਉੱਚ-ਵਾਲੀਅਮ ਸਥਿਤੀ। ਜੇ API ਦਾ ਵਿਹਵਾਰ ਤੁਹਾਨੂੰ ਹੈਰਾਨ ਕਰਦਾ ਹੈ, ਤਾਂ ਇਹ ਤੁਹਾਡੇ ਯੂਜ਼ਰਾਂ ਨੂੰ ਵੀ ਹੈਰਾਨ ਕਰੇਗਾ।
AI ਇੱਕ ਵਾਜਿਬ ਸਕੀਮਾ ਅਤੇ API ਸਤਹ ਤੇਜ਼ੀ ਨਾਲ ਪੈਦਾ ਕਰ ਸਕਦਾ ਹੈ, ਪਰ ਇਹ ਸਾਬਤ ਨਹੀਂ ਕਰ ਸਕਦਾ ਕਿ ਬੈਕਐਂਡ ਅਸਲ ਟ੍ਰੈਫਿਕ, ਅਸਲ ਡੇਟਾ, ਅਤੇ ਭਵਿੱਖੀ ਬਦਲਾਅ ਹੇਠ ਸਹੀ ਤਰੀਕੇ ਨਾਲ ਵਰਤੇਗਾ। AI ਆਉਟਪੁੱਟ ਨੂੰ ਇੱਕ ਡਰਾਫਟ ਸਮਝੋ ਅਤੇ ਇਸਨੂੰ ਟੈਸਟਾਂ ਨਾਲ ਕਾਂਧ ਦਿਓ ਜੋ ਵਿਵਹਾਰ ਨੂੰ ਬੰਦ ਕਰ ਦੇਂ।
ਸ਼ੁਰੂਆਤ ਵਿੱਚ ਕਾਂਟ੍ਰੈਕਟ ਟੈਸਟ ਬਣਾਓ ਜੋ ਰਿਕਵੇਸਟ, ਰਿਸਪਾਂਸ ਅਤੇ ਐਰਰ ਸੈਮੈਂਟਿਕਸ ਦੀ ਪੁਸ਼ਟੀ ਕਰਦੇ ਹਨ—ਕੇਵਲ "ਹੈਪੀ ਪਾਥ" ਨਹੀਂ। ਛੋਟਾ ਸੂਟ ਚਲਾਓ ਜੋ ਸੇਵਾ ਦੇ ਵਾਸਤੇ ਸੱਚੀ ਇੰਸਟੈਂਸ (ਜਾਂ ਕਨਟੇਨਰ) 'ਤੇ ਚਲ ਸਕੇ।
ਫ਼ੋਕਸ ਕਰੋ:
ਜੇ ਤੁਸੀਂ OpenAPI ਸਪੈੱਕ ਪ੍ਰਕਾਸ਼ਿਤ ਕਰਦੇ ਹੋ, ਤਦੋਂ ਉਸ ਤੋਂ ਟੈਸਟ ਜਨਰੇਟ ਕਰੋ—ਪਰ ਸਪੈੱਕ ਜੋ ਵਿਵਹਾਰ ਨਹੀਂ ਦਿਖਾ ਸਕਦੀ (ਆਥਰਾਈਜ਼ੇਸ਼ਨ ਨੀਤੀਆਂ, ਬਿਜ਼ਨਸ ਕੰਸਟਰੇਨਟ) ਲਈ ਹੱਥ-ਲਿਖੇ ਕੇਸ ਵੀ ਸ਼ਾਮਲ ਕਰੋ।
AI-ਜਨਰੇਟ ਕੀਤੀਆਂ ਸਕੀਮਾਂ ਅਕਸਰ ਆਪਰੇਸ਼ਨਲ ਵਿਵਰਣ ਛੱਡ ਦਿੰਦੀਆਂ ਹਨ: ਸੁਰੱਖਿਅਤ ਡੀਫੌਲਟ, ਬੈਕਫਿੱਲ ਅਤੇ ਵਾਪਸੀਯੋਗਤਾ। ਮਾਈਗ੍ਰੇਸ਼ਨ ਟੈਸਟ ਜੋੜੋ ਜੋ:
ਪ੍ਰੋਡਕਸ਼ਨ ਲਈ ਸਕ੍ਰਿਪਟਿਡ ਰੋਲਬੈਕ ਯੋਜਨਾ ਰੱਖੋ: ਜੇਕਰ ਮਾਈਗ੍ਰੇਸ਼ਨ ਸਲੋ ਹੈ, ਟੇਬਲਾਂ ਨੂੰ ਲਾਕ ਕਰਦਾ ਹੈ ਜਾਂ ਕੁੰਪੈਟਬਿਲਿਟੀ ਤੋੜ ਦਿੰਦਾ ਹੈ ਤਾਂ ਕੀ ਕਰਨਾ ਹੈ।
ਆਮ ਐਂਡਪੌਇੰਟ ਦੀ ਬੇਨਤੀ ਨਾਂ ਕਰੋ—ਉਸਦੀ ਬਜਾਇ ਪ੍ਰਤਿੱਨਿਧੀ ਕੁਐਰੀ ਪੈਟਰਨ (ਟੌਪ ਲਿਸਟ ਵੇਖ, search, joins, aggregation) ਪਕੜੋ ਅਤੇ ਉਨ੍ਹਾਂ 'ਤੇ ਲੋਡ ਟੈਸਟ ਕਰੋ।
ਮੀਟਰ ਕਰੋ:
ਇੱਥੇ AI ਡਿਜ਼ਾਈਨ ਆਮ ਤੌਰ 'ਤੇ ਨਾਕਾਮ ਹੁੰਦਾ ਹੈ: "ਸਮਝਦਾਰ" ਟੇਬਲ ਜੇ ਢੀਠ joins ਹੇਠ ਮਹਿੰਗੇ ਕੁਐਰੀ ਬਣਾਉਂਦੀਆਂ ਹਨ।
ਆਟੋਮੇਟਿਕ ਚੈੱਕ ਜੋੜੋ:
ਬੁਨਿਆਦੀ ਹੀਠ ਸੁਰੱਖਿਆ ਟੈਸਟ AI ਦੀਆਂ ਸਭ ਤੋਂ ਮਹਿੰਗੀਆਂ ਗਲਤੀਆਂ ਤੋਂ ਬਚਾਉਂਦੇ ਹਨ: ਐਂਡਪੌਇੰਟ ਜੋ ਕੰਮ ਕਰਦੇ ਹਨ, ਪਰ ਬਹੁਤ ਕੁਝ ਪ੍ਰਗਟ ਕਰ ਦਿੰਦੇ ਹਨ।
AI ਇੱਕ ਵਧੀਆ "ਵਰਜਨ 0" ਸਕੀਮਾ ਡਰਾਫਟ ਦੇ ਸਕਦਾ ਹੈ, ਪਰ ਤੁਹਾਡਾ ਬੈਕਐਂਡ ਵਰਜਨ 50 ਵਿਚ ਜੀਵਿਤ ਰਹੇਗਾ। ਜਿਸ ਵੱਖਰਾ ਬਣਾਉਂਦਾ ਹੈ ਕਿ ਕਿਹੜਾ ਬੈਕਐਂਡ ਚੰਗੀ ਤਰ੍ਹਾਂ ਉਮਰ ਰਿੰਦ ਹੈ ਅਤੇ ਕਿਹੜਾ ਬਦਲਾਅ ਹੇਠ ਟੁੱਟ ਜਾਂਦਾ ਹੈ ਉਹ ਹੈ ਕਿ ਤੁਸੀਂ ਇਸ ਨੂੰ ਕਿਵੇਂ ਵਿਕਸਿਤ ਕਰਦੇ ਹੋ: ਮਾਈਗ੍ਰੇਸ਼ਨ, ਨਿਯੰਤ੍ਰਤ ਰੀਫੈਕਟਰ, ਅਤੇ ਇਰਾਦੇਦਾਰ ਦਸਤਾਵੇਜ਼।
ਹਰ ਸਕੀਮਾ ਬਦਲਾਅ ਨੂੰ ਇੱਕ ਮਾਈਗ੍ਰੇਸ਼ਨ ਵਜੋਂ ਲਓ, ਭਲੇ AI ਕਹੇ "ਸਿਰਫ਼ alter table"। ਖੁੱਲ੍ਹੇ, ਵਾਪਸੀਯੋਗ ਕਦਮ ਵਰਤੋਂ: ਪਹਿਲਾਂ ਨਵੇਂ ਕਾਲਮ ਜੋੜੋ, ਬੈਕਫਿੱਲ ਕਰੋ, ਫਿਰ ਕੰਸਟ੍ਰੇਨਟ ਠੀਕ ਕਰੋ। ਨਿਊਨਤਮ ਪਹੁੰਚ ਲਈ ਆਡੀਟ ਫੇਜ਼ (additive changes) ਨੂੰ ਤਰਜੀਹ ਦਿਓ (ਨਵੇਂ ਫੀਲਡ, ਨਵੇਂ ਟੇਬਲ) ਬਜਾਏ ਨਾਸ਼ਕ (rename/drop) ਦੇ, ਜਦ ਤੱਕ ਇਹ ਤਸਦੀਕ ਨਾ ਹੋ ਜਾਵੇ ਕਿ ਕੁਝ ਵੀ ਪੁਰਾਣੇ ਰੂਪ 'ਤੇ ਨਿਰਭਰ ਨਹੀਂ।
ਜਦੋਂ ਤੁਸੀਂ AI ਤੋਂ ਸਕੀਮਾ ਅਪਡੇਟ ਮੰਗਦੇ ਹੋ, ਤਾਂ ਮੌਜੂਦਾ ਸਕੀਮਾ ਅਤੇ ਆਪਣੀਆਂ ਮਾਈਗ੍ਰੇਸ਼ਨ ਨੀਤੀਆਂ ਸ਼ਾਮਿਲ ਕਰੋ (ਉਦਾਹਰਨ: "ਕੋਈ ਕਾਲਮ ਡਰਾਪ ਨਾ ਕਰੋ; expand/contract ਪੈਟਰਨ ਵਰਤੋ")। ਇਸ ਨਾਲ ਇਹ ਘਟਦਾ ਹੈ ਕਿ ਇਹ ਕੋਈ ਸੁਝਾਅ ਦੇਵੇ ਜੋ ਸਿਧਾ ਠੀਕ ਲੱਗੇ ਪਰ ਪ੍ਰੋਡਕਸ਼ਨ ਵਿੱਚ ਖਤਰਨਾਕ ਹੋ।
ਬ੍ਰੇਕਿੰਗ ਚੇਂਜ ਕਦੇ ਵੀ ਇਕੱਲੇ ਲਹਜੇ ਵਿੱਚ ਨਹੀਂ ਆਉਂਦੇ; ਇਹ ਇੱਕ ਤਬਦੀਲੀ ਖਿੜਕੀ ਹੁੰਦੀ ਹੈ।
AI ਇਸ ਕ੍ਰਮਵਾਰ ਯੋਜਨਾ (SQL ਟੁਕੜੇ ਅਤੇ ਰੋਲਆਉਟ ਢੰਗ) ਪੈਦਾ ਕਰਨ ਵਿੱਚ ਮਦਦਗਾਰ ਹੋ ਸਕਦਾ ਹੈ, ਪਰ ਤੁਸੀਂ ਰਨਟਾਈਮ ਪ੍ਰਭਾਵ (ਲਾਕ, ਲੰਬੇ ਟ੍ਰਾਂਜ਼ੈਕਸ਼ਨ, ਅਤੇ ਬੈਕਫਿੱਲ ਰਿਜ਼ਿਊਮਬਲ ਹੋਣਾ) ਦੀ ਜਾਂਚ ਕਰੋ।
ਰੀਫੈਕਟਰ ਦਾ ਲਕਸ਼ ਇਸਤੋਂ ਬਚਾਉਣ ਲਈ ਇੰਸੋਲੇਸ਼ਨ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ। ਜੇ ਤੁਹਾਨੂੰ ਨਾਰਮਲਾਈਜ਼ ਕਰਨਾ, ਟੇਬਲ ਵੰਡਣੀ, ਜਾਂ ਇਵੈਂਟ ਲੌਗ ਲਿਆਉਣਾ ਹੋਵੇ, ਤਾਂ ਸੰਗਠਨਕ ਸਤਹਾਂ ਰੱਖੋ: views, translation ਕੋਡ, ਜਾਂ "ਸ਼ੈਡੋ" ਟੇਬਲ। AI ਤੋਂ ਪੁੱਛੋ ਕਿ ਉਹ ਏਜੰਟ ਲਿਆਉਣ ਵਾਲੀ ਰੀਫੈਕਟਰ ਸੁਝਾਅ ਦੇਵੇ ਜੋ ਮੌਜੂਦਾ API ਕਾਂਟ੍ਰੈਕਟ ਨੂੰ ਬਰਕਰਾਰ ਰੱਖੇ, ਅਤੇ ਇਹ ਲਿਸਟ ਕਰੇ ਕਿ ਕਿਹੜੇ ਕੁਐਰੀਜ਼, ਇੰਡੈਕਸ ਅਤੇ ਕੰਸਟ੍ਰੇਨਟ ਬਦਲਣਗੇ।
ਜਿਆਦਾਤਰ ਲੰਬੇ ਸਮੇਂ ਦਾ ਡਰਿਫਟ ਇਸ ਲਈ ਹੁੰਦਾ ਹੈ ਕਿ ਅਗਲਾ ਪ੍ਰਾਂਪਟ ਅਸਲੀ ਇਰਾਦੇ ਨੂੰ ਭੁੱਲ ਜਾਂਦਾ ਹੈ। ਇੱਕ ਛੋਟਾ "ਡਾਟਾ ਮਾਡਲ ਕਾਂਟ੍ਰੈਕਟ" ਦਸਤਾਵੇਜ਼ ਰੱਖੋ: ਨਾਮਕਰਨ ਨਿਯਮ, ID ਰਣਨੀਤੀ, timestamp semantics, ਸੋਫਟ-ਡੀਲੀਟ ਨੀਤੀ, ਅਤੇ invariants ("order total derived ਹੈ, ਨਾ ਕਿ ਸਟੋਰ ਕੀਤਾ ਗਿਆ")। ਇਸਨੂੰ ਆਪਣੇ ਇੰਟਰਨਲ ਡੌਕਸ ਵਿੱਚ ਜੋੜੋ (ਉਦਾਹਰਨ: /docs/data-model) ਅਤੇ ਭਵਿੱਖੀ AI ਪ੍ਰਾਂਪਟਾਂ ਵਿੱਚ ਦੁਹਰਾਓ ਤਾਂ ਕਿ ਸਿਸਟਮ ਇਕੋ ਹੀ ਸੀਮਾਵਾਂ ਦੇ ਅੰਦਰ ਡਿਜ਼ਾਈਨ ਕਰੇ।
AI ਤੇਜ਼ੀ ਨਾਲ ਟੇਬਲਾਂ ਅਤੇ ਐਂਡਪੌਇੰਟ ਡਰਾਫਟ ਕਰ ਸਕਦਾ ਹੈ, ਪਰ ਇਹ ਤੁਹਾਡੇ ਜੋਖਮ ਦੀ ਜ਼ਿੰਮੇਵਾਰੀ ਨਹੀਂ ਲੈਂਦਾ। ਸੁਰੱਖਿਆ ਅਤੇ ਗੋਪਨੀਯਤਾ ਨੂੰ ਪ੍ਰਾਂਪਟ ਵਿੱਚ ਪਹਿਲੀ ਕਲਾਸ ਦੀ ਲੋੜ ਵਜੋਂ ਸ਼ਾਮਿਲ ਕਰੋ, ਅਤੇ ਸਮੀਖਿਆ 'ਚ ਇਸਦੀ ਪੁਸ਼ਟੀ ਕਰੋ—ਖ਼ਾਸ ਕਰਕੇ ਸੰਵੇਦਨਸ਼ੀਲ ਡੇਟਾ ਦਰਸਾਉਣ ਵਾਲੇ ਖੇਤਰਾਂ 'ਤੇ।
ਕਿਸੇ ਵੀ ਸਕੀਮਾ ਨੂੰ ਮਨਜ਼ੂਰ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਫੀਲਡਸ ਨੂੰ ਸੰਵੇਦਨਸ਼ੀਲਤਾ ਅਨੁਸਾਰ ਥਾਪਣਾ ਕਰੋ (public, internal, confidential, regulated)। ਇਹ ਦਰਜਾ ਨਿਰਧਾਰਤ ਕਰੇਗਾ ਕਿ ਕੀ encrypt, mask, ਜਾਂ minimize ਕੀਤਾ ਜਾਣਾ ਚਾਹੀਦਾ ਹੈ।
ਉਦਾਹਰਨ: passwords ਕਦੇ ਸਟੋਰ ਨਾ ਕਰੋ (ਕੇਵਲ salted hashes), tokens ਛੋਟੇ ਸਮੇਂ ਵਾਲੇ ਅਤੇ rest 'ਚ encrypt ਹੋਣ, ਅਤੇ PII (email/phone) ਨੂੰ admin views ਅਤੇ ਐਕਸਪੋਰਟਾਂ 'ਚ ਮాసਕ ਕੀਤਾ ਜਾਣਾ ਚਾਹੀਦਾ ਹੈ। ਜੇ ਕਿਸੇ ਫੀਲਡ ਦੀ ਲੋੜ ਉਤਪਾਦ ਮੁੱਲ ਲਈ ਨਹੀਂ, ਤਾਂ ਇਸਨੂੰ ਸਟੋਰ ਨਾ ਕਰੋ—AI ਅਕਸਰ "ਚੰਗੀ ਹੋਵੇ" ਕਰਨ ਲਈ ਹੋਰ ਫੀਲਡ ਜੋੜ ਦੇਵੇਗਾ ਜੋ ਖੁਲਾਸਾ ਦਾ ਖਤਰਾ ਵਧਾਉਂਦੇ ਹਨ।
AI-ਜਨਰੇਟ APIs ਅਕਸਰ ਸਧਾਰਣ "ਰੋਲ ਚੈੱਕ" ਡਿਫਾਲਟ ਕਰਦੇ ਹਨ। RBAC ਸੋਚਣ ਵਿੱਚ ਆਸਾਨ ਹੈ, ਪਰ ਮਲਕੀਅਤ ਨਿਯਮ ("ਯੂਜ਼ਰ ਸਿਰਫ ਆਪਣੇ invoices ਵੇਖ ਸਕਦਾ") ਜਾਂ ਸੰਦਰਭ ਨੀਤੀਆਂ ("ਸਪੋਰਟ ਸਿਰਫ ACTIVE ਟਿਕਟ ਦੌਰਾਨ ਡਾਟਾ ਵੇਖ ਸਕਦਾ") ਨਾਲ ਫੇਲ ਹੋ ਜਾਂਦੀ ਹੈ। ABAC ਇਨ੍ਹਾਂ ਨੂੰ ਬਿਹਤਰ ਹੈਂਡਲ ਕਰਦਾ ਹੈ, ਪਰ ਇਸ ਲਈ ਸਪਸ਼ਟ ਨੀਤੀਆਂ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ।
ਜੋ ਪੈਟਰਨ ਤੁਸੀਂ ਵਰਤ ਰਹੇ ਹੋ ਉਸਦਾ ਸਪਸ਼ਟ ਹੋਰ ਕਰੋ, ਅਤੇ ਯਕੀਨੀ ਬਣਾਓ ਕਿ ਹਰ ਐਂਡਪੌਇੰਟ ਇਸਨੂੰ ਇਕਸਾਰ ਤਰੀਕੇ ਨਾਲ ਲਾਗੂ ਕਰ ਰਿਹਾ ਹੈ—ਖ਼ਾਸ ਕਰਕੇ ਲਿਸਟ/ਸਰਚ ਐਂਡਪੌਇੰਟ, ਜੋ ਆਮ ਰੂਪ ਵਿੱਚ ਡਾਟਾ ਲੀਕ ਕਰਨ ਵਾਲੇ ਪੁਆਇੰਟ ਹੁੰਦੇ ਹਨ।
ਜਨਰੇਟ ਕੀਤਾ ਕੋਡ ਕਦੇ-ਕਦੇ ਪੂਰੀ ਬੇਨਤੀ ਬਾਡੀ, ਹੈਡਰ, ਜਾਂ ਡੇਟਾਬੇਸ ਲਾਈਨਾਂ ਨੂੰ ਐਰਰ ਤੇ ਲੌਗ ਕਰ ਸਕਦਾ ਹੈ। ਇਹ passwords, auth tokens, ਅਤੇ PII ਨੂੰ ਲੋਗਜ਼ ਅਤੇ APM ਟੂਲਜ਼ 'ਚ ਰੀਕਲ ਕਰ ਸਕਦਾ ਹੈ।
ਡਿਫਾਲਟ ਸੈੱਟ ਕਰੋ: ਸਟ੍ਰੱਕਚਰਡ ਲੌਗ, ਲੌਗ ਲਈ allowlist ਫੀਲਡ, ਰੈਡੈਕਟ secrets (Authorization, cookies, reset tokens), ਅਤੇ ਵੈਲੀਡੇਸ਼ਨ ਫੇਲਿਓਂ 'ਤੇ ਰਾਅ ਪੇਲੋਡ ਲੌਗ ਕਰਨ ਤੋਂ ਬਚੋ।
ਅੱਜ ਤੋਂ ਹੀ ਮਿਟਾਉਣ ਲਈ ਡਿਜ਼ਾਈਨ ਕਰੋ: ਯੂਜ਼ਰ-ਇਨਿਸ਼ੀਏਟਡ ਡਿਲੀਟ, ਅਕਾਉਂਟ ਬੰਦ, ਅਤੇ "ਭੁੱਲ ਜਾਣ ਦਾ ਅਧਿਕਾਰ" ਵਰਕਫਲੋਜ਼। ਹਰ ਡੇਟਾ ਕਲਾਸ ਲਈ ਰੀਟੈਂਸ਼ਨ ਵਿੰਡੋ ਨਿਰਧਾਰਤ ਕਰੋ (ਉਦਾਹਰਨ: ਆਡਿਟ ਇਵੈਂਟਸ vs ਮਾਰਕੀਟਿੰਗ ਇਵੈਂਟਸ), ਅਤੇ ਯਕੀਨੀ ਬਣਾਓ ਕਿ ਤੁਸੀਂ ਸਬੂਤ ਕਰ ਸਕਦੇ ਹੋ ਕਿ ਕੀ ਮਿਟਾਇਆ ਗਿਆ ਅਤੇ ਕਦੋਂ।
ਜੇ ਤੁਸੀਂ ਆਡਿਟ ਲਾਗ ਰੱਖਦੇ ਹੋ, ਤਾਂ ਘੱਟੋ-ਘੱਟ ਪਹਿਚਾਨ ਬਚਾਓ, ਉਨ੍ਹਾਂ ਨੂੰ ਉੱਚ ਸੁਰੱਖਿਆ ਨਾਲ ਰੱਖੋ, ਅਤੇ ਦਸਤਾਵੇਜ਼ ਕਰੋ ਕਿ ਕਿਵੇਂ ਡੇਟਾ ਨਿਰਯਾਤ ਜਾਂ ਮਿਟਾਇਆ ਜਾ ਸਕਦਾ ਹੈ ਜਦੋਂ ਲੋੜ ਹੋਵੇ।
AI ਸਭ ਤੋਂ ਵਧੀਆ ਉਦੋਂ ਹੈ ਜਦੋਂ ਤੁਸੀਂ ਇਸਨੂੰ ਤੇਜ਼ ਜੂਨੀਅਰ ਆਰਕੀਟੈਕਟ ਵਾਂਗ ਵਰਤਦੇ ਹੋ: ਪਹਿਲਾ ਡਰਾਫਟ ਬਣਾਉਂਦਾ, ਡੋਮੇਨ-ਅਹਿਮ ਤਰਜੀਹਾਂ ਵਿੱਚ ਕਮਜ਼ੋਰ। ਸਹੀ ਸਵਾਲ ਇਹ ਨਹੀਂ ਕਿ "ਕੀ AI ਮੇਰਾ ਬੈਕਐਂਡ ਡਿਜ਼ਾਈਨ ਕਰ ਸਕਦਾ ਹੈ?" ਪਰ ਇਹ ਹੈ "ਕਿਹੜੇ ਹਿੱਸੇ AI ਤੇਜ਼ੀ ਨਾਲ ਬਣਾਉਂਦਾ ਹੈ ਅਤੇ ਕਿਹੜੇ ਹਿੱਸੇ ਲਈ ਵਿਸ਼ੇਸ਼ਗਿਆ ਦੀ ਲੋੜ ਹੈ?"
AI ਸਮਾਂ ਬਚਾ ਸਕਦਾ ਹੈ ਜਦੋਂ ਤੁਸੀਂ ਰਾਹੀਂ ਬਣਾ ਰਹੇ ਹੋ:
ਇਥੇ AI ਦੀ ਕੀਮਤ ਗਤੀ, ਇਕਸਾਰਤਾ, ਅਤੇ ਕਵਰੇਜ਼ ਹੈ—ਖਾਸ ਕਰਕੇ ਜਦੋਂ ਤੁਸੀਂ ਜਾਣਦੇ ਹੋ ਕਿ ਉਤਪਾਦ ਕਿਵੇਂ ਵਰਤਣਾ ਚਾਹੀਦਾ ਹੈ ਅਤੇ ਅਸਾਨੀ ਨਾਲ ਗਲਤੀਆਂ ਚੀਨ੍ਹਣ ਦੇ ਸਮਰੱਥ ਹੋ।
AI-ਜਨਰੇਟ ਡਿਜ਼ਾਈਨ ਨੂੰ ਪ੍ਰੇਰਣਾ ਤੱਕ ਸੀਮਿਤ ਰੱਖੋ ਜਦੋਂ ਤੁਸੀਂ ਕੰਮ ਕਰ ਰਹੇ ਹੋ:
ਇਨ੍ਹਾਂ ਖੇਤਰਾਂ ਵਿੱਚ ਡੋਮੇਨ ਵਿਸ਼ੇਸ਼ਗਿਆ AI ਦੀ ਗਤੀ ਤੋਂ ਬਹੁਤ ਜ਼ਿਆਦਾ ਮਹੱਤਵਪੂਰਨ ਹਨ।
ਇੱਕ ਪ੍ਰਾਇਕਟਿਕਲ ਨਿਯਮ: AI ਨੂੰ ਵਿਕਲਪ ਸੁਝਾਉਣ ਦਿਓ, ਪਰ ਡੇਟਾ ਮਾਡਲ invariants, ਆਥਰਾਈਜ਼ੇਸ਼ਨ ਬਾਊਂਡਰੀਜ਼, ਅਤੇ ਮਾਈਗ੍ਰੇਸ਼ਨ ਰਣਨੀਤੀ 'ਤੇ ਅੰਤੀਮ ਸਮੀਖਿਆ ਲਾਜ਼ਮੀ ਰੱਖੋ। ਜੇ ਤੁਸੀਂ ਨਹੀਂ ਦੱਸ ਸਕਦੇ ਕਿ ਕਿਸ ਮਨੁੱਖੀ ਨੂੰ ਸਕੀਮਾ ਅਤੇ API ਕਾਂਟ੍ਰੈਕਟ ਦੀ ਜ਼िम्मੇਵਾਰੀ ਹੈ, ਤਾਂ AI-ਡਿਜ਼ਾਈਨ ਕੀਤਾ ਬੈਕਐਂਡ ਸ਼ਿਪ ਨਾ ਕਰੋ।
ਜੇ ਤੁਸੀਂ ਵਰਕਫਲੋਜ਼ ਅਤੇ ਗਾਰਡਰੇਲ ਮੁਲਾਂਕਣ ਕਰ ਰਹੇ ਹੋ, ਤਾਂ /blog ਵਿੱਚ ਸੰਬੰਧਿਤ ਗਾਈਡ ਵੇਖੋ। ਜੇ ਤੁਸੀਂ ਇਹ ਅਭਿਆਸ ਆਪਣੀ ਟੀਮ 'ਤੇ ਲਾਗੂ ਕਰਨ ਲਈ ਮਦਦ ਚਾਹੁੰਦੇ ਹੋ, ਤਾਂ /pricing ਵੇਖੋ।
ਜੇ ਤੁਸੀਂ ਚੈਟ ਰਾਹੀਂ ਇਤਰਾਟ ਕਰਨ, ਵਰਕਿੰਗ ਐਪ ਜਨਰੇਟ ਕਰਨ, ਅਤੇ ਫਿਰ ਵੀ ਸਰੋਤ ਕੋਡ ਐਕਸਪੋਰਟ ਅਤੇ ਰੋਲਬੈਕ-ਫਰੇਂਡਲੀ ਸਨੇਪਸ਼ਾਟ ਰੱਖ ਕੇ ਕੰਟਰੋਲ ਬਣਾਉਣਾ ਪਸੰਦ ਕਰਦੇ ਹੋ, ਤਾਂ Koder.ai ਅਜੇ ਇਸ ਸ਼ੈਲੀ ਦੇ ਬਿਲਡ-ਅਤੇ-ਰੀਵਿਊ ਲੂਪ ਲਈ ਡਿਜ਼ਾਈਨ ਕੀਤਾ ਗਿਆ ਹੈ।
ਇਹ ਆਮ ਤੌਰ 'ਤੇ ਮਤਲਬ ਹੁੰਦਾ ਹੈ ਕਿ ਮਾਡਲ ਨੇ ਇੱਕ ਪਹਿਲਾ ਡਰਾਫਟ ਬਣਾਇਆ ਜੋ ਸ਼ਾਮਲ ਹੈ:
ਇੱਕ ਮਨੁੱਖੀ ਟੀਮ ਨੂੰ ਫਿਰ ਵੀ ਬਿਜ਼ਨਸ ਨਿਯਮ, ਸੁਰੱਖਿਆ ਸੀਮਾਵਾਂ, ਕੁਐਰੀ ਪ੍ਰਦਰਸ਼ਨ ਅਤੇ ਮਾਈਗ੍ਰੇਸ਼ਨ ਸੁਰੱਖਿਆ ਦੀ ਤਸਦੀਕ ਕਰਨੀ ਪੈਂਦੀ ਹੈ ਪਹਿਲਾਂ ਕਿ ਇਹ ਸ਼ਿਪ ਕੀਤਾ ਜਾਵੇ।
AI ਨੂੰ ਅਜਿਹੇ ਕਾਂਟ੍ਰੈਕਟ ਦਿੱਤੇ ਜਾਣ ਜੋ ਇਹ ਸੁਰਖਿਅਤ ਤੌਰ 'ਤੇ ਅਨੁਮਾਨ ਨਹੀਂ ਲਾ ਸਕਦਾ:
ਜਿੰਨੀ ਵਧੀਕ ਸਪਸ਼ਟੀਕਰਨ, AI ਉਹਨਾ ਘਟਾਵਾਂ ਨੂੰ ਭਰਨਾ ਘੱਟ ਕਰੇਗਾ।
ਪਹਿਲਾਂ ਇੱਕ ਕਾਂਸੈਪਚੁਅਲ ਮਾਡਲ (ਬਿਜ਼ਨਸ ਧਾਰਨਾਵਾਂ ਅਤੇ ਅਨਿਵਾਰਤਾਵਾਂ) ਬਣਾਓ, ਫਿਰ ਇਸ ਤੋਂ ਨਿਕਲੋ:
ਇਨ੍ਹਾਂ ਲੇਅਰਾਂ ਨੂੰ ਵੱਖਰਾ ਰੱਖਣ ਨਾਲ ਸਟੋਰੇਜ਼ ਬਦਲਣ ਜਾਂ API ਬਦਲਣ 'ਤੇ ਅਸਾਨੀ ਰਹਿੰਦੀ ਹੈ ਬਿਨਾਂ ਬਿਜ਼ਨਸ ਨਿਯਮ ਟੁੱਟਣ ਦੇ।
ਆਮ ਸਮੱਸਿਆਵਾਂ ਵਿੱਚ ਸ਼ਾਮਲ ਹਨ:
tenant_id ਨਾ ਹੋਣਾ)deleted_at ਅਤੇ ਯੂਨੀਕਨੈੱਸ)AI ਨੂੰ ਆਪਣੇ ਟਾਪ ਕੁਐਰੀਜ਼ ਦੇ ਆਧਾਰ 'ਤੇ ਡਿਜ਼ਾਈਨ ਕਰਨ ਲਈ ਕਹੋ ਅਤੇ ਫਿਰ ਜਾਂਚ ਕਰੋ:
tenant_id + created_at)ਜੇ ਤੁਸੀਂ ਆਪਣੇ ਟਾਪ 5 ਕੁਐਰੀਜ਼ ਨਹੀਂ ਗਿਣ ਸਕਦੇ, ਕੋਈ ਵੀ ਇੰਡੈਕਸ ਪਲਾਨ ਅਧੂਰਾ ਮੰਨੋ।
AI ਆਮ ਤੌਰ 'ਤੇ ਸਟੈਂਡਰਡ ਸਕੈਫੋਲਡਿੰਗ ਸਹੀ ਬਣਾਉਂਦਾ ਹੈ, ਪਰ ਧਿਆਨ ਦਿਓ:
200 ਨਾਲ error body)API ਨੂੰ ਉਪਭੋਗਤਾ ਦੇ ਮਾਨਸਿਕ ਮਾਡਲ ਦੇ ਆਲੇ-ਦੁਆਲੇ ਡਿਜ਼ਾਈਨ ਕਰੋ—ਡਾਟਾਬੇਸ ਦੇ ਨਹੀਂ।
ਇੱਕ ਦੋਹਰਾਏ ਜਾਣਯੋਗ ਲૂਪ ਵਰਤੋ:
ਹਮੇਸ਼ਾ ਇੱਕ ਹੀ ਐਰਰ ਐਨਵਲੋਪ ਅਤੇ ਢੰਗ ਵਰਤੋ, ਉਦਾਹਰਨ:
ਸਭ ਤੋਂ ਪਹਿਲਾਂ ਉਨ੍ਹਾਂ ਟੈਸਟਾਂ ਨੂੰ ਤਰਜੀਹ ਦਿਓ ਜੋ ਵਿਹਵਾਰ ਨੂੰ ਲਾਕ ਕਰਦੇ ਹਨ:
ਟੈਸਟ ਉਹ ਢੰਗ ਹੈ ਜਿਸ ਨਾਲ ਤੁਸੀਂ ਡਿਜ਼ਾਈਨ ਦਾ ਮਾਲਕ ਬਣਦੇ ਹੋ ਨਾ ਕਿ ਕੇਵਲ AI ਦੀ ਧਾਰਣਾ।
AI ਨੂੰ ਖਾਸ ਤੌਰ 'ਤੇ ਡਰਾਫਟਾਂ ਲਈ ਵਰਤੋ ਜਿੱਥੇ ਪੈਟਰਨ ਚੰਗੇ ਤਰੀਕੇ ਨਾਲ ਸਮਝੇ ਹੋਏ ਹਨ (CRUD-heavy MVPs, ਆਭੀਆਂਤਰੀ ਟੂਲ). ਜਦੋਂ ਝੋਨਾ ਜੋਖਮ ਜਾਂ ਡੋਮੇਨ-ਭਾਰੀ ਪ੍ਰਣਾਲੀ ਹੋਵੇ ਤਾਂ ਸਾਵਧਾਨ ਰਹੋ, ਜਿਵੇਂ:
ਇਨ੍ਹਾਂ ਹਾਲਤਾਂ ਵਿੱਚ ਡੋਮੇਨ ਮਾਹਿਰਤਾ AI ਦੀ ਗਤੀਤੋਂ ਵੱਧ ਕੀਮਤੀ ਹੁੰਦੀ ਹੈ।
ਇੱਕ ਸਕੀਮਾ ਪਹਿਲੇ ਨਜ਼ਰ ਵਿੱਚ ਸਾਫ਼ ਲੱਗ ਸਕਦੀ ਹੈ ਪਰ ਅਸਲ ਵਰਕਫਲੋਜ਼ ਅਤੇ ਲੋਡ 'ਤੇ ਫੇਲ ਹੋ ਸਕਦੀ ਹੈ।
ਇਹ ਲੂਪ AI ਦੇ ਸੁਝਾਅਾਂ ਨੂੰ ਸੰਬੋਧਨਯੋਗ ਆਇਟਮ ਬਣਾਉਂਦਾ ਹੈ ਜੋ ਪਰਖੇ ਜਾਂ ਰਦ ਕੀਤੇ ਜਾ ਸਕਦੇ ਹਨ।
400, 401, 403, 404, 409, 422, 429{"error":{"code":"...","message":"...","details":[...]}}
ਇਸਦੇ ਨਾਲ ਇਹ ਯਕੀਨੀ ਬਣਾਓ ਕਿ ਐਰਰ ਸੁਨੇਹੇ ਇੰਟਰਨਲ ਡੀਟੇਲ (SQL, ਸਟੈਕ ਟਰੇਸ) ਜਾਂ ਸਹਿਜੀਕ ਸਾਝਾ ਨਹੀਂ ਕਰਦੇ ਅਤੇ ਸਾਰੇ ਐਂਡਪੌਇੰਟਾਂ 'ਤੇ ਲਾਗੂ ਹਨ।