ਕਿਉਂ ਇਹ ਸਿਧਾਂਤ ਅਜੇ ਵੀ ਮਾਇਨੇ ਰੱਖਦੇ ਹਨ ਜਦੋਂ AI ਤੇਜ਼ੀ ਨਾਲ ਕੋਡ ਲਿਖਦਾ ਹੈ\n\nAI ਮਿੰਟਾਂ ਵਿੱਚ ਕੰਮ-ਵਾਂਗ ਕੋਡ ਤਿਆਰ ਕਰ ਸਕਦਾ ਹੈ। ਇਸ ਨਾਲ ਪ੍ਰੋਜੈਕਟ ਦੀ ਰਫਤਾਰ ਬਦਲਦੀ ਹੈ, ਪਰ ਇਹ ਨਹੀਂ ਬਦਲਦਾ ਕਿ ਸੌਫਟਵੇਅਰ ਕਾਮਿਆਬ ਹੋਣ ਲਈ ਕੀ ਚਾਹੀਦਾ ਹੈ। Joel Spolsky ਦੇ “ਸੌਫਟਵੇਅਰ ਸਿਧਾਂਤ” ਕਦੇ ਭੀ ਸਿਰਫ਼ ਟਾਈਪ ਕਰਨ ਦੀ ਰਫ਼ਤਾਰ ਬਾਰੇ ਨਹੀਂ ਸਨ। ਉਹ ਫੈਸਲੇ, ਫੀਡਬੈਕ ਲੂਪ ਅਤੇ ਆਪਣੇ-ਹੱਥ-ਨਾਲ ਬਣੀ ਜਟਿਲਤਾ ਤੋਂ ਬਚਣ ਬਾਰੇ ਸਨ।\n\nਬਦਲਿਆ ਹੋਇਆ ਜੋ ਹੈ ਉਹ ਹੈ ਕੋਡ ਬਣਾਉਣ ਦੀ ਲਾਗਤ। ਤੁਸੀਂ ਤਿੰਨ ਰੂਪ, ਪੰਜ ਵੈਰੀਏਸ਼ਨ ਜਾਂ ਪੂਰਾ ਰੀਰਾਈਟ ਮੰਗ ਸਕਦੇ ਹੋ ਅਤੇ ਫੌਰਨ ਕੁਝ ਮਿਲ ਜਾਵੇਗਾ। ਜੋ ਨਹੀਂ ਬਦਲਿਆ ਉਹ ਹੈ ਸਹੀ ਰਸਤਾ ਚੁਣਣ ਦੀ, ਉਸਨੂੰ ਚੈੱਕ ਕਰਨ ਦੀ ਅਤੇ ਮਹੀਨਿਆਂ ਤੱਕ ਉਸ ਨਾਲ ਰਹਿਣ ਦੀ ਲਾਗਤ। ਲਿਖਣ 'ਤੇ ਬਚਿਆ ਸਮਾਂ ਅਕਸਰ ਇਹਨਾਂ ਚੀਜ਼ਾਂ ਵਿੱਚ ਚਲੇ ਜਾਂਦਾ ਹੈ: ਤੁਸੀਂ ਕੀ ਮਤਲਬ ਕੀਤਾ, ਐੱਜ ਕੇਸ ਤਸਦੀਕ ਕਰਨਾ, ਅਤੇ ਪੱਕਾ ਕਰਨਾ ਕਿ ਅੱਜ ਦੀ ਤੇਜ਼ੀ ਵਾਲੀ ਜਿੱਤ ਕੱਲ੍ਹ ਦੇ ਰਖ-ਰਖਾਵ ਦੇ ਬੋਰ ਨਹੀਂ ਬਣੀ।\n\nਸਹੀਪਣ, ਸੁਰੱਖਿਆ ਅਤੇ ਰੱਖ-ਰਖਾਵ ਅਜੇ ਵੀ ਵਾਸਤਵਿਕ ਸਮਾਂ ਲੈਂਦੇ ਹਨ ਕਿਉਂਕਿ ਉਹ ਦ੍ਰਿੜ ਸਬੂਤ ਤੇ ਨਿਰਭਰ ਹੁੰਦੇ ਹਨ, ਭਰੋਸੇ ਤੇ ਨਹੀਂ। ਇੱਕ ਲੌਗਿਨ ਫਲੋ ਉਸ ਵੇਲੇ ਤੱਕ ਮੁਕੰਮਲ ਨਹੀਂ ਹੁੰਦਾ ਜਦੋਂ ਉਹ ਕੰਪਾਈਲ ਹੋ ਜਾਵੇ। ਉਹ ਮੁਕੰਮਲ ਉਹ ਵੇਲੇ ਹੁੰਦਾ ਹੈ ਜਦੋਂ ਉਹ ਮੰਗਣ ਵਾਲੇ ਖ਼ਰਾਬ ਇਨਪੁੱਟ ਨੂੰ ਨਿਰਧਾਰਤ ਤੌਰ 'ਤੇ ਰੱਦ ਕਰ ਦਿੰਦਾ, ਅਜੀਬ ਹਾਲਤਾਂ ਨੂੰ ਹੈਂਡਲ ਕਰਦਾ ਅਤੇ ਡਾਟਾ ਲੀਕ ਨਹੀਂ ਹੁੰਦਾ। AI ਪੱਕਾ ਲੱਗ ਸਕਦਾ ਹੈ ਪਰ ਇੱਕ ਅਹੰਕਾਰਕ ਖਾਮੀ ਛੱਡ ਸਕਦਾ ਹੈ—ਜਿਵੇਂ ਕਿਸੇ ਏਂਡਪੋਇੰਟ 'ਤੇ ਪਰਮਿਸ਼ਨ ਚੈਕ ਨਾ ਹੋਣਾ ਜਾਂ ਪੇਮੈਂਟ ਅਪਡੇਟ ਵਿੱਚ ਰੇਸ ਕਂਡੀਸ਼ਨ।\n\nAI ਉਸ ਵੇਲੇ ਸਭ ਤੋਂ ਜ਼ਿਆਦਾ ਮਜ਼ਬੂਤ ਹੁੰਦਾ ਹੈ ਜਦੋਂ ਤੁਸੀਂ ਇਸਨੂੰ ਇੱਕ ਤੇਜ਼ ਡਰਾਫਟ ਮਸ਼ੀਨ ਵਾਂਗ ਵਰਤਦੇ ਹੋ। ਇਹ ਬੋਇਲਰਪਲੇਟ, ਦੁਹਰਾਉਣਯੋਗ ਪੈਟਰਨ, ਤੇਜ਼ ਰਿਫੈਕਟਰ ਅਤੇ ਇਕੱਠੇ ਤੁਲਨਾ ਕਰਨ ਲਾਇਕ ਵਿਕਲਪਾਂ ਵਿੱਚ ਚਮਕਦਾ ਹੈ। ਚੰਗੀ ਤਰ੍ਹਾਂ ਵਰਤਿਆ ਜਾਵੇ ਤਾਂ ਇਹ “ਖਾਲੀ ਪੇਜ” ਫੇਜ਼ ਨੂੰ ਸੰਕੁਚਿਤ ਕਰਦਾ ਹੈ।\n\nAI ਸਭ ਤੋਂ ਵੱਧ ਨੁਕਸਾਨ ਪਹੁੰਚਾਉਂਦਾ ਹੈ ਜਦੋਂ ਤੁਸੀਂ ਇਸਨੂੰ ਝੁਟਲੇ ਮਨੋਰਥ ਦਿੰਦਿਆਂ ਹੋ ਅਤੇ ਨਤੀਜੇ ਨੂੰ ਸਿਧਾ ਮੰਨ ਲੈਂਦੇ ਹੋ। ਉਹੀ ਫੇਲယਰ ਪੈਟਰਨ ਫਿਰ ਵਾਰ-ਵਾਰ ਆਉਂਦੇ ਹਨ: ਲੁਕੀਆਂ ਧਾਰਨਾਵਾਂ (ਬਿਆਨ ਨਾ ਕੀਤੇ ਬਿਜ਼ਨਸ ਨਿਯਮ), ਅਣਪਰੀਖਿਆਵੇਂ ਰਾਹ (ਰੇਟ੍ਰਾਈਜ਼, ਏਰਰ ਹੈਂਡਲਿੰਗ, ਖਾਲੀ ਸਟੇਟ), ਪੱਕੇ ਹੋਏ ਗਲਤ ਫੈਸਲੇ (ਐਸਾ ਕੋਡ ਜੋ ਯਕੀਨੀ ਲੱਗਦਾ ਹੈ ਪਰ ਸੁਥਰਾ ਗਲਤ ਹੈ), ਅਤੇ “ਚਲਾਕ” ਸੁਝਾਅ ਜੋ ਅੱਗੇ ਜਾ ਕੇ ਸਮਝਾਉਣਾ ਔਖਾ ਹੁੰਦੇ ਹਨ।\n\nਜੇ ਕੋਡ ਸਸਤਾ ਹੋ ਗਿਆ ਹੈ ਤਾਂ ਨਵਾਂ ਘੱਟ-ਉਪਲਬਧ ਸਾਧਨ ਭਰੋਸਾ ਹੈ। ਇਹ ਸਿਧਾਂਤ ਇਸ ਲਈ ਮਾਇਨੇ ਰੱਖਦੇ ਹਨ ਕਿ ਇਹ ਭਰੋਸਾ ਬਚਾਉਂਦੇ ਹਨ: ਯੂਜ਼ਰਾਂ ਨਾਲ, ਟੀਮ ਨਾਲ, ਅਤੇ ਤੁਹਾਡੇ ਭਵਿੱਖ ਦੇ ਆਪ ਨਾਲ।\n\n## ਟੈਸਟਿੰਗ ਹਾਲੇ ਵੀ ਬੋਤਲਗੇਟ ਹੈ, ਅਤੇ ਇਹ ਚੰਗੀ ਗੱਲ ਹੈ\n\nਜਦੋਂ AI ਕਿਸੇ ਫੀਚਰ ਨੂੰ ਮਿੰਟਾਂ ਵਿੱਚ ਜਨਰੇਟ ਕਰ ਸਕਦਾ ਹੈ, ਤਾਂ ਟੈਸਟਿੰਗ ਨੂੰ ਕੁਝ ਲੋਕ ਤੇਜ਼ੀ ਨਾਲ ਖਤਮ ਕਰਨ ਵਾਲੀ ਹਿੱਸਾ ਮੰਨਣ ਦੀ ਲਾਲਚ ਹੁੰਦੀ ਹੈ। Spolsky ਦਾ ਨੁਕਤਾ ਅਜੇ ਵੀ ਸਹੀ ਹੈ: ਹੌਲੀ ਭਾਗ ਹੀ ਸੱਚਾਈ ਰੱਖਦਾ ਹੈ। ਕੋਡ ਤਿਆਰ ਕਰਨਾ ਆਸਾਨ ਹੈ। ਸਹੀ ਵਿਹਾਰ ਨਹੀਂ।\n\nਇੱਕ ਲਾਭਦਾਇਕ ਬਦਲਾਅ ਇਹ ਹੈ ਕਿ ਟੈਸਟਾਂ ਨੂੰ ਉਹ ਲੋੜ ਮੰਨੋ ਜੋ ਤੁਸੀਂ ਰਨ ਕਰ ਸਕਦੇ ਹੋ। ਜੇ ਤੁਸੀਂ ਉਮੀਦ ਕੀਤੀ ਵਿਹਾਰ ਨੂੰ ਚੈੱਕ ਕਰਨਯੋਗ ਤਰੀਕੇ ਨਾਲ ਦਰਸਾ ਨਹੀਂ ਸਕਦੇ, ਤਾਂ ਤੁਸੀਂ ਸੋਚਣਾ ਮੁਕੰਮਲ ਨਹੀਂ ਕੀਤਾ। AI-ਸਹਾਇਤ ਕੰਮ ਵਿੱਚ ਇਹ ਹੋਰ ਮਹੱਤਵਪੂਰਨ ਹੋ ਜਾਂਦਾ ਹੈ, ਕਿਉਂਕਿ ਮਾਡਲ ਆਤਮ-ਵਿਸ਼ਵਾਸ ਨਾਲ ਕੁਝ ਐਸਾ ਨਿਰਪੇਖ ਰੂਪ ਦੇ ਸਕਦਾ ਹੈ ਜੋ ਥੋੜ੍ਹਾ ਜਿਹਾ ਗਲਤ ਹੋਵੇ।\n\nਟੈਸਟਿੰਗ ਉਨ੍ਹਾਂ ਚੀਜ਼ਾਂ ਨਾਲ ਸ਼ੁਰੂ ਕਰੋ ਜਿਨ੍ਹਾਂ ਦੇ ਟੁੱਟਣ ਨਾਲ ਸਭ ਤੋਂ ਜ਼ਿਆਦਾ ਨੁਕਸਾਨ ਹੋਵੇ। ਜ਼ਿਆਦਾਤਰ ਉਤਪਾਦਾਂ ਵਿੱਚ ਇਹ ਮੁੱਖ ਫਲੋ ਹਨ (ਸਾਈਨਅਪ, ਚੈਕਆਊਟ, ਸੇਵ, ਐਕਸਪੋਰਟ), ਪਰਮਿਸ਼ਨ (ਕੌਣ ਦੇਖ ਸਕਦਾ/ਸੰਪਾਦਨ/ਹਟਾ ਸਕਦਾ ਹੈ), ਅਤੇ ਡੇਟਾ ਇੰਟੀਗ੍ਰਿਟੀ (ਕੋਈ ਡੁਪਲੀਕੇਟ ਨਹੀਂ, ਸਹੀ ਟੋਟਲ, ਸੇਫ ਮਾਈਗ੍ਰੇਸ਼ਨ)। ਫਿਰ ਉਹ ਐੱਜ ਵੇਰਿਆਂ ਨੂੰ ਕਵਰ ਕਰੋ ਜੋ ਆਖਰੀ ਪਲ ਦੇ INCIDENTS ਦਾ ਕਾਰਨ ਬਣਦੇ ਹਨ: ਖਾਲੀ ਇਨਪੁੱਟ, ਲੰਬਾ ਟੈਕਸਟ, ਟਾਈਮ ਝੋਨ, ਰੀਟ੍ਰਾਈਜ਼, ਅਤੇ ਬਹਿਰਲੇ ਸਰਹੱਦ ਜਿਵੇਂ payments, emails ਅਤੇ ਫਾਇਲ ਅpload।\n\nAI ਟੈਸਟ ਕੇਸ ਸੁਝਾਉਣ ਵਿੱਚ ਮਹਿਰਤ ਰੱਖਦਾ ਹੈ, ਪਰ ਇਹ ਨਹੀਂ ਜਾਣ ਸਕਦਾ ਕਿ ਤੁਸੀਂ ਯਥਾਰਥ ਵਿੱਚ ਯੂਜ਼ਰਾਂ ਨੂੰ ਕੀ ਵਾਅਦਾ ਕੀਤਾ ਹੈ। ਇਸਨੂੰ ਇੱਕ ਬ੍ਰੇਨਸਟਾਰਮਿੰਗ ਸਾਥੀ ਵਾਂਗ ਵਰਤੋ: ਗੁੰਮਸ਼ੁਦਾ ਐੱਜ ਕੇਸਾਂ, ਅਬਿਊਜ਼ ਸਥਿਤੀਆਂ, ਅਤੇ ਪਰਮਿਸ਼ਨ ਕਾਂਬੀਨੇਸ਼ਨਾਂ ਲਈ ਪੁੱਛੋ। ਫਿਰ ਮਨੁੱਖੀ ਕੰਮ ਕਰੋ: ਕਵਰੇਜ ਨੂੰ ਤੁਹਾਡੇ ਅਸਲੀ ਨਿਯਮਾਂ ਨਾਲ ਮਿਲਾਓ ਅਤੇ ਉਹ ਟੈਸਟ ਹਟਾਓ ਜੋ ਸਿਰਫ਼ “ਇੰਪਲਿਮੈਂਟੇਸ਼ਨ” ਦੀ ਜਾਂਚ ਕਰਦੇ ਹਨ ਨਾ ਕਿ ਵਿਹਾਰ ਦੀ।\n\nਫੇਲਯੂਰ ਨੂੰ actionable ਬਣਾਓ। ਨਾਕਾਮ ਟੈਸਟ ਤੁਹਾਨੂੰ ਇਹ ਦੱਸਣਾ ਚਾਹੀਦਾ ਹੈ ਕਿ ਕੀ ਟੁੱਟਿਆ, ਨਾ ਕਿ ਤੁਹਾਨੂੰ ਖਜਾਨੇ ਦੀ ਖੋਜ 'ਤੇ ਭੇਜੋ। ਟੈਸਟਾਂ ਨੂੰ ਛੋਟੇ ਰੱਖੋ, ਉਹਨਾਂ ਦੇ ਨਾਮ ਵਾਕਿਆਂ ਵਾਂਗ ਰੱਖੋ, ਅਤੇ ਏਰਰ ਸੁਨੇਹੇ ਨਿਰਦਿਸ਼ਟ ਬਣਾਓ।\n\n### ਇੱਕ ਤੇਜ਼ ਉਦਾਹਰਣ\n\nਮਾਨ ਲਓ ਤੁਸੀਂ ਇੱਕ ਸਧਾਰਣ “ਟੀਮ ਨੋਟਸ” ਐਪ ਬਣਾਉਂਦੇ ਹੋ AI ਮਦਦ ਨਾਲ। CRUD ਸਕ੍ਰੀਨ ਤੇਜ਼ੀ ਨਾਲ ਆ ਜਾਂਦੇ ਹਨ। ਸਹੀਪਣ ਦੀ ਜੋਖਮ UI ਨਹੀਂ ਹੁੰਦੀ। ਉਹ ਹੈ ਪਹੁੰਚ ਨਿਯੰਤਰਣ ਅਤੇ ਡੇਟਾ ਨਿਯਮ: ਇੱਕ ਯੂਜ਼ਰ ਨੂੰ ਦੂਜੇ ਟੀਮ ਦੀਆਂ ਨੋਟਸ ਨਹੀਂ ਵੇਖਣੀਆਂ, ਸੰਪਾਦਨ ਨਵੇਂ ਬਦਲਾਅ ਨੂੰ ਓਵਰਰਾਈਟ ਨਹੀਂ ਕਰਨਾ ਚਾਹੀਦਾ, ਅਤੇ ਨੋਟ ਹਟਾਉਣ ਨਾਲ ਅਟੈਚਮੈਂਟ orphan ਨਹੀਂ ਛੱਡਣੇ ਚਾਹੀਦੇ। ਇਹ ਨਿਯਮ ਲਾਕ ਕਰਨ ਵਾਲੇ ਟੈਸਟ ਬੋਤਲਗੇਟ ਹੋਣਗੇ, ਪਰ ਉਹ ਤੁਹਾਡਾ ਸੁਰੱਖਿਆ ਜਾਲ ਵੀ ਹਨ।\n\nਜਦੋਂ ਟੈਸਟਿੰਗ ਬੋਤਲਗੇਟ ਬਣਦੀ ਹੈ, ਇਹ ਸਪਸ਼ਟਤਾ ਨੂੰ ਮਜਬੂਤ ਕਰਦੀ ਹੈ। ਇਹੀ ਸਪਸ਼ਟਤਾ ਤੇਜ਼ ਕੋਡ ਨੂੰ ਤੇਜ਼ ਬੱਗ ਵਿੱਚ ਬਦਲਣ ਤੋਂ ਰੋਕਦੀ ਹੈ।\n\n## ਸਾਦਗੀ ਚਲਾਕੀ 'ਤੇ ਜਿੱਤਦੀ ਹੈ, ਖਾਸ ਕਰਕੇ AI ਦੇ ਨਾਲ\n\nਇੱਕ ਸਭ ਤੋਂ ਦਰਗਾਹੀ ਸਿਧਾਂਤ ਇਹ ਹੈ ਕਿ ਸਧਾਰਨ ਕੋਡ ਚਲਾਕ ਕੋਡ 'ਤੇ ਜਿੱਤਦਾ ਹੈ। AI ਇਸ ਗੱਲ ਦੀ ਲਾਲਚ ਦਿੰਦਾ ਹੈ ਕਿ ਤੁਸੀਂ ਸਵੈ-ਪ੍ਰਦੱਸ਼ਿਤ ਸੁਧੀ ਅਬਸਟ੍ਰੈਕਸ਼ਨਾਂ ਨੂੰ ਸਵੀਕਾਰ ਕਰੋ ਕਿਉਂਕਿ ਉਹ ਪਾਲਿਸ਼ਡ ਅਤੇ ਤੇਜ਼ ਆਉਂਦੀਆਂ ਹਨ। ਖਰਚਾ ਅੱਗੇ ਆਉਂਦਾ ਹੈ: ਬਗਾਂ ਲਈ ਹੋਰ ਥਾਵਾਂ, ਜ਼ਿਆਦਾ ਫਾਇਲਾਂ ਜਾਂ “ਇਹ ਕੀ ਕਰ ਰਿਹਾ ਹੈ?” ਦੇ ਮੋਹਰੇ।\n\nਜਦੋਂ ਕੋਡ ਸਸਤਾ ਹੋ ਜਾਂਦਾ ਹੈ, ਤਾਂ ਤੁਸੀਂ ਜਟਿਲਤਾ ਲਈ ਪੇਸਾ ਚੁਕਾਉਂਦੇ ਹੋ। ਇੱਕ ਛੋਟੀ, ਬੋਰਿੰਗ ਡਿਜ਼ਾਇਨ ਟੈਸਟ ਕਰਨ ਵਿੱਚ ਆਸਾਨ ਹੁੰਦੀ ਹੈ, ਬਦਲਣ ਵਿੱਚ ਆਸਾਨ ਅਤੇ ਸਮਝਾਉਣ ਵਿੱਚ ਆਸਾਨ। ਇਹ ਉਸ ਵੇਲੇ ਹੋਰ ਜ਼ਰੂਰੀ ਹੈ ਜਦੋਂ ਪਹਿਲਾ ਡਰਾਫਟ ਕਿਸੇ ਮਾਡਲ ਤੋਂ ਆਇਆ ਹੋਵੇ ਜੋ ਪੱਕਾ ਲੱਗ ਸਕਦਾ ਹੈ ਪਰ ਸੁਥਰੇ ਤਰੀਕੇ ਨਾਲ ਗਲਤ ਹੋ ਸਕਦਾ ਹੈ।\n\nਇੱਕ ਲਾਭਕਾਰੀ ਨਿਯਮ ਇਹ ਹੈ ਕਿ ਫੰਕਸ਼ਨ, ਕੰਪੋਨੈਂਟ ਅਤੇ ਮੌਡਿਊਲ ਇੰਨੇ ਛੋਟੇ ਰੱਖੋ ਕਿ ਕੋਈ ਟੀਮਮੇਟ ਉਹਨਾਂ ਦੀ ਸਮੀਖਿਆ ਮਿੰਟਾਂ ਵਿੱਚ ਕਰ ਸਕੇ, ਘੰਟਿਆਂ ਵਿੱਚ ਨਹੀਂ। ਜੇ ਇੱਕ React ਕੰਪੋਨੈਂਟ ਨੂੰ ਕਈ custom hooks, ਇੱਕ ਲੋਕਲ ਸਟੇਟ ਮਸ਼ੀਨ ਅਤੇ ਇੱਕ generic “smart renderer” ਲੇਅਰ ਦੀ ਲੋੜ ਹੈ, ਤਾਂ ਠਹਿਰੋ ਅਤੇ ਸੋਚੋ ਕਿ ਕੀ ਤੁਸੀਂ ਇੱਕ ਅਸਲ ਸਮੱਸਿਆ ਹੱਲ ਕਰ ਰਹੇ ਹੋ ਜਾਂ ਸਿਰਫ਼ ਆਰਕਿਟੈਕਚਰ ਕਬੂਲ ਕਰ ਰਹੇ ਹੋ ਕਿਉਂਕਿ AI ਨੇ ਇਹ ਦੱਸਿਆ।\n\nਕੁਝ “ਸਾਦਗੀ ਟੈਸਟ” ਤੁਹਾਨੂੰ ਵਾਪਸ ਧੱਕ ਸਕਦੇ ਹਨ:\n\n- ਇੱਕ ਨਵਾਂ ਟੀਮਮੇਟ ਮੁੱਖ ਫਲੋ ਕੀ ਇੱਕ ਬੈਠਕ ਵਿੱਚ ਸਮਝ ਸਕਦਾ ਹੈ?\n- ਕੀ ਤੁਸੀਂ ਇਸ ਅਬਸਟ੍ਰੈਕਸ਼ਨ ਨੂੰ ਹਟਾ ਕੇ ਸਧਾਰਨ ਕੋਡ ਨਾਲ ਬਦਲ ਸਕਦੇ ਹੋ ਬਿਨਾਂ ਸਪਸ਼ਟਤਾ ਗੁਆਏ?\n- ਕੀ ਬੱਗ ਠੀਕ ਕਰਨ ਲਈ ਇੱਕ ਸਪਸ਼ਟ ਜਗ੍ਹਾ ਹੈ, ਜਾਂ ਪੰਜ?\n- ਕੀ ਹਰ ਹਿੱਸੇ ਦੀ ਇੱਕ ਜاب ਹੈ ਜੋ ਤੁਸੀਂ ਇੱਕ ਵਾਕ ਵਿੱਚ ਬਿਆਨ ਕਰ ਸਕਦੇ ਹੋ?\n\nਪ੍ਰੌਂਪਟਾਂ ਮਹੱਤਵਪੂਰਨ ਹਨ। ਜੇ ਤੁਸੀਂ “ਸਭ ਤੋਂ ਵਧੀਆ ਆਰਕੀਟੈਕਚਰ” ਮੰਗਦੇ ਹੋ, ਤਾਂ ਅਕਸਰ ਤੁਹਾਨੂੰ ਇੱਕ ਵੱਧ-ਬਣਿਆ ਹੋਇਆ ਆਰਕੀਟੈਕਚਰ ਮਿਲਦਾ ਹੈ। ਇਨ੍ਹਾਂ ਅਸਥਿਰਤਾਵਾਂ ਵੱਲ ਧਕੇਲਣ ਲਈ ਪਾਬੰਦੀਆਂ ਦਿਓ: ਸਭ ਤੋਂ ਘੱਟ ਫਾਇਲਾਂ ਨਾਲ ਸਧਾਰਨ ਤਰੀਕਾ ਵਰਤੋ; ਨਵੇਂ ਅਬਸਟ੍ਰੈਕਸ਼ਨ ਤਦ ਹੀ ਲੈਓ ਜਦੋਂ ਉਹ 3+ ਥਾਵਾਂ 'ਤੇ ਨਕਲ ਘਟਾਉਂਦੇ ਹਨ; ਜਨਰਿਕ ਹੈਲਪਰਾਂ ਬਜਾਏ ਸਪਸ਼ਟ ਕੋਡ ਨੂੰ ਪਸੰਦ ਕਰੋ।\n\nਇੱਕ ਵਾਸਤਵਿਕ ਉਦਾਹਰਣ: ਤੁਸੀਂ AI ਨੂੰ ਇੱਕ ਐਡਮਿਨ ਪੇਜ 'ਤੇ ਰੋਲ-ਆਧਾਰਿਤ ਐਕਸੈਸ ਜੋੜਨ ਲਈ ਕਹਿੰਦੇ ਹੋ। ਚਲਾਕ ਵਰਜ਼ਨ ਇੱਕ permission ਫਰੇਮਵਰਕ, ਡੈਕੇਰੇਟਰਾਂ ਅਤੇ ਇੱਕ config DSL ਲਿਆਉਂਦਾ ਹੈ। ਸਧਾਰਨ ਵਰਜ਼ਨ ਇੱਕ ਹੀ ਜਗ੍ਹਾ 'ਤੇ ਯੂਜ਼ਰ ਰੋਲ ਚੈੱਕ ਕਰਦਾ ਹੈ, ਰੂਟਾਂ ਨੂੰ ਇੱਕ ਹੀ ਥਾਂ ਤੇ ਗੇਟ ਕਰਦਾ ਹੈ, ਅਤੇ ਨਾਕਾਰਤ ਨੋ-ਐਕਸੈਸ ਨੂੰ ਲੌਗ ਕਰਦਾ ਹੈ। ਸਧਾਰਨ ਵਰਜ਼ਨ ਸਮੀਖਿਆ ਵਿੱਚ ਆਸਾਨ, ਟੈਸਟ ਕਰਨ ਵਿੱਚ ਆਸਾਨ ਅਤੇ ਗਲਤ ਸਮਝਣ 'ਚ ਮੁਸ਼ਕਲ ਹੁੰਦਾ ਹੈ।\n\nਜੇ ਤੁਸੀਂ ਕਿਸੇ ਚੈਟ-ਅਧਾਰਤ ਟੂਲ ਜਿਵੇਂ Koder.ai ਵਿੱਚ ਬਣਾ ਰਹੇ ਹੋ, ਤਾਂ ਸਾਦਗੀ snapshots ਅਤੇ rollback ਨੂੰ ਵੀ ਕੀਮਤੀ ਬਣਾਉਂਦੀ ਹੈ। ਛੋਟੇ, ਸਪਸ਼ਟ ਬਦਲਾਅ ਦੀ ਤੁਲਨਾ, ਸੰਭਾਲਣਾ ਜਾਂ ਵਾਪਸ ਲੈਣਾ ਆਸਾਨ ਹੁੰਦਾ ਹੈ।\n\n## ਭਰਤੀ: ਤੁਹਾਨੂੰ ਟਾਈਪਿਸਟ ਨਹੀਂ, ਐਡੀਟਰ ਅਤੇ ਫੈਸਲੇ ਕਰਨ ਵਾਲੇ ਚਾਹੀਦੇ ਹਨ\n\nਜਦੋਂ ਕੋਡ ਪੈਦਾ ਕਰਨਾ ਆਸਾਨ ਹੋ ਜਾਂਦਾ ਹੈ, ਤਾਂ ਕੀਮਤੀ ਹੁਨਰ ਇਹ ਹੁੰਦਾ ਹੈ ਕਿ ਇਹ ਚੁਣਨਾ ਕਿ ਕੀ ਮੌਜੂਦ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ ਅਤੇ ਇਹ ਪੱਕਾ ਕਰਨਾ। ਪਹਿਲਾਂ ਵਾਲੀ “ਉਤਮ ਪ੍ਰੋਗ੍ਰਾਮਰ ਭਰਤੀ ਕਰੋ” ਸਲਾਹ ਅਜੇ ਵੀ ਲਾਗੂ ਹੁੰਦੀ ਹੈ, ਪਰ ਨੌਕਰੀ ਬਦਲਦੀ ਹੈ। ਤੁਸੀਂ ਕਿਸੇ ਨੂੰ ਟਾਈਪ ਤੇਜ਼ੀ ਨਾਲ ਕਰਨ ਲਈ ਨਹੀਂ ਰੱਖ ਰਹੇ। ਤੁਸੀਂ ਕਿਸੇ ਨੂੰ ਭਰਤੀ ਕਰ ਰਹੇ ਹੋ ਜੋ ਫੈਸਲਾ ਕਰੇ, ਸੁਧਾਰੇ ਅਤੇ ਉਤਪਾਦ ਦੀ ਰੱਖਿਆ ਦੇ ਵਾਸਤੇ ਖੜਾ ਰਹੇ।\n\nAI-ਸਹਾਇਤ ਵਿਕਾਸ ਵਿੱਚ ਸਭ ਤੋਂ ਵਧੀਅਾ ਲੋਕ ਅਕਸਰ ਚਾਰ ਗੁਣ ਸਾਂਝੇ ਕਰਦੇ ਹਨ: ਫੈਸਲਾ ਕਰਨ ਦੀ ਸਮਰੱਥਾ (ਕੀ ਮਾਇਨੇ ਰੱਖਦਾ ਹੈ), ਸਵਾਦ (ਵਧੀਆ ਕੀ ਦਿਖਦਾ ਹੈ), ਡੀਬੱਗ ਸਖਤੀ (ਅਸਲ ਕਾਰਨ ਲੱਭਣਾ), ਅਤੇ ਸੰਚਾਰ (ਟਰੇਡ-ਆਫ ਸਪਸ਼ਟ ਕਰਨਾ)। ਉਹ AI-ਲਿਖੀ ਫੀਚਰ ਨੂੰ ਜੋ “ਲਗਭਗ ਕੰਮ ਕਰਦਾ” ਉਹ ਪ੍ਰੋਡਕਟ ਤੇ ਭਰੋਸਾ ਯੋਗ ਬਣਾਉਣ ਵਿੱਚ ਬਦਲ ਸਕਦੇ ਹਨ।\n\n### ਇੱਕ ਬਿਹਤਰ ਇੰਟਰਵਿਊ: AI ਬਦਲਾਅ ਸੁਧਾਰੋ\n\nਸਿਰਫ਼ ਸ਼ੁਰੂ ਤੋਂ ਪੂਰਾ ਹੱਲ ਮੰਗਣ ਦੀ ਥਾਂ, ਉਮੀਦਵਾਰਾਂ ਨੂੰ ਇੱਕ AI-ਜਨਰੇਟ ਕੀਤੀ pull request (ਯਾ ਪੇਸਟ ਕੀਤੀ diff) ਦਿਓ ਜਿਸ ਵਿੱਚ ਕੁਝ ਹਕੀਕਤੀ ਸਮੱਸਿਆਵਾਂ ਹੋਣ: ਅਸਪਸ਼ਟ ਨਾਂ, ਇੱਕ ਛੁਪਿਆ ਐੱਜ ਕੇਸ, ਲਾਪਤਾ ਟੈਸਟ, ਅਤੇ ਇੱਕ ਛੋਟੀ ਸੁਰੱਖਿਆ ਗਲਤੀ।\n\nਉਨ੍ਹਾਂ ਨੂੰ ਪੁੱਛੋ ਕਿ ਉਹ ਕੋਡ ਕੀ ਕਰਨ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰ ਰਿਹਾ ਹੈ ਸਧਾਰਨ ਭਾਸ਼ਾ ਵਿੱਚ ਸਮਝਾਂ, ਸਭ ਤੋਂ ਉੱਚਾ-ਖਤਰੇ ਵਾਲੇ ਹਿੱਸੇ ਲੱਭੋ, ਸੁਧਾਰ ਸੁਝਾਅ ਦਿਓ, ਅਤੇ ਉਹ ਟੈਸਟ ਸ਼ਾਮਲ (ਜਾਂ ਰੂਪਰੇਖਾ) ਕਰਕੇ ਦਿਖਾਓ ਜੋ ਰਿਗਰੈਸ਼ਨ ਫੜ ਲੈਣਗੇ। ਜੇ ਤੁਸੀਂ ਇੱਕ ਮਜ਼ਬੂਤ ਸੰਕੇਤ ਚਾਹੁੰਦੇ ਹੋ, ਤਾਂ ਪੁੱਛੋ ਕਿ ਉਹ ਕਿਵੇਂ ਅਗਲੀ AI ਕੋਸ਼ਿਸ਼ ਨੂੰ ਬਿਹਤਰ ਬਣਾਉਣ ਲਈ ਹਦਾਇਤਾਂ ਨੂੰ ਬਦਲਦੇ।\n\nਇਹ ਦਿਖਾਉਂਦਾ ਹੈ ਕਿ ਉਹ ਅਸਲੀ ਹਾਲਾਤਾਂ ਵਿੱਚ ਕਿਵੇਂ ਸੋਚਦੇ ਹਨ: ਅਪਰਿਪੂਰਨ ਕੋਡ, ਸੀਮਿਤ ਸਮਾਂ, ਅਤੇ ਤਰਜੀحات ਚੁਣਨ ਦੀ ਲੋੜ।\n\n### ਸੁਪਰਪਾਵਰ: “ਨਹੀਂ” ਕਹਿਣ ਦੀ ਕਾਬਲੀਅਤ\n\nAI ਅਕਸਰ ਆਤਮ-ਵਿਸ਼ਵਾਸ ਨਾਲ ਗੱਲ ਕਰਦਾ ਹੈ। ਚੰਗੀਆਂ ਭਰਤੀਆਂ ਵਾਪਸ ਧੱਕਣ ਵਿੱਚ ਆਰਾਮਦਾਇਕ ਹੁੰਦੀਆਂ ਹਨ। ਉਹ ਕਿਸੇ ਫੀਚਰ ਨੂੰ ਕਰਲੀਅਟ ਮੰਨਣ ਵਿੱਚ ਨਾ ਕਹਿ ਸਕਦੇ ਜੋ ਜਟਿਲਤਾ ਵਧਾਉਂਦਾ ਹੈ, ਕਿਸੇ ਬਦਲਾਅ ਨੂੰ ਨਾ ਕਹਿ ਸਕਦੇ ਜੋ ਸੁਰੱਖਿਆ ਨੂੰ ਕਮਜ਼ੋਰ ਕਰਦਾ ਹੈ, ਅਤੇ ਸਬੂਤ ਦੇ ਬਿਨਾਂ ਸ਼ਿਪ ਕਰਨ ਨੂੰ ਨਹੀੰ ਮੰਨਦੇ।\n\nਇੱਕ ਠੋਸ ਨਿਸ਼ਾਨ ਇਹ ਹੈ ਕਿ ਉਹ “ਕੀ ਤੁਸੀਂ ਇਹ ਮਰਜ ਕਰੋਗੇ?” ਦੇ ਜਵਾਬ ਵਿੱਚ ਸਿਰਫ਼ ਭਾਵਨਾ ਨਹੀਂ ਦਿੰਦੇ। ਉਹ ਇੱਕ ਫੈਸਲਾ ਦਿੰਦੇ ਹਨ ਅਤੇ ਲੋੜੀਦੇ ਬਦਲਾਅ ਦੀ ਛੋਟੀ ਸੂਚੀ ਦੇਂਦੇ ਹਨ।\n\nਉਦਾਹਰਣ: ਤੁਸੀਂ ਇੱਕ “ਤਤਕਾਲ” access-control ਅਪਡੇਟ ਮੰਗਦੇ ਹੋ ਅਤੇ AI ਸੁਝਾਅ ਦਿੰਦਾ ਹੈ ਕਿ ਚੈੱਕ ਹੈਂਡਲਰਾਂ ਵਿਚ ਛਿੜਕ ਦੇਓ। ਇੱਕ ਮਜ਼ਬੂਤ ਉਮੀਦਵਾਰ ਉਸ ਪਹੁੰਚ ਨੂੰ ਨਕਾਰਦਾ ਅਤੇ ਇੱਕ ਸਾਫ਼ ਐਥੋਰਾਈਜੇਸ਼ਨ ਲੇਅਰ ਸੁਝਾਉਂਦਾ, ਨਾਲ ਹੀ ਐਡਮਿਨ ਅਤੇ ਨਾਨ-ਐਡਮਿਨ ਰਾਹਾਂ ਲਈ ਟੈਸਟ।\n\nਅੰਤ ਵਿੱਚ, ਸਾਂਝੇ ਮਿਆਰ ਬਣਾਓ ਤਾਂ ਟੀਮ AI ਆਉਟਪੁੱਟ ਨੂੰ ਇਕੋ ਤਰੀਕੇ ਨਾਲ ਸੋਧੇ। ਸਧਾਰਨ ਰੱਖੋ: ਇਕ ਡਿਫਿਨੀਸ਼ਨ ਆਫ ਡਨ, ਕਨਸਿਸਟੈਂਟ ਰਿਵਿਊ ਉਮੀਦਾਂ, ਅਤੇ ਇੱਕ ਟੈਸਟਿੰਗ ਬੇਸਲਾਈਨ।\n\n## ਸਪੈੱਕ ਅਤੇ ਯੋਜਨਾ: ਸਾਫ਼ ਪ੍ਰੌਂਪਟ ਸਾਫ਼ ਸੋਚ ਤੋਂ ਸ਼ੁਰੂ ਹੁੰਦੇ ਹਨ\n\nਜਦੋਂ AI ਮਿੰਟਾਂ ਵਿੱਚ ਬਹੁਤ ਕੋਡ ਜਨਰੇਟ ਕਰ ਸਕਦਾ ਹੈ, ਤਾਂ ਸੋਚ ਛੱਡ ਕੇ ਸਿੱਧਾ ਇਟਰੇਟ ਕਰਨ ਦੀ ਲਾਲਚ ਹੁੰਦੀ ਹੈ। ਡੈਮੋ ਲਈ ਇਹ ਚੱਲ ਸਕਦਾ ਹੈ। ਜਦੋਂ ਤੁਹਾਨੂੰ ਸਹੀਪਣ, ਭਵਿੱਖਬਾਣੀਯੋਗ ਵਿਹਾਰ, ਅਤੇ ਘੱਟ ਹੈਰਾਨੀਆਂ ਚਾਹੀਦੀਆਂ ਹਨ ਤਾਂ ਇਹ ਟੁੱਟ ਜਾਂਦਾ ਹੈ।\n\nਇੱਕ ਚੰਗਾ ਪ੍ਰੌਂਪਟ ਆਮ ਤੌਰ 'ਤੇ ਇੱਕ ਛੋਟੇ ਸਪੈੱਕ ਵਿੱਚ ਲੁਕਿਆ ਹੁੰਦਾ ਹੈ। ਕੋਡ ਮੰਗਣ ਤੋਂ ਪਹਿਲਾਂ ਅਸਲ ਲਕੜ ਨੂੰ ਕੁਝ ਐਕਸੈਪਟੈਂਸ ਕਰਾਈਟੇਰੀਆ ਅਤੇ ਸਪਸ਼ਟ ਨੋਨ-ਗੋਲਾਂ ਵਿੱਚ ਬਦਲੋ। ਇਹ AI (ਅਤੇ ਤੁਹਾਡੀ ਟੀਮ) ਨੂੰ ਸ਼ਾਮ-ਖੇਤਰ ਵਧਾਉਣ ਤੋਂ ਰੋਕਦਾ ਹੈ।\n\nਸਪੈੱਕ ਨੂੰ ਛੋਟਾ ਪਰ ਨਿਰਧਾਰਤ ਰੱਖੋ। ਤੁਸੀਂ ਇਕ ਨਾਵਲ ਨਹੀਂ ਲਿਖ ਰਹੇ—ਤੁਸੀਂ ਹੱਦਾਂ ਨਿਰਧਾਰਤ ਕਰ ਰਹੇ ਹੋ ਜਿਵੇਂ:\n\n- ਇਨਪੁਟ: ਕੀ ਆਉਂਦਾ ਹੈ (ਫੀਲਡ, ਫਾਰਮੈਟ, ਐੱਜ ਕੇਸ)\n- ਆਉਟਪੁਟ: ਕੀ ਵਾਪਸ ਆਉਣਾ ਚਾਹੀਦਾ ਹੈ (ਉਦਾਹਰਣਾਂ ਸਮੇਤ)\n- ਐਰਰ: ਕੀ ਖਰਾਬ ਹੋ ਸਕਦਾ ਹੈ ਅਤੇ ਕਿਵੇਂ ਜਵਾਬ ਦੇਣਾ ਹੈ\n- ਪਾਬੰਦੀਆਂ: ਪਰਫੌਰਮੈਂਸ, ਪ੍ਰਾਈਵੇਸੀ, ਡੀਪੈਂਡੈਂਸੀ ਜਾਂ “ਇਹ ਬਦਲ ਨਹੀੰਣਾ ਚਾਹੀਦਾ” ਖੇਤਰ\n- ਨੋਨ-ਗੋਲ: ਇਸ ਬਦਲਾਅ ਵਿੱਚ ਕੀ ਨਹੀਂ ਕੀਤਾ ਜਾ ਰਿਹਾ\n\nਜਨਰੇਸ਼ਨ ਤੋਂ ਪਹਿਲਾਂ “ਡਨ” ਪਰਿਭਾਸ਼ਿਤ ਕਰੋ, ਨਾਥਰ “ਇਹ ਕੰਪਾਈਲ ਹੋ ਗਿਆ” ਜਾਂ “UI ਠੀਕ ਲੱਗ ਰਿਹਾ” ਤੋਂ ਵੱਧ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ। “ਡਨ” ਵਿੱਚ ਟੈਸਟ ਉਮੀਦਾਂ, ਬੈਕਵਰਡ ਕੰਪੈਟਬਿਲਟੀ, ਅਤੇ ਰਿਲੀਜ਼ ਬਾਅਦ ਕੀ ਮਾਨੀਟਰ ਕੀਤਾ ਜਾਵੇ ਸ਼ਾਮਿਲ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ।\n\nਉਦਾਹਰਣ: ਤੁਸੀਂ “ਪਾਸਵਰਡ ਰੀਸੈੱਟ ਜੋੜੋ” ਕਹਿੰਦੇ ਹੋ। ਇੱਕ ਸਾਫ਼ ਸਪੈੱਕ ਹੋ ਸਕਦਾ ਹੈ: ਯੂਜ਼ਰ ਈਮੇਲ ਰਾਹੀਂ ਰੀਕੁਏਸਟ ਕਰਦੇ ਹਨ; ਲਿੰਕ 15 ਮਿੰਟ ਵਿੱਚ ਖਤਮ; ਚਾਹੇ ਈਮੇਲ ਮੌਜੂਦ ਹੋਵੇ ਜਾਂ ਨਾਹ, ਉਹੀ ਸੁਨੇਹਾ ਦਿਖਾਇਆ ਜਾਵੇ; ਹਰ IP ਲਈ ਰੇਟ ਲਿਮਿਟ; ਟੋਕਨ ਪਲੇਨ-ਟੈਕਸਟ ਵਿੱਚ ਸਟੋਰ ਨਾ ਹੋਵੇ। ਨੋਨ-ਗੋਲ: ਲੌਗਿਨ ਪੇਜ ਦਾ ਰੀਡਿਜ਼ਾਇਨ ਨਹੀਂ। ਹੁਣ ਤੁਹਾਡਾ ਪ੍ਰੌਂਪਟ ਗਾਰਡਰੇਲਸ ਨਾਲ ਆ ਜਾਂਦਾ ਹੈ ਅਤੇ ਸਮੀਖਿਆ ਆਸਾਨ ਹੋ ਜਾਂਦੀ ਹੈ।\n\nਫੈਸਲਿਆਂ ਦਾ ਇੱਕ ਹਲਕਾ ਚੇਂਜਲਾਗ ਰੱਖੋ। ਹਰ ਫੈਸਲੇ ਲਈ ਇੱਕ ਪੈਰਾ ਕਾਫ਼ੀ ਹੈ। ਕਿਉਂ ਤੁਸੀਂ ਇਕ ਅਪ੍ਰੋਚ ਚੁਣੀ ਅਤੇ ਕਿਉਂ ਵਿਕਲਪਾਂ ਨੂੰ ਰੱਦ ਕੀਤਾ—ਦੋ ਹਫ਼ਤੇ ਬਾਅਦ ਜਦੋਂ ਕੋਈ ਪੁੱਛੇ “ਇਹ ਐਸਾ ਕਿਉਂ ਹੈ?” ਤੁਹਾਡੇ ਕੋਲ ਸਮਝਾਉਣ ਲਈ ਇਕ ਜਵਾਬ ਹੋਵੇਗਾ।\n\n## ਇੱਕ ਪ੍ਰਾਇਕਟਿਕਲ AI-ਸਹਾਇਤ ਵਰਕਫਲੋ ਜੋ ਤੁਸੀਂ ਦੁਹਰਾਵੋ ਸਕਦੇ ਹੋ\n\nAI ਨਾਲ ਸਭ ਤੋਂ ਵੱਡਾ ਬਦਲਾਅ ਇਹ ਹੈ ਕਿ ਕੋਡ ਪੈਦਾ ਕਰਨਾ ਆਸਾਨ ਹੋ ਗਿਆ ਹੈ। ਮੁਸ਼ਕਲ ਹਿੱਸਾ ਇਹ ਹੋ ਗਿਆ ਹੈ ਕਿ ਫੈਸਲਾ ਕਰੋ ਕਿ ਕੋਡ ਕੀ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ ਅਤੇ ਇਹ ਸਾਬਤ ਕਰੋ ਕਿ ਉਹ ਐਸਾ ਕਰਦਾ ਹੈ।\n\nਸ਼ੁਰੂਆਤ ਸਧਾਰਨ ਭਾਸ਼ਾ ਵਿੱਚ ਲਕੜ ਅਤੇ ਪਾਬੰਦੀਆਂ ਲਿਖ ਕੇ ਕਰੋ। ਸ਼ਾਮਿਲ ਕਰੋ ਕਿ ਕੀ ਕਦੀ ਨਾਹ ਹੋਣਾ ਚਾਹੀਦਾ, ਕੀ ਹੌਲੀ ਹੋ ਸਕਦਾ ਹੈ, ਅਤੇ ਕੀ ਬਾਹਰ-ਦਾ-ਖੇਤਰ ਹੈ। ਇੱਕ ਚੰਗੀ ਪਾਬੰਦੀ ਟੈਸਟੇਬਲ ਹੋਣੀ ਚਾਹੀਦੀ ਹੈ: “ਕੋਈ ਯੂਜ਼ਰ ਹੋਰ ਯੂਜ਼ਰ ਦਾ ਡੇਟਾ ਨਾ ਵੇਖੇ” ਜਾਂ “ਟੋਟਲ finance export ਨਾਲ ਸੈਂਟ ਤੱਕ ਮੇਲ ਖਾਂਦੇ ਹੋਣ।”\n\nਕੋਡ ਮੰਗਣ ਤੋਂ ਪਹਿਲਾਂ ਇੱਕ ਸਧਾਰਨ ਡਿਜ਼ਾਇਨ ਅਤੇ ਟਰੇਡ-ਆਫ ਮੰਗੋ। ਤੁਸੀਂ ਚਾਹੁੰਦੇ ਹੋ ਕਿ AI ਆਪਣੀ ਸੋਚ ਇੱਕ ਐਸੇ ਰੂਪ ਵਿੱਚ ਦਰਸਾਵੇ ਜੋ ਤੁਸੀਂ ਮੱਤ-ਜਾਂਚ ਸਕੋ: ਕੀ ਸਟੋਰ ਕਰੇਗਾ, ਕੀ ਵੈਰੀਫਾਈ ਕਰੇਗਾ, ਅਤੇ ਕੀ ਲੌਗ ਕਰੇਗਾ। ਜੇ ਕੁਝ ਚਲਾਕ ਸੁਝਾਉਂਦਾ ਹੈ, ਤੁਰੰਤ ਵਾਪਸ ਧੱਕੋ ਅਤੇ ਉਸ ਦੀ ਬਜਾਏ ਸਭ ਤੋਂ ਸਧਾਰਨ ਵਰਜਨ ਮੰਗੋ ਜੋ ਫਿਰ ਵੀ ਪਾਬੰਦੀਆਂ ਪੂਰੀਆਂ ਕਰੇ।\n\nਦਹਰਾਊ ਲੂਪ ਇਸ ਤਰ੍ਹਾਂ ਲੱਗਦਾ ਹੈ:\n\n1. ਇੱਕ ਛੋਟਾ ਸਮੱਸਿਆ ਬਿਆਨ ਅਤੇ 3-5 ਸਪਸ਼ਟ ਪਾਸ/ਫੇਲ ਐਕਸੈਪਟੈਂਸ ਚੈਕ ਲਿਖੋ।\n2. ਇੱਕ ਨਿਛਲੇ ਯੋਜਨਾ ਮੰਗੋ: ਡੇਟਾ ਮਾਡਲ, ਮੁੱਖ ਫੰਕਸ਼ਨ, ਅਤੇ ਕੀ ਗਲਤ ਹੋ ਸਕਦਾ ਹੈ।\n3. ਇੱਕ ਵਾਰੀ ਵਿੱਚ ਇੱਕ ਛੋਟਾ ਬਦਲਾਅ ਜਨਰੇਟ ਕਰੋ (ਇੱਕ ਐਂਡਪੋਇੰਟ, ਇੱਕ UI ਸਕ੍ਰੀਨ, ਇੱਕ ਮਾਈਗ੍ਰੇਸ਼ਨ), ਨਾ ਕਿ ਪੂਰੇ ਐਪ ਦਾ ਡਮਪ।\n4. ਏਡੀਟਰ ਵਾਂਗ ਰਿਵਿਊ ਕਰੋ: diffs ਪੜ੍ਹੋ, ਟੈਸਟ ਚਲਾਓ, failure ਕੇਸ ਆਜ਼ਮਾਓ, ਫਿਰ ਸੁਧਾਰ ਮੰਗੋ।\n5. ਸੁਰੱਖਿਅਤ ਤਰੀਕੇ ਨਾਲ ਰਿਲੀਜ਼ ਕਰੋ: ਫਲੈਗ ਜਾਂ ਸੀਮਤ ਰੋਲਆਉਟ ਵਰਤੋ, ਲੌਗ ਅਤੇ ਮੈਟ੍ਰਿਕਸ ਵੇਖੋ, ਅਤੇ ਜਲਦੀ ਰੋਲਬੈਕ ਲਈ ਤਿਆਰ ਰਹੋ।\n\nਇੱਥੇ ਇੱਕ ਛੋਟਾ ਸੈਨਾਰਿਓ: ਤੁਸੀਂ order screen 'ਤੇ “refund status” ਜੋੜਦੇ ਹੋ। AI UI ਤੇਜ਼ੀ ਨਾਲ ਜਨਰੇਟ ਕਰ ਸਕਦਾ ਹੈ, ਪਰ ਸਹੀਪਣ ਐੱਜ ਕੇਸਾਂ ਵਿੱਚ ਹੁੰਦਾ ਹੈ। ਜੇ refund.partial ਹੋਵੇ ਤਾਂ ਕੀ ਹੋਵੇ? ਜੇ payment provider webhook ਨੂੰ ਰੀਟ੍ਰਾਈ ਕਰਦਾ ਹੈ ਤਾਂ? ਪਹਿਲਾਂ ਇਹ ਕੇਸ ਲਿਖੋ, ਫਿਰ ਇੱਕ ਸਲਾਇਸ (ਡੇਟਾਬੇਸ ਕਾਲਮ + ਵੈਲਿਡੇਸ਼ਨ) ਇੰਪਲੀਮੈਨਟ ਕਰੋ ਅਤੇ ਟੈਸਟ ਨਾਲ ਵੈਰੀਫਾਈ ਕਰੋ ਫਿਰ ਅੱਗੇ ਵਧੋ।\n\nਜੇ ਤੁਸੀਂ Koder.ai ਵਰਤਦੇ ਹੋ, ਤਾਂ planning mode, snapshots ਅਤੇ rollback ਵਰਗੀਆਂ ਖਾਸੀਅਤਾਂ ਇਸ ਲੂਪ ਨਾਲ ਸੁਭਾਵਿਕ ਤਰੀਕੇ ਨਾਲ ਫ਼ਿੱਟ ਹੁੰਦੀਆਂ ਹਨ: ਪਹਿਲਾਂ ਯੋਜਨਾ ਬਣਾਓ, ਟੁਕੜਿਆਂ ਵਿੱਚ ਜਨਰੇਟ ਕਰੋ, ਅਤੇ ਹਰ ਮਹੱਤਵਪੂਰਨ ਬਦਲਾਅ ਲਈ ਇੱਕ ਸੁਰੱਖਿਅਤ ਰਿ-ਸਟੋਰ ਪਾਇੰਟ ਕੈਪਚਰ ਕਰੋ।\n\n## ਆਮ ਗਲਤੀਆਂ ਜਦੋਂ AI ਨਾਲ ਕੋਡ ਕਰਨਾ ਬਹੁਤ ਆਸਾਨ ਮਹਿਸੂਸ ਹੁੰਦਾ ਹੈ\n\nਜਦੋਂ ਕੋਡ ਜਨਰੇਸ਼ਨ ਤੇਜ਼ ਹੁੰਦਾ ਹੈ, ਤਾਂ ਕੋਡ ਨੂੰ ਕੰਮ ਸਮਝਣ ਦੀ ਲਾਲਚ ਹੁੰਦੀ ਹੈ। ਇਹ ਕੰਮ-ਉਤਪਾਦ ਨਹੀਂ ਹੈ। ਕੰਮ-ਉਤਪਾਦ ਵਿਹਾਰ ਹੈ: ਐਪ ਸਹੀ ਤਰੀਕੇ ਨਾਲ ਕੰਮ ਕਰਦਾ ਹੈ, ਭਾਵੇਂ ਚੀਜ਼ਾਂ ਗਲਤ ਹੋ ਜਾਣ।\n\n### 1) ਪੱਕਾ ਆਉਟਪੁੱਟ ਬਿਨਾਂ ਸਾਬੂਤ ਦੇ ਮੰਨ ਲੈਣਾ\n\nAI ਅਕਸਰ ਪੱਕਾ ਲੱਗਦਾ ਹੈ, ਭਾਵੇਂ ਇਹ ਅੰਦਾਜ਼ਾ ਲਗਾ ਰਿਹਾ ਹੋਵੇ। ਨੁਕਸਾਨ ਇਹ ਹੈ ਕਿ ਬोरਿੰਗ ਹਿੱਸੇ (ਟੈਸਟ ਚਲਾਉਣਾ, ਐੱਜ ਕੇਸ ਚੈੱਕ ਕਰਨਾ, ਅਸਲ ਇਨਪੁੱਟ ਵੈਰੀਫਾਈ ਕਰਨਾ) ਛੱਡ ਦਿੱਤੇ ਜਾਂਦੇ ਹਨ।\n\nਇੱਕ ਸਧਾਰਨ ਆਦਤ ਮਦਦਗਾਰ ਹੈ: ਬਦਲਾਅ ਨੂੰ ਕਬੂਲ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਪੁੱਛੋ “ਅਸੀਂ ਕਿਵੇਂ ਜਾਣਦੇ ਹਾਂ ਕਿ ਇਹ ਸਹੀ ਹੈ?” ਜੇ ਜਵਾਬ “ਇਹ ਠੀਕ ਲੱਗਦਾ ਹੈ” ਹੈ, ਤਾਂ ਤੁਸੀਂ ਜੂਆ ਖੇਡ ਰਹੇ ਹੋ।\n\n### 2) ਟੂਲ ਨੂੰ ਸਕੋਪ ਵਧਾਉਣ ਦੇਣਾ\n\nAI ਵਧੇਰੇ ਚੀਜ਼ਾਂ ਜੋੜਨਾ ਪਸੰਦ ਕਰਦਾ ਹੈ: caching, retries, ਹੋਰ ਸੈਟਿੰਗ, ਹੋਰ ਐਂਡਪੋਇੰਟ, ਇੱਕ ਸੁੰਦਰ UI। ਕੁਝ ਵਧੀਆ ਹੋ ਸਕਦੇ ਹਨ, ਪਰ ਉਹ ਖਤਰਾ ਵਧਾਉਂਦੇ ਹਨ। ਬਹੁਤ ਸਾਰੀਆਂ ਬੱਗਾਂ “ਨਾਈਸ-ਟੂ-ਹੈਵ” ਫੀਚਰਾਂ ਤੋਂ ਆਉਂਦੀਆਂ ਹਨ ਜੋ ਕਿਸੇ ਨੇ ਮੰਗੀਆਂ ਨਹੀਂ।\n\nਹੌਰ-ਪਾਬੰਦੀ ਰੱਖੋ: ਜਿਸ ਸਮੱਸਿਆ ਨੂੰ ਤੁਸੀਂ ਹੱਲ ਕਰਨ ਚਾਹੁੰਦੇ ਹੋ, ਪਹਿਲਾਂ ਉਹ ਖਤਮ ਕਰੋ; ਜੇ ਕੋਈ ਸੁਝਾਅ ਕੀਮਤੀ ਹੈ ਤਾਂ ਉਸਨੂੰ ਇੱਕ ਵੱਖਰੀ ਟਾਸਕ ਵਜੋਂ ਰੱਖੋ ਜਿਸ ਲਈ ਟੈਸਟ ਹੋਣ।\n\n### 3) ਬਹੁਤ ਵੱਡੀਆਂ ਚੇਨਜਾਂ ਮਰਜ ਕਰ ਦੇਣਾ ਜੋ ਰਿਵਿਊ ਨਹੀਂ ਹੋ ਸਕਦੀਆਂ\n\nAI-ਜਨਰੇਟ ਕੀਤੀ ਵੱਡੀ ਕਮੇਟ ਦਜ਼ਦੋ ਕਈ ਅਲੱਗ ਫੈਸਲੇ ਛੁਪਾ ਸਕਦੀ ਹੈ। ਰਿਵਿਊ ਇੱਕ rubber-stamp ਬਣ ਜਾਂਦਾ ਹੈ ਕਿਉਂਕਿ ਕੋਈ ਵੀ ਸਾਰਾ ਸਿਰ ਦਰਦ ਵਿੱਚ ਨਹੀਂ ਰੱਖ ਸਕਦਾ।\n\nਚੈਟ ਆਉਟਪੁੱਟ ਨੂੰ ਡਰਾਫਟ ਮੰਨੋ। ਇਸਨੂੰ ਛੋਟੇ ਬਦਲਾਅ ਵਿੱਚ ਤੋੜੋ ਜੋ ਤੁਸੀਂ ਪੜ੍ਹ ਸਕੋ, ਚਲਾ ਸਕੋ ਅਤੇ ਵਾਪਸ ਲੈ ਸਕੋ। Snapshots ਅਤੇ rollback ਤਦ ਹੀ ਕਾਫ਼ੀ ਹੁੰਦੇ ਹਨ ਜਦੋਂ ਤੁਸੀਂ ਉਨ੍ਹਾਂ ਨੂੰ ਸਮਝਦਾਰ ਬਿੰਦੂ 'ਤੇ ਲੈਂਦੇ ਹੋ।\n\nਕੁਝ ਸੀਮਾਵਾਂ ਰੋਕਣ ਲਈ: ਇੱਕ ਫੀਚਰ ਪ੍ਰ ਚੈਨਜ, ਇੱਕ ਮਾਈਗ੍ਰੇਸ਼ਨ ਪ੍ਰ ਚੈਨਜ, ਇੱਕ ਉੱਚ-ਖਤਰੇ ਖੇਤਰ ਪ੍ਰ ਚਿਰ (auth, payments, data deletion), ਟੈਸਟ ਇਕੱਠੇ ਅਪਡੇਟ, ਅਤੇ ਇੱਕ ਸਪਸ਼ਟ “ਕਿਵੇਂ ਵੇਰਿਫਾਇ” ਨੋਟ।\n\n### 4) ਅਣਪਛਾਤੇ ਲਾਇਸੈਂਸ ਜਾਂ ਸੁਰੱਖਿਆ ਜੋਖਮ ਵਾਲਾ ਕੋਡ ਕਾਪੀ ਕਰਨਾ\n\nAI ਆਪਣੀ ਟ੍ਰੇਨਿੰਗ ਡੇਟਾ ਤੋਂ ਪੈਟਰਨ ਦੁਹਰਾਉ ਸਕਦਾ ਹੈ ਜਾਂ ਅਜਿਹੇ ਡੀਪੈਂਡੈਂਸੀ ਸੁਝਾ ਸਕਦਾ ਹੈ ਜੋ ਤੁਸੀਂ ਨਹੀਂ ਸਮਝਦੇ। ਭਾਵੇਂ ਲਾਇਸੈਂਸ ਠੀਕ ਹੋਵੇ, ਵੱਡੀ ਜੋਖਮ ਸੁਰੱਖਿਆ ਹੈ: हार्ड-ਕੋਡ ਕੀ, ਕਮਜ਼ੋਰ ਟੋਕਨ ਹੈਂਡਲਿੰਗ ਜਾਂ ਅਸੁਰੱਖਿਅਤ ਫਾਇਲ/ਕੁਐਰੀ ਓਪਰੇਸ਼ਨ।\n\nਜੇ ਤੁਸੀਂ ਇਹ ਸਮਝਾ ਨਾ ਸਕਦੇ ਕਿ ਇੱਕ ਸਨਿੱਪੇਟ ਕੀ ਕਰਦਾ ਹੈ ਤਾਂ ਇਸਨੂੰ ਸ਼ਿਪ ਨਾ ਕਰੋ। ਇੱਕ ਸਧਾਰਨ ਵਰਜਨ ਮੰਗੋ ਜਾਂ ਆਪਣੇ ਆਪ ਰੀਰਾਈਟ ਕਰੋ।\n\n### 5) ਮਾਈਗ੍ਰੇਸ਼ਨਾਂ, ਲਿਮਿਟ ਅਤੇ ਫੇਲਯੋਰ ਮੋਡ ਭੁੱਲ ਜਾਣਾ\n\nਕਈ “ਮੈਕ ਠੀਕ ਕੀਤਾ” ਬੱਗ ਦਰਅਸਲ ਡੇਟਾ ਅਤੇ ਸਕੇਲ ਬੱਗ ਹੁੰਦੇ ਹਨ। AI ਸਕੀਮਾ ਬਦਲ ਸਕਦਾ ਹੈ ਬਿਨਾਂ ਮੌਜੂਦਾ ਰਿਕਾਰਡਾਂ, ਵੱਡੀਆਂ ਟੇਬਲਾਂ ਜਾਂ ਡਾਉਨਟਾਈਮ ਬਾਰੇ ਸੋਚੇ।\n\nਹਕੀਕਤੀ ਉਦਾਹਰਣ: ਮਾਡਲ ਇੱਕ ਨਵੀਂ NOT NULL ਕੌਲਮ ਜੋੜ ਦੇਂਦਾ ਹੈ ਅਤੇ ਰੋਂਲਫਿਲਬੈਕ ਇਕ ਸਲੋ ਲੂਪ ਵਿੱਚ ਕਰਦਾ ਹੈ। ਪ੍ਰੋਡਕਸ਼ਨ ਵਿੱਚ ਉਹ ਟੇਬਲ ਲਾਕ ਕਰ ਸਕਦਾ ਹੈ ਅਤੇ ਐਪ ਨੂੰ ਤੋੜ ਦੇ ਸਕਦਾ ਹੈ। ਹਮੇਸ਼ਾ ਸੋਚੋ ਕਿ ਇੱਕ ਮਿਲੀਅਨ ਰਿਕਾਰਡਾਂ, ਸਲੋ ਨੈੱਟਵਰਕ ਜਾਂ ਡਿਪਲੋਅ ਅਧੂਰਾ ਰਹਿ ਜਾਣ 'ਤੇ ਕੀ ਹੋਵੇਗਾ।\n\n## ਉਦਾਹਰਣ: ਇੱਕ ਸਧਾਰਣ ਐਪ ਜਿੱਥੇ ਸਹੀਪਣ ਤੇਜ਼ੀ ਤੋ ਵੱਧ ਗੁੁਰੂਤਵ ਰੱਖਦਾ ਹੈ\n\nਕੱਲੋ ਇੱਕ ਛੋਟੇ ਅੰਦਰੂਨੀ ਬੇਨਤੀ ਟ੍ਰੈਕਰ ਦਾ ਸੋਚੋ: ਲੋਕ ਬੇਨਤੀ ਭੇਜਦੇ ਹਨ, ਮੈਨੇਜਰ ਮਨਜ਼ੂਰ ਜਾਂ ਨਾਇਜ਼ ਕਰਦੇ ਹਨ, ਅਤੇ ਫਾਇਨੈਂਸ ਆਈਟਮ ਨੂੰ ਭੁਗਤਾਨੀ ਦਿੱਸਦਾ ਹੈ। ਇਹ ਸਾਦਾ ਲੱਗਦਾ ਹੈ, ਅਤੇ AI ਸਹਾਇਤਾ ਨਾਲ ਤੁਸੀਂ ਸਕਰੀਨਾਂ ਅਤੇ ਐਂਡਪოਇੰਟ ਤੇਜ਼ੀ ਨਾਲ ਜਨਰੇਟ ਕਰ ਸਕਦੇ ਹੋ। ਜੋ ਚੀਜ਼ ਤੁਹਾਨੂੰ ਧੀਰੇ ਕਰੇਗੀ ਉਹ ਉਹੀ ਪੁਰਾਣਾ ਸੱਚ: ਨਿਯਮ, ਨਾ ਕਿ ਟਾਈਪਿੰਗ।\n\nਸਭ ਤੋਂ ਘੱਟ ਜੋ ਸਹੀ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ, ਉਹ ਸਾਦੇ ਸ਼ਬਦਾਂ ਵਿੱਚ ਲਿਖ ਕੇ ਸ਼ੁਰੂ ਕਰੋ। ਜੇ ਤੁਸੀਂ ਇਸਨੂੰ ਸਪਸ਼ਟ ਨਹੀਂ ਸਮਝਾ ਸਕਦੇ ਤਾਂ ਤੁਸੀਂ ਟੈਸਟ ਨਹੀਂ ਕਰ ਸਕਦੇ।\n\nਇੱਕ ਤੰਗ ਫਰਸਟ-ਵਰਜ਼ਨ ਪਰਿਭਾਸ਼ਾ ਆਮ ਤੌਰ 'ਤੇ ਇਸ ਤਰ੍ਹਾਂ ਲੱਗਦੀ ਹੈ: ਫੀਲਡ (title, requester, department, amount, reason, status, timestamps); ਭੂਮਿਕਾਵਾਂ (requester, approver, finance, admin); ਸਟੇਟਸ (draft, submitted, approved, rejected, paid). ਫਿਰ ਉਹ ਟ੍ਰਾਂਜ਼ੀਸ਼ਨ ਦਰਜ ਕਰੋ ਜੋ ਮਹੱਤਵਪੂਰਨ ਹਨ: ਸਿਰਫ਼ approver ਹੀ submitted ਨੂੰ approved ਜਾਂ rejected 'ਚ ਬਦਲ ਸਕਦਾ; ਸਿਰਫ਼ finance ਹੀ approved ਨੂੰ paid ਕਰ ਸਕਦਾ।\n\nAI ਨੂੰ ਨਿਯੰਤਰਿਤ ਕਰਮਕ੍ਰਮ ਵਿੱਚ ਵਰਤੋਂ ਤਾਂ ਜੋ ਤੁਸੀਂ ਗਲਤੀਆਂ ਜਲਦੀ ਫੜ ਸਕੋ:\n\n1) ਪਹਿਲਾਂ ਡੇਟਾਬੇਸ ਸਕੀਮਾ ਅਤੇ ਸਟੇਟ ਐਨਮ ਪਰਿਭਾਸ਼ਿਤ ਕਰੋ।\n2) ਟ੍ਰਾਂਜ਼ੀਸ਼ਨ-ਕੇਂਦਰਤ ਐਂਡਪੋਇੰਟ ਜਨਰੇਟ ਕਰੋ (submit, approve, reject, pay), ਨਾ ਕਿ generic update-anything ਰੂਟ।\n3) UI ਆਖਿਰ ਵਿੱਚ ਜਨਰੇਟ ਕਰੋ, API ਦੀਆਂ ਅਨੁਮਤੀਆਂ ਦੇ ਅਧਾਰ 'ਤੇ।\n\nਸਭ ਤੋਂ ਕੀਮਤੀ ਟੈਸਟ “ਪੇਜ਼ ਲੋਡ ਹੁੰਦਾ ਹੈ” ਨਹੀਂ ਹੁੰਦੇ। ਉਹ ਪਰਮਿਸ਼ਨ ਚੈਕ ਅਤੇ ਸਟੇਟ ਟ੍ਰਾਂਜ਼ੀਸ਼ਨ ਹੁੰਦੇ ਹਨ। ਉਦਾਹਰਣ ਲਈ: ਸਾਬਤ ਕਰੋ ਕਿ requester ਆਪਣੀ ਹੀ ਬੇਨਤੀ ਨੂੰ approve ਨਹੀਂ ਕਰ ਸਕਦਾ, approver paid ਨਹੀਂ ਕਰ ਸਕਦਾ, rejected ਨੂੰ paid ਨਹੀਂ ਕੀਤਾ ਜਾ ਸਕਦਾ, ਅਤੇ (ਜੇ ਤੁਹਾਡਾ ਨਿਯਮ ਹੈ) submission ਤੋਂ ਬਾਅਦ amounts ਸੋਧੇ ਨਹੀਂ ਜਾ ਸਕਦੇ।\n\nਜੋ ਸਭ ਤੋਂ ਜ਼ਿਆਦਾ ਸਮਾਂ ਲੈਂਦਾ ਹੈ ਉਹ ਐੱਜ ਕੇਸ ਦੀ ਸਪਸ਼ਟੀਕਰਨ ਹੁੰਦਾ ਹੈ। ਕੀ approver ਆਪਣੇ ਫੈਸਲੇ ਬਦਲ ਸਕਦਾ ਹੈ rejection ਤੋਂ ਬਾਅਦ? ਜੇ ਦੋ approvers ਇੱਕਸਮੇਂ approve 'ਤੇ ਕਲਿਕ ਕਰਦੇ ਹਨ ਤਾਂ ਕੀ ਹੋਵੇਗਾ? ਜੇ finance ਨੇ ਹਿੱਸੇਵਾਰ ਭੁਗਤਾਨ ਕਰਨਾ ਹੋਵੇ ਤਾਂ? AI ਕਿਸੇ ਵੀ ਜਵਾਬ ਲਈ ਕੋਡ ਜਨਰੇਟ ਕਰ ਸਕਦਾ ਹੈ, ਪਰ ਉਹ ਤੁਹਾਡੇ ਲਈ ਜਵਾਬ ਨਹੀਂ ਚੁਣੇਗਾ। ਸਹੀਪਣ ਇਹਨਾਂ ਫੈਸਲਿਆਂ ਨੂੰ ਲੈ ਕੇ ਆਉਂਦਾ ਹੈ, ਫਿਰ ਕੋਡ ਨੂੰ ਉਹਨਾਂ 'ਤੇ ਅਮਲ ਕਰਵਾਉਂਦਾ ਹੈ।\n\n## AI-ਜਨਰੇਟ ਕੀਤੇ ਬਦਲਾਅ ਸ਼ਿਪ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਤੇਜ਼ ਚੈੱਕਲਿਸਟ\n\nAI ਬਹੁਤ ਕੋਡ ਤੇਜ਼ੀ ਨਾਲ ਤੇਅਰ ਕਰ ਸਕਦਾ ਹੈ, ਪਰ ਆਖਰੀ ਮੀਲ ਹਾਲੇ ਵੀ ਮਨੁੱਖੀ ਕੰਮ ਹੈ: ਇਹ ਸਾਬਤ ਕਰਨਾ ਕਿ ਇਹ ਉਹੀ ਕਰ ਰਿਹਾ ਜੋ ਤੁਸੀਂ ਚਾਹੁੰਦੇ ਸੀ, ਅਤੇ ਜਦੋਂ ਇਸਨੇ ਗਲਤੀ ਕੀਤੀ ਤਾਂ ਸੁਰੱਖਿਅਤ ਤਰੀਕੇ ਨਾਲ ਫੇਲ ਹੋਵੇ।\n\nਸ਼ੁਰੂ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਸਭ ਤੋਂ ਛੋਟਾ “ਡਨ” ਪਰਿਭਾਸ਼ਾ ਚੁਣੋ ਜੋ ਮਾਇਨੇ ਰੱਖਦੀ ਹੈ। ਇੱਕ ਛੋਟੀ ਫੀਚਰ ਲਈ ਇਹ ਇੱਕ ਹੈਪੀ ਪਾਥ, ਦੋ ਫੇਲ ਪਾਥ, ਅਤੇ ਇੱਕ ਤੇਜ਼ readability pass ਹੋ ਸਕਦਾ ਹੈ। ਭੁਗਤਾਨ ਜਾਂ auth ਲਈ ਮਿਆਰ ਨੂੰ ਉੱਚਾ ਰੱਖੋ।\n\n### ਪੰਜ ਚੈੱਕ\n\n- ਹਰ ਲੋੜ ਨੂੰ ਵੇਰਿਫਾਇ ਬਹੁਯੋਗ ਬਣਾਇਆ ਗਿਆ ਹੈ। ਹਰ ਲੋੜ ਲਈ ਤੁਹਾਡੇ ਕੋਲ ਜਾਂ ਤਾਂ ਇੱਕ ਟੈਸਟ ਹੈ ਜਾਂ ਇੱਕ ਸਪਸ਼ਟ ਮੈਨੂਅਲ ਚੈੱਕ ਇੱਕ ਵਾਕ ਵਿੱਚ। ਜੇ ਤੁਸੀਂ ਇਹ ਸਮਝਾ ਨਹੀਂ ਸਕਦੇ ਕਿ ਕਿਸੇ ਚੀਜ਼ ਦੀ ਪੁਸ਼ਟੀ ਕਿਵੇਂ ਕਰਨੀ ਹੈ, ਤਦ ਤੁਹਾਨੂੰ ਅਹੁਂ ਨਹੀਂ ਸਮਝ ਆਇਆ।\n- ਫੇਲਯਾਰ ਹੈਂਡਲ ਕੀਤਾ ਅਤੇ ਸਮਝਾਇਆ ਗਿਆ। ਸਭ ਤੋਂ ਉੱਚੇ ਐਰਰ ਕੇਸ (ਖ਼ਰਾਬ ਇਨਪੁੱਟ, ਗੈਰ-ਹਾਜ਼ਰ ਪਰਮਿਸ਼ਨ, ਨੈੱਟਵਰਕ ਫੇਲ, ਖਾਲੀ ਡੇਟਾਬੇਸ) ਆਜ਼ਮਾਓ। ਐਪ ਯੂਜ਼ਫੁਲ ਸੁਨੇਹਾ ਦਿਖਾਵੇ ਅਤੇ ਸੰਵੇਦਨਸ਼ੀਲ ਵੇਰਵਾ ਲੀਕ ਨਾ ਹੋਵੇ।\n- ਡਿਜ਼ਾਇਨ ਸਧਾਰਨ ਰਿਹਾ। ਜੇ AI ਨੇ ਹੈਲਪਰ, ਅਬਸਟ੍ਰੈਕਸ਼ਨ ਜਾਂ ਚਲਾਕ ਪੈਟਰਨ ਜੋੜੇ ਹਨ, ਤਾਂ ਪੁੱਛੋ: ਜੇ ਤੁਸੀਂ ਇਹ ਹੱਥੋਂ ਲਿਖਦੇ, ਕੀ ਤੁਸੀਂ ਇਹ ਰੱਖਦੇ? ਜੇ ਨਹੀਂ, ਵਾਧੂ ਤਹਾਂ ਹਟਾਓ।\n- ਇਕ ਨਵਾਂ ਰਿਵਿਊਵਰ ਇਸਨੂੰ ਫੋਲੋ ਕਰ ਸਕੇ। ਸੋਚੋ ਕਿ ਰਿਵਿਊਵਰ ਨੇ ਚੈਟ ਸੈਸ਼ਨ ਨਹੀਂ ਵੇਖਿਆ। ਕੋਡ ਇੱਕ ਕਹਾਣੀ ਵਾਂਗ ਪੜ੍ਹਨਾ ਚਾਹੀਦਾ ਹੈ: ਸਪਸ਼ਟ ਨਾਂ, ਛੋਟੇ ਫੰਕਸ਼ਨ, ਅਤੇ ਇੱਕ ਛੋਟਾ ਨੋਟ ਕਿ ਇਹ ਬਦਲਾਅ ਕਿਉਂ ਕਰਿਆ।\n- ਤੁਸੀਂ ਇਸਨੂੰ ਸੁਰੱਖਿਅਤ ਤਰੀਕੇ ਨਾਲ ਵਾਪਸ ਲੈ ਸਕਦੇ ਹੋ। “ਨਾਰਮਲ” 'ਤੇ ਵਾਪਸੀ ਕਿਵੇਂ ਲੱਗਦੀ ਹੈ ਇਹ ਜਾਣੋ। ਇੱਕ ਜਾਣੀ-ਪਛਾਣੀ ਅਚਛੀ ਵਰਜਨ ਕੈਪਚਰ ਕਰੋ ਅਤੇ ਪੱਕਾ ਕਰੋ ਕਿ ਜੇ ਪ੍ਰੋਡਕਸ਼ਨ ਅਲੱਗ ਵਰਤਰੇ ਤਾਂ ਤੁਹਾਡਾ ਰੋਲਬੈਕ ਤੇਜ਼ ਹੈ।\n\n### ਛੋਟਾ ਉਦਾਹਰਣ\n\nਮਾਨ ਲਓ AI ਇੱਕ ਐਡਮਿਨ ਸਕ੍ਰੀਨ 'ਤੇ “bulk invite users” ਜੋੜਦਾ ਹੈ। ਹੈਪੀ ਪਾਥ ਕੰਮ ਕਰਦਾ ਹੈ, ਪਰ ਅਸਲ ਜੋਖਮ ਐੱਜ ਕੇਸਾਂ ਵਿੱਚ ਹਨ: ਡੁਪਲੀਕੇਟ ਈਮੇਲ, ਅੰਸ਼ਿਕ ਫੇਲਯਾਰ, ਅਤੇ ਰੇਟ ਲਿਮਿਟ। ਇੱਕ ਮਜ਼ਬੂਤ ਸ਼ਿਪ ਫੈਸਲਾ ਹੋ ਸਕਦਾ ਹੈ: duplicates ਲਈ ਇੱਕ ਆਟੋਮੈਟਿਕ ਟੈਸਟ, partial-failure messaging ਲਈ ਇੱਕ ਮੈਨੂਅਲ ਚੈੱਕ, ਅਤੇ ਰੋਲਬੈਕ ਯੋਜਨਾ।\n\n## ਅਗਲੇ ਕਦਮ: ਗਾਰਡਰੇਲ ਜੋੜੋ, ਫਿਰ ਆਪਣੀ ਪ੍ਰਕਿਰਿਆ ਨੂੰ ਸਕੇਲ ਕਰੋ\n\nਜਦੋਂ ਕੋਡ ਸਸਤਾ ਹੋ ਜਾਂਦਾ ਹੈ, ਤਾਂ ਜੋਖਮ ਫੈਸਲੇ ਦੀ ਗੁਣਵੱਤਾ ਤੇ ਵੱਧਦਾ ਹੈ: ਤੁਸੀਂ ਕੀ ਮੰਗਿਆ, ਤੁਸੀਂ ਕੀ ਸਵੀਕਾਰ ਕੀਤਾ, ਅਤੇ ਤੁਸੀਂ ਕੀ ਸ਼ਿਪ ਕੀਤਾ। ਇਹ ਸਿਧਾਂਤ AI-ਸਹਾਇਤ ਕੰਮ ਵਿੱਚ ਲਾਗੂ ਕਰਨ ਦਾ ਸਭ ਤੋਂ ਤੇਜ਼ ਤਰੀਕਾ ਇਹ ਹੈ ਕਿ ਉਹ ਗਾਰਡਰੇਲ ਜੋੜੋ ਜੋ “ਲਗਭਗ ਠੀਕ” ਬਦਲਾਅਾਂ ਨੂੰ ਸਲਿੱਪ ਹੋਣ ਤੋਂ ਰੋਕਣ।\n\nਅਗਲੇ ਫੀਚਰ ਲਈ ਇੱਕ ਸਫ਼ਾ ਸਪੈੱਕ ਨਾਲ ਸ਼ੁਰੂ ਕਰੋ। ਸਧਾਰਨ ਰੱਖੋ: ਕਿਸ ਲਈ ਹੈ, ਕੀ ਕਰਨਾ ਹੈ, ਕੀ ਨਹੀਂ ਕਰਨਾ ਅਤੇ ਦੋ-ਤਿੰਨ ਐਕਸੈਪਟੈਂਸ ਟੈਸਟਾਂ ਦੀ ਭਾਸ਼ਾ। ਇਹ ਐਕਸੈਪਟੈਂਸ ਟੈਸਟ AI ਦੇ ਕਿਸੇ ਲੁਭਾਵਨੇ ਸੁਝਾਅ ਦੇ ਸਮੇਂ ਤੁਹਾਡਾ ਲੰਗਰ ਬਣ ਜਾਂਦੇ ਹਨ।\n\nਇੱਕ ਗਾਰਡਰੇਲ ਸੈੱਟ ਜੋ ਬਿਨਾਂ ਵੱਧ ਪ੍ਰਕਿਰਿਆ ਓਵਹਹੈਡ ਦੇ ਸਕੇ:\n\n- ਬਦਲਾਅ ਛੋਟੇ ਰੱਖੋ ਤਾਂ ਜੋ ਮਿੰਟਾਂ ਵਿੱਚ ਸਮੀਖਿਆ ਕੀਤੀ ਜਾ ਸਕੇ, ਘੰਟਿਆਂ ਵਿੱਚ ਨਹੀਂ।\n- ਹਰ ਵਿਹਾਰ ਬਦਲਾਅ ਲਈ ਟੈਸਟ (ਯਾ ਘੱਟੋ ਘੱਟ ਟੈਸਟ ਨੋਟ) ਲਾਜ਼ਮੀ ਕਰੋ।\n- ਇੱਕ ਸਟੈਂਡਰਡ ਪ੍ਰੌਂਪਟ ਟੈਂਪਲੇਟ ਵਰਤੋ: ਪਾਬੰਦੀਆਂ, ਕੋਡਿੰਗ ਸਟਾਈਲ, ਅਤੇ ਟੈਸਟ ਉਮੀਦਾਂ।\n- ਹਰ ਡਿਪਲੋਏ ਲਈ ਇੱਕ ਭਰੋਸੇਯੋਗ ਰੋਲਬੈਕ ਰਾਹ ਰੱਖੋ।\n- ਅਣਪਛਾਤੀਆਂ ਨੂੰ ਖੁਦ-ਕਥਿਤ TODOs ਵਜੋਂ ਟ੍ਰੈਕ ਕਰੋ, ਛੁਪੀ ਹੋਈ ਧਾਰਨਾਵਾਂ ਵਜੋਂ ਨਹੀਂ।\n\nਹੁਣ ਪ੍ਰੌਂਪਟ ਤੁਹਾਡੀ ਪ੍ਰਕਿਰਿਆ ਦਾ ਹਿੱਸਾ ਹਨ। ਇਕ ਹਾਊਸ ਸਟਾਈਲ ਤੇ ਸਹਿਮਤ ਹੋਵੋ: ਕਿਹੜੀਆਂ ਲਾਇਬਰੇਰੀਆਂ ਆਗਿਆਤ ਹਨ, ਐਰਰ ਕਿਵੇਂ ਹੈਂਡਲ ਹੋਣ, “ਡਨ” ਦਾ ਕੀ ਮਤਲਬ, ਅਤੇ ਕਿਹੜੇ ਟੈਸਟ ਗੁਜ਼ਰਣੇ ਲਾਜ਼ਮੀ ਹਨ। ਜੇ ਇੱਕ ਪ੍ਰੌਂਪਟ ਦੂਜੇ ਟੀਮਮੇਟ ਵੱਲੋਂ ਦੁਬਾਰਾ ਵਰਤਿਆ ਨਹੀਂ ਜਾ ਸਕਦਾ ਤਾਂ ਉਹ ਸ਼ਾਇਦ ਬਹੁਤ vague ਹੈ।\n\nਜੇ ਤੁਸੀਂ ਚੈਟ-ਪਹਿਲਾਂ ਤਰੀਕੇ ਨਾਲ ਵੈੱਬ, ਬੈਕਐਂਡ ਅਤੇ ਮੋਬਾਈਲ ਐਪ ਬਣਾਉਣਾ ਪਸੰਦ ਕਰਦੇ ਹੋ ਤਾਂ Koder.ai (koder.ai) ਇੱਕ ਉਦਾਹਰਣ ਹੈ ਜਿੱਥੇ planning mode, snapshots ਅਤੇ source code export ਇਹ ਗਾਰਡਰੇਲਸ ਨੂੰ ਸਹਾਇਤ ਕਰ ਸਕਦੇ ਹਨ। ਇਹ ਟੂਲ ਡਰਾਫਟ ਤੇਜ਼ ਕਰ ਸਕਦਾ ਹੈ, ਪਰ ਅਨੁਸ਼ਾਸਨ ਹੀ ਮਨੁੱਖਾਂ ਨੂੰ ਸਹੀਪਣ 'ਤੇ ਕਾਬੂ ਰੱਖਦਾ ਹੈ।
