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

ਪੂਰਵ-ਅਬਸਟ੍ਰੈਕਸ਼ਨ ਤਾਂ ਹੁੰਦੀ ਹੈ ਜਦੋਂ ਤੁਸੀਂ ਇੱਕ “ਸਧਾਰਨ ਸਮੱਸਿਆ” ਦੀ ਥਾਂ ਇੱਕ “ਸਾਮਾਨਤਾ ਵਾਲਾ ਹੱਲ” ਬਣਾ ਦਿੰਦੇ ਹੋ — ਇਸ ਤੋਂ ਪਹਿਲਾਂ ਕਿ ਤੁਸੀਂ ਕਾਫ਼ੀ ਅਸਲ ਮਾਮਲੇ ਵੇਖ ਲਈ ਹੋਵੇ ਕਿ ਕੀ ਵਾਕਈ ਸਮਾਨ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ।
ਆਕਸਰ ਅੱਜ ਦੀ ਸਮੱਸਿਆ ਨੂੰ ਹਲ ਕਰਨ ਵਾਲਾ ਸਭ ਤੋਂ ਸਧਾਰਨ ਕੋਡ ਲਿਖਣ ਦੀ ਥਾਂ, ਤੁਸੀਂ ਇੱਕ ਫਰੇਮਵਰਕ ਦੀ ਰਚਨਾ ਕਰ ਦਿੰਦੇ ਹੋ: ਵਾਧੂ ਇੰਟਰਫੇਸ, ਸੰਰਚਨਾ ਪ੍ਰਣਾਲੀਆ, ਪਲੱਗ-ਇਨ ਬਿੰਦੂ, ਜਾਂ ਰਿਊਜ਼ਬਲ ਮਾਡਿਊਲ — ਕਿਉਂਕਿ ਤੁਸੀਂ ਸੋਚਦੇ ਹੋ ਕਿ ਭਵਿੱਖ ਵਿੱਚ ਇਹ ਲੋੜ ਹੋਵੇਗੀ।
ਅਤਿ-ਇੰਜੀਨੀਅਰਿੰਗ ਇਸਦਾ ਵਿਆਪਕ ਰਵੱਈਆ ਹੈ। ਇਹ ਉਹ ਜਟਿਲਤਾ ਹੈ ਜੋ ਇਸ ਵੇਲੇ ਆਪਣੀ ਕਿਰਾਇਆ ਨਹੀਂ ਭਰ ਰਹੀ: ਵਾਧੂ ਪਰਤਾਂ, ਪੈਟਰਨ, ਸਰਵਿਸਜ਼, ਜਾਂ ਵਿਕਲਪ ਜੋ ਇਸ ਸਮੇਂ ਲਾਗਤ ਜਾਂ ਜੋਖਮ ਨੂੰ ਸਪੱਸ਼ਟ ਤੌਰ ਤੇ ਘਟਾਉਂਦੇ ਨਹੀਂ।
ਜੇ ਤੁਹਾਡੇ ਉਤਪਾਦ ਕੋਲ ਇੱਕ ਹੀ ਬਿਲਿੰਗ ਪਲੈਨ ਹੈ ਅਤੇ ਤੁਸੀਂ “ਸਾਨੂੰ ਭਵਿੱਖ ਲਈ” ਇੱਕ ਮਲਟੀ-ਟੇਨੈਂਟ ਪ੍ਰਾਇਸਿੰਗ ਇੰਜਨ ਬਣਾਉਂਦੇ ਹੋ, ਇਹ ਪੂਰਵ-ਅਬਸਟ੍ਰੈਕਸ਼ਨ ਹੈ।
ਜੇਕਰ ਕਿਸੇ ਫੀਚਰ ਨੂੰ ਇੱਕ ਸਧਾਰਣ ਫੰਕਸ਼ਨ ਨਾਲ ਕੀਤਾ ਜਾ ਸਕਦਾ ਸੀ, ਪਰ ਤੁਸੀਂ ਇਸਨੂੰ ਛੇ ਕਲਾਸਾਂ, ਫੈਕਟਰੀਆਂ ਅਤੇ ਰਜਿਸਟਰੀਆਂ ਵਿੱਚ ਵੰਡ ਦਿੰਦੇ ਹੋ ਤਾਂ ਇਹ ਅਤਿ-ਇੰਜੀਨੀਅਰਿੰਗ ਹੈ।
ਏਸੇ ਰਵੱਈਏ ਸ਼ੁਰੂ ਵਿੱਚ ਆਮ ਹਨ ਕਿਉਂਕਿ ਸ਼ੁਰੂਆਤੀ ਪ੍ਰੋਜੈਕਟ uncertainty ਨਾਲ ਭਰਪੂਰ ਹੁੰਦੇ ਹਨ:
ਸਮੱਸਿਆ ਇਹ ਹੈ ਕਿ “ਲਚਕੀਲਾ” ਅਕਸਰ ਮਤਲਬ ਹੁੰਦਾ ਹੈ “ਬਦਲਣਾ ਮੁਸ਼ਕਿਲ।” ਵਾਧੂ ਪਰਤਾਂ ਆਮ ਸੋਧਾਂ ਨੂੰ ਹੌਲੀ ਕਰ ਸਕਦੀਆਂ ਹਨ, ਡਿਬੱਗਿੰਗ ਨੂੰ ਔਖਾ ਬਣਾਉਂਦੀਆਂ ਹਨ, ਅਤੇ ਔਨਬੋਰਡਿੰਗ ਨੂੰ ਦਰਦਨਾਕ। ਤੁਸੀਂ ਜਟਿਲਤਾ ਦੀ ਕੀਮਤ ਤੁਰੰਤ ਭਰਦੇ ਹੋ, ਜਦਕਿ ਫਾਇਦੇ ਕਦੇ ਵੀ ਨਹੀਂ ਆ ਸਕਦੇ।
AI-ਚਲਾਏ ਵਰਕਫਲੋ ਟੀਮਾਂ ਨੂੰ ਕੰਮ ਨੂੰ ਠੋਸ ਰੱਖਣ ਲਈ ਪ੍ਰੇਰਿਤ ਕਰ ਸਕਦੇ ਹਨ—ਪ੍ਰੋਟੋਟਾਈਪਿੰਗ ਨੂੰ ਤੇਜ਼ ਕਰ ਕੇ, ਉਦਾਹਰਣਾਂ ਜਲਦੀ ਦੇ ਕੇ, ਅਤੇ ਧਾਰਨਾਵਾਂ ਨੂੰ ਆਜ਼ਮਾਉਣਾ ਆਸਾਨ ਬਣਾਕੇ। ਇਸ ਨਾਲ ਉਹ ਚਿੰਤਾ ਘਟਦੀ ਹੈ ਜੋ ਅਨੁਮਾਨ ਤੇ ਆਧਾਰਿਤ ਡਿਜ਼ਾਈਨ ਨੂੰ ਪੈਦਾ ਕਰਦੀ ਹੈ।
ਪਰ AI ਇੰਜੀਨੀਅਰਿੰਗ ਜੱਜਮੈਂਟ ਦੀ ਥਾਂ ਨਹੀਂ ਲੈ ਸਕਦਾ। ਇਹ ਤੁਰੰਤ ਕੋਈ ਚਤੁਰ ਆਰਕੀਟੈਕਚਰ ਜਾਂ ਅਬਸਟ੍ਰੈਕਸ਼ਨ ਤਿਆਰ ਕਰ ਸਕਦਾ ਹੈ। ਤੁਹਾਡੀ ਜ਼ਿੰਮੇਵਾਰੀ ਹੁਣ ਵੀ ਇਹ ਪੁੱਛਣਾ ਹੈ: ਅੱਜ ਲਈ ਸਭ ਤੋਂ ਸਧਾਰਨ ਚੀਜ਼ ਕੀ ਹੈ ਜੋ ਕੰਮ ਕਰਦੀ ਹੈ, ਅਤੇ ਕਿਹੜਿਆਂ ਸਬੂਤਾਂ ਦੀ ਲੋੜ ਹੋਵੇਗੀ ਕਿ ਕੱਲ੍ਹ ਨੂੰ ਬਣਾਉਣ ਦਾ ਕਦਮ ਵਾਜਬ ਹੈ?
ਆਲੇ-ਦੁਆਲੇ Koder.ai ਵਰਗੇ ਟੂਲ ਇੱਥੇ ਖਾਸਤੌਰ 'ਤੇ ਪ੍ਰਭਾਵਸ਼ਾਲੀ ਹਨ ਕਿਉਂਕਿ ਉਹ ਚੈਟ ਪ੍ਰਾਂਪਟ ਤੋਂ ਲੈ ਕੇ ਰਨਏਬਲ ਸਮੱਗਰੀ ਤੱਕ ਜਲਦੀ ਜਾਣਾ ਆਸਾਨ ਬਣਾਉਂਦੇ ਹਨ—ਤਾਂ ਜੋ ਟੀਮਾਂ “ਭਵਿੱਖ-ਪ੍ਰੋਫ਼” ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਲੋੜ ਨੂੰ ਸਥਿਰ ਕਰ ਸਕਣ।
AI-ਸਹਾਇਤਾ ਵਾਲਾ ਵਿਕਾਸ ਆਮ ਤੌਰ 'ਤੇ ਕਿਸੇ ਤੱਥ-ਅਧਾਰਤ ਚੀਜ਼ ਨਾਲ ਸ਼ੁਰੂ ਹੁੰਦਾ ਹੈ: ਇੱਕ ਖਾਸ ਬੱਗ, ਇੱਕ ਛੋਟਾ ਫੀਚਰ, ਡੇਟਾ ਰੂਪਾਂਤਰਣ, ਜਾਂ ਇੱਕ UI ਸਕ੍ਰੀਨ। ਇਹ ਫਰੇਮਿੰਗ ਮਹੱਤਵਪੂਰਨ ਹੈ। ਜਦੋਂ ਵਰਕਫਲੋ “ਇਥੇ ਇਸੀ ਖਾਸ ਚੀਜ਼ ਦੀ ਲੋੜ ਹੈ” ਨਾਲ ਸ਼ੁਰੂ ਹੁੰਦਾ ਹੈ, ਟੀਮਾਂ ਅਕਸਰ ਇੱਕ ਆਮ ਆਰਕੀਟੈਕਚਰ ਬਣਾ ਕੇ ਪਹਿਲਾਂ ਹੀ ਨਹੀਂ ਸੋਚਦੀਆਂ।
ਜ਼ਿਆਦਾਤਰ AI ਟੂਲ ਸਭ ਤੋਂ ਵਧੀਆ ਜਵਾਬ ਦਿੰਦੇ ਹਨ ਜਦੋਂ ਤੁਸੀਂ ਵਿਸਥਾਰ ਦਿੰਦੇ ਹੋ: ਇਨਪੁਟ, ਆਉਟਪੁਟ, ਸੀਮਾਵਾਂ, ਅਤੇ ਇੱਕ ਉਦਾਹਰਣ। “ਇੱਕ ਲਚਕੀਲਾ ਨੋਟੀਫਿਕੇਸ਼ਨ ਸਿਸਟਮ ਡਿਜ਼ਾਇਨ ਕਰੋ” ਵਰਗਾ ਪ੍ਰਾਂਪਟ ਧੁੰਦਲਾ ਹੈ, ਇਸ ਲਈ ਮਾਡਲ ਅਕਸਰ ਵਾਧੂ ਪਰਤਾਂ ਨਾਲ ਭਰ ਦੇਵੇਗਾ—ਇੰਟਰਫੇਸ, ਫੈਕਟਰੀਆਂ, ਸੰਰਚਨਾ—ਕਿਉਂਕਿ ਇਹ ਅਸਲ ਸੀਮਾਵਾਂ ਨਹੀਂ ਵੇਖ ਸਕਦਾ।
ਪਰ ਜਦੋਂ ਪ੍ਰਾਂਪਟ ਜ਼ਮੀਨੀ ਹੁੰਦਾ ਹੈ, ਆਉਟਪੁਟ ਵੀ ਜ਼ਮੀਨੀ ਹੁੰਦਾ ਹੈ:
PENDING_PAYMENT ਲਈ ਦਿਖਾਓ …”ਇਸ ਨਾਲ ਫਿਰ ਟੀਮਾਂ ਨੂੰ ਇੱਕ ਸਪਸ਼ਟ ਟੁਕੜਾ ਲਾਗੂ ਕਰਨ ਵੱਲ ਧਕਿਆ ਜਾਂਦਾ ਹੈ ਜੋ end-to-end ਕੰਮ ਕਰਦਾ ਹੈ। ਜਦੋਂ ਤੁਸੀਂ ਇਸਨੂੰ ਚਲਾ ਸਕਦੇ ਹੋ, ਸਮੀਖਿਆ ਕਰ ਸਕਦੇ ਹੋ, ਅਤੇ ਦਿਖਾ ਸਕਦੇ ਹੋ, ਤਾਂ ਤੁਸੀਂ ਪਰਿਭਾਸ਼ਾ ਨਹੀਂ ਬਣਾ ਰਹੇ — ਤੁਸੀਂ ਹੱਕੀਕਤ ਵਿੱਚ ਕੰਮ ਕਰ ਰਹੇ ਹੋ।
AI ਪੇਅਰ-ਪ੍ਰੋਗ੍ਰਾਮਿੰਗ ਇਟਰੈਸ਼ਨ ਨੂੰ ਸਸਤਾ ਕਰ ਦਿੰਦੀ ਹੈ। ਜੇ ਪਹਿਲਾ ਸੰਸਕਰਣ ਥੋੜ੍ਹਾ ਗੰਦਗਦ ਵਾਲਾ ਪਰ ਸਹੀ ਹੈ, ਤਾਂ ਅਗਲਾ ਕਦਮ ਅਕਸਰ “ਇਸ ਨੂੰ ਰੀਫੈਕਟਰ ਕਰੋ” ਹੁੰਦਾ ਹੈ ਨਾ ਕਿ “ਭਵਿੱਖ ਦੇ ਹਾਲਤਾਂ ਲਈ ਇੱਕ ਪ੍ਰਣਾਲੀ ਡਿਜ਼ਾਇਨ ਕਰੋ।” ਇਹ ਲੜੀ—ਪਹਿਲਾਂ ਕੰਮ ਕਰਨ ਵਾਲਾ ਕੋਡ, ਦੂਜੇ ਨੰਬਰ ਤੇ ਸੁਧਾਰ—ਉਹ ਦਬਾਅ ਘਟਾਉਂਦੀ ਹੈ ਜੋ ਅਜਿਹੀਆਂ ਅਬਸਟ੍ਰੈਕਸ਼ਨਾਂ ਨੂੰ ਜਨਮ ਦਿੰਦੀ ਹੈ।
ਅਮਲ ਵਿੱਚ, ਟੀਮਾਂ ਇੱਕ ਰਿਥਮ ਅਪਣਾ ਲੈਂਦੀਆਂ ਹਨ:
ਪ੍ਰਾਂਪਟ ਤੁਹਾਡੇ ਤੋਂ ਪੂਛਣ ਲਈ ਮਜ਼ਬੂਰ ਕਰਦੇ ਹਨ ਕਿ ਤੁਸੀਂ ਅਸਲ ਵਿੱਚ ਕੀ ਮਤਲਬ ਲੈਂਦੇ ਹੋ। ਜੇ ਤੁਸੀਂ ਇਨਪੁਟ/ਆਉਟਪੁਟ ਸਪਸ਼ਟ ਨਹੀਂ ਕਰ ਸਕਦੇ, ਤਾਂ ਇਹ ਸੰਕੇਤ ਹੈ ਕਿ ਤੁਸੀਂ ਅਬਸਟ੍ਰੈਕਟ ਕਰਨ ਲਈ ਤਿਆਰ ਨਹੀਂ—ਤੁਸੀਂ ਹਾਲੇ ਵੀ ਲੋੜਾਂ ਦੀ ਖੋਜ ਕਰ ਰਹੇ ਹੋ। AI ਟੂਲ ਸਪਸ਼ਟਤਾ ਨੂੰ ਇਨਾਮ ਦਿੰਦੇ ਹਨ, ਇਸ ਲਈ ਉਹ ਨਰਮ ਤੌਰ 'ਤੇ ਟੀਮਾਂ ਨੂੰ ਪਹਿਲਾਂ ਸਪਸ਼ਟ ਕਰਨ ਅਤੇ ਬਾਅਦ ਵਿੱਚ ਆਮ ਕਰਨ ਲਈ ਤਿਆਰ ਕਰਦੇ ਹਨ।
ਤੇਜ਼ ਫੀਡਬੈਕ ਇਹ ਬਦਲ ਦਿੰਦਾ ਹੈ ਕਿ “ਚੰਗੀ ਇੰਜੀਨੀਅਰਿੰਗ” ਕਿਹੜੀ ਮਹਿਸੂਸ ਹੁੰਦੀ ਹੈ। ਜਦੋਂ ਤੁਸੀਂ ਕਈ ਵਿਚਾਰ ਨੂੰ ਮਿੰਟਾਂ ਵਿੱਚ ਅਜ਼ਮਾ ਸਕਦੇ ਹੋ, ਤਦ ਸਪੈਕੁਲੇਟਿਵ ਆਰਕੀਟੈਕਚਰ ਇੱਕ ਆਰਥਿਕ ਲੋਡ ਜਾਪਦਾ ਹੈ ਜਿਸ ਤੋਂ ਬਚਿਆ ਜਾ ਸਕਦਾ ਹੈ।
AI-ਚਲਾਏ ਵਰਕਫਲੋਜ਼ ਚੱਕਰ ਨੂੰ ਸੰਕੁਚਿਤ ਕਰ ਦੇਂਦੇ ਹਨ:
ਇਹ ਲੂਪ ਠੋਸ ਤਰੱਕੀ ਨੂੰ ਇਨਾਮ ਦਿੰਦਾ ਹੈ। “ਸਾਨੂੰ ਪਲੱਗ-ਇਨ ਸਿਸਟਮ ਦੀ ਲੋੜ ਹੋਵੇਗੀ” ਜਾਂ “ਇਹ 12 ਡਾਟਾ ਸੋਰਨਾਂ ਦਾ ਸਹਿਯੋਗ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ” ਦੀ ਚਰਚਾ ਕਰਨ ਦੀ ਥਾਂ, ਟੀਮ ਵੇਖਦੀ ਹੈ ਕਿ ਮੌਜੂਦਾ ਸਮੱਸਿਆ ਵਾਕਈ ਕੀ ਮੰਗਦੀ ਹੈ।
ਪੂਰਵ-ਅਬਸਟ੍ਰੈਕਸ਼ਨ ਅਕਸਰ ਉਦੋਂ ਹੁੰਦੀ ਹੈ ਜਦੋਂ ਟੀਮਾਂ ਬਦਲਾਅ ਤੋਂ ਡਰਦੀਆਂ ਹਨ: ਜੇ ਬਦਲਾਅ ਮਹਿੰਗੇ ਹਨ, ਤਾਂ ਤੁਸੀਂ ਭਵਿੱਖ ਦੀ ਭਵਿੱਖਬਾਣੀ ਕਰਨ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰਦੇ ਹੋ ਅਤੇ ਉਸਦਾ ਡਿਜ਼ਾਈਨ ਕਰਦੇ ਹੋ। ਛੋਟੀ ਲੂਪਾਂ ਨਾਲ, ਬਦਲਾਅ ਸਸਤਾ ਹੋ ਜਾਂਦਾ ਹੈ। ਇਹ ਪ੍ਰੇਰਣਾ ਨੂੰ ਉਲਟ ਦਿੰਦਾ ਹੈ:
ਕਹੋ ਤਸੀਂ ਇੱਕ ਆਂਤਰਿਕ “CSV ਵਿੱਚ ਐਕਸਪੋਰਟ” ਫੀਚਰ ਜੋੜ ਰਹੇ ਹੋ। ਅਤਿ-ਇੰਜੀਨੀਅਰਿੰਗ ਵਾਲਾ ਰਸਤਾ ਇੱਕ ਜੈਨੇਰਿਕ ਐਕਸਪੋਰਟ ਫਰੇਮਵਰਕ, ਕਈ ਫਾਰਮੈਟ, ਜੌਬ ਕਿਊਜ਼, ਅਤੇ ਸੰਰਚਨਾ ਪਰਤਾਂ ਡਿਜ਼ਾਇਨ ਕਰਨ ਨਾਲ ਸ਼ੁਰੂ ਹੁੰਦਾ ਹੈ।
ਕੁਝ ਛੋਟਾ ਰਸਤਾ ਇਹ ਹੈ: ਇੱਕ ਸਿੰਗਲ /exports/orders.csv ਏਂਡਪੋਇੰਟ (ਜਾਂ ਇੱਕ ਇੱਕ-ਵਾਰ ਸਕ੍ਰਿਪਟ) ਬਣਾਓ, ਇਸਨੂੰ ਸਟੇਜਿੰਗ ਡੇਟਾ 'ਤੇ ਚਲਾਉ, ਅਤੇ ਫਾਇਲ ਸਾਈਜ਼, ਰਨਟਾਈਮ, ਅਤੇ ਮਿਸਿੰਗ ਫੀਲਡਾਂ ਨੂੰ ਨਿਰੀਖਣ ਕਰੋ। ਜੇ ਦੋ-ਤਿੰਨ ਐਕਸਪੋਰਟਾਂ ਤੋਂ ਬਾਅਦ ਤੁਸੀਂ ਦੁਹਰਾਏ ਜਾਂਦੇ ਪੈਟਰਨ ਵੇਖਦੇ ਹੋ—ਉਹੀ pagination ਲਾਜਿਕ, ਸਾਂਝੇ ਫਿਲਟਰਿੰਗ, ਸਾਂਝੇ headers—ਤਦ ਇੱਕ ਅਬਸਟ੍ਰੈਕਸ਼ਨ ਆਪਣੀ ਜਗ੍ਹਾ ਬਣਾਉਂਦਾ ਹੈ ਕਿਉਂਕਿ ਉਹ ਅਨੁਭਵ 'ਤੇ ਅਧਾਰਿਤ ਹੈ, ਅਨੁਮਾਨ 'ਤੇ ਨਹੀਂ।
ਕ੍ਰਮਬੱਧ ਡਿਲਿਵਰੀ ਡਿਜ਼ਾਈਨ ਦੀ ਆਰਥਿਕੀਤਾ ਨੂੰ ਬਦਲ ਦਿੰਦੀ ਹੈ। ਜਦੋਂ ਤੁਸੀਂ ਛੋਟੇ ਟੁਕੜਿਆਂ ਵਿੱਚ ਸ਼ਿਪ ਕਰਦੇ ਹੋ, ਹਰ “ਚੰਗਾ-ਹੋਣ ਵਾਲੀ” ਪਰਤ ਨੂੰ ਇਹ ਸਾਬਤ ਕਰਨਾ ਪੈਂਦਾ ਹੈ ਕਿ ਇਹ ਹੁਣ ਮਦਦ ਕਰਦੀ ਹੈ—ਨਾ ਕਿ ਕੋਈ ਕਲਪਿਤ ਭਵਿੱਖ। ਇੱਥੇ AI-ਚਲਾਏ ਵਰਕਫਲੋ ਪੂਰਵ-ਅਬਸਟ੍ਰੈਕਸ਼ਨ ਨੂੰ ਆਹਿਸਤਗੀ ਨਾਲ ਘਟਾਉਂਦੇ ਹਨ: AI ਬਣਾਉਣ ਵਿੱਚ ਮਹਿਰਤ ਰਖਦਾ ਹੈ, ਪਰ ਇਹਨੀਆਂ ਰਚਨਾਵਾਂ ਨੂੰ ਛੋਟੇ ਸਕੋਪ 'ਚ ਟੈਸਟ ਕਰਨਾ ਸਭ ਤੋਂ ਆਸਾਨ ਹੁੰਦਾ ਹੈ।
ਜੇ ਤੁਸੀਂ ਸਹਾਇਕ ਤੋਂ ਇੱਕ ਸਿਰਫ਼ ਮੋਡਯੂਲ ਰੀਫੈਕਟਰ ਕਰਨ ਜਾਂ ਨਵਾਂ ਏਂਡਪੋਇੰਟ ਜੋੜਨ ਲਈ ਕਹੋ, ਤੁਸੀਂ ਜਲਦੀ ਜਾਂਚ ਸਕਦੇ ਹੋ ਕਿ ਉਸਦੀ ਅਬਸਟ੍ਰੈਕਸ਼ਨ ਸਪਸ਼ਟਤਾ, ਨਕਲ ਘਟਾਉਂਦੀ ਹੈ ਜਾਂ ਅਗਲਾ ਬਦਲਾਅ ਆਸਾਨ ਕਰਦੀ ਹੈ। ਇੱਕ ਛੋਟੀ diff ਨਾਲ, ਫੀਡਬੈਕ ਤੁਰੰਤ ਹੁੰਦਾ ਹੈ: ਟੈਸਟ ਪਾਸ ਜਾਂ ਫੇਲ, ਕੋਡ ਪੜ੍ਹਨਯੋਗ ਹੋਇਆ ਜਾਂ ਨਹੀਂ, ਅਤੇ ਫੀਚਰ ਸਹੀ ਤਰੀਕੇ ਨਾਲ ਚਲਦਾ ਹੈ ਜਾਂ ਨਹੀਂ।
ਵੱਡੇ ਸਕੋਪ ਵਿੱਚ, AI ਸੁਝਾਵ ਪਰਪਲੀਆਦਾਹਕ ਲੱਗ ਸਕਦੇ ਹਨ ਬਿਨਾਂ ਸਾਬਤ ਲਾਭ ਦੇ। ਤੁਸੀਂ ਇੱਕ ਜੈਨੇਰਲਾਈਜ਼ਡ ਫਰੇਮਵਰਕ ਨੂੰ ਇਸ ਲਈ ਕਬੂਲ ਕਰ ਸਕਦੇ ਹੋ ਕਿਉਂਕਿ ਇਹ “ਸਾਫ਼ ਲੱਗਦਾ” ਹੈ, ਪਰ ਬਾਅਦ ਵਿੱਚ ਪਤਾ ਲੱਗਦਾ ਹੈ ਕਿ ਇਸਨੇ ਅਸਲ ਦੁਨੀਆ ਦੇ ਏਜ ਕੇਸਾਂ ਨੂੰ ਜਟਿਲ ਕੀਤਾ।
ਕ੍ਰਮਬੱਧ ਕੰਮ ਛੋਟੇ, ਨਾਸ਼ ਯੋਗ ਕੰਪੋਨੈਂਟ ਪਹਿਲਾਂ ਬਣਾਉਣ ਨੂੰ ਉਤਸ਼ਾਹਿਤ ਕਰਦਾ ਹੈ—ਹੈਲਪਰ, ਐਡੈਪਟਰ, ਸਧਾਰਨ ਡੇਟਾ ਰੂਪ। ਕੁਝ ਇਟਰੇਸ਼ਨਾਂ ਤੋਂ ਬਾਅਦ ਇਹ ਸਪਸ਼ਟ ਹੋ ਜਾਂਦਾ ਹੈ ਕਿ ਕਿਹੜੇ ਪੀਸ ਕਈ ਫੀਚਰਾਂ ਵੱਲੋਂ ਖਿੱਚੇ ਜਾਂਦੇ ਹਨ (ਰੱਖਣਯੋਗ) ਅਤੇ ਕਿਹੜੇ ਸਿਰਫ਼ ਇੱਕ-ਵਾਰੀ ਪ੍ਰਯੋਗ ਲਈ ਸੀ (ਨਿਰਪੱਖ ਤੌਰ 'ਤੇ ਹਟਾਏ ਜਾ ਸਕਦੇ)।
ਅਬਸਟ੍ਰੈਕਸ਼ਨ ਫਿਰ ਅਸਲੀ ਦੁਹਰਾਵਾਂ ਦਾ ਰਿਕਾਰਡ ਬਣਦੇ ਹਨ, ਨਾ ਕਿ ਅਨੁਮਾਨ ਕੀਤੇ ਦੁਹਰਾਵਾਂ ਦਾ।
ਜਦੋਂ ਬਦਲਾਅ ਲਗਾਤਾਰ ਸ਼ਿਪ ਹੁੰਦੇ ਹਨ, ਰੀਫੈਕਟਰੀੰਗ ਘਬਰਾਉਣ ਯੋਗ ਨਹੀਂ ਰਹਿੰਦਾ। ਤੁਹਾਨੂੰ ਅਗਲੇ ਕਦਮ 'ਤੇ “ਸਹੀ” ਹੋਣਾ ਜਰੂਰੀ ਨਹੀਂ ਹੁੰਦਾ ਕਿਉਂਕਿ ਤੁਸੀਂ ਡਿਜ਼ਾਈਨ ਨੂੰ ਇਤ੍ਰੈਟ ਕਰਨ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰ ਸਕਦੇ ਹੋ ਜਦੋਂ ਸਬੂਤ ਇਕੱਠੇ ਹੋ ਜਾਣ। ਜੇ ਕੋਈ ਪੈਟਰਨ ਅਸਲ ਵਿੱਚ ਆਪਣੀ ਜਗ੍ਹਾ ਬਣਾਉਂਦਾ ਹੈ—ਕਈ ਇਨਕ੍ਰੀਮੈਂਟਾਂ ਵਿੱਚ ਦੁਹਰਾਏ ਜਾਂਦੇ ਕੰਮ ਨੂੰ ਘਟਾਉਂਦਾ ਹੈ—ਤਾਂ ਉਸਨੂੰ ਅਬਸਟ੍ਰੈਕਸ਼ਨ ਵਿੱਚ ਤਬਦੀਲ ਕਰਨਾ ਘੱਟ-ਜੋਖਮ, ਉੱਚ-ਭਰੋਸੇ ਵਾਲਾ ਫੈਸਲਾ ਹੁੰਦਾ ਹੈ।
ਇਹ ਸੋਚ ਰੁਝਾਨ ਨੂੰ ਉਲਟ ਦਿੰਦੀ ਹੈ: ਪਹਿਲਾਂ ਸਭ ਤੋਂ ਸਧਾਰਨ ਸੰਸਕਰਣ ਬਣਾਓ, ਫਿਰ ਹੀ ਅਬਸਟ੍ਰੈਕਟ ਕਰੋ ਜਦੋਂ ਅਗਲਾ ਇਨਕ੍ਰੀਮੈਂਟ ਸਬੂਤ ਦਿਖਾਏ।
AI-ਚਲਾਏ ਵਰਕਫਲੋ ਪ੍ਰਯੋਗ ਨੂੰ ਇੰਨਾ ਸਸਤਾ ਬਣਾ ਦਿੰਦੇ ਹਨ ਕਿ “ਇੱਕ ਵੱਡੀ ਪ੍ਰਣਾਲੀ ਬਣਾਉਣ” ਡਿਫੌਲਟ ਰਹਿਣਾ ਬੰਦ ਹੋ ਜਾਂਦਾ ਹੈ। ਜਦੋਂ ਟੀਮ ਇੱਕ ਹੀ ਬਸ ਇੱਕ ਦੁਪਹਿਰ ਵਿੱਚ ਕਈ ਰੁਖਾਂ ਨੂੰ ਜਨਰੇਟ, ਸੁਧਾਰ, ਅਤੇ ਦੁਬਾਰਾ ਚਲਾ ਸਕਦੀ ਹੈ, ਤਾਂ ਅਗਲੇ ਕਦਮ ਦੀ ਭਵਿੱਖਬਾਣੀ ਕਰਨ ਦੀ ਥਾਂ ਇਹ ਜ਼ਿਆਦਾ ਆਸਾਨ ਹੋ ਜਾਂਦਾ ਹੈ ਕਿ ਕੀ ਅਸਲ ਵਿੱਚ ਕੰਮ ਕਰਦਾ ਹੈ।
ਇੱਕ ਜੈਨੇਰਿਕ ਆਰਕੀਟੈਕਚਰ ਡਿਜ਼ਾਈਨ ਕਰਨ ਵਿਚ ਦਿਨ ਲੱਗਣਾਂ ਅਦਲੇ, ਟੀਮ AI ਨੂੰ ਕਹਿ ਸਕਦੀ ਹੈ ਕਿ ਕੁਝ ਵੱਖ-ਵੱਖ, ਨਿਰਧਾਰਿਤ ਲਾਗੂਕਰਨ ਤਿਆਰ ਕਰਦਾ ਹੈ:
ਇਨਾਂ ਵੈਰੀਅੰਟਸ ਨੂੰ ਬਣਾਉਣਾ ਤੇਜ਼ ਹੈ, ਇਸ ਲਈ ਟੀਮ ਬਿਨਾਂ ਵੱਡੇ ਪ੍ਰਣਾਲੀ 'ਤੇ ਬਾਂਧੇ ਬਿਨਾਂ ਟਰੇਡ-ਆਫ਼ ਅਨੁਸ਼ੋਧ ਕਰ ਸਕਦੀ ਹੈ। ਲਕੜੀ ਉਦੇਸ਼ ਸਾਰੇ ਵੈਰੀਅੰਟਸ ਸ਼ਿਪ ਕਰਨਾ ਨ ਹੁੰਦਾ—ਮਕਸਦ ਸਬੂਤ ਪ੍ਰਾਪਤ ਕਰਨਾ ਹੁੰਦਾ ਹੈ।
ਜਦੋਂ ਤੁਸੀਂ ਦੋ-ਤਿੰਨ ਕੰਮ ਕਰਨ ਵਾਲੇ ਵਿਕਲਪਾਂ ਨੂੰ ਪਾਸੇ-ਪਾਸੇ ਰੱਖ ਸਕਦੇ ਹੋ, ਤਾਂ ਜਟਿਲਤਾ ਸਾਹਮਣੇ ਆ ਜਾਂਦੀ ਹੈ। ਅਕਸਰ ਸਧਾਰਣ ਵੈਰੀਅੰਟ:
ਦੂਜੇ ਪਾਸੇ, ਅਤਿ-ਇੰਜੀਨੀਅਰਡ ਵਿਕਲਪ ਆਪਣੀ ਪੱਖਪਾਤ ਸੰਭਾਵੀ ਲੋੜਾਂ ਨਾਲ ਖੁਦ ਨੂੰ ਸਹੀ ਠਹਿਰਾਉਂਦੇ ਹਨ। ਵੈਰੀਅੰਟਸ ਦੀ ਤੁਲਨਾ ਇਸ ਦਾ ਦਵਾਈ ਹੈ: ਜੇ ਵਾਧੂ ਅਬਸਟ੍ਰੈਕਸ਼ਨ ਨੇ ਇੱਕ-ਦੋ ਮੈਟਰਿਕ 'ਤੇ ਸਪਸ਼ਟ ਨਜਾਇਜ਼ ਲਾਭ ਨਹੀਂ ਦਿੱਤਾ, ਤਾਂ ਸਧਾਰਨ ਕੰਮਕਾਜੀ ਰਸਤਾ ਆਮ ਤੌਰ 'ਤੇ ਠੀਕ ਫੈਸਲਾ ਹੁੰਦਾ ਹੈ—ਫਿਲਹਾਲ ਲਈ।
ਜਦੋਂ ਤੁਸੀਂ ਹਲਕੇ-ਫੁਲਕੇ ਪ੍ਰਯੋਗ ਚਲਾਉਂਦੇ ਹੋ, ਤਾਂ ਇਹ ਤੈਅ ਕਰੋ ਕਿ “ਵਧੀਆ” ਦਾ ਕੀ ਮਤਲਬ ਹੈ। ਇੱਕ ਪ੍ਰਯੋਗਿਕ ਚੈੱਕਲਿਸਟ:
ਜੇ ਇੱਕ ਵੱਧ ਜੈਨੇਰਲਾਈਜ਼ਡ ਵੈਰੀਅਂਟ ਇਨ੍ਹਾਂ ਵਿੱਚੋਂ ਇੱਕ ਜਾਂ ਦੋ ਮਾਪਦੰਡਾਂ 'ਤੇ ਜਿੱਤ ਨਹੀਂ ਸਕਦਾ, ਤਾਂ ਅਕਸਰ ਸਭ ਤੋਂ ਸਧਾਰਨ ਕੰਮਕਾਜੀ ਰਸਤਾ ਹੀ ਠੀਕ ਚੋਣ ਹੁੰਦੀ ਹੈ।
ਪੂਰਵ-ਅਬਸਟ੍ਰੈਕਸ਼ਨ ਆਮ ਤੌਰ 'ਤੇ ਇੱਕ ਵਾਕ्य ਨਾਲ ਸ਼ੁਰੂ ਹੁੰਦੀ ਹੈ: “ਸਾਨੂੰ ਇਹ ਭਵਿੱਖ ਵਿੱਚ ਲੋੜ ਹੋ ਸਕਦੀ ਹੈ।” ਇਹਨੂੰ “ਸਾਨੂੰ ਇਹ ਹੁਣ ਲੋੜ ਹੈ” ਨਾਲ ਗਲਤ ਨਾ ਕਰੋ। ਪਹਿਲਾ ਇੱਕ ਭਵਿੱਖ ਬਾਰੇ ਅਨੁਮਾਨ ਹੈ; ਦੂਜਾ ਇੱਕ ਅਜਿਹਾ ਬੰਧਨ ਹੈ ਜੋ ਤੁਸੀਂ ਅੱਜ ਜਾਂਚ ਸਕਦੇ ਹੋ।
AI-ਚਲਾਏ ਵਰਕਫਲੋ ਇਸ ਫਰਕ ਨੂੰ ਨਜ਼ਰਅੰਦਾਜ਼ ਕਰਨਾ ਔਖਾ ਬਣਾਉਂਦੇ ਹਨ ਕਿਉਂਕਿ ਉਹ ਧੁੰਦਲੀ ਗੱਲਾਂ ਨੂੰ ਤੇਜ਼ੀ ਨਾਲ ਉਸ ਲਿਖਤੀ ਰੂਪ ਵਿੱਚ ਬਦਲ ਸਕਦੇ ਹਨ ਜੋ ਤੁਸੀਂ ਨਿਰੀਖਣ ਕਰ ਸਕਦੇ ਹੋ।
ਜਦੋਂ ਇੱਕ ਫੀਚਰ ਤਲਬ ਧੁੰਦਲਾ ਹੁੰਦਾ ਹੈ, ਟੀਮਾਂ ਆਮ ਤੌਰ 'ਤੇ “ਭਵਿੱਖ-ਪ੍ਰੂਫ਼” ਕਰਨ ਲਈ ਜੈਨੇਰਿਕ ਫਰੇਮਵਰਕ ਬਣਾਉਂਦੀਆਂ ਹਨ। ਬਦਲੇ ਵਿੱਚ, AI ਵਰਤ ਕੇ ਤੇਜ਼ੀ ਨਾਲ ਇੱਕ ਇਕ-ਪੰਨੇ ਦੀ ਲੋੜ-ਸਨੈਪਸ਼ਾਟ ਤਿਆਰ ਕਰੋ ਜੋ ਇਹ ਵੱਖ-ਵੱਖ ਕਰੇ:
ਇਹ ਸਧਾਰਨ ਵੰਡ ਇੰਜੀਨੀਅਰਿੰਗ ਗੱਲ-ਬਾਤ ਨੂੰ ਬਦਲ ਦਿੰਦੀ ਹੈ। ਤੁਸੀਂ ਇਕ ਅਣਜਾਣ ਭਵਿੱਖ ਲਈ ਡਿਜ਼ਾਇਨ ਕਰਨਾ ਛੱਡ ਦਿੰਦੇ ਹੋ ਅਤੇ ਜਾਣੂ ਮੌਜੂਦਾ ਲਈ ਬਣਾਉਣ ਸ਼ੁਰੂ ਕਰਦੇ ਹੋ—ਜੇਕਰ ਅਨਿਸ਼ਚਿਤਤਾਵਾਂ ਦੀ ਸਭਾ ਹੋਵੇ ਤਾਂ ਉਨ੍ਹਾਂ ਨੂੰ ਦੁਬਾਰਾ ਵੇਖਣ ਲਈ ਇੱਕ ਗੌਰਤਲੂ ਸੂਚੀ ਰੱਖਦੇ ਹੋ।
Koder.ai ਦੀ Planning Mode ਇੱਥੇ ਵਧੀਆ ਫਿੱਟ ਹੁੰਦੀ ਹੈ: ਤੁਸੀਂ ਧੁੰਦਲੀ ਮੰਗ ਨੂੰ ਇੱਕ ਸਪਸ਼ਟ ਯੋਜਨਾ (ਕਦਮ, ਡੇਟਾ ਮਾਡਲ, ਏਂਡਪੋਇੰਟ, UI ਸਥਿਤੀਆਂ) ਵਿੱਚ ਬਦਲ ਸਕਦੇ ਹੋ ਬਿਨਾਂ ਕਿਸੇ ਵਿਸ਼ਾਲ ਆਰਕੀਟੈਕਚਰ 'ਤੇ ਕਮਿਟ ਹੋਏ।
ਤੁਸੀਂ ਫਿਰ ਵੀ ਵਿਕਸਤ ਹੋਣ ਦੀ ਜਗ੍ਹਾ ਛੱਡ ਸਕਦੇ ਹੋ ਬਿਨਾਂ ਇੱਕ ਗਹਿਰੇ ਅਬਸਟ੍ਰੈਕਸ਼ਨ ਦੀ ਪਰਤ ਬਣਾਏ। ਉਹ ਤਰੱਕੀਆਂ ਵੱਲ ਜ਼ੋਰ ਦਿਓ ਜੋ ਬਦਲਣਾ ਆਸਾਨ ਜਾਂ ਹਟਾਉਣਾ ਆਸਾਨ ਹੋਣ:
ਇੱਕ ਚੰਗਾ ਨਿਯਮ: ਜੇ ਤੁਸੀਂ ਅਗਲੇ ਦੋ ਖਾਸ ਵੈਰੀਏਸ਼ਨਾਂ ਨੂੰ ਨਾਮ ਨਹੀਂ ਦੇ ਸਕਦੇ, ਤਾਂ ਫਰੇਮਵਰਕ ਨਾ ਬਣਾਓ। ਸੰਦੇਹਸਪਦ ਵੈਰੀਏਸ਼ਨਾਂ ਨੂੰ “ਅਣਜਾਣ” ਵਜੋਂ ਲਿਖੋ, ਸਭ ਤੋਂ ਸਧਾਰਨ ਕੰਮਕਾਜੀ ਰਸਤਾ ਸ਼ਿਪ ਕਰੋ, ਫਿਰ ਅਸਲ ਫੀਡਬੈਕ ਅਬਸਟ੍ਰੈਕਸ਼ਨ ਨੂੰ ਨਿਆਂਪੂਰਕ ਬਣਾਉਂਦਾ ਹੈ।
ਜੇ ਤੁਸੀਂ ਇਸ ਆਦਤ ਨੂੰ ਰੂਪਕ੍ਰਿਤ ਕਰਨਾ ਚਾਹੁੰਦੇ ਹੋ, ਤਾਂ ਇਹ ਨੋਟਸ ਆਪਣੇ PR ਟੈਂਪਲੇਟ ਜਾਂ ਇੱਕ ਅੰਦਰੂਨੀ “ਅਨੁਮਾਨ” ਦਸਤਾਵੇਜ਼ ਵਿੱਚ ਰੱਖੋ ਜੋ ਟਿਕਟ ਨਾਲ ਲਿੰਕ ਕੀਤਾ ਗਿਆ ਹੋਵੇ (ਉਦਾਹਰਣ ਲਈ, /blog/engineering-assumptions-checklist)।
ਟੀਮਾਂ ਅਕਸਰ ਕਲਪਿਤ ਪਰਿਸਥਿਤੀਆਂ ਲਈ ਡਿਜ਼ਾਈਨ ਕਰਦੀਆਂ ਹਨ। ਟੈਸਟ ਅਤੇ ਠੋਸ ਉਦਾਹਰਣ ਇਸ ਨੂੰ ਉਲਟ ਦਿੰਦੀਆਂ ਹਨ: ਉਹ ਤੁਹਾਨੂੰ ਅਸਲ ਇਨਪੁਟ, ਅਸਲ ਆਉਟਪੁਟ, ਅਤੇ ਅਸਲ ਫੇਲਿਅਰ ਮੋਡਾਂ ਨੂੰ ਵਰਣਨ ਕਰਨ ਲਈ ਮਜ਼ਬੂਰ ਕਰਦੇ ਹਨ। ਜਦੋਂ ਇਹ ਲਿਖੇ ਜਾਂਦੇ ਹਨ, “ਜਨਰਿਕ” ਅਬਸਟ੍ਰੈਕਸ਼ਨ ਅਕਸਰ ਘੱਟ ਲਾਭਕਾਰੀ ਅਤੇ ਵਧੇਰੇ ਮਹਿੰਗੇ ਲੱਗਦੇ ਹਨ—ਇੱਕ ਛੋਟੇ, ਸਾਫ਼ ਇੰਪਲੀਮੈਂਟੇਸ਼ਨ ਨਾਲ ਤੁਲਨਾਤਮਕ ਤੌਰ 'ਤੇ।
ਜਦੋਂ ਤੁਸੀਂ AI ਸਹਾਇਕ ਨੂੰ ਟੈਸਟ ਲਿਖਣ ਵਿੱਚ ਮਦਦ ਲਈ ਕਹਿੰਦੇ ਹੋ, ਇਹ ਕੁਦਰਤੀ ਤੌਰ 'ਤੇ ਤੁਹਾਨੂੰ ਵਿਸਥਾਰ ਵੱਲ ਧਕਦਾ ਹੈ। “ਇਸਨੂੰ ਲਚਕੀਲਾ ਬਣਾਓ” ਦੀ ਥਾਂ, ਤੁਸੀਂ ਪ੍ਰਾਂਪਟਾਂ ਨੂੰ ਇਸ ਤਰ੍ਹਾਂ ਮਿਲਦੇ ਹੋ: ਇਸ ਫੰਕਸ਼ਨ ਦਾ ਨਤੀਜਾ ਖਾਲੀ ਲਿਸਟ 'ਤੇ ਕੀ ਹੁੰਦਾ? ਵੱਧ ਤੋਂ ਵੱਧ ਮਨਜੂਰ ਕੀਤੀ ਗਈ ਕੀਮਤ ਕੀ ਹੈ? ਅਣਵੈਧ ਸਥਿਤੀ ਕੀਵੇਂ ਦਰਸਾਈਏ?
ਇਹ ਪੁੱਛਤਾਛ ਮਹੱਤਵਪੂਰਨ ਹੈ ਕਿਉਂਕਿ ਇਹ ਏਜ ਕੇਸਾਂ ਨੂੰ ਜਲਦੀ ਖੋਜ ਲੈਂਦੀ ਹੈ, ਜਦੋਂ ਤੁਸੀਂ ਅਜੇ ਵੀ ਨਿਰਧਾਰਤ ਕਰ ਰਹੇ ਹੋ ਕਿ ਫੀਚਰ ਨੂੰ ਅਸਲ ਵਿੱਚ ਕੀ ਚਾਹੀਦਾ ਹੈ। ਜੇ ਉਹ ਏਜ ਕੇਸ ਦੁਰਲਭ ਜਾਂ ਦਾਇਰੇ ਤੋਂ ਬਾਹਰ ਹਨ, ਤੁਸੀਂ ਉਨ੍ਹਾਂ ਨੂੰ ਦਸਤਾਵੇਜ਼ ਕਰ ਸਕਦੇ ਹੋ ਅਤੇ ਅੱਗੇ ਵਧ ਸਕਦੇ ਹੋ—ਬਿਨਾਂ “ਜਰੂਰਤ ਲਈ” ਅਬਸਟ੍ਰੈਕਸ਼ਨ ਬਣਾਉਣ ਦੇ।
ਅਬਸਟ੍ਰੈਕਸ਼ਨ ਆਪਣੀ ਕਦਰ ਉਸ ਵੇਲੇ ਕਮਾਉਂਦਾ ਹੈ ਜਦੋਂ ਕਈ ਟੈਸਟ ਇੱਕੋ ਜਿਹੇ ਸੈਟਅਪ ਜਾਂ ਵਿਵਹਾਰ ਨੂੰ ਸਾਂਝਾ ਕਰਦੇ ਹਨ। ਜੇ ਤੁਹਾਡੇ ਟੈਸਟ ਸੂਟ ਵਿੱਚ ਸਿਰਫ਼ ਇੱਕ ਜਾਂ ਦੋ ਸਪਸ਼ਟ ਦ੍ਰਿਸ਼ ਹੋਣ, ਤਾਂ ਇੱਕ ਫਰੇਮਵਰਕ ਜਾਂ ਪਲੱਗਇਨ ਸਿਸਟਮ ਬਣਾਉਣਾ ਆਮ ਤੌਰ 'ਤੇ ਇਹ ਦਿਖਾਉਂਦਾ ਹੈ ਕਿ ਤੁਸੀਂ ਕਲਪਿਤ ਭਵਿੱਖ ਲਈ ਆਪਟਿਮਾਈਜ਼ ਕਰ ਰਹੇ ਹੋ।
ਇੱਕ ਸਧਾਰਨ ਨਿਯਮ: ਜੇ ਤੁਸੀਂ ਇੱਕ ਜਨਰਲਾਈਜ਼ਡ ਇੰਟਰਫੇਸ ਲਈ ਘੱਟੋ-ਘੱਟ ਤਿੰਨ ਵੱਖ-ਵੱਖ ਵਿਵਹਾਰ ਨਹੀਂ ਦਰਸਾ ਸਕਦੇ, ਤਾਂ ਤੁਹਾਡੀ ਅਬਸਟ੍ਰੈਕਸ਼ਨ ਸੰਭਵਤ: ਪ੍ਰੀਮੈਚਰ ਹੈ।
ਅਮਲ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਇਸ ਹਲਕੇ ਢਾਂਚੇ ਦੀ ਵਰਤੋਂ ਕਰੋ:
ਇਹ ਲਿਖੇ ਜਾਣ 'ਤੇ, ਕੋਡ ਅਕਸਰ ਸਧਾਰਨ ਹੋਣਾ ਚਾਹੇਗਾ। ਜੇ ਕਈ ਟੈਸਟਾਂ ਵਿੱਚ ਦੁਹਰਾਈ ਦਿੱਸਦੀ ਹੈ, ਤਾਂ ਇਹ ਤੁਹਾਡੇ ਲਈ ਸੁਨੇਹਾ ਹੈ ਕਿ ਰੀਫੈਕਟਰ ਕਰੋ—ਨਹੀਂ ਕਿ ਸ਼ੁਰੂ ਤੋਂ ਇੱਕ ਫਰੇਮਵਰਕ ਬਣਾਓ।
ਅਤਿ-ਇੰਜੀਨੀਅਰਿੰਗ ਆਮ ਤੌਰ 'ਤੇ ਚੰਗੀਆਂ ਨੀਤੀਆਂ ਦੇ ਪਿੱਛੇ ਛੁਪ ਜਾਂਦੀ ਹੈ: “ਸਾਨੂੰ ਇਹ ਭਵਿੱਖ ਵਿੱਚ ਲੋੜ ਹੋ ਸਕਦੀ ਹੈ।” ਸਮੱਸਿਆ ਇਹ ਹੈ ਕਿ ਅਬਸਟ੍ਰੈਕਸ਼ਨਾਂ ਦੀ ਚਲਦੀ ਰਹਿਣ ਵਾਲੀ ਲਾਗਤ ਸ਼ੁਰੂਆਤੀ ਟਿਕਟ ਵਿੱਚ ਨਹੀਂ ਦਿਖਦੀ।
ਤੁਸੀਂ ਜੋ ਵੀ ਨਵੀਂ ਪਰਤ ਸ਼ਾਮਲ ਕਰਦੇ ਹੋ, ਅਕਸਰ ਇਹ ਮੁੜ-ਮੁੜ ਕੰਮ ਬਣਾਉਂਦੀ ਹੈ:
AI-ਚਲਾਏ ਵਰਕਫਲੋ ਇਹਨਾਂ ਲਾਗਤਾਂ ਨੂੰ ਨਜ਼ਰਅੰਦਾਜ਼ ਕਰਨਾ ਔਖਾ ਬਣਾਉਂਦੇ ਹਨ ਕਿਉਂਕਿ ਉਹ ਤੇਜ਼ੀ ਨਾਲ ਤੁਹਾਨੂੰ ਦੱਸ ਸਕਦੇ ਹਨ ਕਿ ਤੁਸੀਂ ਕੀ ਮੁਹੱਈਆ ਕਰ ਰਹੇ ਹੋ।
ਇੱਕ ਕਾਰਗਰ ਪ੍ਰਾਂਪਟ ਇਹ ਹੈ: “ਇਸ ਡਿਜ਼ਾਈਨ ਨਾਲ ਨਵੇਂ ਮੂਵਿੰਗ ਹਿੱਸੇ ਅਤੇ ਡਿਪੈਂਡੇਨਸੀਆਂ ਦੀ ਸੂਚੀ ਦਿਓ।” ਇੱਕ ਚੰਗਾ AI ਸਹਾਇਕ ਯੋਜਨਾ ਨੂੰ ਇਹਨਾਂ ਵਸਤਾਂ 'ਚ ਤੋੜ ਸਕਦਾ ਹੈ:
ਉਸ ਸੂਚੀ ਨੂੰ ਸਧਾਰਨ ਇੰਪਲੀਮੈਂਟੇਸ਼ਨ ਨਾਲ ਪਾਸੇ-ਪਾਸੇ ਰੱਖਣ ਨਾਲ “ਸਾਫ਼ ਆਰਕੀਟੈਕਚਰ” ਵਾਲੇ ਦਲੀਲਾਂ ਨੂੰ ਇੱਕ ਸਪਸ਼ਟ ਟਰੇਡ-ਆਫ਼ ਵਿੱਚ ਬਦਲ ਦਿੰਦਾ ਹੈ: ਕੀ ਤੁਸੀਂ ਅੱਠ ਨਵੇਂ ਸੰਕਲਪਾਂ ਨੂੰ ਰੱਖਣਾ ਚਾਹੁੰਦੇ ਹੋ ਸਿਰਫ਼ ਇੱਕ ਨਕਲ ਨੂੰ ਬਚਾਉਣ ਲਈ ਜੋ ਹੋ ਸਕਦਾ ਹੈ ਕਿ ਕਦੇ ਨਹੀਂ ਆਏ?
ਇੱਕ ਹਲਕਾ ਨੀਤੀ: ਹਰ ਫੀਚਰ ਪ੍ਰਤੀ ਨਵੀਆਂ ਸੰਕਲਪਾਂ ਦੀ ਗਿਣਤੀ 'ਤੇ ਸੀਮਾ ਲਗਾਓ। ਉਦਾਹਰਨ ਵਜੋਂ, 허ਮਦੇ ਦੀਆਂ ਹੱਦਾਂ ਰੱਖੋ:
ਜੇ ਫੀਚਰ ਇਸ ਬੱਜਟ ਤੋਂ ਬਾਹਰ ਜਾਏ, ਤਾਂ ਇੱਕ ਵਾਜਬੀਜ਼ਹ ਦੇਣ ਦੀ ਲੋੜ: ਇਹ ਕਿਹੜੇ ਭਵਿੱਖੀ ਬਦਲਾਅ ਨੂੰ ਯੋਗ ਕਰ ਰਿਹਾ ਹੈ, ਅਤੇ ਤੁਹਾਡੇ ਕੋਲ ਕਿਹੜੇ ਸਬੂਤ ਹਨ ਕਿ ਇਹ ਨਜ਼ਦੀਕ ਹਨ? AI ਇਸ ਤਰ੍ਹਾਂ ਦੀ ਵਜਹ ਤਿਆਰ ਕਰਨ (ਅਤੇ ਰਖ-ਰਖਾਵ ਕੰਮਾਂ ਦੀ ਭਵਿੱਖਬਾਣੀ) ਵਿੱਚ ਮਦਦ ਕਰਦਾ ਹੈ, ਅਤੇ ਟੀਮਾਂ ਛੋਟੇ, ਉਲਟਣਯੋਗ ਕਦਮ ਚੁਣਨ ਲਈ ਰੁਝਾਨ ਰੱਖਦੀਆਂ ਹਨ—ਕਿਉਂਕਿ ਲਗਾਤਾਰ ਲਾਗਤਾਂ ਕੋਡ ਜਮ੍ਹਾਂ ਹੋਣ ਤੋਂ ਪਹਿਲਾਂ ਦਿਖਾਈ ਦਿੰਦੀਆਂ ਹਨ।
AI-ਚਲਾਏ ਵਰਕਫਲੋ ਅਕਸਰ ਟੀਮਾਂ ਨੂੰ ਛੋਟੇ, ਟੈਸਟ ਕਰਨ ਯੋਗ ਕਦਮਾਂ ਵੱਲ ਧਕੇਲਦੇ ਹਨ—ਪਰ ਇਹ ਵਿਰੁੱਧ ਵੀ ਕਰ ਸਕਦੇ ਹਨ। ਕਿਉਂਕਿ AI ਤੇਜ਼ੀ ਨਾਲ “ਸੰਪੂਰਨ” ਹੱਲ ਤਿਆਰ ਕਰਨ ਵਿੱਚ ਮਹਿਰਤ ਹੈ, ਇਹ ਸਮਰੱਥਾ ਨਾਲ ਜਾਣ-ਮਨਕੇ ਪਰਚੀਆਂ, ਵਾਧੂ ਢਾਂਚੇ, ਜਾਂ scaffolding ਬਣਾ ਸਕਦਾ ਹੈ ਜੋ ਤੁਸੀਂ ਮੰਗੇ ਨਹੀਂ। ਨਤੀਜਾ ਹੋ ਸਕਦਾ ਹੈ ਕਿ ਜ਼ਿਆਦਾ ਕੋਡ ਬਣ ਜਾਵੇ, ਜ਼ਰੂਰਤ ਤੋਂ ਪਹਿਲਾਂ।
ਮਾਡਲ ਨੂੰ ਅਕਸਰ ਮਨੁੱਖੀ ਧਾਰਨਾ ਦੁਆਰਾ ਪੁਰਸਕਾਰ ਦਿੱਤਾ ਜਾਂਦਾ ਹੈ ਜੇ ਇਹ ਵਿਸਥਾਰਭਰੇ ਦਿਸਦਾ ਹੈ। ਇਹ ਵਾਧੂ ਪਰਤਾਂ, ਹੋਰ ਫਾਈਲਾਂ, ਅਤੇ ਜਨਰਲ ਡਿਜ਼ਾਈਨ ਜੋੜ ਸਕਦਾ ਹੈ ਜੋ ਪੇਸ਼ੇਵਰ ਲੱਗਦੇ ਹਨ ਪਰ ਨਾ ਹੀ ਮੌਜੂਦਾ ਸਮੱਸਿਆ ਨੂੰ ਹੱਲ ਕਰ ਰਹੇ ਹਨ।
ਆਮ ਚੇਤਾਵਨੀ ਨਿਸ਼ਾਨੀਆਂ ਵਿੱਚ ಶਾਮਲ ਹਨ:
AI ਨੂੰ ਇੱਕ ਤੇਜ਼ ਦੋਸਤਾਨ ਹੱਥ ਸਮਝੋ, ਨਾ ਕਿ ਇੱਕ ਆਰਕੀਟੈਕਚਰ ਕਮੇਟੀ। ਕੁਝ ਰੋਕ-ਤੋੜ ਬਹੁਤ ਫਾਇਦਾ ਦਿੰਦੇ ਹਨ:
ਇੱਕ ਸਧਾਰਨ ਨਿਯਮ: AI ਨੂੰ ਜਨਰਲਾਈਜ਼ ਕਰਨ ਨਾ ਦਿਓ ਜਦ ਤੱਕ ਤੁਹਾਡੀ ਕੋਡਬੇਸ ਵਿੱਚ ਦੁਹਰਾਇਆ ਦਰਦ ਨਾ ਹੋਵੇ।
AI ਕੋਡ ਜਨਰੇਟ ਕਰਨ, ਰੀਫੈਕਟਰ ਕਰਨ, ਅਤੇ ਵਿਕਲਪ ਅਜ਼ਮਾਉਣ ਨੂੰ ਸਸਤਾ ਬਣਾਉਂਦਾ ਹੈ। ਇਹ ਇੱਕ ਤੋਹਫ਼ਾ ਹੈ—ਜੇ ਤੁਸੀਂ ਇਸ ਨੂੰ ਇਸਤੇਮਾਲ ਕਰਕੇ ਅਬਸਟ੍ਰੈਕਸ਼ਨ ਨੂੰ ਰੋਕ ਸਕਦੇ ਹੋ ਜਦ ਤੱਕ ਉਹ ਆਪਣੀ ਕਦਰ ਨਾ ਕਮਾ ਲੇ।
ਅੱਜ ਦੀ ਸਮੱਸਿਆ ਹੱਲ ਕਰਨ ਵਾਲੀ ਸਭ ਤੋਂ ਸਧਾਰਨ ਸੰਸਕਰਣ ਨਾਲ ਸ਼ੁਰੂ ਕਰੋ। ਨਾਮ ਰੱਖੋ ਸਿੱਧੇ-ਸਧੇ ਉਸ ਦੇ ਕੰਮ ਦੇ ਨਾਂ ਤੇ (ਨਾ ਕਿ ਜੋ ਇਹ ਭਵਿੱਖ ਵਿੱਚ ਕਰ ਸਕਦਾ ਹੈ), ਅਤੇ APIs ਨੂੰ ਤੰਗ ਰੱਖੋ। ਜੇ ਤੁਸੀਂ ਇਹ ਨਿਸ਼ਚਿਤ ਨਹੀਂ ਕਿ ਕੋਈ ਪੈਰਾਮੀਟਰ, ਇੰਟਰਫੇਸ, ਜਾਂ ਪਲੱਗਇਨ ਸਿਸਟਮ ਲੋੜੀਂਦਾ ਹੈ, ਤਾਂ ਬਿਨਾਂ ਉਸਦੇ ਸ਼ਿਪ ਕਰੋ।
ਹੇਠਾਂ ਇੱਕ ਫ਼ਾਇਦਾਕਾਰ ਨਿਯਮ: ਅਨੁਮਾਨ ਉੱਤੇ ਦੁਹਰਾਅ ਨਾਲੋਂ ਨਕਲ ਨੂੰ ਤਰਜੀਹ ਦਿਓ। ਨਕਲ ਕੋਡ ਦਿੱਖ ਵਿੱਚ ਸਪਸ਼ਟ ਅਤੇ ਹਟਾਉਣ ਵਿੱਚ ਆਸਾਨ ਹੁੰਦਾ ਹੈ; ਕਲਪਿਤ ਜਨਰਲਤਾ ਇੰਡੀਰੈਕਸ਼ਨ ਵਿੱਚ ਜਟਿਲਤਾ ਚੁਪ ਕਰ ਦਿੰਦੀ ਹੈ।
ਜਦੋਂ ਫੀਚਰ ਵਰਤਿਆ ਜਾ ਰਿਹਾ ਹੋਵੇ ਅਤੇ ਬਦਲ ਰਿਹਾ ਹੋਵੇ, ਤਰਕ ਨੂੰ ਧਿਆਨ ਵਿੱਚ ਰੱਖ ਕੇ ਰੀਫੈਕਟਰ ਕਰੋ। AI ਦੀ ਮਦਦ ਨਾਲ, ਤੁਸੀਂ ਇਹ ਤੇਜ਼ੀ ਨਾਲ ਕਰ ਸਕਦੇ ਹੋ: ਇਸਨੂੰ ਪੁੱਛੋ ਕਿ ਇੱਕ extraction ਸੁਝਾਅ ਦਿਓ, ਪਰ ਘੱਟੋ-ਘੱਟ diff ਅਤੇ ਪਾਠਨਯੋਗ ਨਾਂ ਦੀ ਮੰਗ ਕਰੋ।
ਜੇ ਤੁਹਾਡੀ ਟੂਲੀੰਗ ਇਸਨੂੰ ਸਹਾਇਕ ਕਰਦੀ ਹੈ, ਤਾਂ ਉਹ ਸੇਫਟੀ ਨੈੱਟ ਵਰਤੋ ਜੋ ਰੀਫੈਕਟਰ ਨੂੰ ਘੱਟ-ਜੋਖਮ ਬਣਾਉਂਦੇ ਹਨ। ਉਦਾਹਰਨ ਲਈ, Koder.ai ਦੇ snapshots ਅਤੇ rollback ਤੁਹਾਨੂੰ ਰੀਫੈਕਟਰੇਸ਼ਨਾਂ ਨਾਲ ਬੇਫਿਕਰ ਪ੍ਰਯੋਗ ਕਰਨ ਦੀ ਸਮਰੱਥਾ ਦਿੰਦੇ ਹਨ, ਕਿਉਂਕਿ ਤੁਸੀਂ ਜਲਦੀ ਵਾਪਸ ਆ ਸਕਦੇ ਹੋ ਜੇ “ਸਾਫ” ਡਿਜ਼ਾਈਨ ਅਮਲ ਵਿੱਚ ਖਰਾਬ ਨਿਕਲਦਾ ਹੈ।
ਅਬਸਟ੍ਰੈਕਸ਼ਨ ਆਪਣੀ ਕਦਰ ਕਮਾਉਂਦੀ ਹੈ ਜਦੋਂ ਜਿਆਦਾਤਰ ਇਹ ਗੱਲਾਂ ਸਹੀ ਹੁੰਦੀਆਂ ਹਨ:
ਫੀਚਰ ਸ਼ਿਪ ਹੋਣ ਤੋਂ ਇੱਕ ਹਫ਼ਤਾ ਬਾਅਦ ਇੱਕ ਕੈਲੰਡਰ ਯਾਦ ਦਿਓ:
ਇਸ ਨਾਲ ਡਿਫੌਲਟ ਦ੍ਰਿਸ਼ਟਿਕੋਣ ਬਦਲਦਾ ਹੈ: ਪਹਿਲਾਂ ਬਣਾਓ, ਫਿਰ ਜ਼ਮੀਨ ਤੇ ਆ ਕੇ ਜਨਰਲਾਈਜ਼ ਕਰੋ ਜਦੋਂ ਹਕੀਕਤ ਤੁਹਾਨੂੰ ਮਜ਼ਬੂਰ ਕਰੇ।
Lean engineering ਇੱਕ ਅਹਿਸਾਸ ਨਹੀਂ—ਇਹ ਕੁਝ ਜਿਹੜਾ ਤੁਸੀਂ ਨਿਰੀਖ ਸਕਦੇ ਹੋ। AI-ਚਲਾਏ ਵਰਕਫਲੋ ਛੋਟੇ ਬਦਲਾਅ ਤੇਜ਼ੀ ਨਾਲ ਸ਼ਿਪ ਕਰਨ ਨੂੰ ਆਸਾਨ ਬਣਾਉਂਦੇ ਹਨ, ਪਰ ਤੁਹਾਨੂੰ ਕੁਝ ਸੰਗੀਤਕ ਸੰਕੇਤਾਂ ਦੀ ਲੋੜ ਹੈ ਤਾਂ ਜੋ ਟੀਮ ਫਿਰ ਤੋਂ ਕਲਪਿਤ ਡਿਜ਼ਾਈਨ ਵੱਲ ਨਾ ਮੁੜੇ।
ਚੰਦ ਬੇਲੋੜਾ ਇੰਡੀਕੇਟਰ ਟ੍ਰੈਕ ਕਰੋ ਜੋ অਰਥਹੀਨ ਅਬਸਟ੍ਰੈਕਸ਼ਨ ਨਾਲ ਸੰਬੰਧਿਤ ਹਨ:
ਤੁਹਾਨੂੰ ਪੂਰਨਤਾ ਦੀ ਲੋੜ ਨਹੀਂ—ਟ੍ਰੈਂਡ ਲਾਈਨ ਕਾਫ਼ੀ ਹੁੰਦੇ ਹਨ। ਹਫ਼ਤੇਵਾਰ ਜਾਂ ਹਰ ਇਟਰੇਸ਼ਨ 'ਤੇ ਇਹਨਾਂ ਦੀ ਸਮੀਖਿਆ ਕਰੋ, ਅਤੇ ਪੁੱਛੋ: “ਕੀ ਅਸੀਂ ਉਤਪਾਦ ਦੀ ਲੋੜ ਤੋਂ ਵੱਧ ਨਵੇਂ ਸੰਕਲਪ ਜੋੜੇ?”
ਜਦੋਂ ਵੀ ਕੋਈ ਨਵੀਂ ਅਬਸਟ੍ਰੈਕਸ਼ਨ (ਨਵਾਂ ਇੰਟਰਫੇਸ, ਹੈਲਪਰ ਲੇਅਰ, ਅੰਦਰੂਨੀ ਲਾਇਬ੍ਰੇਰੀ ਆਦਿ) ਪੇਸ਼ ਕੀਤੀ ਜਾਵੇ, ਇੱਕ ਛੋਟਾ “ਕਿਉਂ ਇਹ ਮੌਜੂਦ ਹੈ” ਨੋਟ ਲਾਜ਼ਮੀ ਰੱਖੋ। ਇਸਨੂੰ README ਜਾਂ ਐਂਟਰੀ ਪੌਇੰਟ ਨੇੜੇ ਇੱਕ ਟਿੱਪਣੀ ਵਜੋਂ ਰੱਖੋ:
ਇੱਕ ਟੀਮ ਲਈ 2–4 ਹਫ਼ਤਿਆਂ ਲਈ ਇੱਕ ਛੋਟੇ AI-ਸਹਿਯੋਗੀ ਵਰਕਫਲੋ ਦਾ ਪਾਇਲਟ ਚਲਾਓ: AI-ਸਹਾਇਤ ਟਿਕਟ ਬ੍ਰੇਕਡਾਊਨ, AI-ਸਹਾਇਤ ਕੋਡ ਸਮੀਖਿਆ ਚੈੱਕਲਿਸਟ, ਅਤੇ AI-ਜਨਰੇਟ ਕੀਤੇ ਟੈਸਟ ਕੇਸ।
ਆਖਰ ਵਿੱਚ, ਉਪਰੋਕਤ ਮੈਟਰਿਕਾਂ ਦੀ ਤੁਲਨਾ ਕਰੋ ਅਤੇ ਇੱਕ ਛੋਟੀ ਰੇਟ੍ਰੋ ਕਰੋ: ਜੋ ਕੁਝ ਸਾਇਕਲ ਸਮਾਂ ਅਤੇ ਔਨਬੋਰਡਿੰਗ ਘਟਾਉਂਦਾ ਹੈ, ਉਸਨੂੰ ਰੱਖੋ; ਜੋ ਕੁਝ “ਨਵੀਆਂ ਸੰਕਲਪਾਂ” ਬਿਨਾਂ ਉਪਜਾਪੂਰਕ ਲਾਭ ਦੇ ਵਧਾਉਂਦਾ ਹੈ, ਉਸਨੂੰ ਵਾਪਸ ਲਓ।
ਜੇ ਤੁਸੀਂ ਇਸ ਪ੍ਰਯੋਗ ਨੂੰ ਐਂਡ-ਟੂ-ਐਂਡ ਚਲਾਉਣ ਲਈ ਪ੍ਰਯੋਗਸ਼ੀਲ ਮਹੋਲ ਲੱਭ ਰਹੇ ਹੋ, ਤਾਂ Koder.ai ਵਰਗਾ vibe-coding ਪਲੇਟਫਾਰਮ ਤੁਹਾਨੂੰ ਛੋਟੇ, ਠੋਸ ਸਲਾਈਸਾਂ ਨੂੰ ਤੇਜ਼ੀ ਨਾਲ ਡੀਪਲੋਏਬਲ ਐਪ ਵਿੱਚ ਬਦਲਣ ਵਿੱਚ ਮਦਦ ਕਰ ਸਕਦਾ ਹੈ (ਜਦੋਂ ਲੋੜ ਹੋਵੇ ਤਾਂ ਸੋర్స ਐਕਸਪੋਰਟ ਉਪਲੱਬਧ), ਜੋ ਇਸ ਲੇਖ ਦੇ ਮੁੱਖ ਸੰਦੇਸ਼ ਨੂੰ ਮਜ਼ਬੂਤ ਕਰਦਾ ਹੈ: ਕੁਝ ਅਸਲ ਸ਼ਿਪ ਕਰੋ, ਸਿੱਖੋ, ਅਤੇ ਫਿਰ ਹੀ ਅਬਸਟ੍ਰੈਕਟ ਕਰੋ।