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

ਸੌਫਟਵੇਅਰ ਬਣਾਉਣਾ ਹਮੇਸ਼ਾਂ ਇੱਕ ਵਾਪਸੀ-ਦਿੱਤੀ ਪ੍ਰਕਿਰਿਆ ਰਹੀ ਹੈ: ਇੱਕ ਪ੍ਰੋਡਕਟ ਮਾਲਕ ਜ਼ਰੂਰਤ ਦੱਸਦਾ ਹੈ, ਡਿਜ਼ਾਈਨਰ ਇੱਕ ਰੂਪ-ਰੇਖਾ ਬਣਾਉਂਦਾ ਹੈ, ਇਕ ਇੰਜੀਨੀਅਰ "ਅਗਲਾ ਕੀ ਹੁੰਦਾ?" ਪੁੱਛਦਾ ਹੈ, ਅਤੇ ਹਰ ਕੋਈ ਇਹ ਤੈਅ ਕਰਦਾ ਹੈ ਕਿ "ਮੁਕੰਮਲ" ਦਾ ਕੀ ਮਤਲਬ ਹੈ। ਇਸਨੂੰ ਗੱਲਬਾਤ ਕਹਿਣਾ ਲਾਭਕਾਰੀ ਹੈ ਕਿਉਂਕਿ ਇਹ ਉਸ ਚੀਜ਼ ਨੂੰ ਰੌਸ਼ਨ ਕਰਦਾ ਹੈ ਜੋ ਅਸਲ ਵਿੱਚ ਪ੍ਰਗਤੀ ਚਲਾਉਂਦੀ ਹੈ—ਸਾਂਝੀ ਸਮਝ—ਬਨਾਮ ਕਿਸੇ ਇਕ ਇਕਾਈ (ਇੱਕ ਸਪੇਕ, ਇੱਕ ਡਾਇਗ੍ਰਾਮ, ਜਾਂ ਇੱਕ ਟਿਕਟ)।
ਬਹੁਤ ਸਾਰੇ ਪ੍ਰਾਜੈਕਟ ਇਸ ਲਈ ਫੇਲ ਹੋ ਜਾਂਦੇ ਹਨ ਕਿ ਕੋਈ ਕੋਡ ਲਿਖਣ ਵਿਚ ਅਸਮਰੱਥ ਹੈ; ਉਹ ਇਸ ਲਈ ਫੇਲ ਹੁੰਦੇ ਹਨ ਕਿ ਲੋਕ ਗਲਤ ਚੀਜ਼ ਬਣਾਉਂਦੇ ਹਨ, ਜਾਂ ਸਹੀ ਚੀਜ਼ ਗਲਤ ਧਾਰਣਿਆਂ 'ਤੇ। ਵੇਖ-ਸੁਣ ਕੇ ਨੀਅਤ ਸਾਫ਼ ਹੁੰਦੀ ਹੈ:
ਇੱਕ ਚੰਗੀ ਗੱਲਬਾਤ ਇਨ੍ਹਾਂ ਨੂੰ ਸ਼ੁਰੂ ਤੋਂ ਸਪੱਸ਼ਟ ਬਣਾਉਂਦੀ ਹੈ, ਅਤੇ ਜਿਵੇਂ ਹਕੀਕਤ ਬਦਲਦੀ ਹੈ ਉਨ੍ਹਾਂ 'ਤੇ ਮੁੜ-ਚਰਚਾ ਕਰਦੀ ਹੈ।
AI ਇੱਕ ਨਵੇਂ ਕਿਸਮ ਦੇ ਭਾਗੀਦਾਰ ਨੂੰ ਸ਼ਾਮਲ ਕਰਦਾ ਹੈ—ਇਹ ਝਟ ਪੈਨ, ਸਾਰ-ਸੰਖੇਪ, ਵਿਕਲਪ ਪੇਸ਼ ਕਰਨ ਅਤੇ ਤੁਰੰਤ ਕੋਡ ਬਣਾਉਣ ਦੀ ਸਮਰੱਥਾ ਰੱਖਦਾ ਹੈ। ਇਸ ਨਾਲ ਕੰਮ ਦੀ ਗਤੀ ਬਦਲ ਜਾਂਦੀ ਹੈ: ਸਵਾਲਾਂ ਦੇ ਜਵਾਬ ਤੇਜ਼ ਮਿਲਦੇ ਹਨ, ਅਤੇ ਪ੍ਰੋਟੋਟਾਈਪ ਜਲਦੀ ਨਜ਼ਰ ਆਉਂਦੇ ਹਨ।
ਜੋ ਨਹੀਂ ਬਦਲਦਾ, ਉਹ ਜਵਾਬਦੇਹੀ ਹੈ। ਮਨੁੱਖ ਅਜੇ ਵੀ ਫੈਸਲਾ ਕਰਦੇ ਹਨ ਕਿ ਕੀ ਬਣਾਉਣਾ ਹੈ, ਕਿਹੜੇ ਖ਼ਤਰੇ ਕਬੁਲਯੋਗ ਹਨ, ਅਤੇ ਉਪਭੋਗਤਾਵਾਂ ਲਈ ਗੁਣਵੱਤਾ ਦਾ ਕੀ ਮਤਲਬ ਹੈ। AI ਸੁਝਾਵ ਦੇ ਸਕਦਾ ਹੈ, ਪਰ ਨਤੀਜਿਆਂ ਦੀ ਜ਼ਿੰਮੇਵਾਰੀ ਨਹੀਂ ਲੈ ਸਕਦਾ।
ਇਹ ਲੇਖ ਗੱਲਬਾਤ ਨੂੰ ਸਿਰੇ ਤੱਕ ਫਾਲੋ ਕਰਦਾ ਹੈ: ਸਮੱਸਿਆ ਨੂੰ ਪਰਿਭਾਸ਼ਿਤ ਕਰਨਾ, ਲੋੜਾਂ ਨੂੰ ਉਦਾਹਰਣਾਂ ਵਿੱਚ ਤਬਦੀਲ ਕਰਨਾ, ਡਿਜ਼ਾਈਨ 'ਤੇ ਘੁੱਟਣਾ, ਆਰਕੀਟੈਕਚਰ ਫੈਸਲੇ ਕਰਨਾ, ਕੋ-ਰਾਈਟ ਅਤੇ ਕੋਡ ਦੀ ਸਮੀਖਿਆ, "ਚੰਗਾ ਕੰਮ" ਦੀ ਸਾਂਝੀ ਪਰਿਭਾਸ਼ਾ ਦੇ ਨਾਲ ਟੈਸਟਿੰਗ, ਦਸਤਾਵੇਜ਼ ਨੂੰ ਅਪ-ਟੂ-ਡੇਟ ਰੱਖਣਾ, ਅਤੇ ਰਿਲੀਜ਼ ਤੋਂ ਬਾਦ ਹਕੀਕਤੀ ਫੀਡਬੈਕ ਤੋਂ ਸਿੱਖਣਾ—ਇਸ ਸਾਰੇ ਦੌਰਾਨ ਭਰੋਸੇ, ਸੁਰੱਖਿਆ ਅਤੇ ਗੁਣਵੱਤਾ ਲਈ ਪ੍ਰਯੋਗਿਕ ਰੱਖਿਆ-ਰੇਖਾਵਾਂ ਦੇ ਨਾਲ।
ਐਪਲੀਕੇਸ਼ਨ ਵਿਕਾਸ ਹੁਣ ਸਿਰਫ਼ "ਬਿਜ਼ਨਸ" ਤੋਂ "ਇੰਜੀਨੀਅਰਿੰਗ" ਨੂੰ ਹੱਥ ਦੇਣ ਵਾਲੀ ਗਤੀਵੀ ਧਾਰਾ ਨਹੀਂ ਰਹੀ। ਟੀਮ ਵਿਚ ਇੱਕ ਨਵਾਂ ਭਾਗੀਦਾਰ ਸ਼ਾਮਲ ਹੋ ਗਿਆ ਹੈ: AI। ਇਸ ਨਾਲ ਕੰਮ ਦੀ ਰਫਤਾਰ ਬਦਲਦੀ ਹੈ, ਪਰ ਇਸ ਨਾਲ ਭੂਮਿਕਾ ਦੀ ਸਪੱਸ਼ਟਤਾ ਹੋਰ ਵੀ ਜ਼ਰੂਰੀ ਹੋ ਜਾਂਦੀ ਹੈ।
ਇੱਕ ਸਿਹਤਮੰਦ ਡਿਲਿਵਰੀ ਟੀਮ ਅਜੇ ਵੀ ਜਾਣ-пਛਾਣ ਵਾਲੀ ਲੱਗਦੀ ਹੈ: ਪ੍ਰੋਡਕਟ, ਡਿਜ਼ਾਈਨ, ਇੰਜੀਨੀਅਰਿੰਗ, ਸਹਾਇਤਾ, ਅਤੇ ਗਾਹਕ। ਫਰਕ ਇਹ ਹੈ ਕਿ ਹੁਣ ਉਹ ਇੱਕ ਹੀ ਕਮਰੇ ਵਿੱਚ ਬਾਰ-ਬਾਰ ਹੋ ਸਕਦੇ ਹਨ—ਖ਼ਾਸ ਕਰਕੇ ਜਦੋਂ AI ਫੀਡਬੈਕ ਨੂੰ ਤੇਜ਼ੀ ਨਾਲ ਸਾਰ-ਸੰਖੇਪ ਕਰ ਸਕਦਾ ਹੈ, ਵਿਕਲਪ ਡਰਾਫਟ ਕਰ ਸਕਦਾ ਹੈ, ਜਾਂ ਤਕਨੀਕੀ ਅਤੇ ਗੈਰ-ਤਕਨੀਕੀ ਭਾਸ਼ਾ ਵਿਚ ਅਨੁਵਾਦ ਕਰ ਸਕਦਾ ਹੈ।
ਗਾਹਕ ਜੀਵੰਤ ਹਕੀਕਤ ਦਿੰਦੇ ਹਨ: ਕੀ ਦਰਦ ਦੇਂਦਾ ਹੈ, ਕੀ ਉਨ੍ਹਾਂ ਲਈ ਉਲਝਣ ਵਾਲਾ ਹੈ, ਅਤੇ ਉਹ ਅਸਲ ਵਿੱਚ ਕਿਸ ਲਈ ਪੈਸਾ ਭਰਣਗੇ। ਸਹਾਇਤਾ ਰਿਕਰਿੰਗ ਮੁੱਦਿਆਂ ਅਤੇ ਐਜ ਕੇਸਾਂ ਦੀ ਸੱਚੀ ਤਸਵੀਰ ਲਿਆਉਂਦੀ ਹੈ। ਪ੍ਰੋਡਕਟ ਗੋਲ ਅਤੇ ਪਾਬੰਦੀਆਂ ਦਰਸਾਉਂਦਾ ਹੈ। ਡਿਜ਼ਾਈਨ ਨੀਅਤ ਨੂੰ ਵਰਤੋਂਯੋਗ ਬਹਾਵਾਂ ਵਿੱਚ ਬਦਲਦਾ ਹੈ। ਇੰਜੀਨੀਅਰਿੰਗ ਸੰਭਵਤਾ, ਪ੍ਰਦਰਸ਼ਨ, ਅਤੇ ਰੱਖ-ਰਖਾਅ ਨੂੰ ਯਕੀਨੀ ਬਣਾਉਂਦੇ ਹਨ। AI ਹਰ ਇੱਕ ਗੱਲਬਾਤ ਨੂੰ ਸਹਾਇਤਾ ਦੇ ਸਕਦਾ ਹੈ, ਪਰ ਇਹ ਉਹਨਾਂ ਗੱਲਬਾਤਾਂ ਦਾ ਮਾਲਕ ਨਹੀਂ ਬਣਦਾ।
ਮਨੁੱਖ ਸੰਦਰਭ, ਫੈਸਲਾ-ਸ਼ਕਤੀ ਅਤੇ ਜ਼ਿੰਮੇਵਾਰੀ ਲਿਆਉਂਦੇ ਹਨ। ਉਹ ਬਦਲੇ, ਨੈਤਿਕਤਾ, ਗਾਹਕੀ ਰਿਸ਼ਤਿਆਂ ਅਤੇ ਸੰਗਠਨ ਦੇ ਜਟਿਲ ਵੇਰਵਿਆਂ ਨੂੰ ਸਮਝਦੇ ਹਨ।
AI ਤੇਜ਼ੀ ਅਤੇ ਪੈਟਰਨ ਯਾਦ ਰੱਖਣ ਦੀ ਯੋਗਤਾ ਦਿੰਦਾ ਹੈ। ਇਹ ਯੂਜ਼ਰ ਸਟੋਰੀਜ਼ ਡ੍ਰਾਫਟ ਕਰ ਸਕਦਾ ਹੈ, UI ਵਿਆਰਿਅੰਟ ਪੇਸ਼ ਕਰ ਸਕਦਾ ਹੈ, ਇਮਪਲੀਮਿੰਟੇਸ਼ਨ ਦ੍ਰਿਸ਼ਟਿਕੋਣ ਸੁਝਾ ਸਕਦਾ ਹੈ, ਆਮ ਨਾਕਾਮੀਆਂ ਦੀ ਸੂਚੀ ਬਣਾ ਸਕਦਾ ਹੈ, ਅਤੇ ਮਿੰਟਾਂ ਵਿੱਚ ਟੈਸਟ ਵਿਚਾਰ ਜਨਰੇਟ ਕਰ ਸਕਦਾ ਹੈ। ਜਦ ਟੀਮ ਨੂੰ ਵਿਕਲਪ ਚਾਹੀਦੇ ਹਨ—ਨਿਰੀਰਣਾ ਨਹੀਂ—ਤਦ ਇਹ ਖ਼ਾਸ ਤੌਰ 'ਤੇ ਲਾਭਦਾਇਕ ਹੁੰਦਾ ਹੈ।
AI ਨੂੰ ਜੋਨ-ਬੰਨ੍ਹ ਕੇ "ਟੋਪੀਆਂ" ਦਿੱਤੀਆਂ ਜਾ ਸਕਦੀਆਂ ਹਨ, ਉਦਾਹਰਣ ਲਈ:
"AI ਨੂੰ ਮਾਲਕ ਨਾ ਬਣਾਉਣ" ਲਈ ਫੈਸਲਾ ਅਧਿਕਾਰ ਸਪੱਸ਼ਟ ਰੱਖੋ: ਮਨੁੱਖ ਲੋੜਾਂ ਨੂੰ ਮਨਜ਼ੂਰ ਕਰਦੇ ਹਨ, ਡਿਜ਼ਾਈਨ ਕਬੂਲਦੇ ਹਨ, ਕੋਡ ਮਰਜ ਕਰਦੇ ਹਨ, ਅਤੇ ਰਿਲੀਜ਼ ਸਾਈਨ-ਆਫ਼ ਕਰਦੇ ਹਨ। AI ਆਉਟਪੁਟ ਨੂੰ ਇੱਕ ਡਰਾਫਟ ਸਮਝੋ ਜੋ ਸਮੀਖਿਆ, ਟੈਸਟ ਅਤੇ ਸਪੱਸ਼ਟ ਤਰਕ ਨਾਲ ਭਰੋਸਾ ਜਿੱਤਣੀ ਚਾਹੀਦੀ ਹੈ—ਸਿਰਫ਼ ਉਸਦੀ ਭਰੋਸੇਯੋਗ ਅਵਾਜ਼ ਦੇ ਅਧਾਰ 'ਤੇ ਨਹੀਂ।
ਅਮਲ ਵਿੱਚ, ਇਹ ਉਹ ਜਗ੍ਹਾ ਹੈ ਜਿੱਥੇ "vibe-coding" ਪਲੇਟਫਾਰਮ ਮਦਦਗਾਰ ਹੋ ਸਕਦੇ ਹਨ: ਇੱਕ ਸੰਰਚਿਤ ਚੈਟ ਵਰਕਫਲੋ ਨੀਅਤ, ਪਾਬੰਦੀਆਂ, ਡਰਾਫਟ ਅਤੇ ਸੋਧ ਇੱਕ ਥਾਂ ਰੱਖਣ ਨੂੰ ਆਸਾਨ ਬਣਾਉਂਦਾ—ਇਸ ਦੇ ਨਾਲ-ਨਾਲ ਮਨੁੱਖੀ ਮਨਜ਼ੂਰੀਆਂ ਨੂੰ ਸਹੀ ਦਰਵਾਜਿਆਂ 'ਤੇ ਲਾਗੂ ਕਰਨਾ ਵੀ ਯਕੀਨੀ ਬਣਾਉਂਦਾ ਹੈ।
ਬਹੁਤ ਸਾਰੇ ਪ੍ਰਾਜੈਕਟ ਇੱਕ ਫੀਚਰ-ਸੂਚੀ ਨਾਲ ਸ਼ੁਰੂ ਹੁੰਦੇ ਹਨ: "ਸਾਨੂੰ ਇੱਕ ਡੈਸ਼ਬੋਰਡ, ਨੋਟੀਫਿਕੇਸ਼ਨ, ਅਤੇ ਪੇਮੈਂਟ ਚਾਹੀਦੇ ਹਨ." ਪਰ ਫੀਚਰ ਅਨੁਮਾਨ ਹੁੰਦੇ ਹਨ। ਇੱਕ ਬਿਹਤਰ ਸ਼ੁਰੂਆਤ—ਖ਼ਾਸ ਕਰਕੇ ਜਦੋਂ AI ਵੀ ਕਮਰੇ ਵਿੱਚ ਹੋ—ਇੱਕ ਸਪੱਸ਼ਟ ਸਮੱਸਿਆ ਬਿਆਨ ਹੈ ਜੋ ਦੱਸਦਾ ਹੈ ਕੌਣ ਸੰਘਰਸ਼ ਕਰ ਰਿਹਾ ਹੈ, ਅਜਿਹਾ ਹੁਣ ਕੀ ਹੋ ਰਿਹਾ ਹੈ, ਅਤੇ ਇਹ ਕਿਉਂ ਜਰੂਰੀ ਹੈ।
AI ਟੂਲ ਨੂੰ "ਮੇਰੇ ਲਈ ਇੱਕ ਟਾਸਕ ਐਪ ਬਣਾਓ" ਪੁੱਛਣ ਦੀ ਬਜਾਇ, ਕੋਸ਼ਿਸ਼ ਕਰੋ: "ਸਾਡੀ ਸਪੋਰਟ ਟੀਮ ਸਮਾਂ ਖੋ ਰਹੀ ਹੈ ਕਿਉਂਕਿ ਗਾਹਕ ਬੇਨਤੀਆਂ ਪੰਜ ਜਗ੍ਹਾ ਆ ਰਹੀਆਂ ਹਨ ਅਤੇ ਕੁਝ ਵੀ ਐਂਡ-ਟੂ-ਐਂਡ ਟਰੈਕ ਨਹੀਂ ਹੁੰਦਾ।" ਉਹ ਇਕ ਵਾਕ ਦਿਸ਼ਾ ਅਤੇ ਸੀਮਾਵਾਂ ਦਿੰਦਾ ਹੈ। ਇਹ ਮਨੁੱਖਾਂ ਅਤੇ AI ਦੋਹਾਂ ਲਈ ਉਹ ਰਾਹ ਸਪੱਸ਼ਟ ਕਰਦਾ ਹੈ ਜੋ ਸਥਿਤੀ ਵਿੱਚ ਠੀਕ ਬੈਠਦਾ ਹੈ, ਨਾ ਕਿ ਸਿਰਫ਼ ਆਮ ਪੈਟਰਨ।
AI ਖੁਸ਼ੀ-ਖ਼ੁਸ਼ੀ ਉਹ ਵਿਕਲਪ ਬਣਾਏਗਾ ਜੋ ਤੁਹਾਡੀਆਂ ਹਕੀਕਤੀ ਸੀਮਾਵਾਂ ਨੂੰ ਨਜ਼ਰਅੰਦਾਜ਼ ਕਰਦੇ ਹਨ ਜਦ ਤੱਕ ਤੁਸੀਂ ਉਨ੍ਹਾਂ ਨੂੰ ਨਾ ਦਰਜ ਕਰੋ। ਉਹ ਪਾਬੰਦੀਆਂ ਲਿਖੋ ਜੋ ਤੁਸੀਂ ਪਹਿਲਾਂ ਹੀ ਜਾਣਦੇ ਹੋ:
ਇਹ ਪਾਬੰਦੀਆਂ "ਨਕਾਰਾਤਮਕ" ਨਹੀਂ ਹਨ। ਇਹ ਡਿਜ਼ਾਈਨ ਇਨਪੁੱਟ ਹਨ ਜੋ ਦੁਬਾਰਾ ਕੰਮ ਕਰਨ ਤੋਂ ਰੋਕਦੇ ਹਨ।
"ਕੁਸ਼ਲਤਾ ਸੁਧਾਰੋ" ਦੀ ਤਰ੍ਹਾਂ ਦਾ ਲਕਸ਼ ਤਿਆਰ ਕਰਨਾ ਮੁਸ਼ਕਲ ਹੈ। ਇਸਨੂੰ ਉਹਨਾਂ ਨਤੀਜਿਆਂ ਵਿੱਚ ਬਦਲੋ ਜੋ ਤੁਸੀਂ ਮੈਪ ਕਰ ਸਕਦੇ ਹੋ:
ਜਦ ਨਤੀਜੇ ਟੈਸਟਯੋਗ ਹੁੰਦੇ ਹਨ, AI ਤੁਹਾਡੀ ਸਹਾਇਤਾ ਨਾਲ ਐਕਸੈਪਟੈਂਸ ਉਦਾਹਰਣ ਅਤੇ ਐਜ ਕੇਸ ਜਨਰੇਟ ਕਰ ਸਕਦਾ ਹੈ ਜੋ ਤੁਹਾਡੇ ਸਫਲਤਾ ਦੀ ਪਰਿਭਾਸ਼ਾ ਨਾਲ ਮੇਲ ਖਾਂਦੇ ਹਨ।
ਹੱਲ ਮੰਗਣ ਤੋਂ ਪਹਿਲਾਂ, ਇੱਕ-ਪੰਨਾ ਬ੍ਰੀਫ ਲਿਖੋ: ਸਮੱਸਿਆ ਬਿਆਨ, ਯੂਜ਼ਰ, ਮੌਜੂਦਾ ਵਰਕਫਲੋ, ਪਾਬੰਦੀਆਂ, ਅਤੇ ਸਫਲਤਾ ਮਾਪਦੰਡ। ਫਿਰ AI ਨੂੰ ਬੁਲਾਓ ਕਿ ਦਾਰੋਮਦਾਂ ਨੂੰ ਚੁਣੌਤੀ ਦੇਵੇ, ਵਿਕਲਪ ਪੇਸ਼ ਕਰੇ, ਅਤੇ ਖਤਰੇ ਲਿਖੇ। ਇਹ ਲੜੀ ਗੱਲਬਾਤ ਨੂੰ ਜ਼ਮੀਨੀ ਬਣਾਉਂਦੀ ਹੈ—ਅਤੇ "ਸਹੀ ਗਲਤ ਚੀਜ਼" ਬਣਾਉਣ ਦੇ ਦਿਨ ਬਚਾਉਂਦੀ ਹੈ।
ਲੋੜਾਂ ਉਸ ਵੇਲੇ ਸਭ ਤੋਂ ਵਧੀਆ ਕੰਮ ਕਰਦੀਆਂ ਹਨ ਜਦੋਂ ਉਹ ਗੱਲਬਾਤ ਵਰਗੀ ਪੜ੍ਹਨ ਵਿੱਚ ਆਉਂਦੀਆਂ ਹਨ: ਸਪੱਸ਼ਟ ਨੀਅਤ, "ਹੁੰਦਾ" ਦਾ ਸਾਂਝਾ ਸਮਝ, ਅਤੇ ਕੁਝ ਵਿਵਰਤ ਉਦਾਹਰਨ। AI ਇਸਨੂੰ ਤੇਜ਼ ਕਰ ਸਕਦਾ ਹੈ—ਜੇ ਤੁਸੀਂ ਇਸਨੂੰ ਇੱਕ ਡਰਾਫਟਿੰਗ ਸਾਥੀ ਮੰਨੋ, ਨਾਂ ਕਿ ਇੱਕ ਔਰੈਕਲ।
"ਫੀਚਰ X ਲਈ ਲੋੜਾਂ ਲਿਖੋ" ਕਹਿਣ ਦੀ ਬਜਾਇ, AI ਨੂੰ ਇੱਕ ਭੂਮਿਕਾ, ਪਾਬੰਦੀਆਂ ਅਤੇ ਦਰਸ਼ਕ ਦਿਓ। ਉਦਾਹਰਣ:
ਫਿਰ ਜੋ ਇਹ ਵਾਪਸ ਲਿਆਉਂਦਾ ਹੈ ਉਸ ਦੀ ਤੀਬਰ ਸਮੀਖਿਆ ਕਰੋ ਅਤੇ ਕੱਟ-ਛਾਂਟ ਕਰੋ। ਸਟੋਰੀਜ਼ ਨੂੰ ਇਸੇਨੇ ਦੀ ਰੋਜ਼ਾਨਾ ਬਣਾਉਣਯੋਗ ਰੱਖੋ—ਦਿਨਾਂ ਵਿੱਚ ਨਾਂ ਬਲਕਿ ਘੰਟਿਆਂ ਵਿੱਚ ਬਣਾਈਆਂ ਜਾਣ। ਜੇਕਰ ਇੱਕ ਸਟੋਰੀ ਵਿੱਚ ਕਈ ਲਕਸ਼ ਹੋਣ ("ਅਤੇ ਵੀ..."), ਤਾਂ ਇਸਨੂੰ ਵੱਖ-ਵੱਖ ਕਰ ਦਿਓ।
ਇੱਕ ਯੂਜ਼ਰ ਸਟੋਰੀ ਬਿਨਾਂ ਉਦਾਹਰਨ ਦੇ ਅਕਸਰ ਇੱਕ ਨਰਮ ਅਨੁਮਾਨ ਹੁੰਦੀ ਹੈ। ਹਕੀਕਤੀ ਪਰਿਦਰਸ਼ ਦਿਓ:
ਤੁਸੀਂ AI ਨੂੰ 10 ਉਦਾਹਰਨਾਂ ਲਿਖਣ ਲਈ ਕਹਿ ਸਕਦੇ ਹੋ, ਜਿਸ ਵਿੱਚ 3 ਐਜ ਕੇਸ ਅਤੇ 2 ਫੇਲਿਯਰ ਸਟੇਟ ਸ਼ਾਮਲ ਹੋਣ। ਅਤੇ ਕਹੋ ਕਿ ਉਹ ਕਿਸੇ ਵੀ ਧਾਰਣਾ ਨੂੰ ਨਿਸ਼ਾਨ ਲਗਾਏ ਜੋ ਉਸਨੇ ਲੈਣੀ ਪਈ।
"ਪਤਲਾ ਪਰ ਟੈਸਟਯੋਗ" ਦਾ ਉਦੇਸ਼ ਰੱਖੋ। ਇੱਕ ਪੰਨੇ ਦੇ ਤਿੱਖੇ ਨਿਯਮ ਦੱਸਣ ਵਾਲੇ ਟਕੜੇ ਦਸ ਪੰਨਿਆਂ ਦੇ ਧੁੰਦਲੇ ਗੱਥੇ ਨਾਲੋਂ ਬਿਹਤਰ ਹਨ। ਜੇ ਕੁਝ ਬਿਲਿੰਗ, ਪ੍ਰਾਈਵੇਸੀ ਜਾਂ ਯੂਜ਼ਰ ਭਰੋਸੇ ਨੂੰ ਪ੍ਰਭਾਵਿਤ ਕਰਦਾ ਹੈ, ਤਦ ਉਸਨੂੰ ਖੁੱਲ ਕੇ ਲਿਖੋ।
ਗਲਤਫਹਿਮੀਆਂ ਅਕਸਰ ਸ਼ਬਦਾਂ ਕਾਰਨ ਹੁੰਦੀਆਂ ਹਨ, ਕੋਡ ਕਾਰਨ ਨਹੀਂ। ਇੱਕ ਛੋਟਾ ਗਲੌਸੇਰੀ ਬਣਾਓ—ਬਿਹਤਰ ਇਹ ਕਿ ਲੋੜਾਂ ਵਾਲੀ ਥਾਂ ਵਿੱਚ:
ਉਸ ਗਲੌਸੇਰੀ ਨੂੰ ਆਪਣੀਆਂ AI ਪ੍ਰਾਂਪਟਾਂ ਵਿੱਚ ਫੀਡ ਕਰੋ ਤਾਂ ਕਿ ਡਰਾਫਟ ਲਗਾਤਾਰ ਰਹਿਣ ਅਤੇ ਟੀਮ ਮਿਲ ਕੇ ਰਹਿ ਸਕੇ।
ਵਧੀਆ ਡਿਜ਼ਾਈਨ ਆਮ ਤੌਰ 'ਤੇ ਇੱਕੱਠੇ ਨਹੀਂ ਆਉਂਦਾ। ਇਹ ਲੂਪਾਂ ਰਾਹੀਂ ਤਿੱਖਾ ਹੁੰਦਾ ਹੈ: ਸਕੇਚ, ਟੈਸਟ, ਸੋਧ, ਅਤੇ ਦੁਹਰਾਉ—ਇਸ ਦੌਰਾਨ ਮੂਲ ਨੀਅਤ ਬਰਕਰਾਰ ਰੱਖਦੇ ਹੋਏ। AI ਇਹ ਲੂਪ ਤੇਜ਼ ਕਰ ਸਕਦਾ ਹੈ, ਪਰ ਮਕਸਦ ਸਿਰਫ਼ ਤੇਜ਼ੀ ਨਹੀਂ—ਸੋਚ ਛੱਡਣ ਤੋਂ ਬਚ ਕੇ ਜਲਦੀ ਸਿੱਖਣਾ ਹੈ।
ਸਕ੍ਰੀਨਾਂ ਨਾਲ ਸ਼ੁਰੂ ਕਰਨ ਦੀ ਬਜਾਇ ਫਲੋ ਨਾਲ ਸ਼ੁਰੂ ਕਰੋ। ਯੂਜ਼ਰ ਦਾ ਲਕਸ਼ ਅਤੇ ਪਾਬੰਦੀਆਂ ਵੇਰਵਾ ਕਰੋ ("ਮੋਬਾਈਲ 'ਤੇ ਪਹਿਲੀ ਵਾਰੀ ਵਾਲਾ, ਇੱਕ ਹੱਥ ਨਾਲ, ਘੱਟ ਧਿਆਨ"), ਫਿਰ AI ਨੂੰ ਕੁਝ ਫਲੋ ਵਿਕਲਪ ਪ੍ਰਸਤਾਵਿਤ ਕਰਨ ਲਈ ਕਹੋ। ਓਥੇ ਤੋਂ, ਇਸਨੂੰ ਵਾਇਰਫਰੇਮ-ਸਤ੍ਹਰ ਦੀਆਂ ਲੇਆਉਟਸ ਅਤੇ ਬਟਨ ਲੇਬਲ, ਐਰਰ ਸੁਨੇਹੇ, ਮਦਦਗਾਰ ਟੈਕਸਟ ਵਰਗੀਆਂ ਮਾਈਕ੍ਰੋਕਾਪੀ ਵੈਰੀਐਂਟਾਂ ਡਰਾਫਟ ਕਰਨ ਲਈ ਵਰਤੋਂ ਜੋ ਤੁਹਾਡੇ ਬ੍ਰਾਂਡ ਟੋਨ ਨਾਲ ਮਿਲਦੇ ਹਨ।
ਇੱਕ ਲਾਭਦਾਇਕ ਰਿਧਮ ਇਹ ਹੈ: ਮਨੁੱਖ ਨੀਅਤ ਅਤੇ ਟੋਨ ਤੈਅ ਕਰਦਾ ਹੈ, AI ਵਿਕਲਪ ਜਨਰੇਟ ਕਰਦਾ ਹੈ, ਮਨੁੱਖ ਚੁਣਦਾ ਅਤੇ ਸੋਧਦਾ ਹੈ, AI ਸਕ੍ਰੀਨਾਂ 'ਤੇ ਸੰਗਤੀ ਬਨਾਉਂਦਾ ਹੈ।
ਜਦੋਂ ਤੁਸੀਂ "ਤਿੰਨ ਵੱਖ-ਵੱਖ ਦ੍ਰਿਸ਼ਟਿਕੋਣ ਦਿਓ" ਕਹਿੰਦੇ ਹੋ, ਤਾਂ ਬਦਲਿਆਂ ਨਾਲ-ਨਾਲ ਟਰੇਡਆਫ਼ ਵੀ ਮੰਗੋ, ਸਿਰਫ਼ ਵੈਰੀਐਂਟ ਨਹੀਂ। ਉਦਾਹਰਣ: "Option A ਕਦਮ ਘਟਾਉਂਦੀ ਹੈ, Option B ਯੂਜ਼ਰ ਦੀ ਚਿੰਤਾ ਘਟਾਉਂਦੀ ਹੈ, Option C ਸੰਵੇਦਨਸ਼ੀਲ ਡੇਟਾ ਇਕੱਤਰ ਕਰਨ ਤੋਂ ਬਚਦੀ ਹੈ।" ਸ਼ੁਰੂ ਵਿੱਚ ਟਰੇਡਆਫ਼ ਦੀ ਤੁਲਨਾ ਕਰਨ ਨਾਲ ਟੀਮ ਨੂੰ ਗਲਤ ਸਮੱਸਿਆ ਸੁਧਾਰਨ 'ਤੇ ਪੌਲਿਸ਼ ਕਰਨ ਤੋਂ ਰੋਕਦੇ ਹੋ।
ਕਿਸੇ ਚੀਜ਼ ਨੂੰ "ਅੰਤਿਮ" ਮਹਿਸੂਸ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਤੇਜ਼ ਚੈਕ ਕਰੋ: ਰੰਗ ਦਾ ਕਾਂਟਰਾਸਟ, ਕੀਬੋਰਡ ਨੈਵੀਗੇਸ਼ਨ ਉਮੀਦਾਂ, ਪੜ੍ਹਨਯੋਗ ਐਰਰ ਸਟੇਟਸ, ਸਾਹਿਬੀ ਭਾਸ਼ਾ, ਅਤੇ ਸਕਰੀਨ-ਰੀਡਰ ਵਰਗੇ ਐਜ ਕੇਸ। AI ਸੰਭਵ ਮੁੱਦਿਆਂ ਦੀ ਨਿਸ਼ਾਨਦਿਹੀ ਕਰ ਸਕਦਾ ਹੈ ਅਤੇ ਸੁਧਾਰ ਪੇਸ਼ ਕਰ ਸਕਦਾ ਹੈ, ਪਰ ਮਨੁੱਖ ਫੈਸਲਾ ਕਰਦਾ ਹੈ ਕਿ ਤੁਹਾਡੇ ਯੂਜ਼ਰਾਂ ਲਈ ਕੀ ਕਬੂਲਯੋਗ ਹੈ।
ਫੀਡਬੈਕ ਅਕਸਰ ਘੁੰਮਰਦਾ ਹੁੰਦਾ ਹੈ: "ਇਹ ਉਲਝਣ ਵਾਲਾ ਲੱਗਦਾ ਹੈ।" ਅਸਲ ਕਾਰਨ ਨੂੰ ਸਾਫ਼ ਭਾਸ਼ਾ ਵਿੱਚ ਕੈਪਚਰ ਕਰੋ, ਫਿਰ ਇਸਨੂੰ ਖਾਸ ਸੋਧਾਂ ਵਿੱਚ ਬਦਲੋ ("ਇਸ ਕਦਮ ਦਾ ਨਾਮ ਬਦਲੋ", "ਪ੍ਰੀਵਿਊ ਸ਼ਾਮਲ ਕਰੋ", "ਚੋਣਾਂ ਘਟਾਓ"). AI ਨੂੰ ਕਹੋ ਕਿ ਫੀਡਬੈਕ ਨੂੰ ਇੱਕ ਛੋਟੀ ਸੋਧ-ਸੂਚੀ ਵਿੱਚ ਸੰਖੇਪ ਕਰੇ ਜੋ ਮੂਲ ਨੀਅਤ ਨਾਲ ਜੁੜੀ ਹੋਵੇ, ਤਾਂ ਕਿ ਇਟਰੇਸ਼ਨ ਦਿਸ਼ਾ ਵਿੱਚ ਰਹਿਣ।
ਆਰਕੀਟੈਕਚਰ ਪਹਿਲਾਂ ਇੱਕ ਇਕ-ਵਾਰੇ ਦਾ ਨਕਸ਼ਾ ਮੰਨਿਆ ਜਾਂਦਾ ਸੀ: ਇਕ ਪੈਟਰਨ ਚੁਣੋ, ਡਾਇਗ੍ਰਾਮ ਬਣਾਓ, ਅਤੇ ਇਸਨੂੰ ਲਾਗੂ ਕਰੋ। AI ਦੇ ਆਉਣ ਨਾਲ, ਇਹ ਬਿਹਤਰ ਤਰੀਕੇ ਨਾਲ ਇਕ ਵਾਰਤਾਲਾਪ ਬਣ ਜਾਂਦਾ ਹੈ—ਉਤਪਾਦ ਦੀਆਂ ਲੋੜਾਂ, ਡਿਲਿਵਰੀ ਦੀ ਰਫਤਾਰ, ਲੰਬੇ ਸਮੇਂ ਦੀ ਸੰਭਾਲ, ਅਤੇ ਟੀਮ ਦੀ ਯੋਗਤਾ ਦੇ ਦਰਮਿਆਨ।
ਇਕ عملي ਰਵੱਈਆ ਇਹ ਹੈ ਕਿ ਮਨੁੱਖ ਆਰਕੀਟੈਕਚਰ ਫੈਸਲੇ ਲਵੇ ਤੇ AI ਵੱਲੋਂ ਤਿਆਰ ਕੀਤੇ ਵਿਕਲਪ ਦੇਖੇ ਜਾਣ। ਤੁਸੀਂ ਸੰਦਰਭ ਦਿਓ (ਪਾਬੰਦੀਆਂ, ਟੀਮ ਦੀ ਹੁਨਰ-ਸਤਰ, ਅੰਮੇਦਿਤ ਟ੍ਰੈਫਿਕ, ਅਨੁਕੂਲਤਾ ਲੋੜਾਂ), ਅਤੇ AI ਨੂੰ 2–3 ਢਾਂਚੇ ਸਪੱਸ਼ਟ ਟਰੇਡਆਫ਼ ਨਾਲ ਪੁੱਛੋ।
ਫਿਰ ਮਨੁੱਖੀ ਭਾਗ ਕਰੋ: ਉਹ ਚੁਣੋ ਜੋ ਕਾਰੋਬਾਰ ਅਤੇ ਟੀਮ ਨਾਲ ਮੇਲ ਖਾਂਦਾ ਹੈ। ਜੇ ਕੋਈ ਵਿਕਲਪ "ਕੂਲ" ਹੈ ਪਰ ਓਪਰੇਸ਼ਨਲ ਜਟਿਲਤਾ ਵਧਾਂਦਾ ਹੈ, ਤਾਂ ਉਹਨੂੰ ਛੱਡ ਦਿਓ।
ਜ਼ਿਆਦਾਤਰ ਆਰਕੀਟੈਕਚਰ ਸਮੱਸਿਆਵਾਂ ਸਰਹੱਦਾਂ ਦੀਆਂ ਹੁੰਦੀਆਂ ਹਨ। ਪਰਿਭਾਸ਼ਿਤ ਕਰੋ:
AI ਖਾਮੀਆਂ ਨਿਸ਼ਾਨ ਲਗਾ ਸਕਦਾ ਹੈ ("ਜੇ ਯੂਜ਼ਰ ਨੂੰ ਹਟਾਇਆ ਗਿਆ ਤਾਂ ਕੀ ਹੁੰਦਾ?") ਪਰ ਸਰਹੱਦੀ ਫੈਸਲੇ ਸਪੱਸ਼ਟ ਅਤੇ ਟੈਸਟਯੋਗ ਰਹਿਣੇ ਚਾਹੀਦੇ ਹਨ।
ਇੱਕ ਹਲਕਾ ਫੈਸਲਾ ਲਾਗ ਰੱਖੋ ਜੋ ਦਰਸਾਉਂਦਾ ਕਿ ਤੁਸੀਂ ਕੀ ਚੁਣਿਆ, ਕਿਉਂ, ਅਤੇ ਕਦੋਂ ਮੁੜ ਵੇਖੋਗੇ। ਇੱਕ ਛੋਟਾ ਨੋਟ ਪ੍ਰਤੀ ਫੈਸਲਾ, ਕੋਡਬੇਸ ਦੇ ਨੇੜੇ (ਉਦਾਹਰਣ ਲਈ, docs/decisions) ਵਿੱਚ ਰੱਖੋ।
ਇਸ ਨਾਲ ਆਰਕੀਟੈਕਚਰ ਲੋਕ-ਕਥਾ ਬਣਨ ਤੋਂ ਬਚਦੀ ਹੈ—ਅਤੇ AI ਸਹਾਇਤਾ ਜ਼ਿਆਦਾ ਸੁਰੱਖਿਅਤ ਬਣਦੀ ਹੈ ਕਿਉਂਕਿ ਪ੍ਰਣਾਲੀ ਕੋਲ ਲਿਖਤੀ ਨੀਅਤ ਰੈਫਰੈਂਸ ਹੋਵੇਗੀ।
ਜਦ ਦਲੀਲਾਂ ਘੁੰਮਣ ਲੱਗਦੀਆਂ ਹਨ, ਪੁੱਛੋ: "ਅਜ ਦੀਆਂ ਲੋੜਾਂ ਪੂਰੀਆਂ ਕਰਨ ਲਈ ਸਭ ਤੋਂ ਸਧਾਰਣ ਵਰਜਨ ਕੀ ਹੈ ਜੋ ਕੱਲ੍ਹ ਨੂੰ ਰੋਕੇ ਨਾ?" AI ਨੂੰ ਕਹੋ ਕਿ ਇੱਕ ਨ੍ਯੂਨਤਮ ਵਰਕ ਕਰਨ ਵਾਲਾ ਆਰਕੀਟੈਕਚਰ ਅਤੇ ਇੱਕ ਸਕੇਲ-ਰੇਡੀ ਅੱਪਗਰੇਡ ਰਾਹ ਵੀ ਪੇਸ਼ ਕਰੇ, ਤਾਂ ਕਿ ਤੁਸੀਂ ਹੁਣ ਸਪਸ਼ਟ ਰਾਹ ਨਾਲ ਭੇਜ ਸਕੋ ਅਤੇ ਅਮਲੀ ਸਬੂਤ ਨਾਲ ਵਿਕਸਿਤ ਹੋਵੋ।
AI ਨੂੰ ਇੱਕ ਤੇਜ਼ ਜੂਨੀਅਰ ਟੀਮਮੈਟ ਵਜੋਂ ਸੋਚੋ: ਡਰਾਫਟ ਕਰਨ ਵਿੱਚ ਮਾਹਿਰ, ਅੰਤਿਮ ਰੂਪ ਲਈ ਜ਼ਿੰਮੇਵਾਰ ਨਹੀਂ। ਮਨੁੱਖ ਆਰਕੀਟੈਕਚਰ, ਨਾਮਕਰਨ, ਅਤੇ ਫੈਸਲੇ ਦਾ "ਕਿਉਂ" ਨਿਰਧਾਰਤ ਕਰਨ ਵਿੱਚ ਰਹਿਣ; AI "ਕਿਵੇਂ" ਨੂੰ ਤੇਜ਼ ਕਰਦਾ ਹੈ। ਮਕਸਦ ਸੋਚ ਨੂੰ ਆਉਟਸੋਰਸ ਕਰਨਾ ਨਹੀਂ, ਪਰ ਨੀਅਤ ਅਤੇ ਸਾਫ਼, ਸਮੀਖਿਆਯੋਗ ਇੰਪਲੀਮਿੰਟੇਸ਼ਨ ਦਰਮਿਆਨ ਦੀ ਦੂਰੀ ਛੋਟੀ ਕਰਨਾ ਹੈ।
ਛੋਟੀ, ਟੈਸਟਯੋਗ ਸਲਾਈਸ (ਇੱਕ ਫੰਕਸ਼ਨ, ਇੱਕ ਐਂਡਪੌਇੰਟ, ਇੱਕ ਕੰਪੋਨੈਂਟ) ਲਈ ਮੰਗ ਕਰਕੇ ਸ਼ੁਰੂ ਕਰੋ। ਫਿਰ ਤੁਰੰਤ ਮੋਡ ਬਦਲੇ: ਡਰਾਫਟ ਦੀ ਸਮੀਖਿਆ ਕਰੋ ਜੇ ਇਹ ਸਪੱਸ਼ਟਤਾ, ਸੰਗਤੀ, ਅਤੇ ਮੌਜੂਦਾ ਰਿਵਾਜਾਂ ਨਾਲ ਫਿੱਟ ਹੈ।
ਕੁਝ ਲਾਭਦਾਇਕ ਪ੍ਰਾਂਪਟ ਪੈਟਰਨ ਹਨ:
POST /invoices handler using our existing validation helper and repository pattern." (ਇਸ ਤਰ੍ਹਾਂ ਦੇ ਨਿਰਦੇਸ਼ ਦਿੱਤੇ ਜਾ ਸਕਦੇ ਹਨ)(ਉਪਰੋਕਤ ਕਮਾਂਡਾਂ ਵਿੱਚ ਜੋ code ਟੁਕੜੇ ਹਨ, ਉਹ ਕੋਡ ਇਸ਼ਾਰਿਆਂ ਵਜੋਂ ਬਰਕਰਾਰ ਰੱਖੋ।)
AI ਸਹੀ ਕੋਡ ਤਿਆਰ ਕਰ ਸਕਦਾ ਹੈ ਜੋ ਫਿਰ ਵੀ "ਅਲੱਗ" ਮਹਿਸੂਸ ਹੁੰਦਾ ਹੈ। ਮਨੁੱਖ ਹੇਠਾਂ ਦੇ ਕੰਮਾਂ ਲਈ ਜ਼ਿੰਮੇਵਾਰ ਰਹਿਣ:
data/item ਨਾ ਹੋਣ)ਜੇ ਤੁਹਾਡੇ ਕੋਲ ਇੱਕ ਛੋਟਾ ਸਟਾਇਲ ਸਨੈਪਸ਼ਾਟ ਹੈ (ਕੁਝ ਪਸੰਦੀਦਾ ਪੈਟਰਨ ਦੀਆਂ ਉਦਾਹਰਨਾਂ), ਉਸਨੂੰ ਪ੍ਰਾਂਪਟਾਂ ਵਿੱਚ ਸ਼ਾਮਲ ਕਰੋ ਤਾਂ ਆਉਟਪੁਟ ਥਾਂਅਨੁਸਾਰ ਬਨੇ।
AI ਨੂੰ ਵਿਕਲਪ ਪ੍ਰਦਾਨ ਕਰਨ ਅਤੇ ਥੱਕਾ ਦੇਣ ਵਾਲੀਆਂ ਸਮੱਸਿਆਵਾਂ ਤੁਰੰਤ ਠੀਕ ਕਰਨ ਲਈ ਵਰਤੋਂ, ਪਰ ਇਸਨੂੰ ਆਪਣੇ ਆਮ ਸਮੀਖਿਆ ਦਰਵਾਜਿਆਂ ਨੂੰ ਛੱਡਣ ਨਾ ਦਿਓ। ਪੂਲ ਰਿਕਵੇਸਟਾਂ ਨੂੰ ਛੋਟਾ ਰੱਖੋ, ਉਹੀ ਜਾਂਚ ਚਲਾਓ, ਅਤੇ ਵਿਸ਼ੇਸ਼ ਕਰਕੇ ਐਜ ਕੇਸਾਂ ਅਤੇ ਸੁਰੱਖਿਆ-ਸੰਵੇਦਨਸ਼ੀਲ ਕੋਡ ਲਈ ਇੱਕ ਮਨੁੱਖ ਦਾ ਪੁਸ਼ਟੀ ਮਨਜ਼ੂਰ ਕਰੋ।
ਜੇ ਤੁਸੀਂ ਇਸ "ਕੋ-ਰਾਈਟਿੰਗ" ਲੂਪ ਨੂੰ ਕੁਦਰਤੀ ਬਣਾਉਣਾ ਚਾਹੁੰਦੇ ਹੋ, ਤਾਂ ਉਨ੍ਹਾਂ ਟੂਲਾਂ ਜਿਵੇਂ Koder.ai ਗੱਲਬਾਤ ਨੂੰ ਖੁਦ ਵਰਕਸਪੇਸ ਬਣਾਉਂਦੀਆਂ ਹਨ: ਤੁਸੀਂ ਯੋਜਨਾ ਬਣਾਉਣ, ਢਾਂਚਾ ਬਣਾਉਣ ਅਤੇ ਇਟਰੇਟ ਕਰਨ ਲਈ ਗੱਲ ਕਰਦੇ ਹੋ, ਫਿਰ ਵੀ ਸੋਰਸ ਕੰਟਰੋਲ ਨਿਯਮ (ਸਮੀਖਿਆਯੋਗ ਡਿਫਜ਼, ਟੈਸਟ, ਮਨੁੱਖੀ ਮਨਜ਼ੂਰੀ) ਬਰਕਰਾਰ ਰਹਿੰਦੀ ਹੈ। ਇਹ ਖ਼ਾਸ ਕਰਕੇ ਪ੍ਰਭਾਵੀ ਹੈ ਜਦੋਂ ਤੁਸੀਂ ਤੇਜ਼ ਪ੍ਰੋਟੋਟਾਈਪ ਚਾਹੁੰਦੇ ਹੋ ਜੋ ਪ੍ਰੋਡਕਸ਼ਨ ਤੱਕ ਪਹੁੰਚ ਸਕਦੇ ਹਨ—React ਵੈੱਬ, Go + PostgreSQL ਬੈਕਐਂਡ, ਅਤੇ Flutter ਮੋਬਾਈਲ—ਬਿਨਾਂ ਪ੍ਰਕਿਰਿਆ ਨੂੰ ਵੱਖ-ਵੱਖ ਪ੍ਰਾਂਪਟਾਂ ਦਾ ਢੇਰ ਬਣਾਉਣ ਦੇ।
ਟੈਸਟਿੰਗ ਉਹ ਜਗ੍ਹਾ ਹੈ ਜਿੱਥੇ ਗੱਲਬਾਤ ਮਿਆਰੀ ਹੁੰਦੀ ਹੈ। ਤੁਸੀਂ ਦਿਨਾਂ ਤੱਕ ਨੀਅਤ ਅਤੇ ਡਿਜ਼ਾਈਨ ਦੀ ਚਰਚਾ ਕਰ ਸਕਦੇ ਹੋ, ਪਰ ਇੱਕ ਚੰਗੀ ਟੈਸਟ ਸੂਟ ਇੱਕ ਸਾਦਾ ਸਵਾਲ ਉੱਤਰਦੀ ਹੈ: "ਜੇ ਅਸੀਂ ਇਹ ਭੇਜਦੇ ਹਾਂ, ਕੀ ਇਹ ਉਸ ਤਰੀਕੇ ਨਾਲ ਵਿਹਾਰ ਕਰੇਗਾ ਜਿਉਂਦਾ ਅਸੀਂ ਵਾਅਦਾ ਕੀਤਾ ਸੀ?" ਜਦੋਂ AI ਕੋਡ ਲਿਖਣ ਵਿੱਚ ਸਹਾਇਤਾ ਕਰਦਾ ਹੈ, ਟੈਸਟ ਹੋਰ ਵੀ ਮੁੱਲਵਾਨ ਹੋ ਜਾਂਦੇ ਹਨ ਕਿਉਂਕਿ ਉਹ ਫੈਸਲਿਆਂ ਨੂੰ ਨਜ਼ਰਅੰਦਾਜ਼ ਨਹੀਂ, ਬਲਕਿ ਨਿਰਣਯਤ ਨਤੀਜੇਾਂ 'ਤੇ ਅਧਾਰਿਤ ਕਰਦੇ ਹਨ।
ਜੇ ਤੁਹਾਡੇ ਕੋਲ ਪਹਿਲਾਂ ਹੀ ਯੂਜ਼ਰ ਸਟੋਰੀਜ਼ ਅਤੇ ਐਕਸੈਪਟੈਂਸ ਮਾਪਦੰਡ ਹਨ, ਤਾਂ AI ਨੂੰ ਉਹਨਾਂ ਤੋਂ ਸਿੱਧਾ ਟੈਸਟ ਕੇਸ ਪੇਸ਼ ਕਰਨ ਲਈ ਕਹੋ। ਵਰਤੋਂਯੋਗ ਭਾਗ ਮਾਤਰ ਨਹੀਂ—ਉਸਦੀ ਕਵਰੇਜ ਮਹੱਤਵਪੂਰਨ ਹੈ: ਐਜ ਕੇਸ, ਬਾਊਂਡਰੀ ਵੈਲਯੂਜ਼, ਅਤੇ "ਜੇ ਯੂਜ਼ਰ ਕੁਝ ਅਣਉਮੀਦ ਕੀਤੇ" ਸਥਿਤੀਆਂ।
ਇੱਕ ਪ੍ਰਯੋਗਿਕ ਪ੍ਰਾਂਪਟ: "ਇਨ੍ਹਾਂ ਐਕਸੈਪਟੈਂਸ ਮਾਪਦੰਡਾਂ ਦੇ ਆਧਾਰ 'ਤੇ ਟੈਸਟ ਕੇਸ ਦੀ ਸੂਚੀ ਦਿਓ ਜਿਸ ਵਿੱਚ ਇਨਪੁੱਟ, ਉਮੀਦ ਕੀਤੀ ਆਉਟਪੁੱਟ ਅਤੇ ਫੇਲਿਯਰ ਮੋਡ ਦਰਸਾਏ ਜਾਣ।" ਇਹ ਅਕਸਰ ਉਹ ਗੱਲਾਂ ਸਾਹਮਣੇ ਲਿਆਉਂਦਾ ਹੈ ਜੋ ਮਿਸ ਹੋ ਰਹੀਆਂ ਹਨ (ਟਾਈਮਆਊਟ, ਅਧਿਕਾਰ, ਐਰਰ ਸੁਨੇਹੇ) ਜਦੋਂ ਹਾਲੇ ਇਹ ਸਸਤਾ ਹੈ ਸੋਧ ਕਰਨ ਲਈ।
AI ਯੂਨਿਟ ਟੈਸਟ ਤੇਜ਼ੀ ਨਾਲ ਡਰਾਫਟ ਕਰ ਸਕਦਾ ਹੈ, ਨਾਲ ਹੀ ਹਕੀਕਤੀ ਨਮੂਨਾ ਡੇਟਾ ਅਤੇ ਨੈਗੇਟਿਵ ਟੈਸਟ (ਗਲਤ ਫਾਰਮੇਟ, ਰੇਂਜ ਤੋਂ ਬਾਹਰ ਮੁੱਲ, ਡੁਪਲੀਕੇਟ ਸਬਮਿਸ਼ਨ, ਅਧੂਰੇ ਫੇਲ) ਵੀ। ਇਨ੍ਹਾਂ ਨੂੰ ਪਹਿਲੀ ਡਰਾਫਟ ਸਮਝੋ।
AI ਕਿਸ ਵਿਚ ਖ਼ਾਸ ਤੌਰ 'ਤੇ ਚੰਗਾ ਹੈ:
ਮਨੁੱਖਾਂ ਨੂੰ ਅਜੇ ਵੀ ਟੈਸਟਾਂ ਦੀ ਸਹੀਤਾ ਅਤੇ ਹਕੀਕਤੀ ਵਿਹਾਰ ਲਈ ਸਮੀਖਿਆ ਕਰਨੀ ਹੁੰਦੀ ਹੈ। ਕੀ ਟੈਸਟ ਵਾਸਤਵ ਵਿੱਚ ਲੋੜ ਦੀ ਜਾਂਚ ਕਰ ਰਿਹਾ ਹੈ—ਆਂਪਨੀ ਇੰਪਲੀਮਿੰਟੇਸ਼ਨ ਨੂੰ ਮੁੜ-ਦੋਹਰਾ ਰਿਹਾ ਹੈ? ਕੀ ਅਸੀਂ ਪ੍ਰਾਈਵੇਸੀ/ਸੁਰੱਖਿਆ ਸਥਿਤੀਆਂ ਛੱਡ ਰੱਖੀਆਂ ਹਨ? ਕੀ ਅਸੀਂ ਸਹੀ ਪੱਧਰ (ਯੂਨਿਟ ਬਨਾਮ ਇੰਟੀਗ੍ਰੇਸ਼ਨ) 'ਤੇ ਜਾਂਚ ਕਰ ਰਹੇ ਹਾਂ?
ਮਜ਼ਬੂਤ "ਡਨ" ਦੀ ਪਰਿਭਾਸ਼ ਵਿੱਚ ਸਿਰਫ਼ "ਟੈਸਟ ਮੌਜੂਦ ਹਨ" ਨਹੀਂ ਹੋਣਾ ਚਾਹੀਦਾ। ਇਸ ਵਿੱਚ ਸ਼ਾਮਲ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ: ਪਾਸ ਹੋ ਰਹੇ ਟੈਸਟ, ਐਕਸੈਪਟੈਂਸ ਮਾਪਦੰਡ ਦੀ ਮਾਨਨਯੋਗ ਕਵਰੇਜ, ਅਤੇ ਅਪਡੇਟ ਕੀਤੀਆਂ ਡੌਕਸ (ਭਾਵੇਂ ਇੱਕ ਛੋਟਾ نوਟ /docs ਜਾਂ ਇੱਕ ਚੇਂਜਲੌਗ ਐਂਟਰੀ ਹੋਵੇ)। ਇਸ ਤਰ੍ਹਾਂ, ਸ਼ਿਪਿੰਗ ਇਕ ਉਮੀਦ ਦਾ ਕਦਮ ਨਹੀਂ—ਇੱਕ ਸਾਹਮਣੇ ਲਿਆਇਆ ਦਾਅਵਾ ਹੁੰਦਾ ਹੈ।
ਅਕਸਰ ਟੀਮਾਂ ਦਸਤਾਵੇਜ਼ ਨਾ ਕਰਨ ਤੋਂ ਨਫ਼ਰਤ ਨਹੀਂ ਕਰਦੀਆਂ—ਉਹ ਉਸੇ ਕੰਮ ਨੂੰ ਦੋ ਵਾਰੀ ਕਰਨ ਜਾਂ ਉਸਨੂੰ ਭੁੱਲ ਜਾਣ ਤੋਂ ਨਫ਼ਰਤ ਕਰਦੀਆਂ ਹਨ। AI ਦੇ ਨਾਲ, ਦਸਤਾਵੇਜ਼ "ਬਾਅਦ ਵਿੱਚ ਓਹੁ ਅਤਿਰਿਕਤ ਕੰਮ" ਤੋਂ ਬਦਲ ਕੇ ਹਰ ਮਹੱਤਵਪੂਰਨ ਬਦਲ 'ਤੇ ਚਲਦੀ ਉਤਪਾਦ ਬਣ ਸਕਦੀ ਹੈ।
ਜਦ ਇੱਕ ਫੀਚਰ ਮਰਜ ਹੁੰਦਾ ਹੈ, AI ਉਸ ਬਦਲਾਅ ਨੂੰ ਮਨੁੱਖੀ-ਪਠਯੋਗ ਭਾਸ਼ਾ ਵਿੱਚ ਤਬਦੀਲ ਕਰਨ ਵਿੱਚ ਮਦਦ ਕਰ ਸਕਦਾ ਹੈ: ਚੇਂਜਲੌਗ, ਰਿਲੀਜ਼ ਨੋਟ, ਅਤੇ ਛੋਟੇ ਯੂਜ਼ਰ ਗਾਈਡ। ਮੂਲ ਚੀਜ਼ ਇਹ ਹੈ ਕਿ ਤੁਸੀਂ ਇਸਨੂੰ ਸਹੀ ਸੂਚਨਾ ਦਿਓ—ਕਾਮਿਟ ਸੰਖੇਪ, ਪੂਲ ਰਿਕਵੇਸਟ ਵਰਣਨ, ਅਤੇ ਇੱਕ ਛੋਟਾ ਨੋਟ ਕਿ ਕਿਉਂ ਤਬਦੀਲ ਕੀਤਾ ਗਿਆ—ਫਿਰ ਆਉਟਪੁਟ ਨੂੰ ਉਸੇ ਤਰ੍ਹਾਂ ਸਮੀਖਿਆ ਕਰੋ ਜਿਵੇਂ ਤੁਸੀਂ ਕੋਡ ਸਮੀਖਿਆ ਕਰਦੇ ਹੋ।
"ਉਨ੍ਹਾ ਨੇ ਪ੍ਰਦਰਸ਼ਨ ਸੁਧਾਰਿਆ" ਵਰਗੀਆਂ ਧੁੰਦਲੀਆਂ ਅਪਡੇਟਾਂ ਦੀ ਥਾਂ "ਤਾਰੀਖ ਦੁਆਰਾ ਛਾਂਟਣ 'ਤੇ ਸਰਚ ਨਤੀਜੇ ਤੇਜ਼ ਹੋ ਗਏ" ਵਰਗੇ ਨਿਰਧਾਰਤ ਬਿਆਨ ਲਿਖੋ ਅਤੇ ਪ੍ਰਭਾਵ ਸਪਸ਼ਟ ਦਿਓ ("ਕੋਈ ਕਾਰਵਾਈ ਜ਼ਰੂਰੀ ਨਹੀਂ" ਬਨਾਮ "ਆਪਣਾ ਖਾਤਾ ਮੁੜ ਜੁੜਵਾਉ")।
ਅੰਦਰੂਨੀ ਡੌਕਸ ਸਭ ਤੋਂ ਵਧੀਆ ਹਨ ਜਦ ਉਹ ਰਾਤ ਦੇ 2 ਵਜੇ ਘਟਿਤ ਸਮੱਸਿਆਵਾਂ ਨੂੰ ਸਵਾਲ-ਜੋੜੀਆਂ ਤਰੀਕੇ ਨਾਲ ਜਵਾਬ ਦੇ ਸਕਣ:
AI ਇਹਨਾਂ ਨੂੰ ਮੌਜੂਦਾ ਸਮੱਗਰੀ (ਸਹਾਇਤਾ ਥ੍ਰੈਡ, ਘਟਨਾ ਨੋਟ, ਕਨਫਿਗ ਫਾਈਲਾਂ) ਤੋਂ ਡਰਾਫਟ ਕਰ ਸਕਦਾ ਹੈ, ਪਰ ਮਨੁੱਖਾਂ ਨੂੰ ਤਾਜ਼ਾ ਵਾਤਾਵਰਣ 'ਤੇ ਕਦਮ ਸਹੀ ਬਣਾ ਕੇ ਜਾਂਚ ਕਰਨੀ ਚਾਹੀਦੀ ਹੈ।
ਸਭ ਤੋਂ ਸਧਾਰਾ ਨਿਯਮ: ਹਰ ਪ੍ਰੋਡਕਟ ਬਦਲਾਅ ਇਕ ਡੌਕਸ ਬਦਲਾਅ ਨਾਲ ਭੇਜੋ। ਪੂਲ ਰਿਕਵੇਸਟਾਂ ਵਿੱਚ ਇੱਕ ਚੈਕਲਿਸਟ ਆਈਟਮ ਸ਼ਾਮਲ ਕਰੋ ("Docs ਅਪਡੇਟ ਕੀਤੇ?"), ਅਤੇ AI ਨੂੰ ਪੁਰਾਣੀ ਅਤੇ ਨਵੀਂ ਵਿਹਾਰ ਦੀ ਤੁਲਨਾ ਕਰਕੇ ਸੁਝਾਅ ਦੇਣ ਦਿਓ।
ਜਦ ਲੋੜ ਹੋਵੇ, ਪਾਠਕਾਂ ਨੂੰ ਸਹਾਇਤਾ ਲਈ ਸਮਰਥਕ ਪੰਨਿਆਂ ਦੀ ਥਾਂ ਦਿਓ (ਜਿਵੇਂ /blog ਲਈ ਡੂੰਘੀ ਵਿਆਖਿਆ, ਜਾਂ /pricing ਲਈ ਯੋਜਨਾ-ਖਾਸ ਫੀਚਰ)। ਇਸ ਤਰ੍ਹਾਂ, ਦਸਤਾਵੇਜ਼ ਇੱਕ ਜੀਵਤੀ ਨਕਸ਼ਾ ਬਣ ਜਾਂਦੀ ਹੈ—ਭੁੱਲੀ ਫੋਲਡਰ ਨਹੀਂ।
ਭੇਜਣਾ ਗੱਲਬਾਤ ਦਾ ਅੰਤ ਨਹੀਂ—ਇਹ ਸਮਾਂ ਹੈ ਜਦ ਗੱਲਬਾਤ ਹੋਰ ਇਮਾਨਦਾਰ ਹੋ ਜਾਂਦੀ ਹੈ। ਜਦ ਅਸਲ ਯੂਜ਼ਰ ਉਤਪਾਦ ਨੂੰ ਛੂਹਦੇ ਹਨ, ਤੁਸੀਂ ਇਹ ਜਾਣਨਾ ਛੱਡਦੇ ਹੋ ਕਿ ਕਿਸ ਤਰ੍ਹਾਂ ਇਹ ਵਿਹਾਰ ਕਰਦਾ ਹੈ ਅਤੇ ਤੁਸੀਂ ਦੇਖਦੇ ਹੋ ਕਿ ਇਹ ਲੋਕਾਂ ਦੇ ਕੰਮ ਵਿੱਚ ਕਿਵੇਂ ਫਿੱਟ ਹੁੰਦਾ ਹੈ।
ਪਰੋਡਕਸ਼ਨ ਨੂੰ ਇਕ ਹੋਰ ਇਨਪੁਟ ਸਟਰਿਮ ਵਜੋਂ ਸਲੋਚੋ, ਖੋਜ ਇੰਟਰਵਿਊ ਅਤੇ ਅੰਦਰੂਨੀ ਸਮੀਖਿਆਵਾਂ ਦੇ ਨਾਲ। ਰਿਲੀਜ਼ ਨੋਟ, ਚੇਂਜਲੌਗ, ਅਤੇ ਇੱਥੇ-ਉੱਥੇ "ਪਤਾ-ਲੱਗੀਆਂ ਮੁੱਦਿਆਂ" ਦੀ ਸੂਚੀ ਇਹ ਦਰਸਾਉਂਦੀ ਹੈ ਕਿ ਤੁਸੀਂ ਸੁਣ ਰਹੇ ਹੋ—ਅਤੇ ਇਹ ਯੂਜ਼ਰਾਂ ਨੂੰ ਜਗ੍ਹਾ ਦਿੰਦੇ ਹਨ ਆਪਣਾ ਫੀਡਬੈਕ ਲਗਾਉਣ ਲਈ।
ਉਪਯੋਗੀ ਫੀਡਬੈਕ ਅਕਸਰ ਇੱਕ ਸਾਫ਼ ਪੈਕੇਟ ਵਿੱਚ ਨਹੀਂ ਆਉਂਦਾ। ਤੁਸੀਂ ਆਮ ਤੌਰ 'ਤੇ ਇਹਨਾਂ ਨੂੰ ਕਈ ਸਰੋਤਾਂ ਤੋਂ ਕੱਢੋਗੇ:
ਮਕਸਦ ਇਹਨਾਂ ਸਿਗਨਲਾਂ ਨੂੰ ਇਕ ਲੜੀ ਵਿੱਚ ਜੋੜਨਾ ਹੈ: ਕਿਹੜੀ ਸਮੱਸਿਆ ਸਭ ਤੋਂ ਜ਼ਿਆਦਾ ਘਟਦੀ ਹੈ, ਕਿਹੜੀ ਸਭ ਤੋਂ ਮਹਿੰਗੀ ਹੈ, ਅਤੇ ਕਿਹੜੀ ਸਭ ਤੋਂ ਸਥਿਤੀ-ਯੋਗ ਹੈ।
AI ਹਫਤਾਵਾਰ ਸਪੋਰਟ ਥੀਮਾਂ ਨੂੰ ਸੰਖੇਪ ਕਰ ਸਕਦਾ ਹੈ, ਮਿਲਦੇ-ਜੁਲਦੇ ਸ਼ਿਕਾਇਤਾਂ ਨੂੰ ਗਰੁੱਪ ਕਰ ਸਕਦਾ ਹੈ, ਅਤੇ ਠੀਕ-ਕੀਮਤ ਵਾਲੀ ਸੁਧਾਰਾਂ ਦੀ ਤਰਤੀਬ ਬਣਾਉਂਦਾ ਹੈ। ਇਹ "ਅਗਲੇ ਕਦਮ" ("ਵੈਲੀਡੇਸ਼ਨ ਸ਼ਾਮਲ ਕਰੋ", "ਇਨਬੋਰਡਿੰਗ ਕਾਪੀ ਸੁਧਾਰੋ", "ਇਸ ਇਵੈਂਟ ਨੂੰ ਇੰਸਟਰੂਮੈਂਟ ਕਰੋ") ਪ੍ਰਸਤਾਵਿਤ ਕਰ ਸਕਦਾ ਹੈ ਅਤੇ ਇੱਕ ਛੋਟਾ ਪੈਚ ਸਪੈਕ ਵੀ ਜਨਰੇਟ ਕਰ ਸਕਦਾ ਹੈ।
ਪਰ ਤਰਜ਼ੀਹ ਫ਼ੈਸਲਾ ਫਿਰ ਵੀ ਪ੍ਰੋਡਕਟ ਦਾ ਫੈਸਲਾ ਹੁੰਦਾ ਹੈ: ਪ੍ਰਭਾਵ, ਜੋਖ਼ਮ, ਅਤੇ ਸਮਾਂਮਿਆਦ ਮਹੱਤਵਪੂਰਨ ਹਨ। AI ਨੂੰ ਪੜ੍ਹਾਈ ਅਤੇ ਛਾਂਟਣ ਲਈ ਵਰਤੋਂ—ਨਾਹ ਕਿ ਫ਼ੈਸਲਾ ਆਉਟਸੋਰਸ ਕਰਨ ਲਈ।
ਤਬਦੀਲੀਆਂ ਇਸ ਤਰੀਕੇ ਨਾਲ ਭੇਜੋ ਕਿ ਤੁਸੀਂ ਨਿਯੰਤਰਣ ਵਿੱਚ ਰਹੋ। ਫੀਚਰ ਫਲੈਗ, ਮੰਚ-ਵਾਰ ਰੋਲਆਊਟ, ਅਤੇ ਤੇਜ਼ ਰੋਲਬੈਕ ਰਿਲੀਜ਼ ਨੂੰ پرਯੋਗਾਂ ਵਾਂਗ ਬਣਾ ਦਿੰਦੇ ਹਨ ਨਾ ਕਿ ਸਟੇਕ। ਇੱਕ ਪ੍ਰਯੋਗਿਕ ਬੇਸਲਾਈਨ ਲਈ, ਹਰ ਤਬਦੀਲੀ ਨਾਲ ਇੱਕ ਰਿਵਰਟ ਯੋਜਨਾ ਦਿਓ—ਬਾਅਦ 'ਚ ਨਹੀਂ।
ਇਹ ਉਹ ਜਗ੍ਹਾ ਵੀ ਹੈ ਜਿਥੇ ਪਲੇਟਫਾਰਮ ਫੀਚਰ ਵਾਸਤਵਿਕ ਜੋਖ਼ਮ ਘਟਾ ਸਕਦੇ ਹਨ: ਸਨੈਪਸ਼ਾਟ ਅਤੇ ਰੋਲਬੈਕ, ਆਡੀਟ-ਅਨੁਕੂਲ ਚੇਨ-ਹਿਸਟਰੀ, ਅਤੇ ਇੱਕ-ਕਲਿੱਕ ਡਿਪਲੌਇਜ਼ "ਅਸੀਂ ਮੁੜ ਵਾਪਸ ਆ ਸਕਦੇ ਹਾਂ" ਦੀ ਆਸ ਨੂੰ ਆਪਰੇਸ਼ਨਲ ਆਦਤ ਬਣਾਉਂਦੇ ਹਨ।
AI ਨਾਲ ਕੰਮ ਕਰਨ ਨਾਲ ਵਿਕਾਸ ਤੇਜ਼ ਹੁੰਦਾ ਹੈ, ਪਰ ਇਹ ਨਵੇਂ ਤਰੀਕੇ ਦੇ ਗਲਤੀਆਂ ਵੀ ਲਿਆਉਂਦਾ ਹੈ। ਮਕਸਦ "ਮਾਡਲ ਤੇ ਭਰੋਸਾ" ਜਾਂ "ਮਾਡਲ 'ਤੇ ਅਣਭਰੋਸਾ" ਨਹੀਂ—ਇੱਕ ਐਸਾ ਵਰਕਫਲੋ ਬਣਾਉਣਾ ਹੈ ਜਿੱਥੇ ਭਰੋਸਾ ਜਾਂਚਾਂ ਰਾਹੀਂ ਕਮਾਇਆ ਜਾਵੇ, ਨਾ ਕਿ ਅਨੁਭਾਵ ਤੋਂ।
AI APIs, ਲਾਇਬ੍ਰੇਰੀਆਂ ਜਾਂ ਤੁਹਾਡੇ ਕੋਡਬੇਸ ਬਾਰੇ "ਤੱਥ" ਗੜਬੜ ਕਰ ਸਕਦਾ ਹੈ (hallucinate). ਇਹ ਲੁਕੋ-ਝਾਕੇ ਧਾਰਣਾਵਾਂ ਲਿਆ ਸਕਦਾ ਹੈ (ਉਦਾਹਰਣ ਲਈ, "ਯੂਜ਼ਰ ਹਮੇਸ਼ਾਂ ਆਨਲਾਈਨ ਹਨ", "ਤਾਰੀਖ UTC ਵਿੱਚ ਹਨ", "UI ਸਿਰਫ਼ ਅੰਗਰੇਜ਼ੀ ਹੈ"). ਅਤੇ ਇਹ ਕਚਹਿਰੀ ਕੋਡ ਪੈਦਾ ਕਰ ਸਕਦਾ ਹੈ: ਖੁਸ਼-ਪਾਥ ਡੈਮੋ 'ਤੇ ਪਾਸ ਪਰ ਲੋਡ, ਅਜਿਹੀਆਂ ਐਨਪੁੱਟਾਂ ਜਾਂ ਹਕੀਕਤੀ ਡੇਟਾ 'ਤੇ ਫੇਲ।
ਇੱਕ ਸਧਾਰਨ ਆਦਤ ਮਦਦਗਾਰ ਹੈ: ਜਦ AI ਕੋਈ ਹੱਲ ਪੇਸ਼ ਕਰੇ, ਤਾਂ ਇਸਨੂੰ ਕਹੋ ਕਿ ਧਾਰਣਾਵਾਂ, ਐਜ ਕੇਸ, ਅਤੇ ਫੇਲਿਯਰ ਮੋਡ ਦੀ ਸੂਚੀ ਦਿਓ, ਫਿਰ ਫੈਸਲਾ ਕਰੋ ਕਿ ਕਿਹੜੀਆਂ ਧਾਰਣਾਵਾਂ ਨੂੰ ਸਪੱਸ਼ਟ ਲੋੜਾਂ ਜਾਂ ਟੈਸਟਾਂ ਬਣਾਇਆ ਜਾਏ।
ਪ੍ਰਾਂਪਟਾਂ ਨੂੰ ਸਾਂਝਾ ਵਰਕਸਪੇਸ ਸਮਝੋ: ਪਾਸਵਰਡ, API ਕੀ, ਨਿੱਜੀ ਗਾਹਕ ਡੇਟਾ, ਐਕਸੈੱਸ ਟੋਕਨ, ਅੰਦਰੂਨੀ ਘਟਨਾ ਰਿਪੋਰਟ, ਅਣਰਿਲੀਜ਼ਡ ਮਾਲੀ ਜਾਣਕਾਰੀ, ਜਾਂ ਗੁਪਤ ਸੋਰਸ ਕੋਡ ਨਾਹ ਪੇਸਟ ਕਰੋ ਬਿਨਾਂ ਸੰਸਥਾ ਦੀ ਮਨਜ਼ੂਰੀ ਵਾਲੇ ਟੂਲਾਂ ਦੇ।
ਇਸਦੀ ਜਗ੍ਹਾ ਪਰਪਾਰੀ ਕਰਨਾ ਅਤੇ ਸੰਖੇਪ ਵਰਤੋਂ: ਅਸਲੀ ਮੁੱਲਾਂ ਨੂੰ ਸਥਾਨਧਾਰਕਾਂ ਨਾਲ ਬਦਲੋ, ਸਕੀਮਾਂ ਦਾ ਵੇਰਵਾ ਦਿਓ ਬਜਾਏ ਟੇਬਲ ਡੰਪ ਕਰਨ ਦੇ, ਅਤੇ ਘੱਟੋ-ਘੱਟ ਟੁਕੜੇ ਸਾਂਝੇ ਕਰੋ ਜੋ ਮੁੱਦੇ ਨੂੰ ਦੁਹਰਾ ਸਕਣ।
ਜੇ ਤੁਹਾਡੀ ਸੰਸਥਾ ਕੋਲ ਡੇਟਾ ਰਿਹਾਇਸ਼ੀ ਮਰਯਾਦਾਵਾਂ ਹਨ, ਤਾਂ ਯਕੀਨੀ ਬਣਾਓ ਕਿ ਤੁਹਾਡੇ ਟੂਲ ਉਹਨਾਂ ਦੀ ਪਾਲਣਾ ਕਰ ਸਕਦੇ ਹਨ। ਕੁਝ ਆਧੁਨਿਕ ਪਲੇਟਫਾਰਮ (ਜਿਨ੍ਹਾਂ ਵਿੱਚ Koder.ai ਵੀ ਸ਼ਾਮਲ ਹੈ) ਗਲੋਬਲ ਤੌਰ 'ਤੇ ਵੰਡੇ ਹੋਏ ਢਾਂਚੇ 'ਤੇ ਚਲਦੇ ਹਨ ਅਤੇ ਅਲੱਗ-ਅਲੱਗ ਖੇਤਰਾਂ ਵਿੱਚ ਐਪ ਤੈਨਾਤ ਕਰ ਸਕਦੇ ਹਨ ਤਾਂ ਕਿ ਡੇਟਾ ਪ੍ਰਾਈਵੇਸੀ ਅਤੇ ਸਰਹੱਦੀ-ਪਾਰ ਟ੍ਰਾਂਸਫਰ ਲੋੜਾਂ ਬਣ ਸਕਣ—ਪਰ ਨੀਤੀ ਪਹਿਲਾਂ ਆਉਂਦੀ ਹੈ।
ਯੂਜ਼ਰ-ਮੁਖੀ ਫੀਚਰ ਅਣਇਨਸਾਫੀ ਡਿਫੌਲਟਸ ਰੱਖ ਸਕਦੇ ਹਨ—ਸਿਫਾਰਸ਼ਾਂ, ਕੀਮਤ, ਯੋਗਤਾ, ਮੋਡਰੇਸ਼ਨ, ਇੱਥੇ-ਤੱਕ ਕਿ ਫਾਰਮ ਵਾਲੀ ਵੈਧਤਾ ਵੀ। ਹਲਕੀ-ਫੁਲਕੀ ਜਾਂਚ ਸ਼ਾਮਲ ਕਰੋ: ਵੱਖ-ਵੱਖ ਨਾਂ ਅਤੇ ਲੋਕਲਜ਼ ਦੇ ਨਾਲ ਟੈਸਟ ਕਰੋ, "ਕੌਣ ਨੁਕਸਾਨ ਵਿਚ ਆ ਸਕਦਾ ਹੈ" ਦਾ ਮੁਲਾਂਕਣ ਕਰੋ, ਅਤੇ ਜਦੋਂ ਫੈਸਲੇ ਲੋਕਾਂ ਨੂੰ ਪ੍ਰਭਾਵਿਤ ਕਰਦੇ ਹਨ ਤਾਂ ਵਿਆਖਿਆ ਅਤੇ ਅਪੀਲ ਦੇ ਰਸਤੇ ਦਿਓ।
AI ਆਉਟਪੁਟ ਨੂੰ ਸਮੀਖਿਆਯੋਗ ਬਣਾਓ: ਮਨੁੱਖੀ ਕੋਡ ਸਮੀਖਿਆ ਲਾਜ਼ਮੀ ਕਰੋ, ਖਤਰਨਾਕ ਬਦਲਾਵਾਂ ਲਈ ਮਨਜ਼ੂਰੀਆਂ, ਅਤੇ ਇੱਕ ਆਡੀਟ ਟ੍ਰੇਲ ਰੱਖੋ (ਪ੍ਰਾਂਪਟ, ਡਿਫਜ਼, ਫੈਸਲੇ)। ਇਸਨੂੰ ਆਟੋਮੇਟਿਕ ਟੈਸਟਾਂ ਅਤੇ ਲਿੰਟਿੰਗ ਨਾਲ ਜੋੜੋ ਤਾਂ ਕਿ ਗੁਣਵੱਤਾ ਗੱਲਬਾਤ ਦਾ ਵਿਸ਼ਾ ਨਾ ਰਹੇ—ਸਿਰਫ਼ ਉਹ ਇਸ ਨੂੰ ਪ੍ਰਾਪਤ ਕਰਨ ਦਾ ਸਭ ਤੋਂ ਤੇਜ਼ ਰਾਹ ਹੋਵੇ।
AI "ਡਿਵੈਲਪਰਾਂ ਨੂੰ ਬਦਲ" ਨਹੀਂ ਕਰੇਗਾ, ਬਲਕਿ ਧਿਆਨ ਨੂੰ ਦੁਬਾਰਾ ਵੰਡੇਗਾ। ਸਭ ਤੋਂ ਵੱਡਾ ਬਦਲਾਅ ਇਹ ਹੋਵੇਗਾ ਕਿ ਦਿਨ ਦਾ ਵਧੀਆ ਹਿੱਸਾ ਨੀਅਤ ਸਪੱਸ਼ਟ ਕਰਨ ਅਤੇ ਨਤੀਜਿਆਂ ਦੀ ਜਾਂਚ ਕਰਨ ਵਿੱਚ ਲੰਘੇਗਾ, ਜਦਕਿ ਰੁਟੀਨ ਕੰਮ (ਸਪਸ਼ਟ ਫੈਸਲਿਆਂ ਨੂੰ ਬੋਇਲਰਪਲੇਟ ਕੋਡ ਵਿੱਚ ਤਬਦੀਲ) ਘੱਟ ਵਕਤ ਲਵੇਗਾ।
ਪ੍ਰੋਡਕਟ ਅਤੇ ਇੰਜੀਨੀਅਰਿੰਗ ਦੀਆਂ ਭੂਮਿਕਾਵਾਂ ਬਿਹਤਰ ਸਮੱਸਿਆ ਬਿਆਨਾਂ ਅਤੇ ਤੰਗ ਫੀਡਬੈਕ ਲੂਪਾਂ ਦੇ ਆਲੇ-ਦੁਆਲੇ ਮੁਰਝਾਇਆਂ ਜਾਣਗੀਆਂ। ਡਿਵੈਲਪਰ ਜ਼ਿਆਦਾ ਸਮਾਂ ਲਗਾਊਂਗੇ:
ਇਸਦੇ ਨਾਲ-ਨਾਲ, AI ਜ਼ਿਆਦਾ ਪਹਿਲੇ-ਡ੍ਰਾਫਟ ਕੰਮ ਸੰਭਾਲੇਗਾ: ਸਕੈਫੋਲਡ ਸਕ੍ਰੀਨ, ਐਂਡਪੌਇੰਟ ਵਾਇਰਿੰਗ, ਮਾਈਗ੍ਰੇਸ਼ਨ ਜਨਰੇਟ ਕਰਨਾ, ਅਤੇ ਰਿਫੈਕਟਰ ਸੁਝਾਅ—ਫਿਰ ਮਨੁੱਖ ਇਸ ਕੰਮ ਨੂੰ ਨਿਰਣਾ ਕਰਨ ਲਈ ਵਾਪਸ ਲੈਂਦੇ ਹਨ।
AI ਤੋਂ ਮੁੱਲ ਲੈਣ ਵਾਲੀਆਂ ਟੀਮਾਂ ਆਮ ਤੌਰ 'ਤੇ ਸਿਰਫ਼ ਟੂਲ ਨਹੀਂ—ਸੰਚਾਰ ਦੀ ਮਾਸਪੇਸ਼ੀ ਬਣਾਉਂਦੀਆਂ ਹਨ। ਲਾਭਦਾਇਕ ਹੁਨਰ:
ਇਹ ਸਿਰਫ਼ ਚਤੁਰ ਪ੍ਰਾਂਪਟ ਨਹੀਂ—ਇਹ ਹੋਰ ਸਪਸ਼ਟ ਹੋਣ ਬਾਰੇ ਹੈ।
ਉੱਚ-ਕਾਰੀਗਰ ਟੀਮਾਂ ਇਹ ਮਿਆਰੀਕਰਨ ਕਰਨਗੀਆਂ ਕਿ ਉਹ ਸਿਸਟਮ ਨਾਲ ਕਿਵੇਂ ਗੱਲ ਕਰਦੀਆਂ ਹਨ। ਇੱਕ ਲਘੂ ਪ੍ਰੋਟੋਕੋਲ ਹੋ ਸਕਦਾ ਹੈ:
/docs ਵਿੱਚ ਛੋਟੀ ਨੋਟ) ਤਾਂ ਜੋ ਅਗਲੀ ਇਟਰੇਸ਼ਨ ਇਨਫ਼ਰਡ ਹੋਵੇਅੱਜ, AI ਸਭ ਤੋਂ ਵਧੀਆ ਡਰਾਫਟ ਤੇਜ਼ ਕਰਨ, ਡਿਫਜ਼ ਨਾਂਕੇ ਸੰਖੇਪ ਕਰਨ, ਟੈਸਟ ਕੇਸ ਜਨਰੇਟ ਕਰਨ, ਅਤੇ ਸਮੀਖਿਆ ਦੌਰਾਨ ਵਿਕਲਪ ਸੁਝਾਉਣ ਵਿੱਚ ਹੈ। ਅਗਲੇ ਕੁਝ ਸਾਲਾਂ ਵਿੱਚ, ਪ੍ਰੋਜੈਕਟ ਦੇ ਲੰਬੇ-ਕਾਂਟੈਕਸਟ ਯਾਦਦਾਸ਼ਤ ਵਿੱਚ ਸੁਧਾਰ, ਟੂਲ-ਉਪਯੋਗਤਾ (ਟੈਸਟ ਚਲਾਉਣਾ, ਲਾਗ ਪੜ੍ਹਨਾ) ਵਿੱਚ ਜ਼ਿਆਦਾ ਭਰੋਸੇਯੋਗੀ, ਅਤੇ ਕੋਡ-ਡੌਕ-ਟਿਕਟ ਵਿੱਚ ਵੱਧ ਸੰਗਤੀ ਦੀ ਉਮੀਦ ਕਰੋ।
ਸੀਮਿਤ ਕਾਰਕ ਹਮੇਸ਼ਾਂ ਸਫ਼ਤ ਸਪਸ਼ਟਤਾ ਰਹੇਗਾ: ਜੋ ਟੀਮ ਨੀਅਤ ਸਪਸ਼ਟ ਤਰੀਕੇ ਨਾਲ ਵਰਣਨ ਕਰ ਸਕਦੀਆਂ ਹਨ ਉਹ ਪਹਿਲਾਂ ਲਾਭ ਲੈਣਗੀਆਂ। ਜਿੱਤਣ ਵਾਲੀਆਂ ਟੀਮਾਂ ਕੋਲ ਸਿਰਫ਼ "AI ਟੂਲ" ਨਹੀਂ ਹੋਵਣਾ—ਉਨ੍ਹਾਂ ਕੋਲ ਇੱਕ ਦੁਹਰਾਊ ਗੱਲਬਾਤ ਹੋਵੇਗੀ ਜੋ ਨੀਅਤ ਨੂੰ ਸੁਰੱਖਿਅਤ ਰੱਖ ਕੇ ਤੇਜ਼ ਬਣਾਉਂਦੀ ਹੈ।
ਜੇ ਤੁਸੀਂ ਇਸ ਬਦਲਾਅ ਦੀ ਜਾਂਚ ਕਰ ਰਹੇ ਹੋ, ਤਾਂ ਇੱਕ ਵਰਕਫਲੋ ਆਜ਼ਮਾਓ ਜਿੱਥੇ ਗੱਲਬਾਤ, ਯੋਜਨਾ, ਅਤੇ ਇੰਪਲੀਮਿੰਟੇਸ਼ਨ ਇਕੱਠੇ ਰਹਿਣ। ਉਦਾਹਰਣ ਲਈ, Koder.ai chat-driven building, planning mode, source export, deployment/hosting, custom domains, ਅਤੇ snapshots/rollback ਨੂੰ ਸਹਾਰਾ ਦਿੰਦਾ ਹੈ—ਲਾਭਦਾਇਕ ਜਦੋਂ ਤੁਸੀਂ ਤੇਜ਼ ਇਟਰੇਸ਼ਨ ਚਾਹੁੰਦੇ ਹੋ ਬਿਨਾਂ ਨਿਯੰਤਰਣ ਛੱਡਣ ਦੇ। (ਅਤੇ ਜੇ ਤੁਸੀਂ ਰਸਤੇ ਵਿੱਚ ਸਿੱਖਣ ਸਾਂਝਾ ਕਰੋ ਤਾਂ Koder.ai ਵਰਗੇ ਪ੍ਰੋਗਰਾਮ earned-credits ਅਤੇ referral ਵਿਕਲਪਾਂ ਨਾਲ ਖਰਚ ਘਟਾ ਸਕਦੇ ਹਨ)।