ਇੱਕ ਪ੍ਰੈਕਟਿਕਲ ਵਿਚਾਰ: ਕਿਵੇਂ “ਚੰਗਾ ਕਾਫੀ” AI-ਜੈਨਰੇਟਡ ਕੋਡ ਤੁਹਾਨੂੰ ਤੇਜ਼ੀ ਨਾਲ ਸਿੱਖਣ, ਜਲਦੀ ਸ਼ਿਪ ਕਰਨ ਅਤੇ ਸਮੀਖਿਆ-ਟੈਸਟ-ਰੀਫੈਕਟਰ ਰਾਹੀਂ ਗੁਣਵੱਤਾ ਸੁਧਾਰਨ ਵਿੱਚ ਮਦਦ ਕਰਦਾ ਹੈ।
“ਚੰਗਾ ਕਾਫੀ” ਕੋਡ ਗਲਤ ਕੰਮ ਲਈ ਇਕ euphemism ਨਹੀਂ ਹੈ। ਇਹ ਇਕ ਮਨਸੂਹਾ ਮਿਆਰ ਹੈ ਜੋ ਤੁਸੀਂ ਜਾਣਬੂਝ ਕੇ ਰੱਖਦੇ ਹੋ: ਪ੍ਰਸੰਗ ਲਈ ਪਰਯਾਪਤ ਸਹੀ ਅਤੇ ਸੁਰੱਖਿਅਤ, ਪਰ ਇਨਾ ਉੱਚਾ ਨਹੀਂ ਕਿ ਤੁਸੀਂ ਸਿੱਖਣ ਅਤੇ ਸ਼ਿਪ ਕਰਨ ਵਿੱਚ ਰੁਕੇ ਰਹੋ।
ਜਿਆਦਾਤਰ ਪ੍ਰੋਡਕਟ ਕੋਡ ਲਈ (ਖਾਸ ਕਰਕੇ ਸ਼ੁਰੂਆਤੀ ਵਰਜਨਾਂ), “ਚੰਗਾ ਕਾਫੀ” ਆਮ ਤੌਰ 'ਤੇ ਮਤਲਬ ਹੁੰਦਾ ਹੈ:
ਇਹੀ ਮਕਸਦ ਹੈ: ਐਸਾ ਕੋਡ ਜੋ ਕੰਮ ਕਰੇ, ਯੂਜ਼ਰਾਂ ਨੂੰ ਨੁਕਸਾਨ ਨਾ ਪਹੁੰਚਾਏ, ਅਤੇ ਤੁਹਾਨੂੰ ਫਸਾ ਨਾ ਦੇਵੇ।
ਇਹ ਮਿਆਰ ਘਟਾਉਣ ਬਾਰੇ ਨਹੀਂ ਹੈ। ਇਹ ਸਹੀ ਸਮੇਂ 'ਤੇ ਸਹੀ ਮਿਆਰ ਚੁਣਨ ਬਾਰੇ ਹੈ।
ਜੇ ਤੁਸੀਂ ਸਿੱਖ ਰਹੇ ਹੋ ਜਾਂ MVP ਬਣਾ ਰਹੇ ਹੋ, ਤਾਂ ਅਕਸਰ ਇੱਕ ਛੋਟੀ, ਕਾਰਜਕਾਰੀ ਵਰਜਨ ਜਿਸਨੂੰ ਤੁਸੀਂ ਅਸਲ ਵਿੱਚ ਦੇਖ ਸਕੋ, ਉਸ ਤੋਂ ਵੱਧ ਮੁੱਲ ਦਿੰਦਾ ਹੈ ਬਨਾਮ ਇੱਕ ਪੋਲਿਸ਼ ਕੀਤੀ ਵਰਜਨ ਜੋ ਕਦੇ ਵੀ ਸ਼ਿਪ ਨਹੀਂ ਹੁੰਦੀ। “ਚੰਗਾ ਕਾਫੀ” ਤੁਹਾਨੂੰ ਫੀਡਬੈਕ, ਸਪਸ਼ਟਤਾ, ਅਤੇ ਗਤੀ ਦਿੰਦਾ ਹੈ।
AI-ਜੈਨਰੇਟਡ ਕੋਡ ਨੂੰ ਸਭ ਤੋਂ ਵਧੀਆ ਪਹਿਲੀ ਪਰਤ ਵਜੋਂ ਲਓ: ਇਕ ਸਕੈਚ ਜੋ ਕੀ-ਸਟ੍ਰੋਕਸ ਬਚਾਉਂਦਾ ਹੈ ਅਤੇ ਸਰਚਨਾ ਸੁਝਾਉਂਦਾ ਹੈ। ਤੁਹਾਡੀ ਜ਼ਿੰਮੇਵਾਰੀ ਹੈ ਫਰਜ਼ੀਆਂ ਦੀ ਜਾਂਚ ਕਰਨਾ, ਕਿਨਾਰੇ ਲਾਉਣਾ, ਅਤੇ ਇਸਨੂੰ ਆਪਣੇ ਕੋਡਬੇਸ ਨਾਲ ਮੇਲ ਕਰਨਾ।
ਇੱਕ ਸਧਾਰਣ ਨਿਯਮ: ਜੇ ਤੁਸੀਂ ਇਹ ਨਹੀਂ ਸਮਝਾ ਸਕਦੇ ਕਿ ਇਹ ਕੀ ਕਰਦਾ ਹੈ, ਤਾਂ ਇਹ ਅਜੇ “ਚੰਗਾ ਕਾਫੀ” ਨਹੀਂ—ਚਾਹੇ ਇਹ ਕਿੰਨਾ ਭੀ ਵਿਸ਼ਵਾਸਪੂਰਨ ਲੱਗੇ।
ਕੁਝ ਖੇਤਰਾਂ ਵਿੱਚ ਬਹੁਤ ਨਜ਼ਦੀਕ ਤੋਂ ਪਰਫੈਕਸ਼ਨ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ: ਸੁਰੱਖਿਆ-ਸੰਵੇਦਨਸ਼ੀਲ ਫੀਚਰ, ਪੇਮੈਂਟਸ ਅਤੇ ਬਿਲਿੰਗ, ਪ੍ਰਾਈਵੇਸੀ ਅਤੇ ਕੰਪਲਾਇੰਸ, ਸੇਫਟੀ-ਕਾਰਗਿਲ ਪ੍ਰਣਾਲੀਆਂ ਅਤੇ ਅਣਵਾਪਸੀ ਡੇਟਾ ਆਪਰੇਸ਼ਨ। ਇਨ੍ਹਾਂ ਖੇਤਰਾਂ ਵਿੱਚ "ਚੰਗਾ ਕਾਫੀ" ਦੀ ਬਾਰ ਕਾਫੀ ਉੱਚੀ ਹੋ ਜਾਂਦੀ ਹੈ—ਅਤੇ ਆਮ ਤੌਰ 'ਤੇ ਹੌਲੀ ਸ਼ਿਪ ਕਰਨਾ ਠੀਕ ਤਰਜੀਹ ਹੁੰਦੀ ਹੈ।
ਗਤੀ ਸਿਰਫ਼ ਪ੍ਰੇਰਕ ਕੋਟ ਨਹੀਂ—ਇਹ ਇਕ ਸਿੱਖਣ ਦੀ ਰਣਨੀਤੀ ਹੈ। ਜਦੋਂ ਤੁਸੀਂ ਛੋਟੀ ਚੀਜ਼ਾਂ ਤੇਜ਼ੀ ਨਾਲ ਸ਼ਿਪ ਕਰਦੇ ਹੋ, ਤੁਸੀਂ ਛੋਟੀ ਫੀਡਬੈਕ ਲੂਪ ਬਣਾਉਂਦੇ ਹੋ: ਕੁਝ ਲਿਖੋ, ਚਲਾਓ, ਫੇਲ/ਸਫਲ ਵੇਖੋ, ਠੀਕ ਕਰੋ, ਅਤੇ ਦੁਹਰਾਓ। ਇਹ ਦੁਹਰਾਈਆਂ ਹੀ ਅਭਿਆਸ ਹਨ ਜੋ ਕਾਰਗੁਜ਼ਾਰੀ ਬਣਾਉਂਦੀਆਂ ਹਨ।
ਪੋਲਿਸ਼ਿੰਗ ਉਤਪਾਦਕ ਮਹਿਸੂਸ ਹੋ ਸਕਦਾ ਹੈ ਕਿਉਂਕਿ ਇਹ ਕੰਟ੍ਰੋਲ ਕਰਨਯੋਗ ਹੈ: ਥੋੜ੍ਹੀ ਰੀਫੈਕਟਰ, ਨਾਂਬਦਲੀ, UI ਤਿੱਖਾ ਕਰਨਾ, ਫਾਈਲਾਂ ਮੁੜ-ਆਯੋਜਿਤ ਕਰਨਾ। ਪਰ ਸਿੱਖਣਾ ਬੇਹਤਰ ਹੁੰਦਾ ਹੈ ਜਦੋਂ ਹਕੀਕਤ ਵਾਪਸੀ ਦਿਖਾਏ—ਜਦੋਂ ਅਸਲ ਯੂਜ਼ਰ ਗਲਤ ਬਟਨ 'ਤੇ ਕਲਿਕ ਕਰਦੇ ਹਨ, ਐਜ-ਕੇਸ ਤੁਹਾਡਾ ਖੁਸ਼-ਪਾਥ ਤੋੜਦਾ ਹੈ, ਜਾਂ ਡੈਪਲੋਇਮੈਂਟ ਲੋਕਲ ਮਸ਼ੀਨ ਤੋਂ ਵੱਖਰਾ ਵਰਤਾਅ ਦਿਖਾਉਂਦਾ ਹੈ।
ਤੇਜ਼ੀ ਨਾਲ ਸ਼ਿਪ ਕਰਨ ਨਾਲ ਇਹ ਲਹਜੇ ਜਲਦੀ ਆਉਂਦੇ ਹਨ। ਤੁਹਾਨੂੰ ਸਪਸ਼ਟ ਸਵਾਲਾਂ ਦੇ ਜਵਾਬ ਮਿਲਦੇ ਹਨ:
ਟਿਊਟੋਰਿਯਲ ਜਾਣ-ਪਛਾਣ ਬਣਾਉਂਦੇ ਹਨ, ਪਰ ਉਹ ਅਕਸਰ ਫੈਸਲਾ-ਯੋਗਤਾ ਨਹੀਂ ਬਣਾਉਂਦੇ। ਬਣਾਉਣਾ ਅਤੇ ਸ਼ਿਪ ਕਰਨਾ ਤੁਹਾਨੂੰ ਵਪਾਰ-ਫੈਸਲੇ ਕਰਨ ਲਈ ਮਜ਼ਬੂਰ ਕਰਦਾ ਹੈ: ਕੀ ਛੱਡਣਾ ਹੈ, ਕੀ ਸਧਾਰਨ ਕਰਨਾ ਹੈ, ਕੀ ਟੈਸਟ ਕਰਨਾ ਹੈ, ਕੀ ਦਸਤਾਵੇਜ਼ ਕਰਨਾ ਹੈ, ਅਤੇ ਕੀ ਠਹਿਰਾਉਣਾ ਹੈ। ਇਹ ਫੈਸਲਾ-ਲੈਣਾ ਹُنਰ ਹੈ।
ਜੇ ਤੁਸੀਂ ਤਿੰਨ ਰਾਤਾਂ ਇੱਕ ਫਰੇਮਵਰਕ 'ਸਿੱਖਣ' ਵਿਚ ਲਾਂਬੇ ਸਮਾਂ ਲਗਾ ਦਿੰਦੇ ਹੋ ਪਰ ਕਦੇ ਵੀ ਕੁਝ ਡਿਪਲੋਏ ਨਹੀਂ ਕਰਦੇ, ਤਾਂ ਤੁਸੀਂ ਸ਼ਾਇਦ ਸ਼ਬਦ-ਭੰਡਾਰ ਜਾਣਦੇ ਹੋ—ਪਰ ਖਾਲੀ ਪ੍ਰੋਜੈਕਟ ਦੇ ਸਾਹਮਣੇ ਅਜੇ ਵੀ ਫਸੇ ਹੋਏ ਮਹਿਸੂਸ ਕਰ ਸਕਦੇ ਹੋ।
ਇੱਥੇ AI-ਜੈਨਰੇਟਡ ਕੋਡ ਮਦਦਗਾਰ ਹੁੰਦਾ ਹੈ: ਇਹ ਵਿਚਾਰ ਅਤੇ ਪਹਿਲੀ ਚਲਣਯੋਗ ਡਰਾਫਟ ਦਰਮਿਆਨ ਦਾ ਸਮਾਂ ਘਟਾਉਂਦਾ ਹੈ। ਖਾਲੀ ਫੋਲਡਰ 'ਤੇ ਘੂਰਨ ਦੀ ਬਜਾਏ, ਤੁਸੀਂ ਮਿੰਟਾਂ ਵਿੱਚ ਬੁਨਿਆਦੀ ਰੂਟ, ਕਮਪੋਨੈਂਟ, ਸਕ੍ਰਿਪਟ ਜਾਂ ਡੇਟਾ ਮਾਡਲ ਪ੍ਰਾਪਤ ਕਰ ਸਕਦੇ ਹੋ।
ਜੇ ਤੁਸੀਂ ਇਕ vibe-coding ਵਰਕਫਲੋ ਵਰਤ ਰਹੇ ਹੋ—ਜਿੱਥੇ ਤੁਸੀਂ ਜੋਚਾਹੁੰਦੇ ਹੋ ਬਿਆਨ ਕਰਦੇ ਹੋ ਅਤੇ ਰਨਏਬਲ ਡਰਾਫਟ ਤੋਂ ਇਟਰੇਟ ਕਰਦੇ ਹੋ—ਤਾਂ Koder.ai ਵਰਗੇ ਟੂਲ ਉਸ ਲੂਪ ਨੂੰ ਹੋਰ ਤਿੱਘਾ ਕਰ ਸਕਦੇ ਹਨ by ਚੈਟ-ਪ੍ਰਾਂਪਟ ਨੂੰ ਕੰਮ ਕਰਨ ਵਾਲੇ ਵੈਬ/ਸੇਰਵਰ/ਮੋਬਾਈਲ ਸਲਾਈਸ ਵਿੱਚ ਬਦਲ ਕੇ (ਸਨੇਪਸ਼ਾਟ ਅਤੇ ਰੋਲਬੈਕ ਵਰਗੇ ਵਿਕਲਪਾਂ ਨਾਲ ਜਦੋਂ ਪ੍ਰਯੋਗ ਵੱਲੋਂ ਗੜਬੜ ਹੋਵੈ)। ਮਕਸਦ ਜਾਦੂ ਨਹੀਂ; ਤੇਜ਼ ਇਟਰੇਸ਼ਨ ਅਤੇ ਸਪਸ਼ਟ ਚੈਕਪੋਇੰਟ ਹਨ।
ਸਾਰੀਆਂ ਚੀਜ਼ਾਂ "ਠੀਕ" ਮਹਿਸੂਸ ਹੋਣ ਤਕ ਸ਼ਿਪ ਕਰਨ ਦੀ ਉਡੀਕ ਕਰਨ ਦਾ ਇਕ ਕੀਮਤ ਹੁੰਦੀ ਹੈ:
“ਚੰਗਾ ਕਾਫੀ” ਦਾ ਮਤਲਬ sloppy ਨਹੀਂ—ਇਹ ਹੈ ਕਿ ਤੁਸੀਂ ਅੱਗੇ ਵਧਦੇ ਹੋ ਜਦੋਂ ਅਗਲਾ ਕਦਮ ਅਗਲੇ polish ਨਾਲੋਂ ਵੱਧ ਸਿਖਾਉਂਦਾ ਹੈ।
“ਚੰਗਾ ਕਾਫੀ” AI ਕੋਡ ਉਪਯੋਗੀ ਹੈ ਕਿਉਂਕਿ ਇਹ ਤੁਹਾਡੇ ਗਿਆਨ ਨੂੰ ਦਿੱਖਾਉਂਦਾ ਹੈ। ਜਦੋਂ ਤੁਸੀਂ ਜੈਨਰੇਟ ਕੀਤੇ ਨਿਊਨ ਹੋਏ ਸਨਿੱਪੇਟ ਨੂੰ ਆਪਣੇ ਪ੍ਰੋਜੈਕਟ ਵਿੱਚ ਪੇਸਟ ਕਰਦੇ ਹੋ, ਤੁਸੀਂ ਤੇਜ਼ੀ ਨਾਲ ਮਿਲਦਾ ਹੈ ਕਿ ਤੁਸੀਂ ਹੋਰ ਕਿੱਥੇ ਸਮਝ ਨਹੀਂ ਰੱਖਦੇ: ਕਿਹੜਾ API ਮੈਥਡ ਲਿਸਟ ਵਾਪਸ ਕਰਦਾ ਹੈ ਬਨਾਮ ਕਰਸਰ, JSON ਪੇਲੋਡ ਦੀ ਆਕਾਰ ਕਿਹੀ ਹੈ, ਜਾਂ ਕਿਉਂ ਇਕ ਸਧਾਰਨ ਐਜ-ਕੇਸ (ਖਾਲੀ ਇਨਪੁੱਟ, ਟਾਈਮ ਜੋਨ, ਰੀਟ੍ਰਾਈ) ਖੁਸ਼-ਪਾਥ ਨੂੰ ਤੋੜਦਾ ਹੈ।
AI ਡਰਾਫਟ ਆਮ ਤੌਰ 'ਤੇ ਆਦਰਸ਼ ਡੇਟਾ ਅਤੇ ਸਾਫ਼ ਬਾਉਂਡਰੀਆਂ ਨੂੰ ਮੰਨ ਲੈਂਦੇ ਹਨ। ਜਦੋਂ ਇਹ ਪਹਿਲੀ ਵਾਰੀ fail ਕਰਦਾ ਹੈ, ਤੁਹਾਨੂੰ ਉਹ ਪ੍ਰੈਕਟਿਕਲ ਸਵਾਲ ਜਵਾਬ ਦੇਣੇ ਪੈਂਦੇ ਹਨ ਜੋ ਤੁਸੀਂ ਤਾਲ ਨਹੀਂ ਸਕਦੇ:
ਇਹ ਸਵਾਲ "ਮੈਂ ਕੋਡ ਨੂੰ ਨਕਲ ਕੀਤਾ" ਤੋਂ "ਮੈਂ ਪ੍ਰਣਾਲੀ ਸਮਝਦਾ ਹਾਂ" ਵੱਲ ਦੀ ਸਿੱਧੀ ਰਾਹ ਹਨ।
AI ਆਉਟਪੁੱਟ ਦੇ ਰਾਹੀਂ ਕਦਮ-ਦਰ-ਕਦਮ ਜਾਣਾ ਵਿਕਾਸ ਦੇ ਉਹ ਹਿੱਸੇ ਸਿਖਾਉਂਦਾ ਹੈ ਜੋ ਦਿਨ-ਪਰ-ਦਿਨ ਮਹੱਤਵਪੂਰਨ ਹਨ: stack traces ਪੜ੍ਹਨਾ, ਟਾਈਪ ਅਤੇ ਡੇਟਾ ਆਕਾਰ ਚੈੱਕ ਕਰਨਾ, ਲੌਗ ਜੋੜਨਾ, ਇੱਕ ਛੋਟਾ ਟੈਸਟ ਲਿਖਨਾ ਜੋ ਬਗ ਨੂੰ ਦੁਹਰਾਓਂਦਾ ਹੈ, ਅਤੇ ਫਿਕਸ ਦੀ ਪੁਸ਼ਟੀ ਕਰਨਾ।
ਕਿਉਂਕਿ ਕੋਡ ਨੇੜਾ-ਪਰ-ਨਾਪੁੱਕ ਹੈ, ਤੁਹਾਨੂੰ ਅਕਸਰ ਛੋਟੇ ਡੀਬੱਗਿੰਗ ਅਭਿਆਸ ਮਿਲਦੇ ਹਨ—ਬਿਨਾਂ ਕਿਸੇ ਅਭਿਆਸ-ਸ਼ਿਖਣ ਉਦਾਹਰਣ ਬਣਾਉਣ ਦੀ ਲੋੜ ਦੇ।
2-3 ਵਿਵਿੱਕਲਪ ਮੰਗੋ ਅਤੇ ਉਨ੍ਹਾਂ ਦੀ ਤੁਲਨਾ ਕਰੋ। ਇਕ ਖਰਾਬ ਹੋਇਆ ਵੀ ਹੋ ਸਕਦਾ ਹੈ, ਪਰ ਵੱਖ-ਵੱਖ ਤਰੀਕੇ ਦੇਖ ਕੇ ਤੁਸੀਂ ਟਰੇਡਆਫ਼ ਸਿੱਖਦੇ ਹੋ (ਪਰਫਾਰਮੈਂਸ ਬਨਾਮ ਸਪੱਸ਼ਟਤਾ, ਅਬਸਟਰੈਕਸ਼ਨ ਬਨਾਮ ਨਕਲ)।
ਮਾਡਲ ਨੂੰ ਇਕ sparring ਪਾਰਟਨਰ ਸਮਝੋ: ਇਹ ਵਿਚਾਰ ਸੁਝਾਉਂਦਾ ਹੈ। ਰਾਖੀ ਕਰਨ ਦਾ ਫੈਸਲਾ ਤੁਹਾਡਾ ਹੈ।
AI-ਜੈਨਰੇਟਡ ਕੋਡ ਝਟ ਪੱਕੀ ਸਰਚਨਾ ਤੇਜ਼ੀ ਨਾਲ ਬਣਾਉਂਦਾ ਹੈ। ਸਮੱਸਿਆਵਾਂ ਆਮ ਤੌਰ 'ਤੇ ਉਸ "ਆਖਰੀ 20%" ਵਿੱਚ ਆਉਂਦੀਆਂ ਹਨ ਜਿੱਥੇ ਅਸਲ ਸਿਸਟਮ ਗੰਦੇ ਹੁੰਦੇ ਹਨ: ਅਸਲ ਇਨਪੁੱਟ, ਅਸਲ ਡੀਪੈਂਡੈਂਸੀਜ਼, ਅਤੇ ਅਸਲ ਐਜ-ਕੇਸ।
ਕੁਝ ਮੁੱਖ ਬਿੰਦੂ ਜੋ ਵਾਰ-ਵਾਰ ਨਜ਼ਰ ਆਉਂਦਾ ਹੈ:
ਮਾਡਲ coherent ਜਵਾਬ ਬਣਾਉਣ ਲਈ optimize ਕੀਤਾ ਗਿਆ ਹੈ, ਨਾ ਕਿ uncertainty ਦਿਖਾਉਣ ਲਈ। ਇਹ ਪੈਟਰਨਾਂ ਦੇ ਆਧਾਰ 'ਤੇ ਉਹ ਕੋਡ ਪੇਸ਼ ਕਰਦਾ ਹੈ ਜੋ ਸਹੀ ਲੱਗਦਾ ਹੈ, ਇਸ ਲਈ ਵਿਆਖਿਆ ਨਰਮ ਹੋ ਸਕਦੀ ਹੈ ਜਦੋਂ ਵੇਰਵੇ ਤੁਹਾਡੇ ਸਟੈਕ, ਵਰਜਨਾਂ, ਜਾਂ ਪਾਬੰਦੀਆਂ ਨਾਲ ਮੇਲ ਨਹੀਂ ਖਾਂਦੇ।
ਅਉਟਪੁੱਟ ਨੂੰ ਡਰਾਫਟ ਸਮਝੋ ਅਤੇ ਤੇਜ਼ੀ ਨਾਲ ਵਰਤਵ ਦੀ ਪੜਤਾਲ ਕਰੋ:
ਸਭ ਤੋਂ ਮਹੱਤਵਪੂਰਨ: ਵਿਆਖਿਆ ਦੀ ਥਾਂ ਵੇਖੀ ਹੋਈ ਵਰਤੋਂ 'ਤੇ ਭਰੋਸਾ ਕਰੋ। ਕੋਡ ਤੁਹਾਡੇ ਚੈਕ ਪਾਸ ਕਰੇ ਤਾਂ ਵਧੀਆ; ਫੇਲ ਹੋਵੇ ਤਾਂ ਤੁਹਾਨੂੰ ਸਹੀ ਤੌਰ 'ਤੇ ਸੋਧਣ ਲਈ ਮਿਲਦੀ ਸਿੱਖਿਆ—ਅਤੇ ਇਹੀ ਫੀਡਬੈਕ ਲੂਪ ਦੀ ਕੀਮਤ ਹੈ।
"ਚੰਗਾ ਕਾਫੀ" sloppy ਨਹੀਂ—ਇਹ ਇਕ ਸੋਚ-ਸਮਝ ਕੇ ਨਿਰਣਾ ਦਿੱਤਾ threshold ਹੈ। ਲਕੜੀ ਦਾ ਮਕਸਦ ਕੁਝ ਐਸਾ ਸ਼ਿਪ ਕਰਨਾ ਹੈ ਜੋ ਕੰਮ ਕਰੇ, ਬਾਅਦ ਵਿੱਚ ਸਮਝ ਆ ਸਕੇ, ਅਤੇ ਯੂਜ਼ਰਾਂ ਨੂੰ ਸਪੱਸ਼ਟ ਤਰੀਕੇ ਨਾਲ ਹੈਰਾਨ ਨਾ ਕਰੇ। ਇਸਨੂੰ ਸੋਚੋ ਜਿਵੇਂ "ਹੁਣ ਲਈ ਮੁਕੰਮਲ": ਤੁਸੀਂ ਅਸਲ ਦੁਨੀਆਂ ਦਾ ਫੀਡਬੈਕ ਖਰੀਦ ਰਹੇ ਹੋ, ਨਾ कि ਕੋਡ ਨੂੰ ਸਦੀਵੀ ਸਹੀ ਘੋਸ਼ਿਤ ਕਰ ਰਹੇ ਹੋ।
AI-ਜੈਨਰੇਟਡ ਕੋਡ (ਜਾਂ ਕੋਈ ਵੀ ਕੋਡ) ਸ਼ਿਪ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਇਹ ਸਧਾਰਣ ਬਾਰ ਪਾਰ ਕਰ ਲਵੇ:
ਜੇ ਇਨ੍ਹਾਂ ਵਿੱਚੋਂ ਕੋਈ ਫੇਲ ਹੁੰਦਾ ਹੈ, ਤਾਂ ਤੁਸੀਂ perfectionist ਨਹੀਂ—ਤੁਸੀਂ predictable ਦਰਦ ਤੋਂ ਬਚ ਰਹੇ ਹੋ।
"ਸਦੀਵ ਲਈ ਮੁਕੰਮਲ" ਉਹ ਮਿਆਰ ਹੈ ਜੋ ਤੁਸੀਂ ਕੋਰ ਸੁਰੱਖਿਆ, ਬਿਲਿੰਗ, ਜਾਂ ਅਹਿਮ ਡੇਟਾ ਇੰਟੀਗ੍ਰਿਟੀ ਵਾਲੇ ਹਿੱਸਿਆਂ 'ਤੇ ਲਗਾਉਂਦੇ ਹੋ। ਹੋਰ ਸਾਰਾ ਕੁਝ "ਹੁਣ ਲਈ ਮੁਕੰਮਲ" ਹੋ ਸਕਦਾ ਹੈ, ਪਰ ਜੇ ਤੁਸੀਂ ਕੁਝ ਟਾਲ ਰਹੇ ਹੋ ਤਾਂ ਕੋਨੀਆਂ ਚੀਜ਼ਾਂ ਮੁੜ ਕਰਨ ਦੀ ਯੋਜਨਾ ਦਰਜ ਕਰੋ।
AI ਡਰਾਫਟ ਨੂੰ ਸਾਫ ਕਰਨ ਲਈ ਆਪਣੇ ਆਪ ਨੂੰ 30–60 ਮਿੰਟ ਦਿਓ: ਸਰਚਨਾ ਸਧਾਰੋ, ਘੱਟੋ-ਘੱਟ ਟੈਸਟ ਜੋੜੋ, ਏਰਰ ਹੈਂਡਲਿੰਗ ਸੁਧਾਰੋ, ਅਤੇ ਮੁਰਝਾਏ ਹੋਏ ਕੋਡ ਨੂੰ ਹਟਾਓ। ਜਦੋਂ ਟਾਈਮ-ਬਾਕਸ ਖਤਮ ਹੋ ਜਾਵੇ, ਸ਼ਿਪ ਕਰੋ (ਜਾਂ ਅਗਲੇ ਪਾਸ ਦੀ ਤਰਤੀਬ ਬਣਾਓ)।
ਜਿੱਥੇ ਤੁਸੀਂ ਕਤਰਨ ਕੀਤੀਆਂ ਹਨ ਉੱਥੇ ਸੰਖੇਪ ਨੋਟ ਛੱਡੋ:
TODO: add rate limitingNOTE: assumes input is validated upstreamFIXME: replace temp parsing with schema validationਇਹ "ਬਾਅਦ ਵਿੱਚ ਸਧਾਰਾਂਗੇ" ਨੂੰ ਇਕ ਯੋਜਨਾ ਵਿੱਚ ਬਦਲ ਦਿੰਦਾ ਹੈ—ਅਤੇ ਭਵਿੱਖ ਦੇ ਤੁਸੀਂ ਨੂੰ ਤੇਜ਼ ਬਣਾਉਂਦਾ ਹੈ।
ਚੰਗੀਆਂ ਪ੍ਰਾਂਪਟਸ ਲੰਬੀਆਂ ਨਹੀਂ ਹੁੰਦੀਆਂ; ਉਹ ਸਪਸ਼ਟ ਸੀਮਾਵਾਂ, ਤਿੱਛੇ ਉਦਾਹਰਣ, ਅਤੇ ਤਿੱਘੇ ਫੀਡਬੈਕ ਲੂਪ ਹੁੰਦੇ ਹਨ। ਮਕਸਦ perfect ਹੱਲ ਨਹੀਂ; ਇਹ ਹੈ ਇਕ ਐਸਾ ਡਰਾਫਟ ਪ੍ਰਾਪਤ ਕਰਨਾ ਜੋ ਤੁਸੀਂ ਚਲਾ ਸਕੋ, ਅੰਕਲਨ ਕਰ ਸਕੋ, ਅਤੇ ਤੇਜ਼ੀ ਨਾਲ ਸੁਧਾਰ ਸਕੋ।
ਮਾਡਲ ਨੂੰ ਸਭ ਤੋਂ ਪਹਿਲਾਂ ਦੱਸੋ ਕੀ ਜ਼ਰੂਰੀ ਹੈ:
ਇਸ ਦੇ ਨਾਲ, ਵਿਕਲਪ ਅਤੇ ਟਰੇਡਆਫ਼ ਵੀ ਮੰਗੋ—ਨਾ ਕਿ ਸਿਰਫ਼ "ਸਭ ਤੋਂ ਵਧੀਆ"। ਉਦਾਹਰਨ: “ਦੋ ਤਰੀਕੇ ਦੱਸੋ: ਇੱਕ ਸਧਾਰਨ ਅਤੇ ਇਕ ਸਕੇਲਏਬਲ; ਫਾਇਦੇ/ਨੁਕਸਾਨ ਅਤੇ ਫੇਲ ਮੋਡ ਸਮਝਾਓ।” ਇਹ ਤੁਲਨਾ ਨੂੰ ਜ਼ਾਬਤ ਕਰਦਾ ਹੈ ਨਾ ਕਿ ਅਕਸਰ-ਸਵੀਕਾਰ ਕਰਨਾ।
ਲੂਪ ਛੋਟੀ ਰੱਖੋ:
ਜਦੋਂ ਤੁਸੀਂ ਵੱਡੇ ਰੀਵਰਾਈਟ ਦੀ ਬਜਾਏ ਛੋਟੇ, ਟੈਸਟੇਬਲ ਇਕਾਈਆਂ ਮੰਗਦੇ ਹੋ ਤਾਂ ਰਿਪੈਅਰਗੇ: “ਇੱਕ ਫੰਕਸ਼ਨ ਲਿਖੋ ਜੋ payload ਨੂੰ ਵੈਲਿਡੇਟ ਕਰੇ ਅਤੇ ਸੰਰਚਿਤ errors ਵਾਪਸ ਕਰੇ।” ਫਿਰ: “ਹੁਣ ਉਸ ਫੰਕਸ਼ਨ ਲਈ 5 ਯੂਨਿਟ ਟੈਸਟ ਲਿਖੋ।” ਛੋਟੀਆਂ ਯੂਨਿਟਾਂ ਨੂੰ ਵਰਤਣਾ ਆਸਾਨ, ਵਿਸ਼ਵਾਸਯੋਗ ਅਤੇ ਸਿੱਖਣਯੋਗ ਹੁੰਦਾ ਹੈ।
AI ਤੁਹਾਨੂੰ ਤੇਜ਼ੀ ਨਾਲ ਡਰਾਫਟ ਦੇ ਸਕਦਾ ਹੈ—ਪਰ ਭਰੋਸੇਯੋਗਤਾ ਉਹ ਚੀਜ਼ ਹੈ ਜੋ ਤੁਹਾਨੂੰ ਬਿਨਾਂ ਦਿਲ-ਕਪਕਾਪੇ ਸ਼ਿਪ ਕਰਨ ਯੋਗ ਬਣਾਂਦੀ ਹੈ। ਮਕਸਦ ਕੋਡ ਨੂੰ "ਮੁਕੰਮਲ" ਬਣਾਉਣਾ ਨਹੀਂ; ਇਹ ਹੈ ਕਿ ਇਤਨੀ ਸਮੀਖਿਆ ਅਤੇ ਟੈਸਟ ਜੋੜੋ ਕਿ ਤੁਸੀਂ ਇਸ 'ਤੇ ਭਰੋਸਾ ਕਰ ਸਕੋ।
ਕਿਸੇ ਵੀ ਚੀਜ਼ ਨੂੰ ਚਲਾਉਣ ਤੋਂ ਪਹਿਲਾਂ AI-ਜੈਨਰੇਟਡ ਕੋਡ ਪੜ੍ਹੋ ਅਤੇ ਆਪਣੀਆਂ ਸ਼ਬਦਾਂ ਵਿੱਚ ਵਾਪਸ ਸਮਝਾਓ:
ਜੇ ਤੁਸੀਂ ਇਸਨੂੰ ਨਹੀਂ ਸਮਝਾ ਸਕਦੇ, ਤਾਂ ਤੁਸੀਂ ਇਸ ਨੂੰ ਸੰਭਾਲ ਨਹੀਂ ਸਕਦੇ। ਇਹ ਕਦਮ ਡਰਾਫਟ ਨੂੰ ਸਿਰਫ਼ ਆਉਟਪੁੱਟ ਨਹੀਂ, ਸਿੱਖਣ ਵਿੱਚ ਬਦਲ ਦਿੰਦਾ ਹੈ।
ਆਪਣੇ ਪਹਿਲੇ ਰੱਖਿਆ-ਲਾਈਨ ਵਜੋਂ automated checks ਵਰਤੋ, ਨਾ ਕਿ ਆਖਰੀ:
ਇਹ ਟੂਲ ਜਜਬਾਤ ਦੀ ਥਾਂ ਨਹੀਂ ਲੈਂਦੇ, ਪਰ ਸਾਨੂੰ ਝੱਲੇ ਬੱਗ ਘਟਾਉਂਦੇ ਹਨ ਜੋ ਸਮਾਂ ਮਰ ਬਰਬਾਦ ਕਰਦੇ ਹਨ।
ਤੁਹਾਨੂੰ ਵੱਡੀ ਟੈਸਟ ਸਿੂਟ ਦੀ ਲੋੜ ਨਹੀਂ; ਸਭ ਤੋਂ ਅਸਾਨ-ਫੇਲ ਹਿੱਸਿਆਂ 'ਤੇ ਛੋਟੇ ਟੈਸਟ ਜੋੜੋ:
ਕੁਝ ਕੇਂਦਰਿਤ ਟੈਸਟ ਇੱਕ "ਚੰਗਾ ਕਾਫੀ" ਹੱਲ ਨੂੰ ਸ਼ਿਪ ਕਰਨ ਯੋਗ ਬਨਾਉਂਦੇ ਹਨ।
ਪੂਰੇ ਜੈਨਰੇਟਡ ਰੀਰਾਈਟ ਨੂੰ ਇਕ ਵੱਡੇ commit ਵਿੱਚ ਪੇਸਟ ਕਰਨ ਤੋਂ ਬਚੋ। ਬਦਲਾਅ ਛੋਟੇ ਅਤੇ ਅਕਸਰ ਰੱਖੋ ਤਾਂ ਕਿ ਤੁਸੀਂ:
ਛੋਟੀਆਂ iterations AI ਡਰਾਫਟਾਂ ਨੂੰ ਭਰੋਸੇਯੋਗ ਕੋਡ ਵਿੱਚ ਬਦਲਣ ਦੀ ਇਜਾਜ਼ਤ ਦਿੰਦੀਆਂ ਹਨ ਬਿਨਾਂ ਤੁਹਾਨੂੰ ਧੀਮਾ ਕਰਨ ਦੇ।
Technical debt ਕੋਈ ਮੋਰਲ ਫੇਲ੍ਹਿਊਰ ਨਹੀਂ। ਇਹ ਉਹ ਟਰੇਡਆਫ਼ ਹੈ ਜੋ ਤੁਸੀਂ ਸਿੱਖਣ ਅਤੇ ਸ਼ਿਪ ਕਰਨ ਨੂੰ ਤਰਜੀਹ ਦੇ ਕੇ ਲੈਂਦੇ ਹੋ। ਮਹੱਤਵਪੂਰਨ ਹੈ ਇਰਾਦੇ ਵਾਲਾ debt: ਤੁਸੀਂ ਜਾਣ-ਬੂਝ ਕੇ ਕੁਝ ਅਧੂਰਾ ਸ਼ਿਪ ਕਰਦੇ ਹੋ ਸੁਧਾਰਣ ਦੀ ਯੋਜਨਾ ਨਾਲ, ਨਾਂ ਕਿ ਆਸ ਰੱਖਦੇ ਹੋ ਕਿ "ਕਦੇ ਨਾ" ਸਿੱਧੇ ਕਰ ਲਿਆ ਜਾਵੇ।
AI-ਸਹਾਇਤ ਡਰਾਫਟ ਇਸ ਵਿਚਾਰ ਨਾਲ ਖਾਸ ਤੌਰ 'ਤੇ ਸਬੰਧਿਤ ਹੈ: ਡਰਾਫਟ ਕੰਮ ਕਰ ਸਕਦਾ ਹੈ, ਪਰ ਉਸ ਦੀ ਸਰਚਨਾ ਹੋ ਸਕਦੀ ਹੈ ਕਿ ਉਹ ਓਸ ਤਰ੍ਹਾਂ ਨਹੀਂ ਹੋ ਜਿਵੇਂ ਤੁਸੀਂ feature ਵਧਾਉਂਦੇ ਹੋ।
ਧੁੰਦਲੇ TODOs debt ਨੂੰ ਛੁਪਾਉਂਦੇ ਹਨ। ਉਹਨਾਂ ਨੂੰ ਕਰਵਾਈਯੋਗ ਬਣਾਓ:
// TODO(week-2): Extract pricing rules into a separate module; current logic is duplicated in checkout and invoice.// TODO(before scaling): Replace in-memory cache with Redis to avoid cross-instance inconsistency.// TODO(after user feedback): Add validation errors to UI; support tickets show users don’t understand failures.ਜੇ ਤੁਸੀਂ "ਕਦੋਂ" ਨਹੀਂ ਨਾਂ ਸਕਦੇ, ਤਾਂ ਇੱਕ ਟ੍ਰਿਗਰ ਚੁਣੋ।
ਤੁਸੀਂ ਉਹਦੋਂ refactor ਕਰਦੇ ਹੋ ਜਦੋਂ ਕੋਡ "ਚੰਗਾ" ਨਾ ਹੋਣ ਕਾਰਨ ਵੱਧ ਖ਼ਰਚੀਲਾ ਹੋ ਜਾਂਦਾ ਹੈ। ਆਮ ਟ੍ਰਿਗਰ:
ਹਲਕਾ ਅਤੇ ਨਿਰੰਤਰ ਰੱਖੋ:
ਸ਼ਰਮ debt ਨੂੰ ਅਦਿੱਖ ਨਹੀਂ ਬਣਾਂਦੀ; ਪਾਰਦਰਸ਼ੀਤਾ ਇਸਨੂੰ ਸੰਭਾਲਯੋਗ ਬਣਾਉਂਦੀ ਹੈ—ਅਤੇ "ਚੰਗਾ ਕਾਫੀ" ਤੁਹਾਡੇ ਹੱਕ ਵਿੱਚ ਕੰਮ ਕਰਦਾ ਰਹਿੰਦਾ ਹੈ।
"ਚੰਗਾ ਕਾਫੀ" ਪ੍ਰੋਟੋਟਾਈਪ ਅਤੇ ਅੰਦਰੂਨੀ ਟੂਲ ਲਈ ਵਧੀਆ ਡਿਫਾਲਟ ਹੈ। ਪਰ ਕੁਝ ਖੇਤਰ ਛੋਟੇ ਗਲਤੀਆਂ ਨੂੰ ਸਜ਼ਾ ਦਿੰਦੇ ਹਨ—ਖ਼ਾਸ ਕਰਕੇ ਜਦੋਂ AI-ਜੈਨਰੇਟਡ ਕੋਡ ਕੁਝ ਇਸ ਤਰ੍ਹਾਂ ਦਿਖਾਉਂਦਾ ਹੈ ਜੋ ਸਹੀ ਲੱਗਦਾ ਹੈ ਪਰ ਅਸਲ ਦਬਾਅ ਹੇਠ ਫੇਲ ਹੋ ਜਾਂਦਾ ਹੈ।
ਹੇਠਾਂ ਦਿੱਤੀਆਂ ਚੀਜ਼ਾਂ ਨੂੰ "ਨੇੜੇ-ਪ੍ਰਾਯ-ਮੁਕੰਮਲ" ਸਮਝੋ, ਨਾ ਕਿ "ਸ਼ਿਪ ਕਰਕੇ ਵੇਖੋ":
ਤੁਹਾਨੂੰ ਵੱਡਾ ਪ੍ਰਕਿਰਿਆ ਚਾਹੀਦੀ ਨਹੀਂ—ਪਰ ਕੁਝ ਇੰਤਜ਼ਾਮ ਜ਼ਰੂਰੀ ਹਨ:
ਜੇ AI ਘਰੇਲੂ auth ਸਿਸਟਮ ਜਾਂ payment flow ਦਾ ਡਰਾਫਟ ਬਣਾਏ, ਉਹਨੂੰ ਲਾਲ ਝੰਡਾ ਸਮਝੋ। ਸਥਾਪਤ ਲਾਇਬਰੇਰੀਆਂ, ਹੋਸਟਡ ਪ੍ਰੋਵਾਇਡਰਾਂ, ਅਤੇ ਅਧਿਕਾਰਿਕ SDKs ਵਰਤੋ—even ਜੇ ਇਹ ਧੀਮਾ ਲੱਗੇ। ਇਹ ਉਹ ਥਾਂ ਹੈ ਜਿਥੇ ਇੱਕ ਮੁਹਿਰਾ ਸਮੀਖਿਆ ਲਿਆਉਣਾ ਇੱਕ ਹਫ਼ਤੇ ਦੀ ਸਫਾਈ ਤੋਂ ਸਸਤਾ ਪੈ ਸਕਦਾ ਹੈ।
ਇਨ੍ਹਾਂ ਸਭ 'ਤੇ ਸੰਰਚਿਤ ਲੌਗਿੰਗ, ਮਨਿਟਰਿੰਗ, ਅਤੇ ਅਲਾਰਟਸ ਜੋੜੋ ਤਾਂ ਕਿ ਫੇਲ early ਮੇਲ ਮਿਲ ਜਾਣ। ਤੇਜ਼ ਇਟਰੇਸ਼ਨ ਕੰਮ ਕਰਦੀ ਹੈ—ਬੱਸ ਗਾਰਡਰੇਲਸ ਅਤੇ ਵਿਜ਼ਿਵਲਿਟੀ ਨਾਲ।
AI ਸਹਾਇਤਾ ਨੂੰ ਅਸਲ ਹੁਨਰ ਵਿੱਚ ਬਦਲਣ ਦਾ ਤੇਜ਼ ਤਰੀਕਾ ਇਹ ਹੈ ਕਿ ਤੁਸੀਂ ਇਸਨੂੰ ਇੱਕ ਲੂਪ ਵਜੋਂ ਦਿਖੋ, ਨਾ ਕਿ ਇੱਕ-ਵਾਰ ਦੀ ਕੋਸ਼ਿਸ਼ ਵਜੋਂ। ਤੁਸੀਂ ਪਹਿਲੀ ਕੋਸ਼ਿਸ਼ 'ਤੇ ਪਰਫੈਕਟ ਹੱਲ ਬਣਾਉਣ ਦੀ ਕੋਸ਼ਿਸ਼ ਨਹੀਂ ਕਰ ਰਹੇ—ਤੁਸੀਂ ਇਕ ਐਸਾ ਕੁਝ ਬਣਾਉਂਦੇ ਹੋ ਜੋ ਤੁਸੀਂ ਚਲਾ ਸਕੋ, ਦੇਖ ਸਕੋ, ਅਤੇ ਸੁਧਾਰ ਸਕੋ।
ਜੇ ਤੁਸੀਂ Koder.ai ਵਰਗੇ environment ਵਿੱਚ ਕੰਮ ਕਰ ਰਹੇ ਹੋ—ਜਿੱਥੇ ਤੁਸੀਂ ਕਾਰਜਕਾਰੀ ਸਲਾਈਸ ਜੈਨਰੇਟ, ਡੈਪਲੋਇਮੈਂਟ ਕਰ ਸਕਦੇ ਹੋ, ਅਤੇ ਜਦੋਂ ਪ੍ਰਯੋਗ fail ਕਰ ਜਾਵੇ ਤਾਂ ਸਨੇਪਸ਼ਾਟ ਰੋਲਬੈਕ ਕਰ ਸਕਦੇ ਹੋ—ਤਾਂ ਤੁਸੀਂ ਇਹ ਲੂਪ ਖਾਸ ਤੌਰ 'ਤੇ ਤਿੱਘਾ ਰੱਖ ਸਕਦੇ ਹੋ, ਬਿਨਾਂ ਹਰ ਕੋਸ਼ਿਸ਼ ਨੂੰ ਇੱਕ ਖਤਰਨਾਕ "ਵੱਡਾ ਬੈਂਗ" ਬਦਲ ਕੇ।
ਰੇਪੋ ਜਾਂ ਇਕ ਡੌਕ 'ਚ ਛੋਟਾ ਨੋਟ ਰੱਖੋ: “ਇਨਪੁੱਟ ਵੈਰੀਫਿਕੇਸ਼ਨ ਭੁੱਲ ਗਈ”, “Off-by-one ਬਗ”, “Async ਕਾਲਾਂ ਵਿੱਚ ਗਲਤ ਫਹਿਮੀ”, “ਐਜ-ਕੇਸਾਂ ਲਈ ਟੈਸਟ ਘੱਟ ਸਨ”। ਸਮੇਂ ਦੇ ਨਾਲ, ਇਹ ਤੁਹਾਡੀ ਨਿੱਜੀ ਚੈੱਕਲਿਸਟ ਬਣ ਜਾਂਦੀ ਹੈ—ਅਤੇ ਤੁਹਾਡੇ ਪ੍ਰਾਂਪਟਸ ਤੇਜ਼ ਹੋ ਜਾਂਦੇ ਹਨ ਕਿਉਂਕਿ ਤੁਸੀਂ ਜਾਣਦੇ ਹੋ ਕਿ ਕੀ ਮੰਗਣਾ ਹੈ।
ਅਸਲ ਫੀਡਬੈਕ ਅਨੁਮਾਨ ਕੱਟਦਾ ਹੈ। ਜੇ ਯੂਜ਼ਰਾਂ ਨੂੰ ਤੁਹਾਡੇ ਸੁਧਾਰਸ਼ੀਲ ਰੀਫੈਕਟਰ ਦੀ ਪਰਵਾਹ ਨਹੀਂ, ਪਰ ਉਹ ਵਾਰ-ਵਾਰ ਇੱਕ ਹੀ ਭ੍ਰਮਿਤ ਬਟਨ 'ਤੇ ਆਉਂਦੇ ਹਨ, ਤਾਂ ਤੁਹਾਨੂੰ ਪਤਾ ਲੱਗਾ ਕਿ ਕੀ ਮਹੱਤਵਪੂਰਨ ਹੈ। ਹਰ ਰਿਲੀਜ਼ "ਮੈਂ ਸੋਚਦਾ ਹਾਂ" ਨੂੰ "ਮੈਂ ਜਾਣਦਾ ਹਾਂ" ਵਿੱਚ ਬਦਲਦੀ ਹੈ।
ਹਰ ਕੁਝ ਹਫ਼ਤੇ 'ਚ ਪਿੱਛਲੇ AI-ਸਹਾਇਤ commits ਨੂੰ ਵੇਖੋ। ਤੁਸੀਂ ਮੁੜ-ਮੁੜ ਆਉਣ ਵਾਲੀਆਂ ਸਮੱਸਿਆਵਾਂ ਨੂੰ ਪਛਾਣੋਗੇ, ਦੇਖੋਗੇ ਕਿ ਤੁਹਾਡੇ ਸਮੀਖਿਆ ਟਿੱਪਣੀਆਂ ਕਿਵੇਂ ਵਿਕਸਿਤ ਹੋਈਆਂ, ਅਤੇ نوਟਿਸ ਕਰੋਗੇ ਕਿ ਹੁਣ ਤੁਸੀਂ ਮੁੱਦੇ ਪਹਿਲਾਂ ਹੀ ਕਿੱਥੇ ਫੜ ਲੈਂਦੇ ਹੋ। ਇਹ ਮਾਪਣ ਯੋਗ ਪ੍ਰਗਤੀ ਹੈ।
AI ਦੀ ਸਹਾਇਤਾ ਨਾਲ ਕੋਡ ਡਰਾਫਟ ਕਰਨ ਤੋਂ ਇਹ ਸੋਚ ਉਠ ਸਕਦੀ ਹੈ: “ਕੀ ਮੈਂ ਚੀਟ ਕਰ ਰਿਹਾ ਹਾਂ?” ਇਕ ਬੇਤਰ ਫਰੇਮ ਹੈ ਸਹਾਇਤ-ਕੀਤੀ ਅਭਿਆਸ। ਤੁਸੀਂ ਅਜੇ ਵੀ ਅਸਲੀ ਕੰਮ ਕਰ ਰਹੇ ਹੋ—ਇਹ ਫੈਸਲਾ ਕਰਨਾ ਕੀ ਬਣਾਉਣਾ ਹੈ, ਟਰੇਡਆਫ਼ ਚੁਣਨਾ, ਆਪਣੇ ਸਿਸਟਮ ਨਾਲ ਇਕੀਕਰਨ ਅਤੇ ਨਤੀਜੇ ਦੀ ਜ਼ਿੰਮੇਵਾਰੀ ਲੈਣਾ। ਕਈ ਰਿਪੋਰਟਾਂ ਵਿੱਚ, ਇਹ ਇੱਕ ਟਿਊਟਰ ਨਾਲ ਸਿੱਖਣ ਦੇ ਨੇੜੇ ਹੁੰਦਾ ਹੈ ਨਾਂ कि ਉਤਰਾਂ ਦੀ ਨਕਲ।
ਖਤਰਾ ਇਹ ਨਹੀਂ ਕਿ AI ਕੋਡ ਲਿਖਦਾ ਹੈ। ਖਤਰਾ ਇਹ ਹੈ ਕਿ ਤੁਸੀਂ ਅਜਿਹਾ ਕੋਡ ਸ਼ਿਪ ਕਰੋ ਜੋ ਤੁਸੀਂ ਸਮਝਦੇ ਨਹੀਂ—ਖ਼ਾਸ ਕਰਕੇ ਆਮ ਰਸਤੇ ਜਿਵੇਂ authentication, payments, data deletion ਅਤੇ ਸੁਰੱਖਿਆ-ਸਬੰਧੀ ਚੀਜ਼ਾਂ।
ਜੇ ਕੋਡ ਪੈਸਾ ਖ਼ਰਚ ਕਰ ਸਕਦਾ ਹੈ, ਡੇਟਾ ਲੀਕ ਕਰ ਸਕਦਾ ਹੈ, ਯੂਜ਼ਰਾਂ ਨੂੰ ਬੰਦ ਕਰ ਸਕਦਾ ਹੈ, ਜਾਂ ਰਿਕਾਰਡ ਨਸ਼ਟ ਕਰ ਸਕਦਾ ਹੈ, ਤਾਂ ਤੁਹਾਨੂੰ ਆਮ-ਅੰਗਰੇਜ਼ੀ ਵਿੱਚ ਸਮਝਾ ਦੇਣਾ ਚਾਹੀਦਾ ਹੈ ਕਿ ਇਹ ਕੀ ਕਰਦਾ ਹੈ ਅਤੇ ਕਿਵੇਂ fail ਕਰਦਾ ਹੈ।
ਹਾਰਾ-ਹਿਸਾ ਪੂਰਾ ਹਥਿਆਉਣ ਦੀ ਲੋੜ ਨਹੀਂ:
ਇਸ ਤਰ੍ਹਾਂ AI ਆਉਟਪੁੱਟ ਇੱਕ ਪੱਧਰ ਬਣ ਜਾਂਦਾ ਹੈ, نه ਕਿ ਸਥਾਈ ਵਿਕਲਪ।
ਆਤਮ-ਵਿਸ਼ਵਾਸ ਵੇਰੀਫਿਕੇਸ਼ਨ ਤੋਂ ਆਉਂਦਾ ਹੈ, vibes ਤੋਂ ਨਹੀਂ। ਜਦੋਂ AI ਇੱਕ ਤਰੀਕਾ ਸੁਝਾਉਂਦਾ ਹੈ, ਉਸਨੂੰ cross-check ਕਰੋ:
ਜੇ ਤੁਸੀਂ ਇੱਕ ਬਗ ਦੁਹਰਾ ਸਕਦੇ ਹੋ, ਇਸਨੂੰ ਫਿਕਸ ਕਰੋ, ਅਤੇ ਸਮਝਾ ਸਕਦੇ ਹੋ ਕਿ ਫਿਕਸ ਕਿਵੇਂ ਕੰਮ ਕਰਦਾ ਹੈ, ਤਾਂ ਤੁਸੀਂ ਲਿਫ਼ਟ ਨਹੀਂ ਲੈ ਰਹੇ—ਤੁਸੀਂ ਸਿਖ ਰਹੇ ਹੋ। ਸਮੇਂ ਦੇ ਨਾਲ, ਤੁਸੀਂ "ਉਤਰ" ਲਈ ਨਹੀਂ, ਬਲਕਿ ਵਿਕਲਪ, ਖਤਰੇ, ਅਤੇ ਸਮੀਖਿਆ ਲਈ ਪ੍ਰੋਂਪਟ ਲਿਖੋਗੇ।
“ਚੰਗਾ ਕਾਫੀ” AI-ਜੈਨਰੇਟਡ ਕੋਡ ਦੀ ਇੱਕ ਮੁੱਖ ਵਜ੍ਹਾ ਹੈ: ਗਤੀ ਫੀਡਬੈਕ ਬਣਾਉਂਦੀ ਹੈ, ਅਤੇ ਫੀਡਬੈਕ ਹੁਨਰ ਬਣਾਂਦੀ ਹੈ। ਜਦੋਂ ਤੁਸੀਂ ਇੱਕ ਛੋਟੀ, ਕੰਮ ਕਰਨ ਯੋਗ ਸਲਾਈਸ ਜਲਦੀ ਸ਼ਿਪ ਕਰਦੇ ਹੋ, ਤੁਹਾਨੂੰ ਅਸਲ ਸੰਕੇਤ ਮਿਲਦੇ ਹਨ—ਯੂਜ਼ਰ ਦਾ ਵਰਤਾਅ, ਪ੍ਰਦਰਸ਼ਨ, ਐਜ-ਕੇਸ, ਅਤੇ ਮੈਨਟੇਨੇਬਿਲਟੀ ਦਾ ਦਰਦ। ਇਹ ਸੰਕੇਤ ਇੱਕ ਹਫ਼ਤੇ ਦੀ ਅਲੌਨ ਕੋਡ-ਪੋਲਿਸ਼ਿੰਗ ਨਾਲੋਂ ਵੱਧ ਸਿਖਾਉਂਦੇ ਹਨ।
ਇਦਾ ਦਾ ਮਤਲਬ ਇਹ ਨਹੀਂ ਕਿ “ਕੁਝ ਵੀ ਚੱਲ ਜਾਵੇ”। "ਚੰਗਾ ਕਾਫੀ" ਦੀ ਪਰਿਭਾਸ਼ਾ ਇਹ ਹੈ: ਇਹ ਘੋਸ਼ਿਤ ਵਾਪਰ-ਕੇਸ ਲਈ ਕੰਮ ਕਰਦਾ ਹੈ, ਇੱਕ ਟੀਮ-ਮੈਂਬਰ ਦੁਆਰਾ ਸਮਝ ਆ ਸਕਦਾ ਹੈ, ਅਤੇ ਅਸਾਨ ਤਰੀਕੇ ਨਾਲ ਸਪੱਸ਼ਟ ਤੌਰ 'ਤੇ ਅਚਾਨਕ ਤਰ੍ਹਾਂ ਖ਼ਰਾਬੀ ਨਹੀਂ ਕਰੇਗਾ। ਤੁਸੀਂ ਅੰਦਰੂਨੀ ਰਚਨਾ ਬਾਅਦ ਵਿੱਚ ਸੁਧਾਰ ਸਕਦੇ ਹੋ—ਜਦੋਂ ਤੁਸੀਂ ਸਿੱਖ ਲੈ ਚੁੱਕੇ ਹੋ ਕਿ ਅਸਲ ਵਿੱਚ ਕੀ ਮਹੱਤਵਪੂਰਨ ਹੈ।
ਕੁਝ ਖੇਤਰ "ਲਰਨ-ਬਾਈ-ਸ਼ਿਪ" ਵਾਲੇ ਨਹੀਂ ਹਨ। ਜੇ ਤੁਹਾਡੇ ਬਦਲਾਅ ਵਿੱਚ payments, authentication, permissions, ਸੰਵੇਦਨਸ਼ੀਲ ਡੇਟਾ, ਜਾਂ ਸੇਫਟੀ-ਕ੍ਰਿਟਿਕਲ ਵਰਤਾਵ ਆਉਂਦੇ ਹਨ, ਤਾਂ ਮਿਆਰ ਵਧਾਓ: ਡੂੰਘੀ ਸਮੀਖਿਆ, ਮਜ਼ਬੂਤ ਟੈਸਟ, ਅਤੇ ਧੀਮਾ ਰੋਲਆਊਟ।
ਇੱਕ ਛੋਟੀ ਫੀਚਰ ਚੁਣੋ ਜੋ ਤੁਸੀਂ ਲੰਮੇ ਸਮੇਂ ਤੱਕ ਟਾਲ ਰਹੇ ਹੋ। AI ਨਾਲ ਪਹਿਲੀ ਪਾਸ ਬਣਾਓ, ਫਿਰ ਸ਼ਿਪ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਇਹ ਕਰੋ:
ਇਕ ਵਾਕ ਲਿਖੋ: “ਇਸ ਬਦਲਾਅ ਦੀ ਸਫਲਤਾ ਇਹ ਹੋਵੇਗੀ ਜੇ…”
ਸਭ ਤੋਂ ਸੰਭਵ ਫੇਲ ਦੇ ਲਈ ਦੋ ਛੋਟੇ ਟੈਸਟ (ਜਾਂ ਮੈਨੁਅਲ ਚੈੱਕਲਿਸਟ) ਜੋੜੋ।
ਫੀਚਰ ਫਲੈਗ ਦੇ ਪਿੱਛੇ ਜਾਂ ਛੋਟੀ ਆਡੀਅਂਸ ਨੂੰ ਸ਼ਿਪ ਕਰੋ।
ਜੋ ਤੁਹਾਨੂੰ ਹੈਰਾਨ ਕਰ ਗਿਆ, ਉਹ ਦਰਜ ਕਰੋ, ਫਿਰ ਇੱਕ ਛੋਟੀ ਰੀਫੈਕਟਰ ਸ਼ੈਡਿਊਲ ਕਰੋ।
ਜੇ ਤੁਸੀਂ iteration ਅਤੇ ਸਮੀਖਿਆ ਦੀਆਂ ਹੋਰ ਸੁਝਾਵਾਂ ਚਾਹੁੰਦੇ ਹੋ, ਤਦ ਬਲੌਗ ਨੂੰ ਵੇਖੋ। ਜੇ ਤੁਸੀਂ ਆਪਣੇ ਵਰਕਫਲੋ ਨੂੰ ਸਹਾਇਤਾ ਦੇਣ ਵਾਲੇ ਟੂਲਾਂ ਦਾ ਮੁਲਾਂਕਣ ਕਰ ਰਹੇ ਹੋ, ਤਾਂ pricing ਨੂੰ ਵੇਖੋ।
"Good enough" ਇੱਕ जान-ਬੂਝ ਕੇ ਰੱਖਿਆ ਗਿਆ ਗੁਣਵੱਤਾ ਮਾਪਦੰਡ ਹੈ: ਕੋਡ ਉਮੀਦ ਕੀਤੇ ਇਨਪੁਟ ਲਈ ਪਰਯਾਪਤ ਸਹੀ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ, ਪਰਯਾਪਤ ਸੁਰੱਖਿਅਤ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ ਤاکہ ਆਸਾਨ ਸੁਰੱਖਿਆ/ਡੇਟਾ ਖਤਰੇ ਨਾ ਬਣਣ, ਅਤੇ ਪਰਯਾਪਤ ਰੱਖ-ਰਖਾਅਯੋਗ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ ਤਾਂ ਜੋ ਤੁਸੀਂ (ਜਾਂ ਕੋਈ ਟੀਮ-ਮੈਂਬਰ) ਆਸਾਨੀ ਨਾਲ ਪੜ੍ਹ ਸਕੋ ਤੇ ਸੋਧ ਸਕੋ।
ਇਹ "ਝੱਲੀ" ਨਹੀਂ; ਇਹ ਇੱਕ "ਹੁਣ ਲਈ ਮੁਕੰਮਲ" ਹਾਲਤ ਹੈ ਜਿਸਦਾ ਮਕਸਦ ਸਪਸ਼ਟ ਮਨਸੂਬਾ ਹੈ।
ਨਹੀਂ—ਹਮੇਸ਼ਾਂ ਨਹੀਂ। ਮਾਪਦੰਡ ਖਤਰੇ ਦੀ ਤੀਬਰਤਾ 'ਤੇ ਨਿਰਭਰ ਕਰਦਾ ਹੈ।
AI ਆਉਟਪੁੱਟ ਨੂੰ ਇੱਕ ਡਰਾਫਟ ਵਜੋਂ ਲਓ, ਅਧਿਕਾਰ ਵਜੋਂ ਨਹੀਂ।
ਇੱਕ ਕਾਇਦਾ: ਜੇ ਤੁਸੀਂ ਵਿਆਖਿਆ ਨਹੀਂ ਕਰ ਸਕਦੇ ਕਿ ਕੋਡ ਕੀ ਕਰਦਾ ਹੈ, ਇਹ ਕਿਸ ਤਰ੍ਹਾਂ ਇਨਪੁੱਟ ਲੈਂਦਾ ਹੈ, ਅਤੇ ਇਹ ਕਿਵੇਂ FAIL ਕਰ ਸਕਦਾ ਹੈ, ਤਾਂ ਇਹ ਤਿਆਰ ਨਹੀਂ—ਚਾਹੇ AI ਕਿੰਨੀ ਭੀ ਆਤਮ-ਵਿਸ਼ਵਾਸੀ ਲੱਗੇ।
ਜਿਆਦਾਤਰ ਤੋੜ-ਫੋੜ ਉਸ "ਅਖੀਰੀ 20%" ਵਿੱਚ ਹੁੰਦੀ ਹੈ ਜਿੱਥੇ ਅਸਲ ਜ਼ਿੰਦਗੀ ਗੰਦਲਈ ਹੋਂਦੀ ਹੈ:
ਇਨਾਂ ਨੂੰ ਤੇਜ਼ੀ ਨਾਲ ਵੇਰੀਫਾਈ ਕਰਨ ਦੀ ਯੋਜਨਾ ਬਣਾਓ ਬਜਾਏ ਡਰਾਫਟ ਨੂੰ ਅਮਾਨ ਕਰ ਲੈਣ ਦੇ।
ਤੇਜ਼, ਵੇਖਣਯੋਗ ਵੇਰੀਫਿਕੇਸ਼ਨ ਲੂਪ ਵਰਤੋਂ:
ਜੋ ਤੁਸੀਂ ਦੁਹਰਾ ਸਕਦੇ ਹੋ ਉਸ 'ਤੇ ਭਰੋਸਾ ਕਰੋ, ਨਾ ਕਿ ਆਲੋਚਨਾ ਦੀ ਗਰਮੀ 'ਤੇ।
ਸ਼ਿਪ ਕਰੋ ਜਦੋਂ ਅਗਲਾ ਕਦਮ ਤੁਹਾਨੂੰ ਅਗਲੇ polish ਪਾਸ ਤੋਂ ਵੱਧ ਸਿਖਾਵੇ।
ਤੁਹਾਨੂੰ ਸ਼ਾਇਦ ਓਵਰ-ਪਾਲਿਸ਼ਿੰਗ ਕਰ ਰਹੇ ਹੋ ਜੇ:
30–60 ਮਿੰਟ ਦਾ ਟਾਈਮ-ਬਾਕਸ ਕਰੋ, ਫਿਰ ਸ਼ਿਪ ਕਰੋ ਜਾਂ ਅੱਗੇ ਦੀ ਪਾਸ ਨਿਯਤ ਕਰੋ।
ਸਧਾਰਣ acceptance ਚੈੱਕਲਿਸਟ:
ਜੇ ਇਨ੍ਹਾਂ ਵਿੱਚੋਂ ਕੋਈ ਫੇਲ ਹੁੰਦਾ ਹੈ, ਤਾਂ ਤੁਸੀਂ perfectionist ਨਹੀਂ ਹੋ—ਤੁਸੀਂ ਅਣਪੇਸ਼ਗੀ ਦਰਦ ਤੋਂ ਬਚ ਰਹੇ ਹੋ।
ਲੰਮੇ "prompt engineering" ਤੋਂ ਬਿਹਤਰ ਹੈ ਸਾਫ਼ ਸੀਮਾਵਾਂ ਅਤੇ ਉਦਾਹਰਣ ਦੇਣਾ:
ਇਹ ਤੁਸੀਂ ਐਸੇ ਡਰਾਫਟ ਲੈਂਦੇ ਹੋ ਜੋ ਤੇਜ਼ੀ ਨਾਲ ਚਲਾਕੀ ਨਾਲ ਜाँचੇ ਅਤੇ ਇਕੱਠੇ ਕੀਤੇ ਜਾ ਸਕਦੇ ਹਨ।
ਇਨਕਿ ਨੁਕਸਾਨਾਂ ਵਾਲੇ ਖੇਤਰਾਂ ਲਈ ਮਿਆਰ ਕਾਫੀ ਤੇਜ਼ੀ ਨਾਲ ਉੱਪਰ ਚੜ੍ਹ ਜਾ ਸਕਦਾ ਹੈ:
ਇਥੇ established libraries, hosted providers ਅਤੇ ਅਧਿਕਾਰਿਕ SDKs ਵਰਤੋ—ਇੱਕ ਛੋਟੀ ਸਮੀਖਿਆ ਲਈ ਵਿਸ਼ੇਸ਼ਗ੍ਯ ਲਿਆਉਣਾ ਲੰਮੇ ਸਮੇਂ ਦੀ ਸੁਰੱਖਿਆ ਤੋਂ ਸਸਤਾ ਪੈ ਸਕਦਾ ਹੈ।
Debts ਨੂੰ ਇਰਾਦੇ ਨਾਲ ਲਿਖੋ ਤੇ ਪਾਰਦਰਸ਼ੀ ਬਣਾਓ:
ਇਸ ਨਾਲ 'ਚੰਗਾ ਕਾਫੀ' ਤੁਹਾਡੇ ਫਾਇਦੇ ਵਿੱਚ ਕੰਮ ਕਰਦਾ ਰਹਿੰਦਾ ਹੈ।