ਕਿਉਂ AI-ਚਲਾਏ ਵਰਕਫਲੋ ਪਹਿਲਾਂ ਅਬਸਟ੍ਰੈਕਸ਼ਨ ਘਟਾਉਂਦੇ ਹਨ

ਪੂਰਵ-ਅਬਸਟ੍ਰੈਕਸ਼ਨ ਅਤੇ ਅਤਿ-ਇੰਜੀਨੀਅਰਿੰਗ ਤੋਂ ਅਰਥ

ਪੂਰਵ-ਅਬਸਟ੍ਰੈਕਸ਼ਨ ਤਾਂ ਹੁੰਦੀ ਹੈ ਜਦੋਂ ਤੁਸੀਂ ਇੱਕ “ਸਧਾਰਨ ਸਮੱਸਿਆ” ਦੀ ਥਾਂ ਇੱਕ “ਸਾਮਾਨਤਾ ਵਾਲਾ ਹੱਲ” ਬਣਾ ਦਿੰਦੇ ਹੋ — ਇਸ ਤੋਂ ਪਹਿਲਾਂ ਕਿ ਤੁਸੀਂ ਕਾਫ਼ੀ ਅਸਲ ਮਾਮਲੇ ਵੇਖ ਲਈ ਹੋਵੇ ਕਿ ਕੀ ਵਾਕਈ ਸਮਾਨ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ।

ਆਕਸਰ ਅੱਜ ਦੀ ਸਮੱਸਿਆ ਨੂੰ ਹਲ ਕਰਨ ਵਾਲਾ ਸਭ ਤੋਂ ਸਧਾਰਨ ਕੋਡ ਲਿਖਣ ਦੀ ਥਾਂ, ਤੁਸੀਂ ਇੱਕ ਫਰੇਮਵਰਕ ਦੀ ਰਚਨਾ ਕਰ ਦਿੰਦੇ ਹੋ: ਵਾਧੂ ਇੰਟਰਫੇਸ, ਸੰਰਚਨਾ ਪ੍ਰਣਾਲੀਆ, ਪਲੱਗ-ਇਨ ਬਿੰਦੂ, ਜਾਂ ਰਿਊਜ਼ਬਲ ਮਾਡਿਊਲ — ਕਿਉਂਕਿ ਤੁਸੀਂ ਸੋਚਦੇ ਹੋ ਕਿ ਭਵਿੱਖ ਵਿੱਚ ਇਹ ਲੋੜ ਹੋਵੇਗੀ।

ਅਤਿ-ਇੰਜੀਨੀਅਰਿੰਗ ਇਸਦਾ ਵਿਆਪਕ ਰਵੱਈਆ ਹੈ। ਇਹ ਉਹ ਜਟਿਲਤਾ ਹੈ ਜੋ ਇਸ ਵੇਲੇ ਆਪਣੀ ਕਿਰਾਇਆ ਨਹੀਂ ਭਰ ਰਹੀ: ਵਾਧੂ ਪਰਤਾਂ, ਪੈਟਰਨ, ਸਰਵਿਸਜ਼, ਜਾਂ ਵਿਕਲਪ ਜੋ ਇਸ ਸਮੇਂ ਲਾਗਤ ਜਾਂ ਜੋਖਮ ਨੂੰ ਸਪੱਸ਼ਟ ਤੌਰ ਤੇ ਘਟਾਉਂਦੇ ਨਹੀਂ।

ਸਧਾਰਨ ਉਦਾਹਰਣਾਂ

ਜੇ ਤੁਹਾਡੇ ਉਤਪਾਦ ਕੋਲ ਇੱਕ ਹੀ ਬਿਲਿੰਗ ਪਲੈਨ ਹੈ ਅਤੇ ਤੁਸੀਂ “ਸਾਨੂੰ ਭਵਿੱਖ ਲਈ” ਇੱਕ ਮਲਟੀ-ਟੇਨੈਂਟ ਪ੍ਰਾਇਸਿੰਗ ਇੰਜਨ ਬਣਾਉਂਦੇ ਹੋ, ਇਹ ਪੂਰਵ-ਅਬਸਟ੍ਰੈਕਸ਼ਨ ਹੈ।

ਜੇਕਰ ਕਿਸੇ ਫੀਚਰ ਨੂੰ ਇੱਕ ਸਧਾਰਣ ਫੰਕਸ਼ਨ ਨਾਲ ਕੀਤਾ ਜਾ ਸਕਦਾ ਸੀ, ਪਰ ਤੁਸੀਂ ਇਸਨੂੰ ਛੇ ਕਲਾਸਾਂ, ਫੈਕਟਰੀਆਂ ਅਤੇ ਰਜਿਸਟਰੀਆਂ ਵਿੱਚ ਵੰਡ ਦਿੰਦੇ ਹੋ ਤਾਂ ਇਹ ਅਤਿ-ਇੰਜੀਨੀਅਰਿੰਗ ਹੈ।

ਇਹ ਪ੍ਰੋਜੈਕਟ ਦੀ ਸ਼ੁਰੂਆਤ ਵਿੱਚ ਕਿਉਂ ਆਉਂਦਾ ਹੈ

ਏਸੇ ਰਵੱਈਏ ਸ਼ੁਰੂ ਵਿੱਚ ਆਮ ਹਨ ਕਿਉਂਕਿ ਸ਼ੁਰੂਆਤੀ ਪ੍ਰੋਜੈਕਟ uncertainty ਨਾਲ ਭਰਪੂਰ ਹੁੰਦੇ ਹਨ:

• ਫੇਰਵਰਕ ਤੋਂ ਡਰ: ਟੀਮਾਂ ਡਰਦੀਆਂ ਹਨ ਕਿ ਜੇ ਉਹ ਕੁਝ ਸਧਾਰਨ ਬਣਾਉਣਗੀਆਂ ਤਾਂ ਉਹਨਾਂ ਨੂੰ ਬਾਅਦ ਵਿੱਚ ਦੁਬਾਰਾ ਲਿਖਣਾ ਪਏਗਾ।
• ਅਸਪਸ਼ਟ ਲੋੜਾਂ: ਜਦੋਂ ਕਿਸੇ ਨੂੰ ਪੱਕਾ ਨਹੀਂ ਪਤਾ ਕਿ ਉਤਪਾਦ ਕੀ ਬਣੇਗਾ, ਤਾਂ ਇੱਕ ਲਚਕੀਲਾ ਢਾਂਚਾ ਬਣਾਉਣ ਦਾ ਲਾਲਚ ਹੋ ਜਾਂਦਾ ਹੈ ਜੋ “ਕੁਝ ਵੀ ਸੰਭਾਲ ਸਕੇ।”
• ਸਮਾਜਿਕ ਦਬਾਅ: ਇੰਜੀਨੀਅਰ ਅਕਸਰ ਅੱਗੇ ਦੀ ਸੋਚ ਦਰਸਾਉਣਾ ਚਾਹੁੰਦੇ ਹਨ ਅਤੇ “ਠੀਕ” ਕਰਨ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰਦੇ ਹਨ, ਭਾਵੇਂ ਕਿ “ਠੀਕ” ਅਜੇ ਪੱਕਾ ਨਹੀਂ ਹੋਦਾ।

ਸਮੱਸਿਆ ਇਹ ਹੈ ਕਿ “ਲਚਕੀਲਾ” ਅਕਸਰ ਮਤਲਬ ਹੁੰਦਾ ਹੈ “ਬਦਲਣਾ ਮੁਸ਼ਕਿਲ।” ਵਾਧੂ ਪਰਤਾਂ ਆਮ ਸੋਧਾਂ ਨੂੰ ਹੌਲੀ ਕਰ ਸਕਦੀਆਂ ਹਨ, ਡਿਬੱਗਿੰਗ ਨੂੰ ਔਖਾ ਬਣਾਉਂਦੀਆਂ ਹਨ, ਅਤੇ ਔਨਬੋਰਡਿੰਗ ਨੂੰ ਦਰਦਨਾਕ। ਤੁਸੀਂ ਜਟਿਲਤਾ ਦੀ ਕੀਮਤ ਤੁਰੰਤ ਭਰਦੇ ਹੋ, ਜਦਕਿ ਫਾਇਦੇ ਕਦੇ ਵੀ ਨਹੀਂ ਆ ਸਕਦੇ।

AI ਕਿੱਥੇ ਫਿੱਟ ਹੁੰਦਾ ਹੈ (ਅਤੇ ਕਿੱਥੇ ਨਹੀਂ)

AI-ਚਲਾਏ ਵਰਕਫਲੋ ਟੀਮਾਂ ਨੂੰ ਕੰਮ ਨੂੰ ਠੋਸ ਰੱਖਣ ਲਈ ਪ੍ਰੇਰਿਤ ਕਰ ਸਕਦੇ ਹਨ—ਪ੍ਰੋਟੋਟਾਈਪਿੰਗ ਨੂੰ ਤੇਜ਼ ਕਰ ਕੇ, ਉਦਾਹਰਣਾਂ ਜਲਦੀ ਦੇ ਕੇ, ਅਤੇ ਧਾਰਨਾਵਾਂ ਨੂੰ ਆਜ਼ਮਾਉਣਾ ਆਸਾਨ ਬਣਾਕੇ। ਇਸ ਨਾਲ ਉਹ ਚਿੰਤਾ ਘਟਦੀ ਹੈ ਜੋ ਅਨੁਮਾਨ ਤੇ ਆਧਾਰਿਤ ਡਿਜ਼ਾਈਨ ਨੂੰ ਪੈਦਾ ਕਰਦੀ ਹੈ।

ਪਰ AI ਇੰਜੀਨੀਅਰਿੰਗ ਜੱਜਮੈਂਟ ਦੀ ਥਾਂ ਨਹੀਂ ਲੈ ਸਕਦਾ। ਇਹ ਤੁਰੰਤ ਕੋਈ ਚਤੁਰ ਆਰਕੀਟੈਕਚਰ ਜਾਂ ਅਬਸਟ੍ਰੈਕਸ਼ਨ ਤਿਆਰ ਕਰ ਸਕਦਾ ਹੈ। ਤੁਹਾਡੀ ਜ਼ਿੰਮੇਵਾਰੀ ਹੁਣ ਵੀ ਇਹ ਪੁੱਛਣਾ ਹੈ: ਅੱਜ ਲਈ ਸਭ ਤੋਂ ਸਧਾਰਨ ਚੀਜ਼ ਕੀ ਹੈ ਜੋ ਕੰਮ ਕਰਦੀ ਹੈ, ਅਤੇ ਕਿਹੜਿਆਂ ਸਬੂਤਾਂ ਦੀ ਲੋੜ ਹੋਵੇਗੀ ਕਿ ਕੱਲ੍ਹ ਨੂੰ ਬਣਾਉਣ ਦਾ ਕਦਮ ਵਾਜਬ ਹੈ?

ਆਲੇ-ਦੁਆਲੇ Koder.ai ਵਰਗੇ ਟੂਲ ਇੱਥੇ ਖਾਸਤੌਰ 'ਤੇ ਪ੍ਰਭਾਵਸ਼ਾਲੀ ਹਨ ਕਿਉਂਕਿ ਉਹ ਚੈਟ ਪ੍ਰਾਂਪਟ ਤੋਂ ਲੈ ਕੇ ਰਨਏਬਲ ਸਮੱਗਰੀ ਤੱਕ ਜਲਦੀ ਜਾਣਾ ਆਸਾਨ ਬਣਾਉਂਦੇ ਹਨ—ਤਾਂ ਜੋ ਟੀਮਾਂ “ਭਵਿੱਖ-ਪ੍ਰੋਫ਼” ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਲੋੜ ਨੂੰ ਸਥਿਰ ਕਰ ਸਕਣ।

AI ਵਰਕਫ਼ਲੋਜ਼ ਟੀਮਾਂ ਨੂੰ ਠੋਸ ਕੰਮ ਵੱਲ ਕਿਵੇਂ ਧਕੇਲਦੇ ਹਨ

AI-ਸਹਾਇਤਾ ਵਾਲਾ ਵਿਕਾਸ ਆਮ ਤੌਰ 'ਤੇ ਕਿਸੇ ਤੱਥ-ਅਧਾਰਤ ਚੀਜ਼ ਨਾਲ ਸ਼ੁਰੂ ਹੁੰਦਾ ਹੈ: ਇੱਕ ਖਾਸ ਬੱਗ, ਇੱਕ ਛੋਟਾ ਫੀਚਰ, ਡੇਟਾ ਰੂਪਾਂਤਰਣ, ਜਾਂ ਇੱਕ UI ਸਕ੍ਰੀਨ। ਇਹ ਫਰੇਮਿੰਗ ਮਹੱਤਵਪੂਰਨ ਹੈ। ਜਦੋਂ ਵਰਕਫਲੋ “ਇਥੇ ਇਸੀ ਖਾਸ ਚੀਜ਼ ਦੀ ਲੋੜ ਹੈ” ਨਾਲ ਸ਼ੁਰੂ ਹੁੰਦਾ ਹੈ, ਟੀਮਾਂ ਅਕਸਰ ਇੱਕ ਆਮ ਆਰਕੀਟੈਕਚਰ ਬਣਾ ਕੇ ਪਹਿਲਾਂ ਹੀ ਨਹੀਂ ਸੋਚਦੀਆਂ।

ਠੋਸ ਪ੍ਰਾਂਪਟ ਠੋਸ ਕੋਡ ਬਣਾਉਂਦੇ ਹਨ

ਜ਼ਿਆਦਾਤਰ AI ਟੂਲ ਸਭ ਤੋਂ ਵਧੀਆ ਜਵਾਬ ਦਿੰਦੇ ਹਨ ਜਦੋਂ ਤੁਸੀਂ ਵਿਸਥਾਰ ਦਿੰਦੇ ਹੋ: ਇਨਪੁਟ, ਆਉਟਪੁਟ, ਸੀਮਾਵਾਂ, ਅਤੇ ਇੱਕ ਉਦਾਹਰਣ। “ਇੱਕ ਲਚਕੀਲਾ ਨੋਟੀਫਿਕੇਸ਼ਨ ਸਿਸਟਮ ਡਿਜ਼ਾਇਨ ਕਰੋ” ਵਰਗਾ ਪ੍ਰਾਂਪਟ ਧੁੰਦਲਾ ਹੈ, ਇਸ ਲਈ ਮਾਡਲ ਅਕਸਰ ਵਾਧੂ ਪਰਤਾਂ ਨਾਲ ਭਰ ਦੇਵੇਗਾ—ਇੰਟਰਫੇਸ, ਫੈਕਟਰੀਆਂ, ਸੰਰਚਨਾ—ਕਿਉਂਕਿ ਇਹ ਅਸਲ ਸੀਮਾਵਾਂ ਨਹੀਂ ਵੇਖ ਸਕਦਾ।

ਪਰ ਜਦੋਂ ਪ੍ਰਾਂਪਟ ਜ਼ਮੀਨੀ ਹੁੰਦਾ ਹੈ, ਆਉਟਪੁਟ ਵੀ ਜ਼ਮੀਨੀ ਹੁੰਦਾ ਹੈ:

• Input: “ਇਹ ਆਰਡਰ ਸਥਿਤੀਆਂ ਦੇ ਦਿੱਤੀਆਂ ਗਈਆਂ ਹਨ…”
• Output: “ਉਪਭੋਗਤਾ-ਦਿਖਾਈ ਦੇਣ ਵਾਲਾ ਸੁਨੇਹਾ ਅਤੇ CTA ਵਾਪਸ ਕਰੋ…”
• Constraints: “ਤੇਜ਼ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ; ਡੇਟਾਬੇਸ ਕਾਲ ਨਾ ਹੋਵੇ; i18n ਦੀ ਲੋੜ…”
• Examples: “PENDING_PAYMENT ਲਈ ਦਿਖਾਓ …”

ਇਸ ਨਾਲ ਫਿਰ ਟੀਮਾਂ ਨੂੰ ਇੱਕ ਸਪਸ਼ਟ ਟੁਕੜਾ ਲਾਗੂ ਕਰਨ ਵੱਲ ਧਕਿਆ ਜਾਂਦਾ ਹੈ ਜੋ end-to-end ਕੰਮ ਕਰਦਾ ਹੈ। ਜਦੋਂ ਤੁਸੀਂ ਇਸਨੂੰ ਚਲਾ ਸਕਦੇ ਹੋ, ਸਮੀਖਿਆ ਕਰ ਸਕਦੇ ਹੋ, ਅਤੇ ਦਿਖਾ ਸਕਦੇ ਹੋ, ਤਾਂ ਤੁਸੀਂ ਪਰਿਭਾਸ਼ਾ ਨਹੀਂ ਬਣਾ ਰਹੇ — ਤੁਸੀਂ ਹੱਕੀਕਤ ਵਿੱਚ ਕੰਮ ਕਰ ਰਹੇ ਹੋ।

“ਪਹਿਲਾਂ ਕੰਮ ਕਰਾਉ, ਫਿਰ ਸੁਧਾਰ” ਡਿਫੌਲਟ ਬਣ ਜਾਂਦਾ ਹੈ

AI ਪੇਅਰ-ਪ੍ਰੋਗ੍ਰਾਮਿੰਗ ਇਟਰੈਸ਼ਨ ਨੂੰ ਸਸਤਾ ਕਰ ਦਿੰਦੀ ਹੈ। ਜੇ ਪਹਿਲਾ ਸੰਸਕਰਣ ਥੋੜ੍ਹਾ ਗੰਦਗਦ ਵਾਲਾ ਪਰ ਸਹੀ ਹੈ, ਤਾਂ ਅਗਲਾ ਕਦਮ ਅਕਸਰ “ਇਸ ਨੂੰ ਰੀਫੈਕਟਰ ਕਰੋ” ਹੁੰਦਾ ਹੈ ਨਾ ਕਿ “ਭਵਿੱਖ ਦੇ ਹਾਲਤਾਂ ਲਈ ਇੱਕ ਪ੍ਰਣਾਲੀ ਡਿਜ਼ਾਇਨ ਕਰੋ।” ਇਹ ਲੜੀ—ਪਹਿਲਾਂ ਕੰਮ ਕਰਨ ਵਾਲਾ ਕੋਡ, ਦੂਜੇ ਨੰਬਰ ਤੇ ਸੁਧਾਰ—ਉਹ ਦਬਾਅ ਘਟਾਉਂਦੀ ਹੈ ਜੋ ਅਜਿਹੀਆਂ ਅਬਸਟ੍ਰੈਕਸ਼ਨਾਂ ਨੂੰ ਜਨਮ ਦਿੰਦੀ ਹੈ।

ਅਮਲ ਵਿੱਚ, ਟੀਮਾਂ ਇੱਕ ਰਿਥਮ ਅਪਣਾ ਲੈਂਦੀਆਂ ਹਨ:

1. ਇੱਕ ਘਟੋ-ਘਟ ਮੰਤਰੀਤ ਲਾਗੂਕਰਨ ਮੰਗੋ।
2. ਅਸਲ ਉਦਾਹਰਣਾਂ 'ਤੇ ਇਸਨੂੰ ਅਜ਼ਮਾਓ।
3. ਜੋ ਕੁਝ ਤੋੜਦਾ ਹੈ ਜਾਂ ਅਜੀਬ ਲੱਗਦਾ ਹੈ ਉਸ ਦੇ ਆਧਾਰ 'ਤੇ ਸਮਾਇਕ ਸ਼ੁਧੀ ਕਰੋ।
4. ਫਿਰ ਹੀ ਇੱਕ ਹੈਲਪਰ, ਮਾਡਿਊਲ, ਜਾਂ ਪੈਟਰਨ ਕਢੋ।

ਵਿਸ਼ੇਸ਼ਤਾ ਸ਼ੁਰੂ ਵਿੱਚ ਘੁੰਮਣ-ਫਿਰਣ ਦੀਆਂ ਲੋੜਾਂ ਨੂੰ ਜਲਦੀ ਬਾਹਰ ਲਾਉਂਦੀ ਹੈ

ਪ੍ਰਾਂਪਟ ਤੁਹਾਡੇ ਤੋਂ ਪੂਛਣ ਲਈ ਮਜ਼ਬੂਰ ਕਰਦੇ ਹਨ ਕਿ ਤੁਸੀਂ ਅਸਲ ਵਿੱਚ ਕੀ ਮਤਲਬ ਲੈਂਦੇ ਹੋ। ਜੇ ਤੁਸੀਂ ਇਨਪੁਟ/ਆਉਟਪੁਟ ਸਪਸ਼ਟ ਨਹੀਂ ਕਰ ਸਕਦੇ, ਤਾਂ ਇਹ ਸੰਕੇਤ ਹੈ ਕਿ ਤੁਸੀਂ ਅਬਸਟ੍ਰੈਕਟ ਕਰਨ ਲਈ ਤਿਆਰ ਨਹੀਂ—ਤੁਸੀਂ ਹਾਲੇ ਵੀ ਲੋੜਾਂ ਦੀ ਖੋਜ ਕਰ ਰਹੇ ਹੋ। AI ਟੂਲ ਸਪਸ਼ਟਤਾ ਨੂੰ ਇਨਾਮ ਦਿੰਦੇ ਹਨ, ਇਸ ਲਈ ਉਹ ਨਰਮ ਤੌਰ 'ਤੇ ਟੀਮਾਂ ਨੂੰ ਪਹਿਲਾਂ ਸਪਸ਼ਟ ਕਰਨ ਅਤੇ ਬਾਅਦ ਵਿੱਚ ਆਮ ਕਰਨ ਲਈ ਤਿਆਰ ਕਰਦੇ ਹਨ।

ਛੋਟੀ ਫੀਡਬੈਕ ਲੂਪ ਸਪੈਕੁਲੇਟਿਵ ਡਿਜ਼ਾਈਨ ਨੂੰ ਘਟਾਉਂਦੇ ਹਨ

ਤੇਜ਼ ਫੀਡਬੈਕ ਇਹ ਬਦਲ ਦਿੰਦਾ ਹੈ ਕਿ “ਚੰਗੀ ਇੰਜੀਨੀਅਰਿੰਗ” ਕਿਹੜੀ ਮਹਿਸੂਸ ਹੁੰਦੀ ਹੈ। ਜਦੋਂ ਤੁਸੀਂ ਕਈ ਵਿਚਾਰ ਨੂੰ ਮਿੰਟਾਂ ਵਿੱਚ ਅਜ਼ਮਾ ਸਕਦੇ ਹੋ, ਤਦ ਸਪੈਕੁਲੇਟਿਵ ਆਰਕੀਟੈਕਚਰ ਇੱਕ ਆਰਥਿਕ ਲੋਡ ਜਾਪਦਾ ਹੈ ਜਿਸ ਤੋਂ ਬਚਿਆ ਜਾ ਸਕਦਾ ਹੈ।

ਲੂਪ: ਡ੍ਰਾਫਟ → ਚਲਾਓ → ਨਿਰੀਖਣ → ਸੁਧਾਰ

AI-ਚਲਾਏ ਵਰਕਫਲੋਜ਼ ਚੱਕਰ ਨੂੰ ਸੰਕੁਚਿਤ ਕਰ ਦੇਂਦੇ ਹਨ:

• ਡ੍ਰਾਫਟ: ਸਹਾਇਕ ਤੋਂ ਇੱਕ ਛੋਟੀ, ਕੰਮ ਕਰਨ-ਯੋਗ ਟੁਕੜੀ ਲੱਭੋ (ਇੱਕ ਸਕ੍ਰਿਪਟ, ਇੱਕ ਹੈਂਡਲਰ, ਇੱਕ ਕਵੇਰੀ)
• ਚਲਾਓ: ਇਸਨੂੰ ਤੁਰੰਤ ਅਸਲ ਇਨਪੁਟਾਂ 'ਤੇ ਚਲਾਓ
• ਨਿਰੀਖਣ: ਆਉਟਪੁਟ, ਲਾਗਜ਼, ਏਜ ਕੇਸ ਅਤੇ ਫੇਲ ਹੋਣ ਦਾ ਤਰੀਕਾ ਵੇਖੋ
• ਸੁਧਾਰ: ਕੋਡ ਅਤੇ ਲੋੜ ਨੂੰ ਇਕੱਠੇ ਸੁਧਾਰੋ

ਇਹ ਲੂਪ ਠੋਸ ਤਰੱਕੀ ਨੂੰ ਇਨਾਮ ਦਿੰਦਾ ਹੈ। “ਸਾਨੂੰ ਪਲੱਗ-ਇਨ ਸਿਸਟਮ ਦੀ ਲੋੜ ਹੋਵੇਗੀ” ਜਾਂ “ਇਹ 12 ਡਾਟਾ ਸੋਰਨਾਂ ਦਾ ਸਹਿਯੋਗ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ” ਦੀ ਚਰਚਾ ਕਰਨ ਦੀ ਥਾਂ, ਟੀਮ ਵੇਖਦੀ ਹੈ ਕਿ ਮੌਜੂਦਾ ਸਮੱਸਿਆ ਵਾਕਈ ਕੀ ਮੰਗਦੀ ਹੈ।

ਗਤੀ ਕਿਉਂ ਸਪੈਕੁਲੇਟਿਵ ਆਰਕੀਟੈਕਚਰ ਘਟਾਉਂਦੀ ਹੈ

ਪੂਰਵ-ਅਬਸਟ੍ਰੈਕਸ਼ਨ ਅਕਸਰ ਉਦੋਂ ਹੁੰਦੀ ਹੈ ਜਦੋਂ ਟੀਮਾਂ ਬਦਲਾਅ ਤੋਂ ਡਰਦੀਆਂ ਹਨ: ਜੇ ਬਦਲਾਅ ਮਹਿੰਗੇ ਹਨ, ਤਾਂ ਤੁਸੀਂ ਭਵਿੱਖ ਦੀ ਭਵਿੱਖਬਾਣੀ ਕਰਨ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰਦੇ ਹੋ ਅਤੇ ਉਸਦਾ ਡਿਜ਼ਾਈਨ ਕਰਦੇ ਹੋ। ਛੋਟੀ ਲੂਪਾਂ ਨਾਲ, ਬਦਲਾਅ ਸਸਤਾ ਹੋ ਜਾਂਦਾ ਹੈ। ਇਹ ਪ੍ਰੇਰਣਾ ਨੂੰ ਉਲਟ ਦਿੰਦਾ ਹੈ:

• ਤੁਸੀਂ ਆਮਕਰਨ ਨੂੰ ਮੰਨ ਲਿਆਉਂਦੇ ਹੋ ਜਦੋਂ ਬਾਰ-ਬਾਰ ਕੰਮ ਇਹ ਦਰਸਾਉਂਦਾ ਹੈ ਕਿ ਇਹ ਲੋੜੀਂਦਾ ਹੈ।
• ਤੁਸੀਂ ਅਸਲ ਸੀਮਾਵਾਂ (ਪਰਫਾਰਮੈਂਸ, ਡਾਟਾ ਆਕਾਰ, ਉਪਭੋਗਤਾ ਵਰਤਾਰਾ) ਜਲਦੀ ਪਤਾ ਲਗਾਉਂਦੇ ਹੋ।
• ਤੁਸੀਂ “ਸਿਰਫ਼ ਸੰਭਵ ਹੈ” ਦੇ ਆਧਾਰ 'ਤੇ ਨਿਰਮਾਣ ਰੋਕ ਦਿੰਦੇ ਹੋ ਕਿਉਂਕਿ ਤੁਸੀਂ "ਸਮੇਂ 'ਤੇ" ਇਤਰੈਟ ਕਰ ਸਕਦੇ ਹੋ।

ਇੱਕ ਸਧਾਰਨ ਉਦਾਹਰਣ: ਫਰੇਮਵਰਕ ਤੋਂ ਪਹਿਲਾਂ ਏਂਡਪੋਇੰਟ

ਕਹੋ ਤਸੀਂ ਇੱਕ ਆਂਤਰਿਕ “CSV ਵਿੱਚ ਐਕਸਪੋਰਟ” ਫੀਚਰ ਜੋੜ ਰਹੇ ਹੋ। ਅਤਿ-ਇੰਜੀਨੀਅਰਿੰਗ ਵਾਲਾ ਰਸਤਾ ਇੱਕ ਜੈਨੇਰਿਕ ਐਕਸਪੋਰਟ ਫਰੇਮਵਰਕ, ਕਈ ਫਾਰਮੈਟ, ਜੌਬ ਕਿਊਜ਼, ਅਤੇ ਸੰਰਚਨਾ ਪਰਤਾਂ ਡਿਜ਼ਾਇਨ ਕਰਨ ਨਾਲ ਸ਼ੁਰੂ ਹੁੰਦਾ ਹੈ।

ਕੁਝ ਛੋਟਾ ਰਸਤਾ ਇਹ ਹੈ: ਇੱਕ ਸਿੰਗਲ /exports/orders.csv ਏਂਡਪੋਇੰਟ (ਜਾਂ ਇੱਕ ਇੱਕ-ਵਾਰ ਸਕ੍ਰਿਪਟ) ਬਣਾਓ, ਇਸਨੂੰ ਸਟੇਜਿੰਗ ਡੇਟਾ 'ਤੇ ਚਲਾਉ, ਅਤੇ ਫਾਇਲ ਸਾਈਜ਼, ਰਨਟਾਈਮ, ਅਤੇ ਮਿਸਿੰਗ ਫੀਲਡਾਂ ਨੂੰ ਨਿਰੀਖਣ ਕਰੋ। ਜੇ ਦੋ-ਤਿੰਨ ਐਕਸਪੋਰਟਾਂ ਤੋਂ ਬਾਅਦ ਤੁਸੀਂ ਦੁਹਰਾਏ ਜਾਂਦੇ ਪੈਟਰਨ ਵੇਖਦੇ ਹੋ—ਉਹੀ pagination ਲਾਜਿਕ, ਸਾਂਝੇ ਫਿਲਟਰਿੰਗ, ਸਾਂਝੇ headers—ਤਦ ਇੱਕ ਅਬਸਟ੍ਰੈਕਸ਼ਨ ਆਪਣੀ ਜਗ੍ਹਾ ਬਣਾਉਂਦਾ ਹੈ ਕਿਉਂਕਿ ਉਹ ਅਨੁਭਵ 'ਤੇ ਅਧਾਰਿਤ ਹੈ, ਅਨੁਮਾਨ 'ਤੇ ਨਹੀਂ।

ਕ੍ਰਮਬੱਧ ਬਦਲਾਅ ਅਬਸਟ੍ਰੈਕਸ਼ਨਾਂ ਨੂੰ ਆਪਣੀ ਕਦਰ ਕਮਾਉਣ ਦਿੰਦੇ ਹਨ

ਕ੍ਰਮਬੱਧ ਡਿਲਿਵਰੀ ਡਿਜ਼ਾਈਨ ਦੀ ਆਰਥਿਕੀਤਾ ਨੂੰ ਬਦਲ ਦਿੰਦੀ ਹੈ। ਜਦੋਂ ਤੁਸੀਂ ਛੋਟੇ ਟੁਕੜਿਆਂ ਵਿੱਚ ਸ਼ਿਪ ਕਰਦੇ ਹੋ, ਹਰ “ਚੰਗਾ-ਹੋਣ ਵਾਲੀ” ਪਰਤ ਨੂੰ ਇਹ ਸਾਬਤ ਕਰਨਾ ਪੈਂਦਾ ਹੈ ਕਿ ਇਹ ਹੁਣ ਮਦਦ ਕਰਦੀ ਹੈ—ਨਾ ਕਿ ਕੋਈ ਕਲਪਿਤ ਭਵਿੱਖ। ਇੱਥੇ AI-ਚਲਾਏ ਵਰਕਫਲੋ ਪੂਰਵ-ਅਬਸਟ੍ਰੈਕਸ਼ਨ ਨੂੰ ਆਹਿਸਤਗੀ ਨਾਲ ਘਟਾਉਂਦੇ ਹਨ: AI ਬਣਾਉਣ ਵਿੱਚ ਮਹਿਰਤ ਰਖਦਾ ਹੈ, ਪਰ ਇਹਨੀਆਂ ਰਚਨਾਵਾਂ ਨੂੰ ਛੋਟੇ ਸਕੋਪ 'ਚ ਟੈਸਟ ਕਰਨਾ ਸਭ ਤੋਂ ਆਸਾਨ ਹੁੰਦਾ ਹੈ।

ਛੋਟਾ ਸਕੋਪ AI ਸੁਝਾਵਾਂ ਨੂੰ ਟੈਸਟ ਕਰਨਯੋਗ ਬਣਾਂਦਾ ਹੈ

ਜੇ ਤੁਸੀਂ ਸਹਾਇਕ ਤੋਂ ਇੱਕ ਸਿਰਫ਼ ਮੋਡਯੂਲ ਰੀਫੈਕਟਰ ਕਰਨ ਜਾਂ ਨਵਾਂ ਏਂਡਪੋਇੰਟ ਜੋੜਨ ਲਈ ਕਹੋ, ਤੁਸੀਂ ਜਲਦੀ ਜਾਂਚ ਸਕਦੇ ਹੋ ਕਿ ਉਸਦੀ ਅਬਸਟ੍ਰੈਕਸ਼ਨ ਸਪਸ਼ਟਤਾ, ਨਕਲ ਘਟਾਉਂਦੀ ਹੈ ਜਾਂ ਅਗਲਾ ਬਦਲਾਅ ਆਸਾਨ ਕਰਦੀ ਹੈ। ਇੱਕ ਛੋਟੀ diff ਨਾਲ, ਫੀਡਬੈਕ ਤੁਰੰਤ ਹੁੰਦਾ ਹੈ: ਟੈਸਟ ਪਾਸ ਜਾਂ ਫੇਲ, ਕੋਡ ਪੜ੍ਹਨਯੋਗ ਹੋਇਆ ਜਾਂ ਨਹੀਂ, ਅਤੇ ਫੀਚਰ ਸਹੀ ਤਰੀਕੇ ਨਾਲ ਚਲਦਾ ਹੈ ਜਾਂ ਨਹੀਂ।

ਵੱਡੇ ਸਕੋਪ ਵਿੱਚ, AI ਸੁਝਾਵ ਪਰਪਲੀਆਦਾਹਕ ਲੱਗ ਸਕਦੇ ਹਨ ਬਿਨਾਂ ਸਾਬਤ ਲਾਭ ਦੇ। ਤੁਸੀਂ ਇੱਕ ਜੈਨੇਰਲਾਈਜ਼ਡ ਫਰੇਮਵਰਕ ਨੂੰ ਇਸ ਲਈ ਕਬੂਲ ਕਰ ਸਕਦੇ ਹੋ ਕਿਉਂਕਿ ਇਹ “ਸਾਫ਼ ਲੱਗਦਾ” ਹੈ, ਪਰ ਬਾਅਦ ਵਿੱਚ ਪਤਾ ਲੱਗਦਾ ਹੈ ਕਿ ਇਸਨੇ ਅਸਲ ਦੁਨੀਆ ਦੇ ਏਜ ਕੇਸਾਂ ਨੂੰ ਜਟਿਲ ਕੀਤਾ।

ਛੋਟੇ ਕੰਪੋਨੈਂਟ ਦਿਖਾਉਂਦੇ ਹਨ ਕਿ ਕੀ ਰੱਖਣਾ ਹੈ (ਅਤੇ ਕੀ ਹਟਾਉਣਾ)

ਕ੍ਰਮਬੱਧ ਕੰਮ ਛੋਟੇ, ਨਾਸ਼ ਯੋਗ ਕੰਪੋਨੈਂਟ ਪਹਿਲਾਂ ਬਣਾਉਣ ਨੂੰ ਉਤਸ਼ਾਹਿਤ ਕਰਦਾ ਹੈ—ਹੈਲਪਰ, ਐਡੈਪਟਰ, ਸਧਾਰਨ ਡੇਟਾ ਰੂਪ। ਕੁਝ ਇਟਰੇਸ਼ਨਾਂ ਤੋਂ ਬਾਅਦ ਇਹ ਸਪਸ਼ਟ ਹੋ ਜਾਂਦਾ ਹੈ ਕਿ ਕਿਹੜੇ ਪੀਸ ਕਈ ਫੀਚਰਾਂ ਵੱਲੋਂ ਖਿੱਚੇ ਜਾਂਦੇ ਹਨ (ਰੱਖਣਯੋਗ) ਅਤੇ ਕਿਹੜੇ ਸਿਰਫ਼ ਇੱਕ-ਵਾਰੀ ਪ੍ਰਯੋਗ ਲਈ ਸੀ (ਨਿਰਪੱਖ ਤੌਰ 'ਤੇ ਹਟਾਏ ਜਾ ਸਕਦੇ)।

ਅਬਸਟ੍ਰੈਕਸ਼ਨ ਫਿਰ ਅਸਲੀ ਦੁਹਰਾਵਾਂ ਦਾ ਰਿਕਾਰਡ ਬਣਦੇ ਹਨ, ਨਾ ਕਿ ਅਨੁਮਾਨ ਕੀਤੇ ਦੁਹਰਾਵਾਂ ਦਾ।

ਕ੍ਰਮਬੱਧ ਡਿਲਿਵਰੀ ਰੀਫੈਕਟਰ ਦੇ ਜੋਖਮ ਨੂੰ ਘਟਾਉਂਦੀ ਹੈ

ਜਦੋਂ ਬਦਲਾਅ ਲਗਾਤਾਰ ਸ਼ਿਪ ਹੁੰਦੇ ਹਨ, ਰੀਫੈਕਟਰੀੰਗ ਘਬਰਾਉਣ ਯੋਗ ਨਹੀਂ ਰਹਿੰਦਾ। ਤੁਹਾਨੂੰ ਅਗਲੇ ਕਦਮ 'ਤੇ “ਸਹੀ” ਹੋਣਾ ਜਰੂਰੀ ਨਹੀਂ ਹੁੰਦਾ ਕਿਉਂਕਿ ਤੁਸੀਂ ਡਿਜ਼ਾਈਨ ਨੂੰ ਇਤ੍ਰੈਟ ਕਰਨ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰ ਸਕਦੇ ਹੋ ਜਦੋਂ ਸਬੂਤ ਇਕੱਠੇ ਹੋ ਜਾਣ। ਜੇ ਕੋਈ ਪੈਟਰਨ ਅਸਲ ਵਿੱਚ ਆਪਣੀ ਜਗ੍ਹਾ ਬਣਾਉਂਦਾ ਹੈ—ਕਈ ਇਨਕ੍ਰੀਮੈਂਟਾਂ ਵਿੱਚ ਦੁਹਰਾਏ ਜਾਂਦੇ ਕੰਮ ਨੂੰ ਘਟਾਉਂਦਾ ਹੈ—ਤਾਂ ਉਸਨੂੰ ਅਬਸਟ੍ਰੈਕਸ਼ਨ ਵਿੱਚ ਤਬਦੀਲ ਕਰਨਾ ਘੱਟ-ਜੋਖਮ, ਉੱਚ-ਭਰੋਸੇ ਵਾਲਾ ਫੈਸਲਾ ਹੁੰਦਾ ਹੈ।

ਇਹ ਸੋਚ ਰੁਝਾਨ ਨੂੰ ਉਲਟ ਦਿੰਦੀ ਹੈ: ਪਹਿਲਾਂ ਸਭ ਤੋਂ ਸਧਾਰਨ ਸੰਸਕਰਣ ਬਣਾਓ, ਫਿਰ ਹੀ ਅਬਸਟ੍ਰੈਕਟ ਕਰੋ ਜਦੋਂ ਅਗਲਾ ਇਨਕ੍ਰੀਮੈਂਟ ਸਬੂਤ ਦਿਖਾਏ।

ਆਸਾਨ ਪ੍ਰਯੋਗ ਕਰਨ ਸਾਦਗੀ ਨੂੰ “ਵੱਡੇ ਡਿਜ਼ਾਈਨ” ਬਜਾਏ ਫਾਇਦਾ ਦਿੰਦਾ ਹੈ

AI-ਚਲਾਏ ਵਰਕਫਲੋ ਪ੍ਰਯੋਗ ਨੂੰ ਇੰਨਾ ਸਸਤਾ ਬਣਾ ਦਿੰਦੇ ਹਨ ਕਿ “ਇੱਕ ਵੱਡੀ ਪ੍ਰਣਾਲੀ ਬਣਾਉਣ” ਡਿਫੌਲਟ ਰਹਿਣਾ ਬੰਦ ਹੋ ਜਾਂਦਾ ਹੈ। ਜਦੋਂ ਟੀਮ ਇੱਕ ਹੀ ਬਸ ਇੱਕ ਦੁਪਹਿਰ ਵਿੱਚ ਕਈ ਰੁਖਾਂ ਨੂੰ ਜਨਰੇਟ, ਸੁਧਾਰ, ਅਤੇ ਦੁਬਾਰਾ ਚਲਾ ਸਕਦੀ ਹੈ, ਤਾਂ ਅਗਲੇ ਕਦਮ ਦੀ ਭਵਿੱਖਬਾਣੀ ਕਰਨ ਦੀ ਥਾਂ ਇਹ ਜ਼ਿਆਦਾ ਆਸਾਨ ਹੋ ਜਾਂਦਾ ਹੈ ਕਿ ਕੀ ਅਸਲ ਵਿੱਚ ਕੰਮ ਕਰਦਾ ਹੈ।

AI ਛੋਟੀਆਂ ਵੈਰੀਅੰਟਸ ਤਕਰੀਬਨ ਮੁਫ਼ਤ ਕਰ ਦਿੰਦਾ ਹੈ

ਇੱਕ ਜੈਨੇਰਿਕ ਆਰਕੀਟੈਕਚਰ ਡਿਜ਼ਾਈਨ ਕਰਨ ਵਿਚ ਦਿਨ ਲੱਗਣਾਂ ਅਦਲੇ, ਟੀਮ AI ਨੂੰ ਕਹਿ ਸਕਦੀ ਹੈ ਕਿ ਕੁਝ ਵੱਖ-ਵੱਖ, ਨਿਰਧਾਰਿਤ ਲਾਗੂਕਰਨ ਤਿਆਰ ਕਰਦਾ ਹੈ:

• ਇੱਕ ਸਧਾਰਣ ਸੰਸਕਰਣ ਜੋ ਖੁਸ਼ੀ ਰਸਤੇ ਨੂੰ ਚੰਗੀ ਤਰ੍ਹਾਂ ਸੰਭਾਲਦਾ ਹੈ
• ਪੜ੍ਹਨਯੋਗਤਾ ਅਤੇ ਰਖ-ਰਖਾਵ ਲਈ ਅਦਾਇਗੀ ਯੋਗ ਸੰਸਕਰਣ
• ਇੱਕ ਸੰਸਕਰਣ ਜੋ ਸਿਰਫ਼ ਇੱਕ ਵਾਧੂ ਸਮਰੱਥਾ (ਉਦਾਹਰਣ ਲਈ, ਦੂਜਾ ਇਨਪੁਟ ਫਾਰמט) ਜੋੜਦਾ ਹੈ

ਇਨਾਂ ਵੈਰੀਅੰਟਸ ਨੂੰ ਬਣਾਉਣਾ ਤੇਜ਼ ਹੈ, ਇਸ ਲਈ ਟੀਮ ਬਿਨਾਂ ਵੱਡੇ ਪ੍ਰਣਾਲੀ 'ਤੇ ਬਾਂਧੇ ਬਿਨਾਂ ਟਰੇਡ-ਆਫ਼ ਅਨੁਸ਼ੋਧ ਕਰ ਸਕਦੀ ਹੈ। ਲਕੜੀ ਉਦੇਸ਼ ਸਾਰੇ ਵੈਰੀਅੰਟਸ ਸ਼ਿਪ ਕਰਨਾ ਨ ਹੁੰਦਾ—ਮਕਸਦ ਸਬੂਤ ਪ੍ਰਾਪਤ ਕਰਨਾ ਹੁੰਦਾ ਹੈ।

ਵੈਰੀਅੰਟਸ ਦੀ ਤੁਲਨਾ ਆਮ ਤੌਰ 'ਤੇ ਸਧਾਰਨ ਹੱਲਾਂ ਨੂੰ ਇਨਾਮ ਦਿੰਦੀ ਹੈ

ਜਦੋਂ ਤੁਸੀਂ ਦੋ-ਤਿੰਨ ਕੰਮ ਕਰਨ ਵਾਲੇ ਵਿਕਲਪਾਂ ਨੂੰ ਪਾਸੇ-ਪਾਸੇ ਰੱਖ ਸਕਦੇ ਹੋ, ਤਾਂ ਜਟਿਲਤਾ ਸਾਹਮਣੇ ਆ ਜਾਂਦੀ ਹੈ। ਅਕਸਰ ਸਧਾਰਣ ਵੈਰੀਅੰਟ:

• ਇਕੋ ਹੀ ਅਸਲੀ ਲੋੜਾਂ ਨੂੰ ਪੂਰਾ ਕਰਦਾ ਹੈ
• ਘੱਟ ਮੂਵਿੰਗ ਹਿੱਸੇ ਹਨ ਜੋ ਡਿਬੱਗ ਕਰਨੇ ਹੋਂਦੇ ਹਨ
• ਭਵਿੱਖ ਦੇ ਬਦਲਾਅ ਆਸਾਨ ਬਣਾਉਂਦਾ ਹੈ ਕਿਉਂਕਿ ਘੱਟ ਲੁਕੀ ਹੋਈ coupling ਹੈ

ਦੂਜੇ ਪਾਸੇ, ਅਤਿ-ਇੰਜੀਨੀਅਰਡ ਵਿਕਲਪ ਆਪਣੀ ਪੱਖਪਾਤ ਸੰਭਾਵੀ ਲੋੜਾਂ ਨਾਲ ਖੁਦ ਨੂੰ ਸਹੀ ਠਹਿਰਾਉਂਦੇ ਹਨ। ਵੈਰੀਅੰਟਸ ਦੀ ਤੁਲਨਾ ਇਸ ਦਾ ਦਵਾਈ ਹੈ: ਜੇ ਵਾਧੂ ਅਬਸਟ੍ਰੈਕਸ਼ਨ ਨੇ ਇੱਕ-ਦੋ ਮੈਟਰਿਕ 'ਤੇ ਸਪਸ਼ਟ ਨਜਾਇਜ਼ ਲਾਭ ਨਹੀਂ ਦਿੱਤਾ, ਤਾਂ ਸਧਾਰਨ ਕੰਮਕਾਜੀ ਰਸਤਾ ਆਮ ਤੌਰ 'ਤੇ ਠੀਕ ਫੈਸਲਾ ਹੁੰਦਾ ਹੈ—ਫਿਲਹਾਲ ਲਈ।

ਚੈੱਕਲਿਸਟ: ਵਿਕਲਪਾਂ ਦੀ ਤੁਲਨਾ ਕਰਦਿਆਂ ਕੀ ਮਾਪਣਾ ਹੈ

ਜਦੋਂ ਤੁਸੀਂ ਹਲਕੇ-ਫੁਲਕੇ ਪ੍ਰਯੋਗ ਚਲਾਉਂਦੇ ਹੋ, ਤਾਂ ਇਹ ਤੈਅ ਕਰੋ ਕਿ “ਵਧੀਆ” ਦਾ ਕੀ ਮਤਲਬ ਹੈ। ਇੱਕ ਪ੍ਰਯੋਗਿਕ ਚੈੱਕਲਿਸਟ:

• ਟਾਈਮ-ਟੂ-ਫਿਸਟ-ਵਰਕਿੰਗ-ਰਿਜ਼ਲਟ: ਬੁਨਿਆਦੀ ਦਿਸ਼ਾ-ਨਿਰਦੇਸ਼ਾਂ ਤੱਕ ਪਹੁੰਚਣ ਲਈ ਕਿੰਨਾ ਸਮਾਂ ਲੱਗਦਾ ਹੈ?
• ਲਾਗੂਕਰਨ ਜਟਿਲਤਾ: ਛੂਹੇ/ਮਾਡਿਊਲ ਛੁਹਣ ਗਿਣਤੀ, ਪਰਿਭਾਸ਼ਾਵਾਂ ਦੀ ਗਿਣਤੀ, ਅਤੇ ਕਿੰਨੇ ਨਿਯਮ ਇਕ ਸਹਿਯੋਗੀ ਨੂੰ ਯਾਦ ਰੱਖਣੇ ਪੈਂਦੇ ਹਨ।
• ਬਦਲਾਅ ਲਾਗਤ: ਇੱਕ ਨਵੀਂ ਲੋੜ (ਅਗਲੀ ਸੰਭਾਵੀ) ਜੋੜਣ ਲਈ ਕਿੰਨੀ ਔਖਾਈ ਹੁੰਦੀ ਹੈ?
• ਫੇਲਿਯਰ ਮੋਡ: ਕੀ ਟੁੱਟਦਾ ਹੈ, ਕਿੰਨਾ ਬੁਰੀ ਤਰ੍ਹਾਂ, ਅਤੇ ਪਤਾ ਲਗਾਉਣਾ ਕਿੰਨਾ ਆਸਾਨ ਹੈ (ਸਾਫ਼ ਐਰਰਜ਼ ਵਿਰੁੱਧ ਚੁਪਚਾਪ ਗਲਤ ਆਉਟਪੁੱਟ)।
• ਓਪਰੇਸ਼ਨਲ ਜੋਖਮ: ਨਵੀਆਂ ਡਿਪੈਂਡੇਨਸੀਆਂ, ਸੰਰਚਨਾ ਸਤਹ, ਅਤੇ ਥਾਵਾਂ ਜਿੱਥੇ ਪ੍ਰੋਡਕਸ਼ਨ ਵਿਵਹਾਰ ਭਟક ਸਕਦਾ ਹੈ।
• ਟੈਸਟੇਬਿਲਟੀ: ਛੋਟੇ ਟੈਸਟ ਲਿਖ ਕੇ ਵਿਵਹਾਰ ਨੂੰ ਕਿੰਨੀ ਆਸਾਨੀ ਨਾਲ ਵਿਆਖਿਆ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ।

ਜੇ ਇੱਕ ਵੱਧ ਜੈਨੇਰਲਾਈਜ਼ਡ ਵੈਰੀਅਂਟ ਇਨ੍ਹਾਂ ਵਿੱਚੋਂ ਇੱਕ ਜਾਂ ਦੋ ਮਾਪਦੰਡਾਂ 'ਤੇ ਜਿੱਤ ਨਹੀਂ ਸਕਦਾ, ਤਾਂ ਅਕਸਰ ਸਭ ਤੋਂ ਸਧਾਰਨ ਕੰਮਕਾਜੀ ਰਸਤਾ ਹੀ ਠੀਕ ਚੋਣ ਹੁੰਦੀ ਹੈ।

AI ਤੁਹਾਨੂੰ ਅਬਸਟ੍ਰੈਕਟ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਲੋੜਾਂ ਸਪਸ਼ਟ ਕਰਨ ਵਿੱਚ ਮਦਦ ਕਰਦਾ ਹੈ

ਪੂਰਵ-ਅਬਸਟ੍ਰੈਕਸ਼ਨ ਆਮ ਤੌਰ 'ਤੇ ਇੱਕ ਵਾਕ्य ਨਾਲ ਸ਼ੁਰੂ ਹੁੰਦੀ ਹੈ: “ਸਾਨੂੰ ਇਹ ਭਵਿੱਖ ਵਿੱਚ ਲੋੜ ਹੋ ਸਕਦੀ ਹੈ।” ਇਹਨੂੰ “ਸਾਨੂੰ ਇਹ ਹੁਣ ਲੋੜ ਹੈ” ਨਾਲ ਗਲਤ ਨਾ ਕਰੋ। ਪਹਿਲਾ ਇੱਕ ਭਵਿੱਖ ਬਾਰੇ ਅਨੁਮਾਨ ਹੈ; ਦੂਜਾ ਇੱਕ ਅਜਿਹਾ ਬੰਧਨ ਹੈ ਜੋ ਤੁਸੀਂ ਅੱਜ ਜਾਂਚ ਸਕਦੇ ਹੋ।

AI-ਚਲਾਏ ਵਰਕਫਲੋ ਇਸ ਫਰਕ ਨੂੰ ਨਜ਼ਰਅੰਦਾਜ਼ ਕਰਨਾ ਔਖਾ ਬਣਾਉਂਦੇ ਹਨ ਕਿਉਂਕਿ ਉਹ ਧੁੰਦਲੀ ਗੱਲਾਂ ਨੂੰ ਤੇਜ਼ੀ ਨਾਲ ਉਸ ਲਿਖਤੀ ਰੂਪ ਵਿੱਚ ਬਦਲ ਸਕਦੇ ਹਨ ਜੋ ਤੁਸੀਂ ਨਿਰੀਖਣ ਕਰ ਸਕਦੇ ਹੋ।

ਅਪੰਨੇ ਬਿਨਾਂ ਜ਼ੋਰ ਦੇ ਧੁੰਦਲਾਪਨ ਨੂੰ ਲਿਖਤੀ ਸੰਮੇਲਨ ਵਿੱਚ ਬਦਲੋ

ਜਦੋਂ ਇੱਕ ਫੀਚਰ ਤਲਬ ਧੁੰਦਲਾ ਹੁੰਦਾ ਹੈ, ਟੀਮਾਂ ਆਮ ਤੌਰ 'ਤੇ “ਭਵਿੱਖ-ਪ੍ਰੂਫ਼” ਕਰਨ ਲਈ ਜੈਨੇਰਿਕ ਫਰੇਮਵਰਕ ਬਣਾਉਂਦੀਆਂ ਹਨ। ਬਦਲੇ ਵਿੱਚ, AI ਵਰਤ ਕੇ ਤੇਜ਼ੀ ਨਾਲ ਇੱਕ ਇਕ-ਪੰਨੇ ਦੀ ਲੋੜ-ਸਨੈਪਸ਼ਾਟ ਤਿਆਰ ਕਰੋ ਜੋ ਇਹ ਵੱਖ-ਵੱਖ ਕਰੇ:

• ਅਸੀਂ ਜੋ ਜਾਣਦੇ ਹਾਂ (ਮੌਜੂਦਾ ਸੀਮਾਵਾਂ): ਨਿਸ਼ਾਨਾ ਉਪਭੋਗਤਾ, ਸਮਰਥਿਤ ਪਲੈਟਫਾਰਮ, ਕਾਰਗੁਜ਼ਾਰੀ ਉਮੀਦਾਂ, ਲੋੜੀਂਦੇ ਇੰਟੀਗ੍ਰੇਸ਼ਨ।
• ਅਸੀਂ ਜੋ ਮੰਨ ਰਹੇ ਹਾਂ: “ਉਪਭੋਗਤਾ ਕਈ ਖਾਤੇ ਰੱਖਣਗੇ,” “ਅਸੀਂ 10 ਭਾਸ਼ਾਵਾਂ ਦੀ ਸਹਾਇਤਾ ਕਰਾਂਗੇ,” “ਮੁੱਲ ਦਾ ਵੱਖਰਾ ਪਦਾਰਥ ਹੋਵੇਗਾ।”
• ਅਸੀਂ ਜੋ ਹੁਣੇ ਨਹੀਂ ਜਾਣਦੇ: ਏਜ ਕੇਸ, ਕਾਨੂੰਨੀ ਪਾਬੰਦੀਆਂ, ਸਕੇਲ, ਮਾਈਗ੍ਰੇਸ਼ਨ ਦੀ ਲੋੜ।

ਇਹ ਸਧਾਰਨ ਵੰਡ ਇੰਜੀਨੀਅਰਿੰਗ ਗੱਲ-ਬਾਤ ਨੂੰ ਬਦਲ ਦਿੰਦੀ ਹੈ। ਤੁਸੀਂ ਇਕ ਅਣਜਾਣ ਭਵਿੱਖ ਲਈ ਡਿਜ਼ਾਇਨ ਕਰਨਾ ਛੱਡ ਦਿੰਦੇ ਹੋ ਅਤੇ ਜਾਣੂ ਮੌਜੂਦਾ ਲਈ ਬਣਾਉਣ ਸ਼ੁਰੂ ਕਰਦੇ ਹੋ—ਜੇਕਰ ਅਨਿਸ਼ਚਿਤਤਾਵਾਂ ਦੀ ਸਭਾ ਹੋਵੇ ਤਾਂ ਉਨ੍ਹਾਂ ਨੂੰ ਦੁਬਾਰਾ ਵੇਖਣ ਲਈ ਇੱਕ ਗੌਰਤਲੂ ਸੂਚੀ ਰੱਖਦੇ ਹੋ।

Koder.ai ਦੀ Planning Mode ਇੱਥੇ ਵਧੀਆ ਫਿੱਟ ਹੁੰਦੀ ਹੈ: ਤੁਸੀਂ ਧੁੰਦਲੀ ਮੰਗ ਨੂੰ ਇੱਕ ਸਪਸ਼ਟ ਯੋਜਨਾ (ਕਦਮ, ਡੇਟਾ ਮਾਡਲ, ਏਂਡਪੋਇੰਟ, UI ਸਥਿਤੀਆਂ) ਵਿੱਚ ਬਦਲ ਸਕਦੇ ਹੋ ਬਿਨਾਂ ਕਿਸੇ ਵਿਸ਼ਾਲ ਆਰਕੀਟੈਕਚਰ 'ਤੇ ਕਮਿਟ ਹੋਏ।

ਹਲਕਾ “ਭਵਿੱਖ-ਮਿੱਤਰ” ਰੁਖ

ਤੁਸੀਂ ਫਿਰ ਵੀ ਵਿਕਸਤ ਹੋਣ ਦੀ ਜਗ੍ਹਾ ਛੱਡ ਸਕਦੇ ਹੋ ਬਿਨਾਂ ਇੱਕ ਗਹਿਰੇ ਅਬਸਟ੍ਰੈਕਸ਼ਨ ਦੀ ਪਰਤ ਬਣਾਏ। ਉਹ ਤਰੱਕੀਆਂ ਵੱਲ ਜ਼ੋਰ ਦਿਓ ਜੋ ਬਦਲਣਾ ਆਸਾਨ ਜਾਂ ਹਟਾਉਣਾ ਆਸਾਨ ਹੋਣ:

• ਫੀਚਰ ਫ਼ਲੈਗ ਤਾਂ ਜੋ ਇੱਕ ਸੰਕੁਚਿਤ ਸੰਸਕਰਣ ਸ਼ਿਪ ਕੀਤਾ ਜਾ ਸਕੇ ਅਤੇ ਅਸਲ ਵਰਤੋਂ ਤੋਂ ਸਿੱਖਿਆ ਜਾ ਸਕੇ।
• ਸੰਰਚਨਾ ਵਿਕਲਪ ਜਿਹੜੇ ਕੇਵਲ ਵੈਰੀਏਸ਼ਨਾਂ ਲਈ ਵਰਤੋਂਗੇ (timeouts, thresholds, copy) ਬਜਾਏ ਪੋਲਿਮਾਰਫਿਕ ਪ੍ਰਣਾਲੀਆਂ।
• ਛੋਟੇ ਐਕਸਟੈਂਸ਼ਨ ਬਿੰਦੂ (ਇੱਕ ਇੰਟਰਫੇਸ, ਇੱਕ ਹੂਕ, ਇੱਕ ਇਵੈਂਟ) ਕੇਵਲ ਓਥੇ ਜਿੱਥੇ ਵੈਰੀਏਸ਼ਨ ਪਹਿਲਾਂ ਤੋਂ ਸੰਭਵ ਹੋਵੇ।

ਇੱਕ ਚੰਗਾ ਨਿਯਮ: ਜੇ ਤੁਸੀਂ ਅਗਲੇ ਦੋ ਖਾਸ ਵੈਰੀਏਸ਼ਨਾਂ ਨੂੰ ਨਾਮ ਨਹੀਂ ਦੇ ਸਕਦੇ, ਤਾਂ ਫਰੇਮਵਰਕ ਨਾ ਬਣਾਓ। ਸੰਦੇਹਸਪਦ ਵੈਰੀਏਸ਼ਨਾਂ ਨੂੰ “ਅਣਜਾਣ” ਵਜੋਂ ਲਿਖੋ, ਸਭ ਤੋਂ ਸਧਾਰਨ ਕੰਮਕਾਜੀ ਰਸਤਾ ਸ਼ਿਪ ਕਰੋ, ਫਿਰ ਅਸਲ ਫੀਡਬੈਕ ਅਬਸਟ੍ਰੈਕਸ਼ਨ ਨੂੰ ਨਿਆਂਪੂਰਕ ਬਣਾਉਂਦਾ ਹੈ।

ਜੇ ਤੁਸੀਂ ਇਸ ਆਦਤ ਨੂੰ ਰੂਪਕ੍ਰਿਤ ਕਰਨਾ ਚਾਹੁੰਦੇ ਹੋ, ਤਾਂ ਇਹ ਨੋਟਸ ਆਪਣੇ PR ਟੈਂਪਲੇਟ ਜਾਂ ਇੱਕ ਅੰਦਰੂਨੀ “ਅਨੁਮਾਨ” ਦਸਤਾਵੇਜ਼ ਵਿੱਚ ਰੱਖੋ ਜੋ ਟਿਕਟ ਨਾਲ ਲਿੰਕ ਕੀਤਾ ਗਿਆ ਹੋਵੇ (ਉਦਾਹਰਣ ਲਈ, /blog/engineering-assumptions-checklist)।

ਟੈਸਟ ਅਤੇ ਉਦਾਹਰਣ ਅਣਜ਼ਰੂਰੀ ਜੈਨਰਲਾਈਜ਼ੇਸ਼ਨ ਨੂੰ ਬਾਹਰ ਲਿਆਉਂਦੇ ਹਨ

ਟੀਮਾਂ ਅਕਸਰ ਕਲਪਿਤ ਪਰਿਸਥਿਤੀਆਂ ਲਈ ਡਿਜ਼ਾਈਨ ਕਰਦੀਆਂ ਹਨ। ਟੈਸਟ ਅਤੇ ਠੋਸ ਉਦਾਹਰਣ ਇਸ ਨੂੰ ਉਲਟ ਦਿੰਦੀਆਂ ਹਨ: ਉਹ ਤੁਹਾਨੂੰ ਅਸਲ ਇਨਪੁਟ, ਅਸਲ ਆਉਟਪੁਟ, ਅਤੇ ਅਸਲ ਫੇਲਿਅਰ ਮੋਡਾਂ ਨੂੰ ਵਰਣਨ ਕਰਨ ਲਈ ਮਜ਼ਬੂਰ ਕਰਦੇ ਹਨ। ਜਦੋਂ ਇਹ ਲਿਖੇ ਜਾਂਦੇ ਹਨ, “ਜਨਰਿਕ” ਅਬਸਟ੍ਰੈਕਸ਼ਨ ਅਕਸਰ ਘੱਟ ਲਾਭਕਾਰੀ ਅਤੇ ਵਧੇਰੇ ਮਹਿੰਗੇ ਲੱਗਦੇ ਹਨ—ਇੱਕ ਛੋਟੇ, ਸਾਫ਼ ਇੰਪਲੀਮੈਂਟੇਸ਼ਨ ਨਾਲ ਤੁਲਨਾਤਮਕ ਤੌਰ 'ਤੇ।

AI ਕਿਵੇਂ ਏਜ ਕੇਸਾਂ ਨੂੰ ਸਾਹਮਣੇ ਲਿਆਉਂਦਾ ਹੈ (ਬਿਨਾਂ ਆਰਕੀਟੈਕਚਰ ਬਣਾਉਣ ਦੇ)

ਜਦੋਂ ਤੁਸੀਂ AI ਸਹਾਇਕ ਨੂੰ ਟੈਸਟ ਲਿਖਣ ਵਿੱਚ ਮਦਦ ਲਈ ਕਹਿੰਦੇ ਹੋ, ਇਹ ਕੁਦਰਤੀ ਤੌਰ 'ਤੇ ਤੁਹਾਨੂੰ ਵਿਸਥਾਰ ਵੱਲ ਧਕਦਾ ਹੈ। “ਇਸਨੂੰ ਲਚਕੀਲਾ ਬਣਾਓ” ਦੀ ਥਾਂ, ਤੁਸੀਂ ਪ੍ਰਾਂਪਟਾਂ ਨੂੰ ਇਸ ਤਰ੍ਹਾਂ ਮਿਲਦੇ ਹੋ: ਇਸ ਫੰਕਸ਼ਨ ਦਾ ਨਤੀਜਾ ਖਾਲੀ ਲਿਸਟ 'ਤੇ ਕੀ ਹੁੰਦਾ? ਵੱਧ ਤੋਂ ਵੱਧ ਮਨਜੂਰ ਕੀਤੀ ਗਈ ਕੀਮਤ ਕੀ ਹੈ? ਅਣਵੈਧ ਸਥਿਤੀ ਕੀਵੇਂ ਦਰਸਾਈਏ?

ਇਹ ਪੁੱਛਤਾਛ ਮਹੱਤਵਪੂਰਨ ਹੈ ਕਿਉਂਕਿ ਇਹ ਏਜ ਕੇਸਾਂ ਨੂੰ ਜਲਦੀ ਖੋਜ ਲੈਂਦੀ ਹੈ, ਜਦੋਂ ਤੁਸੀਂ ਅਜੇ ਵੀ ਨਿਰਧਾਰਤ ਕਰ ਰਹੇ ਹੋ ਕਿ ਫੀਚਰ ਨੂੰ ਅਸਲ ਵਿੱਚ ਕੀ ਚਾਹੀਦਾ ਹੈ। ਜੇ ਉਹ ਏਜ ਕੇਸ ਦੁਰਲਭ ਜਾਂ ਦਾਇਰੇ ਤੋਂ ਬਾਹਰ ਹਨ, ਤੁਸੀਂ ਉਨ੍ਹਾਂ ਨੂੰ ਦਸਤਾਵੇਜ਼ ਕਰ ਸਕਦੇ ਹੋ ਅਤੇ ਅੱਗੇ ਵਧ ਸਕਦੇ ਹੋ—ਬਿਨਾਂ “ਜਰੂਰਤ ਲਈ” ਅਬਸਟ੍ਰੈਕਸ਼ਨ ਬਣਾਉਣ ਦੇ।

ਪਹਿਲਾਂ ਟੈਸਟ ਲਿਖਣਾ ਦਿਖਾਉਂਦਾ ਹੈ ਕਿ ਅਬਸਟ੍ਰੈਕਸ਼ਨ ਦੀ ਲੋੜ ਹੈ ਜਾਂ ਨਹੀਂ

ਅਬਸਟ੍ਰੈਕਸ਼ਨ ਆਪਣੀ ਕਦਰ ਉਸ ਵੇਲੇ ਕਮਾਉਂਦਾ ਹੈ ਜਦੋਂ ਕਈ ਟੈਸਟ ਇੱਕੋ ਜਿਹੇ ਸੈਟਅਪ ਜਾਂ ਵਿਵਹਾਰ ਨੂੰ ਸਾਂਝਾ ਕਰਦੇ ਹਨ। ਜੇ ਤੁਹਾਡੇ ਟੈਸਟ ਸੂਟ ਵਿੱਚ ਸਿਰਫ਼ ਇੱਕ ਜਾਂ ਦੋ ਸਪਸ਼ਟ ਦ੍ਰਿਸ਼ ਹੋਣ, ਤਾਂ ਇੱਕ ਫਰੇਮਵਰਕ ਜਾਂ ਪਲੱਗਇਨ ਸਿਸਟਮ ਬਣਾਉਣਾ ਆਮ ਤੌਰ 'ਤੇ ਇਹ ਦਿਖਾਉਂਦਾ ਹੈ ਕਿ ਤੁਸੀਂ ਕਲਪਿਤ ਭਵਿੱਖ ਲਈ ਆਪਟਿਮਾਈਜ਼ ਕਰ ਰਹੇ ਹੋ।

ਇੱਕ ਸਧਾਰਨ ਨਿਯਮ: ਜੇ ਤੁਸੀਂ ਇੱਕ ਜਨਰਲਾਈਜ਼ਡ ਇੰਟਰਫੇਸ ਲਈ ਘੱਟੋ-ਘੱਟ ਤਿੰਨ ਵੱਖ-ਵੱਖ ਵਿਵਹਾਰ ਨਹੀਂ ਦਰਸਾ ਸਕਦੇ, ਤਾਂ ਤੁਹਾਡੀ ਅਬਸਟ੍ਰੈਕਸ਼ਨ ਸੰਭਵਤ: ਪ੍ਰੀਮੈਚਰ ਹੈ।

ਪ੍ਰਯੋਗਿਕ ਟੈਸਟ ਕੇਸਾਂ ਲਈ ਇੱਕ ਛੋਟਾ ਟੈਂਪਲੇਟ

ਅਮਲ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਇਸ ਹਲਕੇ ਢਾਂਚੇ ਦੀ ਵਰਤੋਂ ਕਰੋ:

• ਖ਼ੁਸ਼ੀ ਰਸਤਾ: ਆਮ ਇਨਪੁਟ → ਉਮੀਦਿਤ ਆਉਟਪੁੱਟ।
• ਸੀਮਾ: ਘੱਟੋ-ਘੱਟ/ਵੱਧ ਤੋਂ ਵੱਧ ਮੁੱਲ, ਖਾਲੀ ਕਲੈਕਸ਼ਨ, ਸੀਮਾਵਾਂ (ਉਦਾਹਰਣ ਲਈ, 0, 1, 1000)।
• ਫੇਲਿਅਰ: ਅਣਵੈਧ ਇਨਪੁਟ, ਘੱਟ ਰਹਿ ਜਾਣ ਵਾਲੀਆਂ ਡਿਪੈਂਡੇਨਸੀਆਂ, ਟਾਈਮਆਉਟ, ਅਨੁਮਤੀ ਤਰੁੱਟੀਆਂ → ਉਮੀਦਿਤ ਐਰਰ ਜਾਂ ਫਾਲਬੈਕ ਵਿਹਾਰ।

ਇਹ ਲਿਖੇ ਜਾਣ 'ਤੇ, ਕੋਡ ਅਕਸਰ ਸਧਾਰਨ ਹੋਣਾ ਚਾਹੇਗਾ। ਜੇ ਕਈ ਟੈਸਟਾਂ ਵਿੱਚ ਦੁਹਰਾਈ ਦਿੱਸਦੀ ਹੈ, ਤਾਂ ਇਹ ਤੁਹਾਡੇ ਲਈ ਸੁਨੇਹਾ ਹੈ ਕਿ ਰੀਫੈਕਟਰ ਕਰੋ—ਨਹੀਂ ਕਿ ਸ਼ੁਰੂ ਤੋਂ ਇੱਕ ਫਰੇਮਵਰਕ ਬਣਾਓ।

ਵਿਜ਼ਿਬਲ ਰਖ-ਰਖਾਵ ਲਾਗਤਾਂ ਅਤਿ-ਇੰਜੀਨੀਅਰਿੰਗ ਨੂੰ ਰੋਕਦੀਆਂ ਹਨ

ਅਤਿ-ਇੰਜੀਨੀਅਰਿੰਗ ਆਮ ਤੌਰ 'ਤੇ ਚੰਗੀਆਂ ਨੀਤੀਆਂ ਦੇ ਪਿੱਛੇ ਛੁਪ ਜਾਂਦੀ ਹੈ: “ਸਾਨੂੰ ਇਹ ਭਵਿੱਖ ਵਿੱਚ ਲੋੜ ਹੋ ਸਕਦੀ ਹੈ।” ਸਮੱਸਿਆ ਇਹ ਹੈ ਕਿ ਅਬਸਟ੍ਰੈਕਸ਼ਨਾਂ ਦੀ ਚਲਦੀ ਰਹਿਣ ਵਾਲੀ ਲਾਗਤ ਸ਼ੁਰੂਆਤੀ ਟਿਕਟ ਵਿੱਚ ਨਹੀਂ ਦਿਖਦੀ।

ਇੱਕ ਅਬਸਟ੍ਰੈਕਸ਼ਨ ਦੀ ਅਸਲ ਬਿੱਲ

ਤੁਸੀਂ ਜੋ ਵੀ ਨਵੀਂ ਪਰਤ ਸ਼ਾਮਲ ਕਰਦੇ ਹੋ, ਅਕਸਰ ਇਹ ਮੁੜ-ਮੁੜ ਕੰਮ ਬਣਾਉਂਦੀ ਹੈ:

• API ਸਤਹ: ਹੋਰ ਮੈਥਡ, ਪੈਰਾਮੀਟਰ, ਅਤੇ ਏਜ ਕੇਸ ਜੋ ਸਪੋਰਟ ਕਰਨੇ ਹਨ (ਅਤੇ ਪਿਛਲੀ-ਅਨੁਕੂਲ ਰਹਿਣੇ ਹਨ)।
• ਦਸਤਾਵੇਜ਼ ਅਤੇ ਉਦਾਹਰਣਾਂ: ਹੋਰਾਂ ਨੂੰ ਔਨਬੋਰਡ ਕਰਨ ਲਈ abstractions ਨੂੰ ਸਮਝਾਉਣਾ।
• ਮਾਈਗ੍ਰੇਸ਼ਨ: ਜਦੋਂ ਹੋਰ ਕੋਡ ਜਨਰਲ ਇੰਟਰਫੇਸ 'ਤੇ ਨਿਰਭਰ ਹੋ ਜਾਂਦਾ ਹੈ, ਇਸਨੂੰ ਬਦਲਣਾ ਐਡੈਪਟਰ, ਡਿਪ੍ਰੀਕੇਸ਼ਨ, ਅਤੇ ਰਿਲੀਜ਼ ਨੋਟਾਂ ਦੀ ਲੋੜ ਪੈਦਾ ਕਰਦਾ ਹੈ।
• ਟੈਸਟਿੰਗ ਮਹਾਮੇਲ: “ਜਨਰਿਕ” ਕੋਡ ਦ੍ਰਿਸ਼ਾਂ ਦਾ ਵਿਰਤਨ ਵਧਾਉਂਦਾ ਹੈ—ਕਈ ਲਾਗੂਕਰਨ, ਹੋਰ ਮੌਕ, ਹੋਰ ਇੰਟੀਗ੍ਰੇਸ਼ਨ ਪਾਇੰਟ।

AI-ਚਲਾਏ ਵਰਕਫਲੋ ਇਹਨਾਂ ਲਾਗਤਾਂ ਨੂੰ ਨਜ਼ਰਅੰਦਾਜ਼ ਕਰਨਾ ਔਖਾ ਬਣਾਉਂਦੇ ਹਨ ਕਿਉਂਕਿ ਉਹ ਤੇਜ਼ੀ ਨਾਲ ਤੁਹਾਨੂੰ ਦੱਸ ਸਕਦੇ ਹਨ ਕਿ ਤੁਸੀਂ ਕੀ ਮੁਹੱਈਆ ਕਰ ਰਹੇ ਹੋ।

ਜਟਿਲਤਾ ਦਾ ਅੰਦਾਜ਼ਾ ਲਗਾਉਣ ਲਈ AI ਦੀ ਵਰਤੋਂ: ਮੂਵਿੰਗ ਪਾਰਟਸ ਦੀ ਗਿਣਤੀ

ਇੱਕ ਕਾਰਗਰ ਪ੍ਰਾਂਪਟ ਇਹ ਹੈ: “ਇਸ ਡਿਜ਼ਾਈਨ ਨਾਲ ਨਵੇਂ ਮੂਵਿੰਗ ਹਿੱਸੇ ਅਤੇ ਡਿਪੈਂਡੇਨਸੀਆਂ ਦੀ ਸੂਚੀ ਦਿਓ।” ਇੱਕ ਚੰਗਾ AI ਸਹਾਇਕ ਯੋਜਨਾ ਨੂੰ ਇਹਨਾਂ ਵਸਤਾਂ 'ਚ ਤੋੜ ਸਕਦਾ ਹੈ:

• ਨਵੇਂ ਮੋਡੀਊਲ/ਪੈਕੇਜ
• ਪਬਲਿਕ ਇੰਟਰਫੇਸ ਅਤੇ ਵਰਜ਼ਨਿੰਗ ਉਮੀਦਾਂ
• ਡੇਟਾਬੇਸ ਸਕੀਮਾ ਬਦਲਾਅ ਅਤੇ ਮਾਈਗ੍ਰੇਸ਼ਨ ਕਦਮ
• ਸਰਵਿਸ-ਟੂ-ਸਰਵਿਸ ਕਾਲ ਅਤੇ ਫੇਲਿਯਰ ਮੋਡ
• ਨਵੇਂ ਸੰਰਚਨਾ ਫ਼ਲੈਗ, ਅਨੁਮਤੀਆਂ, ਜਾਂ ਕਿਊਜ਼

ਉਸ ਸੂਚੀ ਨੂੰ ਸਧਾਰਨ ਇੰਪਲੀਮੈਂਟੇਸ਼ਨ ਨਾਲ ਪਾਸੇ-ਪਾਸੇ ਰੱਖਣ ਨਾਲ “ਸਾਫ਼ ਆਰਕੀਟੈਕਚਰ” ਵਾਲੇ ਦਲੀਲਾਂ ਨੂੰ ਇੱਕ ਸਪਸ਼ਟ ਟਰੇਡ-ਆਫ਼ ਵਿੱਚ ਬਦਲ ਦਿੰਦਾ ਹੈ: ਕੀ ਤੁਸੀਂ ਅੱਠ ਨਵੇਂ ਸੰਕਲਪਾਂ ਨੂੰ ਰੱਖਣਾ ਚਾਹੁੰਦੇ ਹੋ ਸਿਰਫ਼ ਇੱਕ ਨਕਲ ਨੂੰ ਬਚਾਉਣ ਲਈ ਜੋ ਹੋ ਸਕਦਾ ਹੈ ਕਿ ਕਦੇ ਨਹੀਂ ਆਏ?

ਕੰਮ ਨੂੰ ਇਮਾਨਦਾਰ ਰੱਖਣ ਲਈ ਇੱਕ “ਜਟਿਲਤਾ ਬਜਟ”

ਇੱਕ ਹਲਕਾ ਨੀਤੀ: ਹਰ ਫੀਚਰ ਪ੍ਰਤੀ ਨਵੀਆਂ ਸੰਕਲਪਾਂ ਦੀ ਗਿਣਤੀ 'ਤੇ ਸੀਮਾ ਲਗਾਓ। ਉਦਾਹਰਨ ਵਜੋਂ, 허ਮਦੇ ਦੀਆਂ ਹੱਦਾਂ ਰੱਖੋ:

• 1 ਨਵਾਂ ਪਬਲਿਕ API
• 1 ਨਵੀਂ ਸਾਂਝੀ ਅਬਸਟ੍ਰੈਕਸ਼ਨ (ਇੰਟਰਫੇਸ/ਬੇਸ ਕਲਾਸ)
• 1 ਨਵਾਂ ਡੇਟਾ ਮਾਡਲ/ਟੇਬਲ

ਜੇ ਫੀਚਰ ਇਸ ਬੱਜਟ ਤੋਂ ਬਾਹਰ ਜਾਏ, ਤਾਂ ਇੱਕ ਵਾਜਬੀਜ਼ਹ ਦੇਣ ਦੀ ਲੋੜ: ਇਹ ਕਿਹੜੇ ਭਵਿੱਖੀ ਬਦਲਾਅ ਨੂੰ ਯੋਗ ਕਰ ਰਿਹਾ ਹੈ, ਅਤੇ ਤੁਹਾਡੇ ਕੋਲ ਕਿਹੜੇ ਸਬੂਤ ਹਨ ਕਿ ਇਹ ਨਜ਼ਦੀਕ ਹਨ? AI ਇਸ ਤਰ੍ਹਾਂ ਦੀ ਵਜਹ ਤਿਆਰ ਕਰਨ (ਅਤੇ ਰਖ-ਰਖਾਵ ਕੰਮਾਂ ਦੀ ਭਵਿੱਖਬਾਣੀ) ਵਿੱਚ ਮਦਦ ਕਰਦਾ ਹੈ, ਅਤੇ ਟੀਮਾਂ ਛੋਟੇ, ਉਲਟਣਯੋਗ ਕਦਮ ਚੁਣਨ ਲਈ ਰੁਝਾਨ ਰੱਖਦੀਆਂ ਹਨ—ਕਿਉਂਕਿ ਲਗਾਤਾਰ ਲਾਗਤਾਂ ਕੋਡ ਜਮ੍ਹਾਂ ਹੋਣ ਤੋਂ ਪਹਿਲਾਂ ਦਿਖਾਈ ਦਿੰਦੀਆਂ ਹਨ।

ਜਦੋਂ AI ਤੁਹਾਨੂੰ ਗਲਤ ਦਿਸ਼ਾ ਵਿੱਚ ਧਕੇਲ ਸਕਦਾ ਹੈ (ਅਤੇ ਕਿਵੇਂ ਰੋਕਣਾ)

AI-ਚਲਾਏ ਵਰਕਫਲੋ ਅਕਸਰ ਟੀਮਾਂ ਨੂੰ ਛੋਟੇ, ਟੈਸਟ ਕਰਨ ਯੋਗ ਕਦਮਾਂ ਵੱਲ ਧਕੇਲਦੇ ਹਨ—ਪਰ ਇਹ ਵਿਰੁੱਧ ਵੀ ਕਰ ਸਕਦੇ ਹਨ। ਕਿਉਂਕਿ AI ਤੇਜ਼ੀ ਨਾਲ “ਸੰਪੂਰਨ” ਹੱਲ ਤਿਆਰ ਕਰਨ ਵਿੱਚ ਮਹਿਰਤ ਹੈ, ਇਹ ਸਮਰੱਥਾ ਨਾਲ ਜਾਣ-ਮਨਕੇ ਪਰਚੀਆਂ, ਵਾਧੂ ਢਾਂਚੇ, ਜਾਂ scaffolding ਬਣਾ ਸਕਦਾ ਹੈ ਜੋ ਤੁਸੀਂ ਮੰਗੇ ਨਹੀਂ। ਨਤੀਜਾ ਹੋ ਸਕਦਾ ਹੈ ਕਿ ਜ਼ਿਆਦਾ ਕੋਡ ਬਣ ਜਾਵੇ, ਜ਼ਰੂਰਤ ਤੋਂ ਪਹਿਲਾਂ।

AI ਕਿਵੇਂ ਐਨ-ਅਤੇ-ਗਲਤੀ ਤੌਰ 'ਤੇ ਅਤਿ-ਇੰਜੀਨੀਅਰਿੰਗ ਨੂੰ ਉਤਸ਼ਾਹਿਤ ਕਰਦਾ ਹੈ

ਮਾਡਲ ਨੂੰ ਅਕਸਰ ਮਨੁੱਖੀ ਧਾਰਨਾ ਦੁਆਰਾ ਪੁਰਸਕਾਰ ਦਿੱਤਾ ਜਾਂਦਾ ਹੈ ਜੇ ਇਹ ਵਿਸਥਾਰਭਰੇ ਦਿਸਦਾ ਹੈ। ਇਹ ਵਾਧੂ ਪਰਤਾਂ, ਹੋਰ ਫਾਈਲਾਂ, ਅਤੇ ਜਨਰਲ ਡਿਜ਼ਾਈਨ ਜੋੜ ਸਕਦਾ ਹੈ ਜੋ ਪੇਸ਼ੇਵਰ ਲੱਗਦੇ ਹਨ ਪਰ ਨਾ ਹੀ ਮੌਜੂਦਾ ਸਮੱਸਿਆ ਨੂੰ ਹੱਲ ਕਰ ਰਹੇ ਹਨ।

ਆਮ ਚੇਤਾਵਨੀ ਨਿਸ਼ਾਨੀਆਂ ਵਿੱਚ ಶਾਮਲ ਹਨ:

• ਕਿਸੇ ठोस ਵਰਤੀਗੰਨ ਦੀ ਬਿਨਾਂ ਨਵੀਆਂ ਅਬਸਟ੍ਰੈਕਸ਼ਨ (ਉਦਾਹਰਣ: “ਭਵਿੱਖ ਦੀ ਲਚਕ ਲਈ”)
• ਵਾਧੂ ਪਰਤਾਂ: service → manager → adapter → factory, ਜਦੋਂ ਇੱਕ ਫੰਕਸ਼ਨ ਕਾਫ਼ੀ ਹੋਵੇ
• ਸਿਰਫ਼ ਇੱਕ ਲਾਗੂਕਰਨ ਵਾਲੇ ਜਨਰਿਕ ਇੰਟਰਫੇਸ
• ਪਲੱਗਇਨ ਸਿਸਟਮ, ਇਵੈਂਟ ਬਸ, ਜਾਂ ਡਿਪੈਂਡੈਂਸੀ-ਇੰਜੈਕਸ਼ਨ ਸੈੱਟਅਪ ਅਰੰਭ ਵਿੱਚ ਜੋੜੇ ਜਾਣੇ
• ਇੱਕ “ਫਰੇਮਵਰਕ ਅੰਦਰ ਫਰੇਮਵਰਕ” ਬਣਾਉਣਾ ਤਾਂ ਜੋ ਕਿਸੇ ਚੀਜ਼ ਨੂੰ standardize ਕੀਤਾ ਜਾਵੇ ਜੋ ਤੁਸੀਂ ਹਜੇ ਤੱਕ ਦੁਹਰਾਇਆ ਨਹੀਂ

AI ਆਉਟਪੁਟ ਨੂੰ ਜ਼ਮੀਨੀ ਰੱਖਣ ਵਾਲੀਆਂ ਰੋਕਥਾਮਾਂ

AI ਨੂੰ ਇੱਕ ਤੇਜ਼ ਦੋਸਤਾਨ ਹੱਥ ਸਮਝੋ, ਨਾ ਕਿ ਇੱਕ ਆਰਕੀਟੈਕਚਰ ਕਮੇਟੀ। ਕੁਝ ਰੋਕ-ਤੋੜ ਬਹੁਤ ਫਾਇਦਾ ਦਿੰਦੇ ਹਨ:

• ਪ੍ਰਾਂਪਟਾਂ ਨੂੰ ਮੌਜੂਦ ਸਮੇਂ ਤੱਕ ਸੀਮਿਤ ਕਰੋ। ਕੇਵਲ ਉਸ ਸਭ ਤੋਂ ਛੋਟੇ ਬਦਲਾਅ ਲਈ ਪੁੱਛੋ ਜੋ ਅੱਜ ਲੋੜ ਹੈ, ਅਤੇ ਨਵੇਂ ਪੈਟਰਨ ਨੂੰ ਮਨਜ਼ੂਰ ਨਾ ਕਰੋ ਜਦ ਤੱਕ ਜ਼ਰੂਰੀ ਨਾ ਹੋਵੇ।
• ਅਸਲ ਉਦਾਹਰਣ ਲਾਜ਼ਮੀ ਕਰੋ। ਇੱਕ ਅਬਸਟ੍ਰੈਕਸ਼ਨ ਸਵੀਕਾਰ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ 2–3 ਠੋਸ ਕਾਲਸਾਈਟ ਜਾਂ ਯੂਜ਼ਰ ਫਲੋ ਮੰਗੋ ਅਤੇ ਯਕੀਨੀ ਬਣਾਓ ਕਿ ਅਬਸਟ੍ਰੈਕਸ਼ਨ ਉਨ੍ਹਾਂ ਨੂੰ ਸਧਾਰਨ ਕਰਦਾ ਹੈ।
• ਹਰ ਇਟਰੈਸ਼ਨ 'ਤੇ ਆਰਕੀਟੈਕਚਰ ਚੇਨਜ ਦੀ ਸੀਮਾ ਰੱਖੋ। ਇੱਕ ਵਾਰ ਵਿੱਚ ਕੇਵਲ ਇੱਕ ਰਚਨਾਤਮਕ ਬਦਲਾਅ ਦੀ ਇਜਾਜ਼ਤ ਦਿਓ (ਉਦਾਹਰਣ: “ਇੱਕ ਨਵਾਂ ਮੋਡੀਊਲ ਜੋੜੋ” ਜਾਂ “ਇਸ PR ਵਿੱਚ ਕੋਈ ਨਵੀਂ ਪਰਤ ਨਹੀਂ”)।
• ਹਟਾਉਣਯੋਗਤਾ ਲਈ ਸਮੀਖਿਆ ਕਰੋ। ਜੇ ਨਵੀਂ ਪਰਤ ਹਟਾਉਣ 'ਤੇ ਵਿਹਾਰ 'ਚ ਬਹੁਤ ਘੱਟ ਬਦਲਾਅ ਆਉਂਦਾ, ਤਾਂ ਇਹ ਸੰਭਵਤ: ਕਮਾਈ ਨਹੀਂ ਕੀਤੀ।

ਇੱਕ ਸਧਾਰਨ ਨਿਯਮ: AI ਨੂੰ ਜਨਰਲਾਈਜ਼ ਕਰਨ ਨਾ ਦਿਓ ਜਦ ਤੱਕ ਤੁਹਾਡੀ ਕੋਡਬੇਸ ਵਿੱਚ ਦੁਹਰਾਇਆ ਦਰਦ ਨਾ ਹੋਵੇ।

ਇੱਕ ਪ੍ਰਾਇਕਟਿਕਲ ਫੈਸਲਾ ਫਰੇਮਵਰਕ: ਪਹਿਲਾਂ ਬਣਾਓ, ਫਿਰ ਅਬਸਟ੍ਰੈਕਟ ਕਰੋ

AI ਕੋਡ ਜਨਰੇਟ ਕਰਨ, ਰੀਫੈਕਟਰ ਕਰਨ, ਅਤੇ ਵਿਕਲਪ ਅਜ਼ਮਾਉਣ ਨੂੰ ਸਸਤਾ ਬਣਾਉਂਦਾ ਹੈ। ਇਹ ਇੱਕ ਤੋਹਫ਼ਾ ਹੈ—ਜੇ ਤੁਸੀਂ ਇਸ ਨੂੰ ਇਸਤੇਮਾਲ ਕਰਕੇ ਅਬਸਟ੍ਰੈਕਸ਼ਨ ਨੂੰ ਰੋਕ ਸਕਦੇ ਹੋ ਜਦ ਤੱਕ ਉਹ ਆਪਣੀ ਕਦਰ ਨਾ ਕਮਾ ਲੇ।

ਕਦਮ 1: ਠੋਸ ਨਾਲ ਸ਼ੁਰੂ ਕਰੋ (ਸਿੱਖਣ ਲਈ ਢਾਲੂ)

ਅੱਜ ਦੀ ਸਮੱਸਿਆ ਹੱਲ ਕਰਨ ਵਾਲੀ ਸਭ ਤੋਂ ਸਧਾਰਨ ਸੰਸਕਰਣ ਨਾਲ ਸ਼ੁਰੂ ਕਰੋ। ਨਾਮ ਰੱਖੋ ਸਿੱਧੇ-ਸਧੇ ਉਸ ਦੇ ਕੰਮ ਦੇ ਨਾਂ ਤੇ (ਨਾ ਕਿ ਜੋ ਇਹ ਭਵਿੱਖ ਵਿੱਚ ਕਰ ਸਕਦਾ ਹੈ), ਅਤੇ APIs ਨੂੰ ਤੰਗ ਰੱਖੋ। ਜੇ ਤੁਸੀਂ ਇਹ ਨਿਸ਼ਚਿਤ ਨਹੀਂ ਕਿ ਕੋਈ ਪੈਰਾਮੀਟਰ, ਇੰਟਰਫੇਸ, ਜਾਂ ਪਲੱਗਇਨ ਸਿਸਟਮ ਲੋੜੀਂਦਾ ਹੈ, ਤਾਂ ਬਿਨਾਂ ਉਸਦੇ ਸ਼ਿਪ ਕਰੋ।

ਹੇਠਾਂ ਇੱਕ ਫ਼ਾਇਦਾਕਾਰ ਨਿਯਮ: ਅਨੁਮਾਨ ਉੱਤੇ ਦੁਹਰਾਅ ਨਾਲੋਂ ਨਕਲ ਨੂੰ ਤਰਜੀਹ ਦਿਓ। ਨਕਲ ਕੋਡ ਦਿੱਖ ਵਿੱਚ ਸਪਸ਼ਟ ਅਤੇ ਹਟਾਉਣ ਵਿੱਚ ਆਸਾਨ ਹੁੰਦਾ ਹੈ; ਕਲਪਿਤ ਜਨਰਲਤਾ ਇੰਡੀਰੈਕਸ਼ਨ ਵਿੱਚ ਜਟਿਲਤਾ ਚੁਪ ਕਰ ਦਿੰਦੀ ਹੈ।

ਕਦਮ 2: ਬਾਅਦ ਵਿੱਚ ਕੱਢੋ (ਸਥਿਰਤਾ ਲਈ ਢਾਲੂ)

ਜਦੋਂ ਫੀਚਰ ਵਰਤਿਆ ਜਾ ਰਿਹਾ ਹੋਵੇ ਅਤੇ ਬਦਲ ਰਿਹਾ ਹੋਵੇ, ਤਰਕ ਨੂੰ ਧਿਆਨ ਵਿੱਚ ਰੱਖ ਕੇ ਰੀਫੈਕਟਰ ਕਰੋ। AI ਦੀ ਮਦਦ ਨਾਲ, ਤੁਸੀਂ ਇਹ ਤੇਜ਼ੀ ਨਾਲ ਕਰ ਸਕਦੇ ਹੋ: ਇਸਨੂੰ ਪੁੱਛੋ ਕਿ ਇੱਕ extraction ਸੁਝਾਅ ਦਿਓ, ਪਰ ਘੱਟੋ-ਘੱਟ diff ਅਤੇ ਪਾਠਨਯੋਗ ਨਾਂ ਦੀ ਮੰਗ ਕਰੋ।

ਜੇ ਤੁਹਾਡੀ ਟੂਲੀੰਗ ਇਸਨੂੰ ਸਹਾਇਕ ਕਰਦੀ ਹੈ, ਤਾਂ ਉਹ ਸੇਫਟੀ ਨੈੱਟ ਵਰਤੋ ਜੋ ਰੀਫੈਕਟਰ ਨੂੰ ਘੱਟ-ਜੋਖਮ ਬਣਾਉਂਦੇ ਹਨ। ਉਦਾਹਰਨ ਲਈ, Koder.ai ਦੇ snapshots ਅਤੇ rollback ਤੁਹਾਨੂੰ ਰੀਫੈਕਟਰੇਸ਼ਨਾਂ ਨਾਲ ਬੇਫਿਕਰ ਪ੍ਰਯੋਗ ਕਰਨ ਦੀ ਸਮਰੱਥਾ ਦਿੰਦੇ ਹਨ, ਕਿਉਂਕਿ ਤੁਸੀਂ ਜਲਦੀ ਵਾਪਸ ਆ ਸਕਦੇ ਹੋ ਜੇ “ਸਾਫ” ਡਿਜ਼ਾਈਨ ਅਮਲ ਵਿੱਚ ਖਰਾਬ ਨਿਕਲਦਾ ਹੈ।

ਕਦੋਂ ਅਬਸਟ੍ਰੈਕਸ਼ਨ ਵਾਜਬ ਹੁੰਦੀ ਹੈ (ਇੱਕ ਛੋਟਾ ਚੈੱਕਲਿਸਟ)

ਅਬਸਟ੍ਰੈਕਸ਼ਨ ਆਪਣੀ ਕਦਰ ਕਮਾਉਂਦੀ ਹੈ ਜਦੋਂ ਜਿਆਦਾਤਰ ਇਹ ਗੱਲਾਂ ਸਹੀ ਹੁੰਦੀਆਂ ਹਨ:

• ਦੁਹਰਾਇਆ ਲੌਜਿਕ: ਇੱਕੋ ਹੀ ਵਿਵਹਾਰ 2–3 ਥਾਵਾਂ ਤੇ ਮੌਜੂਦ ਹੈ, ਅਤੇ ਅੱਪਡੇਟਾਂ ਨੇ ਪਹਿਲਾਂ ਕਈ ਸੋਧਾਂ ਦੀ ਲੋੜ ਪੈਦੀ ਕੀਤੀ ਹੈ।
• ਸਾਬਤ ਵੱਖਰਾ-ਵੋਲਾ: ਤੁਸੀਂ ਪ੍ਰੋਡਕਸ਼ਨ ਜਾਂ ਮਨਜ਼ੂਰ ਕੀਤਾ ਗਿਆ ਪ੍ਰੋਟੋਟਾਈਪ ਵਿੱਚ ਅਸਲ ਵੱਖਰਾਂ ਦੇਖ ਚੁੱਕੇ ਹੋ ("ਕਦੇ-ਭਵਿੱਖ" ਦੀ ਥਾਂ)।
• ਸਪੱਸ਼ਟ ਮਲਕੀਅਤ: ਇੱਕ ਵਿਅਕਤੀ/ਟੀਮ ਅਬਸਟ੍ਰੈਕਸ਼ਨ, ਉਸ ਦੀ ਡੌਕਸ, ਅਤੇ ਭਵਿੱਖੀ ਬਦਲਾਅ ਦੀ ਧਾਰਣਾ ਰੱਖਦੀ ਹੈ।
• ਸਥਿਰ ਬਾਊਂਡਰੀ: ਇਨਪੁਟ/ਆਉਟਪੁਟ ਆਕਾਰ ਕਈ ਇਟਰੇਸ਼ਨਾਂ 'ਤੇ ਸਥਿਰ ਰਹਿ ਚੁੱਕਾ ਹੈ।
• ਕੁੱਲ ਸਧਾਰਨ: ਐਕਸਟ੍ਰੈਕਸ਼ਨ ਕੁੱਲ ਕੋਡ ਅਤੇ ਸੰਜੀਵਨੀ ਭਾਰ ਘਟਾਉਂਦਾ ਹੈ, ਸਿਰਫ਼ ਉਸਨੂੰ ਦੁਬਾਰਾ ਸੁਤਰ ਕਰਨ ਦੀ ਥਾਂ।

ਇੱਕ ਸਾਦਾ ਰਿਵਾਜ: “ਇੱਕ ਹਫ਼ਤਾ ਬਾਅਦ” ਸਮੀਖਿਆ

ਫੀਚਰ ਸ਼ਿਪ ਹੋਣ ਤੋਂ ਇੱਕ ਹਫ਼ਤਾ ਬਾਅਦ ਇੱਕ ਕੈਲੰਡਰ ਯਾਦ ਦਿਓ:

1. diff ਮੁੜ ਖੋਲ੍ਹੋ ਅਤੇ ਲਿਖੋ ਕਿ ਰਿਲੀਜ਼ ਤੋਂ ਬਾਅਦ ਕੀ ਬਦਲਾ ਹੈ।
2. ਕਿਸੇ ਵੀ copy-paste ਸੋਧਾਂ ਜਾਂ ਦੁਹਰਾਏ ਬੱਗਾਂ ਦੀ ਪਛਾਣ ਕਰੋ।
3. ਤਿੰਨ ਨਤੀਜਿਆਂ ਵਿੱਚੋਂ ਇੱਕ ਨੂੰ ਚੁਣੋ: ਸੰਕੁਚਿਤ ਰੱਖੋ, ਛੋਟਾ ਹੈਲਪਰ ਕੱਢੋ, ਜਾਂ ਸਾਂਝਾ ਮੋਡੀਊਲ ਲਿਆਓ।

ਇਸ ਨਾਲ ਡਿਫੌਲਟ ਦ੍ਰਿਸ਼ਟਿਕੋਣ ਬਦਲਦਾ ਹੈ: ਪਹਿਲਾਂ ਬਣਾਓ, ਫਿਰ ਜ਼ਮੀਨ ਤੇ ਆ ਕੇ ਜਨਰਲਾਈਜ਼ ਕਰੋ ਜਦੋਂ ਹਕੀਕਤ ਤੁਹਾਨੂੰ ਮਜ਼ਬੂਰ ਕਰੇ।

ਕੀ ਮਾਪਣਾ ਹੈ ਤਾਂ ਜੋ ਇੰਜੀਨੀਅਰਿੰਗ ਲੀਨ ਰਹੇ

Lean engineering ਇੱਕ ਅਹਿਸਾਸ ਨਹੀਂ—ਇਹ ਕੁਝ ਜਿਹੜਾ ਤੁਸੀਂ ਨਿਰੀਖ ਸਕਦੇ ਹੋ। AI-ਚਲਾਏ ਵਰਕਫਲੋ ਛੋਟੇ ਬਦਲਾਅ ਤੇਜ਼ੀ ਨਾਲ ਸ਼ਿਪ ਕਰਨ ਨੂੰ ਆਸਾਨ ਬਣਾਉਂਦੇ ਹਨ, ਪਰ ਤੁਹਾਨੂੰ ਕੁਝ ਸੰਗੀਤਕ ਸੰਕੇਤਾਂ ਦੀ ਲੋੜ ਹੈ ਤਾਂ ਜੋ ਟੀਮ ਫਿਰ ਤੋਂ ਕਲਪਿਤ ਡਿਜ਼ਾਈਨ ਵੱਲ ਨਾ ਮੁੜੇ।

ਕੁਝ ਮੈਟਰਿਕ ਜੋ ਜਲਦੀ ਅਤਿ-ਇੰਜੀਨੀਅਰਿੰਗ ਨੂੰ ਫੜ ਲੈਂਦੇ ਹਨ

ਚੰਦ ਬੇਲੋੜਾ ਇੰਡੀਕੇਟਰ ਟ੍ਰੈਕ ਕਰੋ ਜੋ অਰਥਹੀਨ ਅਬਸਟ੍ਰੈਕਸ਼ਨ ਨਾਲ ਸੰਬੰਧਿਤ ਹਨ:

• ਸਾਇਕਲ ਸਮਾਂ: “ਕੰਮ ਸ਼ੁਰੂ” ਤੋਂ “merged ਅਤੇ deployed” ਤੱਕ ਦਾ ਸਮਾਂ। ਜਦੋਂ ਸਾਇਕਲ ਸਮਾਂ ਬਿਨਾਂ ਵਿਸ਼ਾਲ ਸਕੋਪ ਵਧਦਾ ਹੈ, ਅਕਸਰ ਇਸਦਾ ਮਤਲਬ ਹੈ ਵਾਧੂ ਇੰਡਾਇਰੈਕਸ਼ਨ।
• ਡਿਫ਼ ਅਕਾਰ: ਦਰਮਿਆਨੀ ਲਾਈਨਾਂ ਬਦਲੇ/ਫਾਈਲਾਂ ਜੋ ਛੁਹੀਆਂ ਜਾਂਦੀਆਂ ਹਨ। ਵੱਡੇ diffs ਸਮੀਖਿਆ ਨੂੰ ਔਖਾ ਬਣਾਉਂਦੇ ਹਨ ਅਤੇ ਜਨਰਲਾਈਜ਼ਡ ਹੱਲਾਂ ਨੂੰ ਬੁਲੈਂਦੇ ਹਨ।
• ਨਵੀਆਂ ਸੰਕਲਪਾਂ ਦੀ ਗਿਣਤੀ: ਨਵੇਂ ਮੋਡੀਊਲ/ਸਰਵਿਸز/ਪੈਕੇਜ, ਨਵੀਆਂ ਇੰਟਰਫੇਸ, ਨਵੀਆਂ ਸੰਰਚਨਾ ਨੋਬਜ਼। ਸੰਕਲਪ ਇੱਕ ਸਦਾ-ਚੱਲਣ ਵਾਲਾ ਕਰ ਹੈ।
• ਡੈਫੈਕਟ ਦਰ: ਰਿਲੀਜ਼ ਪ੍ਰਤੀ ਪ੍ਰੋਡਕਸ਼ਨ ਬੱਗ ਜਾਂ ਸਹਾਇਤਾ ਟਿਕਟ। ਅਬਸਟ੍ਰੈਕਸ਼ਨਾਂ ਨਾਲ ਛੁਪੇ ਏਜ ਕੇਸ ਹੋ ਸਕਦੇ ਹਨ; “ਕਲਿਨਅੱਪ” ਕੰਮ ਤੋਂ ਬਾਅਦ ਚੜ੍ਹਦਾ ਦੋਸ਼ ਦਰ ਇੱਕ ਚੇਤਾਵਨੀ ਹੈ।
• ਔਨਬੋਰਡ ਕਰਨ ਦਾ ਸਮਾਂ: ਨਵੇਂ ਇੰਜੀਨੀਅਰ ਲਈ ਇੱਕ ਛੋਟਾ ਬਦਲਾਅ ਸ਼ਿਪ ਕਰਨ ਲਈ ਕਿੰਨਾ ਸਮਾਂ ਲੱਗਦਾ ਹੈ। ਜੇ ਔਨਬੋਰਡਿੰਗ ਢੀਰੀ ਹੋ ਜਾਂਦੀ ਹੈ, ਪ੍ਰਣਾਲੀ ਸੰਗੀਨਤਾ ਬਣਾ ਰਹੀ ਹੁੰਦੀ ਹੈ।

ਤੁਹਾਨੂੰ ਪੂਰਨਤਾ ਦੀ ਲੋੜ ਨਹੀਂ—ਟ੍ਰੈਂਡ ਲਾਈਨ ਕਾਫ਼ੀ ਹੁੰਦੇ ਹਨ। ਹਫ਼ਤੇਵਾਰ ਜਾਂ ਹਰ ਇਟਰੇਸ਼ਨ 'ਤੇ ਇਹਨਾਂ ਦੀ ਸਮੀਖਿਆ ਕਰੋ, ਅਤੇ ਪੁੱਛੋ: “ਕੀ ਅਸੀਂ ਉਤਪਾਦ ਦੀ ਲੋੜ ਤੋਂ ਵੱਧ ਨਵੇਂ ਸੰਕਲਪ ਜੋੜੇ?”

ਹਲਕੀ ਦਸਤਾਵੇਜ਼ੀਕਰਨ ਜੋ ਰਹੱਸਮਈ ਅਬਸਟ੍ਰੈਕਸ਼ਨਾਂ ਨੂੰ ਰੋਕਦੀ ਹੈ

ਜਦੋਂ ਵੀ ਕੋਈ ਨਵੀਂ ਅਬਸਟ੍ਰੈਕਸ਼ਨ (ਨਵਾਂ ਇੰਟਰਫੇਸ, ਹੈਲਪਰ ਲੇਅਰ, ਅੰਦਰੂਨੀ ਲਾਇਬ੍ਰੇਰੀ ਆਦਿ) ਪੇਸ਼ ਕੀਤੀ ਜਾਵੇ, ਇੱਕ ਛੋਟਾ “ਕਿਉਂ ਇਹ ਮੌਜੂਦ ਹੈ” ਨੋਟ ਲਾਜ਼ਮੀ ਰੱਖੋ। ਇਸਨੂੰ README ਜਾਂ ਐਂਟਰੀ ਪੌਇੰਟ ਨੇੜੇ ਇੱਕ ਟਿੱਪਣੀ ਵਜੋਂ ਰੱਖੋ:

• ਇਸਨੇ ਅੱਜ ਕਿਹੜੀ ठोस ਸਮੱਸਿਆ ਹੱਲ ਕੀਤੀ?
• ਕਿਹੜੇ ਵਿਕਲਪਾਂ ਦੀ ਕੋਸ਼ਿਸ਼ ਕੀਤੀ ਗਈ ਸੀ?
• ਇਸਨੂੰ ਹਟਾਉਣ ਲਈ ਕੀ ਸਾਬਤ ਹੋਣਾ ਚਾਹੀਦਾ?

ਸ਼ੁਰੂ ਕਰਨ ਲਈ ਕਾਰਵਾਈ ਯੋਜਨਾ

ਇੱਕ ਟੀਮ ਲਈ 2–4 ਹਫ਼ਤਿਆਂ ਲਈ ਇੱਕ ਛੋਟੇ AI-ਸਹਿਯੋਗੀ ਵਰਕਫਲੋ ਦਾ ਪਾਇਲਟ ਚਲਾਓ: AI-ਸਹਾਇਤ ਟਿਕਟ ਬ੍ਰੇਕਡਾਊਨ, AI-ਸਹਾਇਤ ਕੋਡ ਸਮੀਖਿਆ ਚੈੱਕਲਿਸਟ, ਅਤੇ AI-ਜਨਰੇਟ ਕੀਤੇ ਟੈਸਟ ਕੇਸ।

ਆਖਰ ਵਿੱਚ, ਉਪਰੋਕਤ ਮੈਟਰਿਕਾਂ ਦੀ ਤੁਲਨਾ ਕਰੋ ਅਤੇ ਇੱਕ ਛੋਟੀ ਰੇਟ੍ਰੋ ਕਰੋ: ਜੋ ਕੁਝ ਸਾਇਕਲ ਸਮਾਂ ਅਤੇ ਔਨਬੋਰਡਿੰਗ ਘਟਾਉਂਦਾ ਹੈ, ਉਸਨੂੰ ਰੱਖੋ; ਜੋ ਕੁਝ “ਨਵੀਆਂ ਸੰਕਲਪਾਂ” ਬਿਨਾਂ ਉਪਜਾਪੂਰਕ ਲਾਭ ਦੇ ਵਧਾਉਂਦਾ ਹੈ, ਉਸਨੂੰ ਵਾਪਸ ਲਓ।

ਜੇ ਤੁਸੀਂ ਇਸ ਪ੍ਰਯੋਗ ਨੂੰ ਐਂਡ-ਟੂ-ਐਂਡ ਚਲਾਉਣ ਲਈ ਪ੍ਰਯੋਗਸ਼ੀਲ ਮਹੋਲ ਲੱਭ ਰਹੇ ਹੋ, ਤਾਂ Koder.ai ਵਰਗਾ vibe-coding ਪਲੇਟਫਾਰਮ ਤੁਹਾਨੂੰ ਛੋਟੇ, ਠੋਸ ਸਲਾਈਸਾਂ ਨੂੰ ਤੇਜ਼ੀ ਨਾਲ ਡੀਪਲੋਏਬਲ ਐਪ ਵਿੱਚ ਬਦਲਣ ਵਿੱਚ ਮਦਦ ਕਰ ਸਕਦਾ ਹੈ (ਜਦੋਂ ਲੋੜ ਹੋਵੇ ਤਾਂ ਸੋర్స ਐਕਸਪੋਰਟ ਉਪਲੱਬਧ), ਜੋ ਇਸ ਲੇਖ ਦੇ ਮੁੱਖ ਸੰਦੇਸ਼ ਨੂੰ ਮਜ਼ਬੂਤ ਕਰਦਾ ਹੈ: ਕੁਝ ਅਸਲ ਸ਼ਿਪ ਕਰੋ, ਸਿੱਖੋ, ਅਤੇ ਫਿਰ ਹੀ ਅਬਸਟ੍ਰੈਕਟ ਕਰੋ।