ਸਿੱਖੋ ਕਿ vibe coding ਕਿਵੇਂ ਕੋਡ ਨੂੰ ਸਖ਼ਤ ਨਿਰਦੇਸ਼ਾਂ ਤੋਂ ਗੱਲਬਾਤ ਵਿੱਚ ਬਦਲਦਾ ਹੈ—ਭੂਮਿਕਾਵਾਂ, ਵਰਕਫਲੋ, ਗੁਣਵੱਤਾ ਚੈੱਕਸ ਵਿੱਚ ਕੀ ਬਦਲਦਾ ਹੈ, ਤੇ ਨਿਯੰਤਰਣ ਰੱਖਣ ਦੇ ਕਾਰਗਰ ਢੰਗ।

"Vibe coding" ਇੱਕ ਸਧਾਰਣ ਵਿਚਾਰ ਹੈ: ਹਰ ਲਾਈਨ ਆਪਣਾ ਖੁਦ ਨਾ ਲਿਖ ਕੇ, ਤੁਸੀਂ ਇੱਕ ਚਲਦੇ-ਫਿਰਦੇ ਗੰਭੀਰ ਗੱਲਬਾਤ ਰਾਹੀਂ ਸੌਫਟਵੇਅਰ ਬਣਾਉਂਦੇ ਹੋ—AI ਕੋਡ ਸੁਝਾਅ ਦਿੰਦਾ ਹੈ, ਟਰੇਡ-ਆਫਸ ਦੱਸਦਾ ਹੈ, ਅਤੇ ਤੁਹਾਡੇ ਨਾਲ ਦੁਹਰਾਉਂਦਾ ਹੈ।
ਤੁਸੀਂ ਇਰਾਦੇ ਨਾਲ ਨਿਰਦੇਸ਼ ਦਿੰਦੇ ਹੋ ("ਇਸ ਪੰਨੇ ਨੂੰ ਤੇਜ਼ ਕਰੋ", "ਸਾਈਨ-ਇਨ ਜੋੜੋ", "ਇਸ API ਆਕਾਰ ਨਾਲ ਮੇਲ ਖਾਓ"), ਅਤੇ AI ਸੰਚਾਲਨ ਯੋਗ ਬਦਲਾਅ ਦਿੱਦਾ ਹੈ ਜੋ ਤੁਸੀਂ ਚਲਾ ਸਕਦੇ, ਪਰਖ ਸਕਦੇ ਅਤੇ ਸੋਧ ਸਕਦੇ ਹੋ।
ਰਵਾਇਤੀ ਵਰਕਫਲੋ ਅਕਸਰ ਇਹੇ ਜਾਂਦੇ ਹਨ: ਡੀਟੇਲਡ ਸਪੈਕ ਲਿਖੋ → ਟਾਸਕ ਵਿੱਚ ਵੰਡੋ → ਇੰਪਲੀਮੈਂਟ ਕਰੋ → ਟੈਸਟ ਕਰੋ → ਸੋਧੋ। ਇਹ ਠੀਕ ਹੈ, ਪਰ ਇਹ ਧਾਰਨਾ ਰੱਖਦਾ ਹੈ ਕਿ ਤੁਸੀਂ ਪਹਿਲਾਂ ਹੀ ਠੀਕ ਡਿਜ਼ਾਈਨ ਦਾ ਅਨੁਮਾਨ ਲਾ ਸਕਦੇ ਹੋ ਅਤੇ ਕਿ ਕੋਡ ਲਿਖਣਾ ਮੁੱਖ ਰੁਕਾਵਟ ਹੈ।
Vibe coding ਜ਼ੋੜ ਸਥਿਤੀ ਨੂੰ ਬਦਲਦਾ ਹੈ: ਲਕੜੀ ਦਰਸਾਓ → ਇੱਕ ਡਰਾਫਟ ਲਵੋ → ਜੋ ਤੁਸੀਂ ਵੇਖਦੇ ਹੋ ਉਸ 'ਤੇ ਪ੍ਰਤੀਕਿਰਿਆ ਦਿਓ → ਛੋਟੇ ਕਦਮਾਂ ਵਿੱਚ ਸੁਧਾਰ ਕਰੋ। "ਸਪੈਕ" ਕੋਈ ਵੱਡਾ ਦਸਤਾਵੇਜ਼ ਨਹੀਂ—ਇਹ ਇੱਕ ਵਿਕਸਤ ਹੁੰਦਾ ਗੱਲਬਾਤ ਹੈ ਜੋ ਕੰਮ ਕਰ ਰਹੇ ਨਤੀਜੇ ਨਾਲ ਜੋੜਿਆ ਰਹਿੰਦਾ ਹੈ।
ਤਿੰਨ ਤਾਕਤਾਂ ਇਸ ਬਦਲਾਅ ਨੂੰ ਭੜਕਾ ਰਹੀਆਂ ਹਨ:
Vibe coding ਵਧੀਆ ਕੰਮ ਕਰਦਾ ਹੈ ਜਦੋਂ ਤੁਸੀਂ ਖੋਜ ਕਰ ਰਹੇ ਹੋ, ਪ੍ਰੋਟੋਟਾਈਪ ਬਣਾ ਰਹੇ ਹੋ, ਆਮ ਪੈਟਰਨ ਇਕੱਠੇ ਕਰ ਰਹੇ ਹੋ ਜਾਂ ਛੋਟੇ ਮਾਈਕ੍ਰੋ-ਇਟਰੈਸ਼ਨ ਰਾਹੀਂ ਫੀਚਰ ਪਾਲਿਸ਼ ਕਰ ਰਹੇ ਹੋ। ਇਹ ਗਲਤ ਸਮਝਾ ਸਕਦਾ ਹੈ ਜਦੋਂ ਤੁਸੀਂ AI ਦੀ ਆਉਟਪੁੱਟ ਨੂੰ "ਮੂਲ ਤੌਰ ਤੇ ਸਹੀ" ਮੰਨ ਲੈਂਦੇ ਹੋ—ਖਾਸ ਕਰਕੇ ਸੁਰੱਖਿਆ, ਪ੍ਰਦਰਸ਼ਨ ਅਤੇ ਨਾਜੁਕ ਬਿਜ਼ਨਸ ਨਿਯਮਾਂ ਬਾਰੇ।
ਉਪਯੋਗੀ ਮਨੋਭਾਵ ਇਹ ਹੈ: AI ਤੇਜ਼ ਸਹਿਯੋਗੀ ਹੈ, ਅਧਿਕਾਰ ਨਹੀਂ। ਤੁਸੀਂ ਅਜੇ ਵੀ ਸਪਸ਼ਟਤਾ, ਪਾਬੰਦੀਆਂ ਅਤੇ "ਡਨ" ਦੇ ਮਾਇਨੇ ਫੈਸਲਿਆਂ ਲਈ ਜ਼ਿੰਮੇਵਾਰ ਹੋ।
ਰਵਾਇਤੀ ਸਪੈਕ ਇਸ ਦਾ ਉਦੇਸ਼ ਹੁੰਦੇ ਹਨ ਕਿ ਸਮੱਸਿਆ ਵਿੱਚੋਂ ਅਸਪਸ਼ਟੀ ਹਟਾ ਕੇ ਲੋਕਾਂ ਨੇ ਕੋਡ ਲਿਖਣ ਤੋਂ ਪਹਿਲਾਂ ਫੈਸਲੇ ਜਮ੍ਹਾਂ ਕਰ ਲਏ। ਉਹ ਫੈਸਲੇ ਪਹਿਲਾਂ ਫ੍ਰੀਜ਼ ਕਰਨ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰਦੇ ਹਨ: ਅਚੋਕ ਫੀਲਡ, ਅਚੋਕ ਸਟੇਟ, ਅਚੋਕ ਐਜ-ਕੇਸ। ਇਹ ਲਾਭਦਾਇਕ ਹੋ ਸਕਦਾ ਹੈ—ਪਰ ਇਹ ਵੀ ਮੰਨਦਾ ਹੈ ਕਿ ਤੁਸੀਂ ਪਹਿਲਾਂ ਹੀ ਜਾਣਦੇ ਹੋ ਕਿ ਤੁਸੀਂ ਕੀ ਚਾਹੁੰਦੇ ਹੋ।
Vibe coding ਕ੍ਰਮ ਨੂੰ ਉਲਟ ਦਿੰਦਾ ਹੈ। ਅਣਿਸ਼ਚਿਤਤਾ ਨੂੰ ਇੱਕ ਤਰ੍ਹਾਂ ਦੀ ਚੀਜ਼ ਮੰਨੋ ਜੋ ਖੋਜ ਲਈ ਮਾਦਾ ਹੈ। ਤੁਸੀਂ ਇਰਾਦੇ ਨਾਲ ਸ਼ੁਰੂ ਕਰੋ ਅਤੇ ਗੱਲਬਾਤ ਉਹ ਹਿੱਸੇ ਉਜਾਗਰ ਕਰਦੀ ਹੈ ਜੋ ਘੱਟ ਪੂਰੇ ਸਨ: ਪਾਬੰਦੀਆਂ, ਟਰੇਡ-ਆਫਸ ਅਤੇ "ਅਰੇ, ਇਹ ਤਾਂ ਸਾਡੇ ਮਨ ਵਿੱਚ ਨਹੀਂ ਸੀ" ਵਾਲੇ ਪਲ।
ਇੱਕ ਸਪੈਕ ਕਹਿੰਦਾ ਹੈ: "ਇਹ ਸਿਸਟਮ ਹੈ." ਇੱਕ ਗੱਲਬਾਤ ਪੁੱਛਦੀ ਹੈ: "ਜਦੋਂ ਇਹ ਹੋਵੇ ਤਾਂ ਸਿਸਟਮ ਕੀ ਕਰੇਗਾ?" ਇਹ ਪ੍ਰਸ਼ਨ-ਪਹਿਲਾ ਰਵੀਆ ਉਹ ਜ਼ਰੂਰਤਾਂ ਖੋਲ੍ਹਣਾ ਅਸਾਨ ਬਣਾ ਦਿੰਦਾ ਹੈ ਜੋ ਦਸਤਾਵੇਜ਼ ਵਿੱਚ ਕਦੇ ਨਜ਼ਰ ਨਹੀਂ ਆਉਂਦੀਆਂ—ਜਿਵੇਂ ਕਿੰਨੀ ਕਠੋਰ ਵੈਧਤਾ ਹੋਣੀ ਚਾਹੀਦੀ ਹੈ, ਐਰਰ ਸੁਨੇਹੇ ਕੀ ਕਹਿਣ, ਜਾਂ ਜਦੋਂ ਇੱਕ ਈਮੇਲ ਪਹਿਲਾਂ ਹੀ ਲੈਂ ਲਿਆ ਗਿਆ ਹੋਵੇ ਤਾਂ ਕੀ ਕਰੀਏ।
ਜਦੋਂ AI ਕੁਝ ਮਿੰਟਾਂ ਵਿੱਚ ਇੱਕ ਇੰਪਲੀਮੈਂਟੇਸ਼ਨ ਡਰਾਫਟ ਕਰ ਸਕਦਾ ਹੈ, ਪਹਿਲੀ ਕੋਸ਼ਿਸ਼ ਦਾ ਮਕਸਦ ਬਦਲ ਜਾਂਦਾ ਹੈ। ਤੁਸੀਂ ਕਿਸੇ ਨਿਰਣಾಯಕ ਰੂਪ-ਰੇਖਾ ਤਿਆਰ ਕਰਨ ਦੀ ਕੋਸ਼ਿਸ਼ ਨਹੀਂ ਕਰ ਰਹੇ—ਤੁਸੀਂ ਕੋਈ ਟੈਸਟ ਕੀਤੇ ਜਾ ਸਕਣ ਵਾਲਾ ਟੁਕੜਾ ਬਣਾਉਣ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰ ਰਹੇ ਹੋ: ਇੱਕ ਪਤਲਾ ਸਲਾਈਸ ਜੋ ਤੁਸੀਂ ਕਲਿੱਕ, ਚਲਾ ਜਾਂ ਸਿਮੁਲੇਟ ਕਰ ਸਕੋ। ਉਸ ਪ੍ਰੋਟੋਟਾਈਪ ਤੋਂ ਮਿਲੀ ਪ੍ਰਤਿਕਿਰਿਆ ਅਸਲ ਲੋੜਾਂ ਬਣ ਜਾਂਦੀ ਹੈ।
ਪ੍ਰਗਤੀ ਹੁਣ "ਸਾਡੇ ਨੇ ਸਪੈਕ ਖਤਮ ਕਰ ਲਿਆ" ਨਹੀਂ ਰਹਿ ਗਈ। ਇਹ ਹੋ ਗਿਆ: "ਅਸੀਂ ਇਸਨੂੰ ਚਲਾਇਆ, ਵਰਤਾਰਾ ਵੇਖਿਆ, ਅਤੇ ਸੋਧ ਕੀਤੀ।" ਗੱਲਬਾਤ ਕੋਡ ਪੈਦਾ ਕਰਦੀ ਹੈ, ਕੋਡ ਸਬੂਤ ਪੈਦਾ ਕਰਦਾ ਹੈ, ਅਤੇ ਸਬੂਤ ਅਗਲੇ ਪ੍ਰਾਂਪਟ ਨੂੰ ਰਾਹ ਦਿਖਾਉਂਦਾ ਹੈ।
ਪੂਰੇ PRD ਲਿਖਣ ਦੀ ਥਾਂ ਤੁਸੀਂ ਪੁੱਛ ਸਕਦੇ ਹੋ:
ਇਹ ਇੱਕ ਅਸਪਸ਼ਟ ਇੱਛਾ ਨੂੰ ठੋਸ ਕਦਮਾਂ ਵਿੱਚ ਬਦਲ ਦਿੰਦਾ ਹੈ—ਬਿਨਾਂ ਇਹ ਦਾਅਵਾ ਕੀਤੇ ਕਿ ਤੁਸੀਂ ਪਹਿਲਾਂ ਹੀ ਹਰ ਵੇਰਵਾ ਜਾਣਦੇ ਸੀ। ਨਤੀਜਾ ਘੱਟ ਪਹਿਲੂ ਵਰਕਪੇਪਰ ਅਤੇ ਜ਼ਿਆਦਾ ਕਾਰਜ-ਦ্বਾਰਾ-ਸਿੱਖਣਾ ਹੁੰਦਾ ਹੈ, ਜਿਸ 'ਤੇ ਮਨੁੱਖ ਹਰ ਇਟਰੈਸ਼ਨ 'ਤੇ ਕਮਾਂ ਕਰਦਾ ਹੈ।
Vibe coding "ਡਿਵੈਲਪਰ" ਨੂੰ ਬਦਲਦਾ ਨਹੀਂ—ਪਰ ਇਹ ਕੰਮ ਨੂੰ ਇਸ ਤਰ੍ਹਾਂ ਮਹਿਸੂਸ ਕਰਵਾਉਂਦਾ ਹੈ ਜਿਵੇਂ ਤੁਸੀਂ ਵੱਖ-ਵੱਖ ਟੋਪੀਆਂ ਪਹਿਨਦੇ ਹੋ। ਇਹਨਾਂ ਭੂਮਿਕਾਵਾਂ ਨੂੰ ਨਾਮ ਦਿੱਤਾ ਜਾਣਾ ਟੀਮਾਂ ਨੂੰ ਇਹ ਨਿਰਧਾਰਤ ਕਰਨ ਵਿੱਚ ਮਦਦ ਕਰਦਾ ਹੈ ਕਿ ਕੌਣ ਕੀ ਫੈਸਲਾ ਕਰਦਾ ਹੈ, ਅਤੇ AI ਨੂੰ ਚੁੱਪਚਾਪ ਫੈਸਲਾ ਕਰਨ ਵਾਲਾ ਬਣਨ ਤੋਂ ਰੋਕਦਾ ਹੈ।
Director ਇਹ ਨਿਰਧਾਰਤ ਕਰਦਾ ਹੈ ਕਿ ਤੁਸੀਂ ਕੀ ਬਣਾ ਰਹੇ ਹੋ ਅਤੇ "ਚੰਗਾ" ਕੀ ਮੰਨਿਆ ਜਾਵੇਗਾ। ਇਹ ਸਿਰਫ ਫੀਚਰ ਨਹੀਂ—ਇਹ ਸੀਮਾਵਾਂ ਅਤੇ ਪਸੰਦਾਂ ਵੀ ਹਨ:
ਜਦੋਂ ਤੁਸੀਂ Director ਵਰਤਦੇ ਹੋ, ਤੁਸੀਂ AI ਤੋਂ ਇੱਕ ਉੱਤਰ ਨਹੀਂ ਮੰਗਦੇ—ਤੁਸੀਂ ਐਸੇ ਵਿਕਲਪ ਮੰਗਦੇ ਹੋ ਜੋ ਤੁਹਾਡੇ ਪਾਬੰਦੀਆਂ ਦੇ ਅਨੁਕੂਲ ਹੋਣ, ਫਿਰ ਚੁਣਦੇ ਹੋ।
Editor AI ਆਉਟਪੁੱਟ ਨੂੰ ਇੱਕ ਤਰਤੀਬਯੁਕਤ ਉਤਪਾਦ ਵਿੱਚ ਬਦਲਦਾ ਹੈ। ਇੱਥੇ ਮਨੁੱਖੀ ਨਿਰਣੇ ਸਭ ਤੋਂ ਜ਼ਿਆਦਾ ਮਾਹਤਵਪੂਰਨ ਹੁੰਦੇ ਹਨ: ਸੰਗਤਤਾ, ਐਜ-ਕੇਸ, ਨਾਮਕਰਨ, ਸਫਾਈ, ਅਤੇ ਕੀ ਕੋਡ ਵਾਸਤਵ ਵਿੱਚ ਇਰਾਦੇ ਨਾਲ ਮਿਲਦਾ ਹੈ।
ਇੱਕ ਵਰਤੋਂਯੋਗ ਮਨੋਭਾਵ: AI ਸੁਝਾਅ ਨੂੰ ਇੱਕ ਤੇਜ਼ ਜੂਨੀਅਰ ਟੀਮ-ਮੇਟ ਦੇ ਡਰਾਫਟ ਵਜੋਂ ਲਵੋ। ਤੁਹਾਨੂੰ ਅਜੇ ਵੀ ਅਨੁਮਾਨ ਚੈੱਕ ਕਰਨੇ ਪੈਣਗੇ, ਪੁੱਛਣਾ ਹੈ "ਅਸੀ ਕੀ ਭੁੱਲੇ?", ਅਤੇ ਪੱਕਾ ਕਰਨਾ ਹੈ ਕਿ ਇਹ ਸਿਸਟਮ ਦੇ ਬਾਕੀ ਹਿੱਸੇ ਨਾਲ ਫਿੱਟ ਹੋਵੇ।
Implementer ਭੂਮਿਕਾ ਉਹ ਜਿੱਥੇ AI ਚਮਕਦਾ ਹੈ: ਬੋਇਲਰਪਲੇਟ ਬਣਾਉਣਾ, ਐਂਡਪਾਇੰਟ ਜੁੜਨਾ, ਟੈਸਟ ਲਿਖਣਾ, ਭਾਸ਼ਾਵਾਂ ਦਰਮਿਆਨ ਅਨੁਵਾਦ ਕਰਨਾ, ਜਾਂ ਤੇਜ਼ੀ ਨਾਲ ਕਈ ਰਸਤੇ ਪੇਸ਼ ਕਰਨਾ।
AI ਦੀ ਸਭ ਤੋਂ ਵੱਧ ਮੁੱਲ ਗਤੀ ਅਤੇ ਵਿਸ਼ਾਲਤਾ ਹੈ—ਪੈਟਰਨ ਸੁਝਾਓ, ਖਾਲੀ ਥਾਵਾਂ ਭਰੋ, ਅਤੇ ਦੁਹਰਾਅ ਵਾਲਾ ਕੰਮ ਕਰੋ ਜਦੋਂ ਕਿ ਤੁਸੀਂ ਸਟੀਅਰਿੰਗ-ਵ ਜਿੰਮੇਵਾਰ ਹੋ।
ਭਾਵੇਂ AI ਨੇ 80% ਲਾਈਨਾਂ ਲਿਖੀਆਂ ਹੋਣ, ਨਤੀਜੇ ਮਨੁੱਖੀ ਜ਼ਿੰਮੇਵਾਰੀ ਹੁੰਦੇ ਹਨ: ਸਹੀਤਾ, ਸੁਰੱਖਿਆ, ਪ੍ਰਾਈਵੇਸੀ, ਅਤੇ ਯੂਜ਼ਰ ਪ੍ਰਭਾਵ। ਇਸਨੂੰ ਆਪਣੇ ਵਰਕਫਲੋ ਵਿੱਚ ਸਪਸ਼ਟ ਬਣਾਓ—ਕੌਣ ਤਬਦੀਲੀਆਂ ਮਨਜ਼ੂਰ ਕਰਦਾ ਹੈ, ਕੌਣ ਸਮੀਖਿਆ ਕਰਦਾ ਹੈ, ਕੌਣ ਸ਼ਿਪ ਕਰਦਾ ਹੈ।
ਸਹਿਯੋਗ ਸਿਹਤਮੰਦ ਬਣਾਈ ਰੱਖਣ ਲਈ:
ਮਕਸਦ ਇਹ ਹੈ ਕਿ AI ਸੰਭਾਵਨਾਵਾਂ ਪੈਦਾ ਕਰੇ—ਅਤੇ ਤੁਸੀਂ ਦਿਸ਼ਾ, ਮਿਆਰ ਅਤੇ ਅੰਤਿਮ ਫੈਸਲਾ ਦਿਓ।
Vibe coding ਕੰਮ ਦੀ ਮੁੱਖ ਇਕਾਈ ਨੂੰ "ਫੀਚਰ ਖਤਮ ਹੋਇਆ" ਤੋਂ "ਅਗਲਾ ਛੋਟਾ ਕਦਮ ਸਾਬਤ ਹੋ ਗਿਆ" ਵਿਚ ਬਦਲ ਦਿੰਦਾ ਹੈ। ਇੱਕ ਵੱਡੇ ਪ੍ਰਾਂਪਟ ਦੀ ਥਾਂ ਜੋ ਹਰ ਐਜ-ਕੇਸ ਦੀ ਭਵਿੱਖਵਾਣੀ ਕਰਨ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰਦਾ ਹੈ, ਤੁਸੀਂ ਤੰਗ ਲੂਪਾਂ ਵਿੱਚ ਇਤਰੈਟ ਕਰੋ: ਪੁੱਛੋ, ਜੇਨਰੇਟ ਕਰੋ, ਟੈਸਟ ਕਰੋ, ਅਨੁਕੂਲ ਕਰੋ।
ਇੱਕ ਉਪਯੋਗੀ ਨਿਯਮ ਇਹ ਹੈ ਕਿ ਵੱਡੇ ਅਗਾਂਵੇ ਦੀ ਬੇਨਤੀ ਤੋਂ ਛੋਟੇ, ਟੈਸਟਯੋਗ ਇਨਕ੍ਰੀਮੈਂਟਾਂ ਵੱਲ ਵਧੋ। ਇੱਕ ਫੰਕਸ਼ਨ, ਇੱਕ ਐਂਡਪਾਇੰਟ, ਜਾਂ ਇੱਕ UI ਸਟੇਟ ਮੰਗੋ—ਨਾ ਕਿ ਪੂਰਾ ਮੋਡਿਊਲ। ਫਿਰ ਚਲਾਓ, ਪੜ੍ਹੋ, ਅਤੇ ਫੈਸਲਾ ਕਰੋ ਕਿ ਕੀ ਬਦਲਣਾ ਹੈ।
ਇਸ ਨਾਲ ਤੁਸੀਂ ਹਕੀਕਤ ਦੇ ਨੇੜੇ ਰਹਿੰਦੇ ਹੋ: ਫੇਲ ਹੋਏ ਟੈਸਟ, ਅਸਲ ਕੰਪਾਇਲ ਏਰਰਸ, ਅਤੇ ਨਿਰਪੱਖ UX ਮੁੱਦੇ ਗੈਸਵਰਕ ਨਾਲੋਂ ਵਧੀਆ ਮਾਰਗਦਰਸ਼ਨ ਦਿੰਦੇ ਹਨ।
ਮਾਈਕ੍ਰੋ-ਇਟਰੈਸ਼ਨ ਉਹ ਸਭ ਤੋਂ ਵਧੀਅਾ ਕੰਮ ਕਰਦੀ ਹੈ ਜਦੋਂ ਤੁਸੀਂ ਇਕ ਠੋਸ ਰਿਧਮ ਰੱਖਦੇ ਹੋ:
ਯੋਜਨਾ: ਅਗਲਾ ਇੰਕ੍ਰੀਮੈਂਟ ਅਤੇ ਸਫਲਤਾ ਮਾਪਦੰਡ ਪਰਿਭਾਸ਼ਤ ਕਰੋ।
ਕੋਡ: AI ਨੂੰ ਸਿਰਫ਼ ਉਹੀ ਬਣਾਉਣ ਲਈ ਕਹੋ ਜੋ ਯੋਜਨਾ ਨਾਲ ਮੇਲ ਖਾਂਦਾ ਹੋਵੇ।
ਤਸ਼ਦੀਕ: ਟੈਸਟ, ਲਿੰਟ ਚਲਾਓ ਅਤੇ ਤੇਜ਼ੀ ਨਾਲ ਇਕ ਪੜ੍ਹਨ ਕਰੇ।
ਸੁਧਾਰ: ਜੋ ਤੁਸੀਂ ਸਿੱਖਿਆ ਉਸ ਅਧਾਰ 'ਤੇ ਯੋਜਨਾ ਅੱਪਡੇਟ ਕਰੋ।
ਜੇ ਤੁਸੀਂ ਯੋਜਨਾ ਕਦਮ ਛੱਡ ਦਿੰਦੇ ਹੋ, ਤਾਂ AI ਠੀਕ ਲੱਗਣ ਵਾਲਾ ਕੋਡ ਨਿਰਪੱਖ ਢੰਗ ਨਾਲ ਤੁਹਾਡੇ ਇਰਾਦੇ ਤੋਂ ਭਟਕ ਸਕਦਾ ਹੈ।
ਕੋਡ ਲਿਖਣ ਤੋਂ ਪਹਿਲਾਂ AI ਨੂੰ ਆਪਣਾ ਬਿਆਨ ਦੇਣ ਲਈ ਕਹੋ: ਇਹ ਅਸਪੱਸ਼ਟਤਾਵਾਂ ਨੂੰ ਪਹਿਲਾਂ ਉਜਾਗਰ ਕਰਦਾ ਹੈ: "ਕੀ ਅਸੀਂ ਖਾਲੀ ਸਤਰਾਂ ਨੂੰ ਮਿਸਿੰਗ ਮੰਨਾਂਗੇ?" "ਇਹ synchronous ਹੋਵੇਗਾ ਜਾਂ async?" "ਐਰਰ ਦਾ ਫਾਰਮੈਟ ਕੀ ਹੈ?" ਤੁਸੀਂ ਇੱਕ ਸੁਨੇਹੇ ਵਿੱਚ ਦੁਰੁਸਤ ਕਰ ਸਕਦੇ ਹੋ ਬਜਾਏ ਕਿ ਬਾਅਦ ਵਿੱਚ ਭੇਦ ਮਿਲਣਗਾ।
ਕਿਉਂਕਿ ਫੈਸਲੇ ਗੱਲਬਾਤ ਰਾਹੀਂ ਹੁੰਦੇ ਹਨ, ਇੱਕ ਹਲਕਾ ਫੁਲਕਾ ਚੇਨਜਲੌਗ ਰੱਖੋ: ਤੁਸੀਂ ਕੀ ਬਦਲਿਆ, ਕਿਉਂ ਬਦਲਿਆ, ਅਤੇ ਕੀ ਤੁਸੀਂ ਮੁਅੱਖਰ ਕੀਤਾ। ਇਹ ਤੁਹਾਡੇ PR ਦੀ ਵਰਣਨਾ ਵਿੱਚ ਇੱਕ ਛੋਟੀ ਸੈਕਸ਼ਨ ਜਾਂ ਇੱਕ ਸਧਾਰਨ ਨੋਟਸ ਫਾਈਲ ਹੋ ਸਕਦੀ ਹੈ। ਫਾਇਦਾ ਇਹ ਹੈ ਕਿ ਜਦੋਂ ਤੁਸੀਂ ਇੱਕ ਹਫਤੇ ਬਾਅਦ ਫੀਚਰ 'ਤੇ ਵਾਪਸ ਜਾਵੋਗੇ ਜਾਂ ਕਿਸੇ ਹੋਰ ਨੂੰ ਦੇਵੋਗੇ ਤਾਂ ਸਪਸ਼ਟਤਾ ਰਹੇਗੀ।
ਜੇ ਤੁਸੀਂ vibe-coding ਪਲੇਟਫਾਰਮ ਵਰਤ ਰਹੇ ਹੋ ਜਿਵੇਂ Koder.ai, ਤਾਂ "planning mode", "snapshots", ਅਤੇ "rollback" ਵਰਗੀਆਂ ਵਿਸ਼ੇਸ਼ਤਾਵਾਂ ਇਹ ਮਾਈਕ੍ਰੋ-ਇਟਰੈਸ਼ਨਾਂ ਨੂੰ ਸੁਰੱਖਿਅਤ ਬਣਾਉਂਦੀਆਂ ਹਨ: ਤੁਸੀਂ ਤੇਜ਼ੀ ਨਾਲ ਖੋਜ ਕਰ ਸਕਦੇ ਹੋ, ਚੈਕਪੋਇੰਟ ਬਣਾ ਸਕਦੇ ਹੋ, ਅਤੇ ਪ੍ਰਯੋਗਾਂ ਨੂੰ ਰੱਦ ਕਰ ਸਕਦੇ ਹੋ ਬਿਨਾਂ ਗਤੀ ਖੋਏ।
Vibe coding ਤਦੋਂ ਵਧੀਆ ਕੰਮ ਕਰਦਾ ਹੈ ਜਦੋਂ ਪ੍ਰਾਂਪਟ ਆਮ ਤੌਰ 'ਤੇ "ਮੈਨੂੰ ਇੱਕ ਫੰਕਸ਼ਨ ਲਿਖੋ" ਵਾਲੇ ਨਹੀਂ, ਪਰ "ਮੇਰੇ ਲਈ ਇੱਕ ਵਧੀਆ ਉਤਪਾਦ ਨਿਰਣਾ ਲੈਣ ਵਿੱਚ ਮਦਦ ਕਰੋ" ਵਾਲੇ ਲੱਗਦੇ ਹਨ। ਲੁਕਿਆ ਹੋਇਆ ਹੁਨਰ ਕੋਈ ਚਤੁਰ ਸਰਵਣੀ ਨਹੀਂ—ਇਹ ਇਹ ਹੈ ਕਿ ਤੁਸੀਂ ਸਫਲਤਾ ਨੂੰ ਸਪਸ਼ਟ ਬਣਾਉਂਦੇ ਹੋ।
ਸ਼ੁਰੂ ਵਿੱਚ ਉਸ ਸਥਿਤੀ ਨੂੰ ਦੱਸੋ ਜਿੱਥੇ ਕੋਡ ਰਹੇਗਾ: ਗੋਲ, ਯੂਜ਼ਰ, ਪਾਬੰਦੀਆਂ, ਅਤੇ ਗੈਰ-ਲਕੜੀਆਂ। ਇਸ ਨਾਲ ਮਾਡਲ ਨੂੰ ਤੁਹਾਡੇ ਲਈ ਅਣਚਾਹੇ ਅਨੁਮਾਨ ਭਰਨ ਤੋਂ ਰੋਕਦਾ ਹੈ।
ਉਦਾਹਰਨ:
ਇੰਪਲੀਮੈਂਟੇਸ਼ਨ ਤੱਕ ਫਸਣ ਤੋਂ ਪਹਿਲਾਂ, ਹਰ ਵਿਕਲਪ ਦੇ ਲਾਭ/ਨੁਕਸਾਨ ਮੰਗੋ। ਤੁਸੀਂ ਸਿਰਫ ਕੋਡ ਨਾਂਹ ਪੈਦਾ ਕਰ ਰਹੇ—ਤੁਸੀਂ ਟਰੇਡ-ਆਫ ਚੁਣ ਰਹੇ ਹੋ (ਗਤੀ vs ਮੁਰੰਮਤਯੋਗਤਾ, ਸਹੀਤਾ vs ਜਟਿਲਤਾ, ਇਕਸਪੈਠਤਾ vs ਨਵੀਂਨਤਾ)।
ਇੱਕ ਉਪਯੋਗੀ ਪ੍ਰਾਂਪਟ ਪੈਟਰਨ:
"ਮੈਨੂੰ 3 ਰਸਤੇ ਦਿਓ। ਹਰ ਇੱਕ ਲਈ: ਇਹ ਕਿਵੇਂ ਕੰਮ ਕਰਦਾ ਹੈ, ਲਾਭ, ਖਤਰੇ, ਕੀ ਮੈਨੂੰ ਪਰਖਣਾ ਪਵੇਗਾ। ਫਿਰ ਮੇਰੀ ਪਾਬੰਦੀਆਂ ਦੇ ਅਧਾਰ 'ਤੇ ਇੱਕ ਦੀ ਸਿਫਾਰਿਸ਼ ਕਰੋ।"
AI ਖੁਸ਼-ਪਾਥ ਉਤਪਾਦ ਬਣਾ ਸਕਦਾ ਹੈ। ਇਸ ਦਾ ਮੁਕਾਬਲਾ ਕਰਨ ਲਈ ਇਸਨੂੰ ਆਪਣੇ ਆਪ ਨੂੰ ਇੱਕ ਚੈੱਕਲਿਸਟ ਨਾਲ ਆਡਿਟ ਕਰਨ ਲਈ ਕਹੋ: ਐਜ-ਕੇਸ, ਐਰਰ ਸਟੇਟ, ਐਕਸੈਸਬਿਲਟੀ, ਅਤੇ ਪ੍ਰਦਰਸ਼ਨ। ਇਹ ਪ੍ਰਾਂਪਟਿੰਗ ਨੂੰ ਹਲਕਾ-ਫੁਲਕਾ ਉਤਪਾਦ QA ਬਣਾਉਂਦਾ ਹੈ।
ਪਹਿਲਾਂ ਘੱਟੋ-ਘੱਟ ਉਦਾਹਰਨ ਮੰਗੋ, ਫਿਰ ਵਧਾਓ। MVP → ਵੈਰੀਫਿਕੇਸ਼ਨ → ਪਾਲਿਸ਼. ਇਸ ਨਾਲ ਤੁਸੀਂ ਨਿਯੰਤਰਣ ਵਿੱਚ ਰਹਿੰਦੇ ਹੋ ਅਤੇ ਗਲਤੀਆਂ ਛੋਟੀ ਰਹਿੰਦੀਆਂ ਹਨ।
ਜਦੋਂ AI ਕੋਡ ਸੁਝਾਉਂਦਾ ਹੈ, ਇਹ ਮਹਿਸੂਸ ਹੁੰਦਾ ਹੈ ਕਿ ਤੁਸੀਂ "ਚੁਣ ਰਹੇ" ਹੋ ਨਾ ਕਿ "ਲਿਖ ਰਹੇ"। ਇਸੇ ਕਾਰਨ ਗੁਣਵੱਤਾ ਨਿਯੰਤਰਣ ਮਹੱਤਵਪੂਰਨ ਹੈ: ਸੁਝਾਇਆ ਗਿਆ ਕੋਡ ਸੰਜੀਦਾ, ਤੇਜ਼ ਅਤੇ ਬਿਲਕੁਲ ਗਲਤ ਵੀ ਹੋ ਸਕਦਾ ਹੈ।
ਜੇਨਰੇਟ ਕੀਤਾ ਕੋਡ ਇੱਕ ਤੇਜ਼ ਟੀਮ-ਮੇਟ ਦੇ ਪਹਿਲੇ ਪਾਸ ਵਜੋਂ ਹੈ। ਇਹ ਜ਼ਰੂਰੀ ਸਮਝੋ ਕਿ ਇਸ ਵਿੱਚ ਸੋਧ, ਤਸ਼ਦੀਕ, ਅਤੇ ਤੁਹਾਡੇ ਨਿਯਮਾਂ ਨਾਲ ਸੁਮੇਲ ਦੀ ਲੋੜ ਹੈ।
ਆਪਣੀ ਆਮ ਰਿਵਿਊ ਚੈਕਲਿਸਟ ਚਲਾਓ, ਭਾਵੇਂ ਤਬਦੀਲੀ ਛੋਟੀ ਹੋਵੇ:
ਜੇ ਕੋਡ ਪੜ੍ਹਨ ਵਿੱਚ ਮੁਸ਼ਕਲ ਹੈ, ਤਾਂ ਭਰੋਸੇਯੋਗ ਨਹੀਂ—ਅਤੇ ਸੁਭਾਲਣਾ ਵੀ ਮੁਸ਼ਕਲ।
ਕਿਸੇ ਚੀਜ਼ ਨੂੰ ਮਰਜ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ, AI ਨੂੰ ਸਧਾਰਨ-ਭਾਸ਼ਾ ਵਿੱਚ ਸਮਝਾਉਣ ਲਈ ਕਹੋ: ਕੋਡ ਕੀ ਕਰਦਾ ਹੈ, ਮੁੱਖ ਅਨੁਮਾਨ, ਅਤੇ ਜਿੰਨ੍ਹਾਂ ऐज-ਕੇਸ ਨੂੰ ਛੱਡ ਸਕਦਾ ਹੈ। ਜੇ ਸਮਝਾਉਣਾ ਢਿੱਲਾ ਹੈ, ਤਾਂ ਰੁਕੋ।
AI ਨੂੰ ਵਿਹਾਰ ਸਾਬਤ ਕਰਨ ਵਾਲੇ ਟੈਸਟ ਬਣਾਉਣ ਲਈ ਕਹੋ:
ਹਲਕੇ ਟੈਸਟ ਵੀ ਸੁਚਜਤਾ ਮਜ਼ਬੂਤ ਕਰਦੇ ਹਨ। ਜੇ ਤੁਸੀਂ ਇੱਨਾਂ ਨੂੰ ਟੈਸਟ ਨਹੀਂ ਕਰ ਸਕਦੇ, ਤਾਂ ਤੁਹਾਡਾ ਨਿਯੰਤਰਣ ਨਹੀਂ ਹੈ।
ਸੁਝਾਇਆ ਗਿਆ ਕੋਡ ਤਬ ਹੀ ਸਵੀਕਾਰ ਕਰੋ ਜਦੋਂ ਤੁਸੀਂ (1) ਇਸ ਨੂੰ سمجھਾ ਸਕੋ, (2) ਇਸ ਨੂੰ ਚਲਾ ਸਕੋ, ਅਤੇ (3) ਇਸ ਦੀ ਜाँच ਕਰ ਸਕੋ। ਗਤੀ ਕਮਾਲ ਦੀ ਹੈ—ਪਰ ਅਣਪਛਾਤੇ ਤਤਕਾਲੀ ਸ਼ਿਪਿੰਗ ਅਣਚਾਹੀ ਅਣਿਸ਼ਚਿਤਤਾ ਲਿਆ ਸਕਦੀ ਹੈ।
Vibe coding ਵਧੀਆ ਕੰਮ ਕਰਦਾ ਹੈ ਜਦੋਂ ਤੁਸੀਂ ਖੋਜ ਕਰ ਰਹੇ ਹੋ, ਪ੍ਰੋਟੋਟਾਈਪ ਕਰ ਰਹੇ ਹੋ, ਜਾਂ ਠੀਕ-ਥਾਂ ਪੈਟਰਨਾਂ 'ਤੇ ਇਤਰੈਟ ਕਰ ਰਹੇ ਹੋ। ਇਹ ਟੁੱਟ ਜਾਂਦਾ ਹੈ ਜਦੋਂ AI ਉਹ ਗੈਪ ਭਰਦਾ ਹੈ ਜੋ ਤੁਸੀਂ ਮੰਨ ਹੀ ਨਾ ਰਹੇ ਸੀ।
AI ਸੁਝਾਅ ਅਕਸਰ ਬੇ-ਆਵਾਜ਼ ਅਨੁਮਾਨ ਰੱਖਦੇ ਹਨ: ਕਿਹੜਾ ਡੇਟਾਬੇਸ, auth ਕਿਵੇਂ ਕੰਮ ਕਰਦਾ, "ਸਕ੍ਰਿਆ ਉਪਭੋਗਤਾ" ਦਾ ਕੀ ਅਰਥ, ਜਾਂ ਕਿਹੜੀ ਐਰਰ-ਹੈਂਡਲਿੰਗ ਮਨਜ਼ੂਰ ਹੈ। ਇਹ ਅਨੁਮਾਨ ਡਿਫ਼ ਵਿੱਚ ਸਮਝਦਾਰ ਲੱਗ ਸਕਦੇ ਹਨ—ਪਰ ਤੁਹਾਡੇ ਉਤਪਾਦ ਲਈ ਗਲਤ ਹੋ ਸਕਦੇ ਹਨ।
ਇਕ ਵਿਆਵਹਾਰਿਕ ਨਿਸ਼ਾਨ: ਜੇ ਕੋਡ ਵਿੱਚ ਅਜਿਹਾ ਕੁਝ ਨਵੇਂ ਆਇਆ ਜੋ ਤੁਸੀਂ ਨMention ਨਹੀਂ ਕੀਤਾ (ਕੋਈ cache, queue, ਜਾਂ ਨਵੀਂ ਲਾਇਬ੍ਰੇਰੀ), ਤਾਂ ਇਸਨੂੰ ਇੱਕ ਪਰਿਕਲਪਨਾ ਸਮਝੋ, ਨਾ ਕਿ ਨਿਸ਼ਚਿਤ ਉੱਤਰ।
ਮਾਡਲ ਕਿਸੇ API, ਫਲੈਗ, ਜਾਂ ਪੂਰੀ ਪদ্ধਤੀ ਦਾ ਖ਼ਿਆਲ ਢੰਗ ਨਾਲ ਬਣਾਉ ਸਕਦੇ ਹਨ—ਖਾਸ ਕਰਕੇ ਤੇਜ਼ੀ ਨਾਲ ਵਿਕਸਿਤ ਹੋ ਰਹੇ ਫਰੇਮਵਰਕਾਂ ਵਿੱਚ। ਇਹ ਆਵਾਜ਼ ਮਨੋֹਭਾਵੀ ਹੁੰਦੀ ਹੈ, ਜੋ ਟੀਮਾਂ ਨੂੰ ਕਪੜੇ ਕੱਢਣ ਵਾਲੀ ਕਥਾ ਦੇ ਸਕਦੀ ਹੈ।
ਰੌਕ-ਸਿੱਧੇ ਤਰੀਕੇ:
AI ਟੈਸਟ ਨੂੰ ਪਾਸ ਕਰਵਾ ਸਕਦਾ ਹੈ ਪਰ ਅਸਲ ਜ਼ਰੂਰਤਾਂ (ਐਕਸੈਸਬਿਲਟੀ, ਲੇਟੈਂਸੀ, ਐਜ-ਕੇਸ, ਜਾਂ ਬਿਜ਼ਨਸ ਨਿਯਮ) ਨੂੰ ਛੱਡ ਸਕਦਾ ਹੈ। ਟੈਸਟ ਪਾਸ ਕਰਨਾ ਸਿਰਫ਼ ਇਹ ਸਾਬਤ ਕਰਦਾ ਹੈ ਕਿ ਤੁਸੀਂ ਠੀਕ ਚੀਜ਼ ਟੈਸਟ ਕੀਤੀ।
ਜੇ ਤੁਸੀਂ ਕੋਈ ਸੰਦਰਭੀ ਪਹੁੰਚ ਵਿੱਚ ਬੇਸਿਤ ਤਾਂ ਦੋ-ਤੀਨ ਹੋਰ ਟੈਸਟ ਬਣਾਉਣੇ ਪਏ ਤਾਂ ਇੱਕ ਕਦਮ ਪਿੱਛੇ ਹੋ ਕੇ ਯੂਜ਼ਰ ਨਤੀਜੇ ਸਧਾਰਨ ਭਾਸ਼ਾ ਵਿੱਚ ਦੁਬਾਰਾ ਬਿਆਨ ਕਰੋ।
ਰੁਕੋ ਅਤੇ ਅਧਿਕਾਰਿਕ ਡੌਕਸ (ਜਾਂ ਮਨੁੱਖੀ ਮਾਹਿਰ) ਨਾਲ ਸਲਾਹ ਕਰੋ ਜਦੋਂ:
Vibe coding ਤੇਜ਼ ਗੱਲਬਾਤ ਹੈ—ਪਰ ਕੁਝ ਫੈਸਲੇ ਹਮੇਸ਼ਾਂ ਇਕ ਦਰਸਤੀ ਉੱਤਰ ਮੰਗਦੇ ਹਨ, ਨਾ ਕਿ ਸੁਚੱਜੀ ਅਨੁਸ਼ਾਝ।
Vibe coding ਬਹੁਤ ਸਾਰਾ ਸੋਚ-ਵਿਚਾਰ ਚੈਟ ਵਿਚ ਲਿਆਉਂਦਾ ਹੈ। ਇਹ ਲਾਭਦਾਇਕ ਹੈ—ਪਰ ਇਹ ਵੀ ਅਸਾਨ ਬਣਾਉਂਦਾ ਹੈ ਕਿ ਤੁਸੀਂ ਉਹ ਚੀਜ਼ ਪੇਸਟ ਕਰੋ ਜੋ ਆਮ ਤੌਰ 'ਤੇ ਪਬਲਿਕ ਨਹੀਂ ਕਰਦੇ।
ਇੱਕ ਸਧਾਰਣ ਨਿਯਮ: ਹਰ ਪ੍ਰਾਂਪਟ ਨੂੰ ਇਹ ਸਮਝ ਕੇ ਕੰਮ ਕਰੋ ਕਿ ਉਹ ਲੌਗ ਹੋ ਸਕਦਾ/ਸਮੀਖਿਆ ਕੀਤੀ ਜਾ ਸਕਦੀ/ਲੀਕ ਹੋ ਸਕਦੀ। ਤਾਂ ਵੀ ਜੇ ਤੁਹਾਡਾ ਟੂਲ ਪਰਾਈਵੇਸੀ ਦਾ ਵਾਅਦਾ ਕਰਦਾ ਹੈ, ਆਪਣੀਆਂ ਆਦਤਾਂ ਨੂੰ "ਅਕਸਿਡੈਂਟਲ ਸ਼ੇਅਰ ਹੋ ਸਕਦਾ ਹੈ" ਸਮਝੋ।
ਕੁਝ ਜਾਣਕਾਰੀਆਂ ਪ੍ਰਾਂਪਟ, ਸਕ੍ਰੀਨਸ਼ਾਟ ਜਾਂ ਲਾਗ ਵਿੱਚ ਕਦੇ ਵੀ ਨਹੀਂ ਭੇਜਣੀਆਂ:
ਸੰਦੇਹ ਹੋਵੇ ਤਾਂ ਮੰਨੋ ਕਿ ਇਹ ਸੰਵੇਦਨਸ਼ੀਲ ਹੈ ਅਤੇ ਹਟਾ ਦਿਓ।
ਤੁਸੀਂ ਅਸਲ ਡੇਟਾ ਨੂੰ ਨਿਖੇੜ ਕੇ ਵੀ ਮਦਦ ਲੈ ਸਕਦੇ ਹੋ। ਸੰਵੇਦਨਸ਼ੀਲ ਮੁੱਲਾਂ ਨੂੰ ਇੱਕ ਸਮਰਥਿਤ placeholder ਨਾਲ ਬਦਲੋ ਤਾਂ ਕਿ ਮਾਡਲ ਢਾਂਚੇ ਬਾਰੇ ਸੋਚ ਸਕੇ।
ਉਦਾਹਰਨ:
API_KEY=REDACTEDuser_email=<EMAIL>customer_id=<UUID>s3://<BUCKET_NAME>/<PATH>ਲਾਗਾਂ ਨੂੰ ਸਾਂਝਾ ਕਰਦੇ ਸਮੇਂ ਹੈਡਰ, ਕਵੇਰੀ ਸਟਰਿੰਗ ਅਤੇ ਪੇਲੋਡ ਹਟਾਓ। ਕੋਡ ਸਾਂਝਾ ਕਰਨ ਵਕਤ, ਕ੍ਰੈਡੇਂਸ਼ੀਅਲ ਅਤੇ environment configs ਹਟਾ ਕੇ ਸਿਰਫ਼ ਘੱਟੋ-ਘੱਟ ਸ్నਿੱਪੈਟ ਦਿਓ ਜੋ ਮੁੱਦੇ ਨੂੰ ਦੁਹਰਾਉਂਦਾ ਹੋਵੇ।
AI ਸੁਝਾਅ ਲੋਕ-ਜਨਤਾ ਉਦਾਹਰਨਾਂ ਵਰਗੇ ਕੋਡ ਸ਼ਾਮਲ ਕਰ ਸਕਦਾ ਹੈ। ਹਰ ਉਹ ਚੀਜ਼ ਜੋ ਤੁਸੀਂ ਨਹੀਂ ਲਿਖੀ, ਉਹ ਸੰਭਵਤ: "ਬੋਰੋ ਕੀਤੀ" ਹੋ ਸਕਦੀ ਹੈ। ਕਾਰਗਰ ਨਿਯਮ:
ਇਸਨੂੰ ਇੰਨਾ ਛੋਟਾ ਰੱਖੋ ਕਿ ਲੋਕ ਇਸਨੂੰ ਮਨ ਲੈਣ:
ਇੱਕ ਪੰਨਾ ਕਾਫੀ ਹੈ। ਲਕੜੀ ਇਹ ਹੈ ਕਿ vibe coding ਨੂੰ ਤੇਜ਼ ਰੱਖੋ—ਪਰ ਰਫਤਾਰ ਨੂੰ ਜੋਖਿਮ ਬਣਨ ਨਾ ਦਿਓ।
Vibe coding ਸਭ ਤੋਂ ਵਧੀਆ ਉਸ ਵੇਲੇ ਕੰਮ ਕਰਦਾ ਹੈ ਜਦੋਂ ਮਨੁੱਖ "ਪਾਇਲਟ ਸੀਟ" 'ਤੇ ਰਹਿੰਦੇ ਹਨ ਅਤੇ AI ਨੂੰ ਤੇਜ਼, ਬੋਲੇ-ਬੋਲਣ ਵਾਲਾ ਸਹਾਇਕ ਮੰਨਿਆ ਜਾਂਦਾ ਹੈ। ਫਰਕ ਅਕਸਰ ਮਾਡਲ ਨਹੀਂ—ਇਹ ਸੰਚਾਰ ਦੀਆਂ ਆਦਤਾਂ ਹੁੰਦੀਆਂ ਹਨ ਜੋ ਭਟਕਾਅ, ਚੁਪਚਾਪ ਅਨੁਮਾਨ ਅਤੇ ਅਕਸਮਾਤ ਸਕੋਪ ਵਧਾਉਣ ਨੂੰ ਰੋਕਦੀਆਂ ਹਨ।
ਹਰੇਕ ਚੈਟ ਜਾਂ ਸੈਸ਼ਨ ਨੂੰ ਇੱਕ ਛੋਟੇ ਪ੍ਰੋਜੈਕਟ ਵਾਂਗ ਵਰਤੋ। ਇੱਕ ਸਾਫ਼ ਉਦੇਸ਼ ਤੇ ਸੀਮਾ ਨਾਲ ਸ਼ੁਰੂ ਕਰੋ। ਜੇ ਟੀਚਾ ਬਦਲਦਾ ਹੈ, ਨਵਾਂ ਥ੍ਰੈਡ ਸ਼ੁਰੂ ਕਰੋ ਤਾਂ ਕਿ ਸੰਦਰਭ ਧੁੰਦਲਾ ਨਾ ਹੋਵੇ।
ਉਦਾਹਰਨ: "ਸਾਈਨਅਪ ਫਾਰਮ ਲਈ client-side ਵੈਲਿਡੇਸ਼ਨ ਜੋੜੋ—ਕੋਈ backend ਬਦਲਾਅ ਨਹੀਂ." ਇਹ ਵਾਕ ਇੱਕ ਸਾਫ਼ ਸਫਲਤਾ ਸਥਿਤੀ ਤੇ ਰੁਕਾਅ ਦੀ ਲਕੀਰ ਦਿੰਦਾ ਹੈ।
ਕਿਸੇ ਵੀ ਮਹੱਤਵਪੂਰਨ ਕਦਮ ਤੋਂ ਬਾਅਦ—ਪਹੁੰਚ ਚੁਣਨ, ਕੰਪੋਨੈਂਟ ਅਧਿਕਤਮ ਸਥਿਤੀ ਬਦਲਣ, ਜਾਂ ਡਿਪੈਂਡੈਂਸੀ ਤਬਦੀਲ ਕਰਨ—ਦੋ-ਤੋਂ ਚਾਰ ਲਾਈਨਾਂ ਦਾ ਸੰਖੇਪ ਲਿਖੋ। ਇਹ ਇਰਾਦਾ ਲਾਕ ਕਰਦਾ ਹੈ ਅਤੇ ਗੱਲਬਾਤ ਨੂੰ ਭਟਕਣ ਤੋਂ ਰੋਕਦਾ ਹੈ।
ਇੱਕ ਸਰਲ ਸੰਖੇਪ ਇਹ ਜਵਾਬ ਦਿੰਦਾ:
ਮਰਜ ਕਰਨ ਤੋਂ (ਜਾਂ ਕੰਮ ਬਦਲਣ ਤੋਂ) ਪਹਿਲਾਂ, ਇਕ ਸੰਰਚਿਤ ਰਿਕੈਪ ਦੀ ਮੰਗ ਕਰੋ। ਇਹ ਇੱਕ ਨਿਯੰਤਰਣ ਯੰਤਰ ਹੈ: ਇਹ AI ਨੂੰ ਚੁਪਚਾਪ ਅਨੁਮਾਨ ਉਜਾਗਰ ਕਰਨ ਲਈ ਮਜ਼ਬੂਰ ਕਰਦਾ ਹੈ ਅਤੇ ਤੁਹਾਨੂੰ ਇੱਕ ਚੈੱਕਲਿਸਟ ਦਿੰਦਾ ਹੈ ਜਿਸਨੂੰ ਤੁਸੀਂ ਵੈਰੀਫਾਈ ਕਰ ਸਕਦੇ ਹੋ।
ਮੰਗੋ:
ਜੇ AI ਸੁਝਾਅ ਨੇ ਕੋਡ 'ਤੇ ਅਸਰ ਕੀਤਾ, ਤਾਂ "ਕਿਉਂ" ਨੂੰ "ਕੀ" ਦੇ ਨੇੜੇ ਰੱਖੋ। ਪ੍ਰਮੁੱਖ ਪ੍ਰਾਂਪਟ ਅਤੇ ਆਉਟਪੁੱਟ PR ਜਾਂ ਟਿਕਟਾਂ ਦੇ ਨਾਲ ਰੱਖੋ ਤਾਂ ਕਿ ਸਮੀਖਿਆਕਾਰ ਇਰਾਦਾ ਸਮਝ ਸਕਣ ਤੇ ਬਾਅਦ ਵਿੱਚ ਤਰਕ ਨੂੰ ਦੁਹਰਾਉਂ ਸਕਣ।
ਇੱਕ ਹਲਕਾ ਟੇਮਪਲੇਟ ਜੋ ਤੁਸੀਂ PR ਵੇਰਣ ਵਿੱਚ ਪੇਸਟ ਕਰ ਸਕਦੇ ਹੋ:
Goal:
Scope boundaries:
Key prompts + summaries:
Recap (files/commands/assumptions):
Verification steps:
ਇਹ ਤਰੀਕੇ ਤੁਹਾਨੂੰ ਹੌਲੀ ਨਹੀਂ ਕਰਦੇ—ਉਹ ਦੁਹਰਾਅ ਰੋਕਦੇ ਹਨ ਅਤੇ ਗੱਲਬਾਤ ਨੂੰ ਆਡੀਟਯੋਗ, ਸਮੀਖਿਆਯੋਗ ਅਤੇ ਮਨੁੱਖੀ ਰੱਖਦੇ ਹਨ।
Vibe coding ਸਿੱਖਣ ਨੂੰ "ਪਹਿਲਾਂ ਪੜ੍ਹੋ, ਫਿਰ ਬਣਾਓ" ਤੋਂ "ਬਣਾਓ, ਫਿਰ ਜੋਜ਼ੋ ਕਿ ਕੀ ਹੋਇਆ" ਵਿੱਚ ਬਦਲ ਦਿੰਦਾ ਹੈ। ਇਹ ਇੱਕ ਸუპਰਪਾਵਰ ਹੋ ਸਕਦਾ ਹੈ—ਜਾਂ ਫੈਸਲਾ—ਇਹ ਟੀਮ ਮਾਪਦੰਡਾਂ 'ਤੇ ਨਿਰਭਰ ਕਰਦਾ ਹੈ।
ਜੂਨੀਅਰ ਡਿਵੈਲਪਰਾਂ ਲਈ ਸਭ ਤੋਂ ਵੱਡਾ ਫਾਇਦਾ ਫੀਡਬੈਕ ਦੀ ਰਫਤਾਰ ਹੈ। ਰਿਵਿਊ ਸਾਇਕਲ ਦੀ ਉਡੀਕ ਕਰਨ ਦੀ ਥਾਂ ਉਹ ਤੁਰੰਤ ਉਦਾਹਰਨ, ਵਿਕਲਪ ਅਤੇ ਸਧਾਰਨ-ਭਾਸ਼ਾ ਸਮਝ ਮੰਗ ਸਕਦੇ ਹਨ।
ਚੰਗੀ ਵਰਤੋਂ ਇਸ ਤਰ੍ਹਾਂ ਦਿਖਦੀ ਹੈ: ਇੱਕ ਛੋਟਾ ਸਨਿੱਪੇਟ ਬਣਾਓ, ਪੁੱਛੋ ਕਿ ਕਿਉਂ ਇਹ ਕੰਮ ਕਰਦਾ, ਫਿਰ ਆਪਣੇ ਸ਼ਬਦਾਂ ਅਤੇ ਕੋਡ ਵਿੱਚ ਦੁਹਰਾਓ। ਖ਼ਤਰਾ ਇਹ ਹੈ ਕਿ ਉਹ ਅੰਤਿਮ ਕਦਮ ਛੱਡ ਦੇਣ ਅਤੇ ਸੁਝਾਅ ਨੂੰ ਜਾਦੂ ਸਮਝ ਲੈਣ। ਟੀਮਾਂ ਸਿੱਖਣ ਨੂੰ ਪ੍ਰੋਤਸਾਹਿਤ ਕਰ ਸਕਦੀਆਂ ਹਨ ਕਿ PRs ਵਿੱਚ ਇੱਕ ਛੋਟੀ "ਮੈਂ ਕੀ ਬਦਲਿਆ ਅਤੇ ਕਿਉਂ" ਨੋਟ ਦੇਣੀ ਲਾਜ਼ਮੀ ਹੋਵੇ।
ਸੀਨੀਅਰ ਇੰਜੀਨੀਅਰਾਂ ਨੂੰ ਸਭ ਤੋਂ ਵੱਧ ਫਾਇਦਾ ਬੋਇਲਰਪਲੇਟ ਅਤੇ ਵਿਕਲਪ-ਖੋਜ 'ਤੇ ਹੁੰਦਾ ਹੈ। AI ਤੇਜ਼ੀ ਨਾਲ ਟੈਸਟ ਸਕੈਫੋਲਡ ਕਰ ਸਕਦਾ, glue ਕੋਡ ਜੋੜ ਸਕਦਾ, ਜਾਂ ਤੁਲਨਾਤਮਕ ਡਿਜ਼ਾਈਨਾਂ ਸੁਝਾ ਸਕਦਾ। ਇਸ ਨਾਲ ਸੀਨੀਅਰਜ਼ ਵੱਧ ਸਮਾਂ ਆਰਕੀਟੈਕਚਰ, ਐਜ-ਕੇਸ ਅਤੇ ਕੋਚਿੰਗ ਲਈ ਬਚਾਉਂਦੇ ਹਨ।
Mentorship بھی ਜ਼ਿਆਦਾ ਸੰਪਾਦਕੀ ਬਣ ਜਾਂਦੀ ਹੈ: ਜੂਨੀਅਰਾਂ ਦੇ ਪੁੱਛੇ ਗਏ ਸਵਾਲ, ਪ੍ਰਾਂਪਟਾਂ ਦੇ ਅੰਦਰ ਅਨੁਮਾਨ, ਅਤੇ ਚੁਣੇ ਟਰੇਡ-ਆਫਸ ਦੀ ਸਮੀਖਿਆ ਕਰਨ 'ਤੇ ਧਿਆਨ ਦਿੱਤਾ ਜਾਂਦਾ ਹੈ—ਸਿਰਫ਼ ਆਖ਼ਰੀ ਕੋਡ ਨਹੀਂ।
ਜੇ ਲੋਕ diffs ਨੂੰ ਧਿਆਨ ਨਾਲ ਪੜ੍ਹਨਾ ਛੱਡ ਦਿੰਦੇ ਕਿਉਂਕਿ "ਮਾਡਲ ਸ਼ਾਇਦ ਠੀਕ ਹੈ", ਤਾਂ ਸਮੀਖਿਆ ਦੀ ਗੁਣਵੱਤਾ ਘਟਦੀ ਹੈ ਅਤੇ ਸਮਝ ਪਤਲੀ ਹੋ ਜਾਂਦੀ ਹੈ। ਸਮੇਂ ਦੇ ਨਾਲ, ਡੀਬੱਗਿੰਗ ਹੌਲੀ ਹੋ ਜਾਦੀ ਹੈ ਕਿਉਂਕਿ ਘੱਟ ਲੋਗ ਪਹਿਲੇ ਸਿਧਾਂਤ ਤੋਂ ਕਾਰਨ ਨੂੰ ਸਮਝ ਸਕਦੇ।
ਇੱਕ ਸਿਹਤਮੰਦ ਨਿਯਮ ਇਹ ਹੈ: AI ਸਿੱਖਣ ਨੂੰ ਤੇਜ਼ ਕਰਦਾ ਹੈ, ਸਮਝ ਨੂੰ ਨਹੀਂ ਬਦਲਦਾ। ਜੇ ਕੋਈ ਬਦਲਾਅ ਕਿਸੇ ਵਿਅਕਤੀ ਵੱਲੋਂ ਸਮਝ ਨਹੀਂ ਸਕਿਆ ਤਾਂ ਇਹ ਸ਼ਿਪ ਨਹੀਂ ਹੁੰਦਾ—ਭਾਵੇਂ ਆਉਟਪੁੱਟ ਸਾਫ਼ ਕਿਉਂ ਨਾ ਲੱਗੇ।
Vibe coding ਤੇਜ਼ ਮਹਿਸੂਸ ਹੋ ਸਕਦਾ ਹੈ ਪਰ ਚੁਪਚਾਪ ਜੋਖਮ ਪੈਦਾ ਕਰ ਸਕਦਾ ਹੈ: ਅਸਪਸ਼ਟ ਇਰਾਦਾ, ਪਤਲੇ ਟੈਸਟ, ਜਾਂ ਉਹ ਤਬਦੀਲੀਆਂ ਜੋ "ਠੀਕ ਲੱਗਦੀਆਂ" ਹਨ ਪਰ ਨਹੀਂ ਹਨ। ਸਫਲਤਾ ਨੂੰ ਮਾਪਣਾ ਉਹ ਸੰਕੇਤ ਚੁਣਨਾ ਹੈ ਜੋ ਸਹੀਤਾ ਅਤੇ ਸਪਸ਼ਟਤਾ ਨੂੰ ਇਨਾਮ ਦਿੰਦੇ—ਸਿਰਫ ਰਫਤਾਰ ਨੂੰ ਨਹੀਂ।
AI ਤੋਂ ਹੱਲ ਮੰਗਣ ਤੋਂ ਪਹਿਲਾਂ, ਦੱਸੋ ਕਿ "ਡਨ" ਦਾ ਸਾਦਾ ਮਤਲਬ ਕੀ ਹੈ। ਇਹ ਗੱਲਬਾਤ ਨੂੰ ਨਤੀਜਿਆਂ ਨਾਲ ਜੋੜਦੀ ਹੈ ਨਾ ਕਿ ਨਿਰਦੇਸ਼ਾਂ ਨਾਲ।
ਉਦਾਹਰਨ acceptance criteria:
ਜੇ ਤੁਸੀਂ ਸਫਲਤਾ ਨੁੰ ਕਿਸੇ ਕਲਾਸ, ਫਰੇਮਵਰਕ ਜਾਂ ਫੰਕਸ਼ਨ ਦਾ ਜ਼ਿਕਰ ਕੀਤੇ ਬਿਨਾਂ ਨਹੀਂ ਬਿਆਨ ਕਰ ਸਕਦੇ, ਤਾਂ ਸ਼ਾਇਦ ਤੁਸੀਂ ਪਹਿਲਾਂ ਹੀ ਕੋਡ ਸੁਝਾਅ ਸौंਪਣ ਲਈ ਤਿਆਰ ਨਹੀਂ ਹੋ।
ਜਦੋਂ ਕੋਡ ਸੁਝਾਇਆ ਗਿਆ ਹੋਵੇ, ਆਟੋਮੇਟਿਡ ਚੈਕਸ ਤੁਹਾਡੀ ਪਹਿਲੀ ਲਾਈਨ ਆਫ਼ ਸਚ ਹੈ। ਇੱਕ "ਚੰਗਾ" vibe-coding ਵਰਕਫਲੋ ਹੌਲੀ-ਹੌਲੀ ਉਨ੍ਹਾਂ ਬਦਲਾਵਾਂ ਦਾ ਹਿੱਸਾ ਵਧਾਉਂਦਾ ਹੈ ਜੋ ਪਹਿਲੀ ਜਾਂ ਦੂਜੇ ਇਤਰੈਸ਼ਨ 'ਤੇ ਚੈਕਸ ਪਾਸ ਕਰ ਲੈਂਦੇ ਹਨ।
ਆਮ ਚੈੱਕਸ:
ਜੇ ਇਹ ਟੂਲਸ ਨਹੀਂ ਹਨ ਤਾਂ ਸਫਲਤਾ ਮੈਟ੍ਰਿਕਸ ਜ਼ਿਆਦਾਤਰ "ਵਾਇਬਜ਼" ਹੋਣਗੀਆਂ—ਅਤੇ ਉਹ ਸਮੇਂ ਦੇ ਨਾਲ ਟਿਕਣਗੀਆਂ ਨਹੀਂ।
ਉਪਯੋਗੀ ਇਸ਼ਾਰੇ ਟੀਮ ਆਦਤਾਂ ਅਤੇ ਉਤਪਾਦ স্থਿਰਤਾ ਵਿੱਚ ਦਿਖਦੇ ਹਨ:
ਜੇ PRs ਵੱਡੇ, ਜ਼ਿਆਦਾ ਮੁਸ਼ਕਲ ਜਾਂ "ਰਹੱਸਮਈ" ਹੋ ਰਹੇ ਹਨ, ਤਾਂ ਪ੍ਰਕਿਰਿਆ ਖਿਸਕ ਰਹੀ ਹੈ।
ਉਹ ਸ਼੍ਰੇਣੀਆਂ ਜੋ ਹਮੇਸ਼ਾਂ ਮਨੁੱਖੀ ਮਨਜ਼ੂਰੀ ਲੈਣੀਆਂ ਚਾਹੀਦੀਆਂ ਹਨ: auth, payments, data deletion, permissions, ਸੁਰੱਖਿਆ ਸੈਟਿੰਗ, ਅਤੇ ਕੋਰ ਬਿਜ਼ਨਸ ਲੌਜਿਕ। AI ਸੁਝਾ ਸਕਦਾ ਹੈ; ਮਨੁੱਖੀ ਯਕੀਨ ਕਰੇ ਕਿ ਇਰਾਦਾ ਤੇ ਜੋਖਿਮ ਸਟੀਕ ਹਨ।
"ਚੰਗਾ" ਇਸਦਾ ਮਤਲਬ ਹੈ ਕਿ ਟੀਮ ਤੇਜ਼ੀ ਨਾਲ ਭੇਜਦੀ ਹੈ ਅਤੇ ਅੱਤ ਰਹਿਣੀ ਨਿੰਦਰ ਨਹੀ ਕਰਦੀ—ਕਿਉਂਕਿ ਗੁਣਵੱਤਾ ਲਗਾਤਾਰ ਮਾਪੀ ਜਾਂਦੀ ਹੈ, ਮਨਾਂ ਨਹੀਂ।
Vibe coding ਸਭ ਤੋਂ ਵਧੀਆ ਉਸ ਸਮੇਂ ਕੰਮ ਕਰਦੀ ਹੈ ਜਦੋਂ ਤੁਸੀਂ ਇਸਨੂੰ ਇੱਕ ਹਲਕੇ-ਫੁਲਕੇ ਪ੍ਰੋਡਕਸ਼ਨ ਪ੍ਰਕਿਰਿਆ ਵਾਂਗ ਰੱਖਦੇ ਹੋ, ਨਾ ਕਿ ਕਿਸੇ ਚੈਟ ਜੋ "ਕਿਸੇ ਤਰ੍ਹਾਂ" ਸੌਫਟਵੇਅਰ ਬਣ ਜਾਵੇ। ਮਕਸਦ ਗੱਲਬਾਤ ਨੂੰ ਠੋਸ ਰੱਖਣਾ ਹੈ: ਛੋਟਾ ਸਕੋਪ, ਸਪਸ਼ਟ ਸਫਲਤਾ ਮਾਪਦੰਡ, ਅਤੇ ਤੇਜ਼ ਤਸ਼ਦੀਕ।
ਉਸ ਪ੍ਰੋਜੈਕਟ ਨੂੰ ਚੁਣੋ ਜੋ ਇੱਕ-ਦੋ ਦਿਨਾਂ ਵਿੱਚ ਖਤਮ ਹੋ ਸਕੇ: ਇੱਕ ਛੋਟਾ CLI ਟੂਲ, ਇੱਕ ਆਸਾਨ internal ਡੈਸ਼ਬੋਰਡ widget, ਜਾਂ CSV ਸਾਫ਼ ਕਰਨ ਵਾਲਾ ਸਕ੍ਰਿਪਟ।
ਡਨ ਦੀ ਪਰਿਭਾਸ਼ਾ ਉਹ ਨਤੀਜੇ ਸ਼ਾਮਲ ਕਰੇ ਜੋ ਨਿਰੀਖਣਯੋਗ ਹਨ (ਆਊਟਪੁੱਟ, ਐਰਰ ਕੇਸ, ਅਤੇ ਪ੍ਰਦਰਸ਼ਨ ਸੀਮਾਵਾਂ)। ਉਦਾਹਰਨ: "10k ਰੌਜ਼ 2 ਸਕਿੰਟ ਤੋਂ ਘੱਟ ਵਿੱਚ parse ਕਰੇ, malformed ਲਾਈਨਾਂ ਰੱਦ ਕਰੇ, ਇੱਕ summary JSON ਉਤਪਨੁ ਦੇਵੇ, ਅਤੇ 5 ਟੈਸਟ ਸ਼ਾਮਲ ਕਰਨ।"
ਇਕ ਦੋਹਰਾਏ ਜਾਣ ਵਾਲੇ ਢਾਂਚੇ ਨਾਲ drift ਘੱਟ ਹੁੰਦਾ ਹੈ ਅਤੇ ਸਮੀਖਿਆ ਆਸਾਨ ਹੁੰਦੀ ਹੈ.
Context:
- What we’re building and why
Constraints:
- Language/framework, style rules, dependencies, security requirements
Plan:
- Step-by-step approach and file changes
Code:
- Provide the implementation
Tests:
- Unit/integration tests + how to run them
ਜੇ ਤੁਸੀਂ ਪ੍ਰਾਂਪਟ ਢਾਂਚਾ ਬਾਰੇ ਗਹਿਰਾਈ ਚਾਹੁੰਦੇ ਹੋ ਤਾਂ ਆਪਣੀ ਟੀਮ ਲਈ ਇੱਕ ਰੈਫਰੰਸ ਪੇਜ਼ ਰੱਖੋ (ਉਦਾਹਰਨ: /blog/prompting-for-code)।
ਹਰ ਇਤਰੈਸ਼ਨ ਤੋਂ ਬਾਅਦ ਇਸਨੂੰ ਵਰਤੋ:
ਅਗਲੇ ਸਭ ਤੋਂ ਛੋਟੇ ਬਦਲਾਅ ਲਈ ਮੰਗ ਕਰੋ (ਇੱਕ ਫੰਕਸ਼ਨ, ਇੱਕ ਐਂਡਪਾਇੰਟ, ਇੱਕ ਰਿਫੈਕਟੋਰ)। ਹਰ ਕਦਮ ਤੋਂ ਬਾਅਦ ਟੈਸਟ ਚਲਾਓ, ਡਿਫ਼ਜ਼ ਸਕਿੰ, ਅਤੇ ਫਿਰੋਂ ਤੱਕ ਅਗਲਾ ਚਾਹੋ। ਜੇ ਬਦਲਾਵ ਵੱਧ ਜਾਵੇ, ਰੁੱਕੋ ਅਤੇ ਪਾਬੰਦੀਆਂ ਦੁਬਾਰਾ ਬਿਆਨ ਕਰੋ।
ਜੇ ਤੁਹਾਡਾ ਮਕਸਦ ਟੀਮ-ਵਿਆਪਕ ਦੁਹਰਾਅਯੋਗ ਵਰਕਫਲੋ ਬਣਾਉਣਾ ਹੈ ਤਾਂ ਉਹ ਟੂਲ ਸਹਾਇਕ ਹੁੰਦੇ ਹਨ ਜੋ ਗਾਰਡਰੇਲਸ ਨੂੰ ਬਿੱਲਟ-ਇਨ ਕਰਦੇ ਹਨ: Koder.ai, ਉਦਾਹਰਨ ਲਈ, ਚੈਟ-ਚਲਿਤ ਨਿਰਮਾਣ ਨੂੰ ਸੰਰਚਿਤ ਯੋਜਨਾਬੰਦੀ ਫਲੋ ਨਾਲ ਜੋੜਦਾ ਹੈ ਅਤੇ practical delivery ਫੀਚਰ ਜਿਵੇਂ ਸਰੋਤ ਨਿਰਯਾਤ ਅਤੇ deployment/hosting ਦਿੰਦਾ—ਤਾਂ ਜੋ "ਗੱਲਬਾਤ" runnable ਸੌਫਟਵੇਅਰ ਨਾਲ ਜੁੜੀ ਰਹੇ ਨਾ ਕਿ ਸਿਰਫ ਟੁਕੜਿਆਂ ਦਾ ਢੇਰ।
"Vibe coding" ਇੱਕ ਇੱਦਾ ਦੀ ਬਣਤਰ ਹੈ ਕਿ ਸੌਫਟਵੇਅਰ ਨੂੰ ਕਦਮ-ਬਦ-ਕਦਮ AI ਨਾਲ ਗੱਲਬਾਤ ਰਾਹੀਂ ਬਣਾਇਆ ਜਾਵੇ: ਤੁਸੀਂ ਮਕਸਦ ਅਤੇ ਪਾਬੰਦੀਆਂ ਦੱਸਦੇ ਹੋ, AI ਕੋਡ ਡ੍ਰਾਫਟ ਕਰਦਾ ਹੈ ਤੇ ਟਰੇਡ-ਆਫਸ ਦੱਸਦਾ ਹੈ, ਫਿਰ ਤੁਸੀਂ ਨਤੀਜਾ ਚਲਾਉਂਦੇ/ਜਾਂਚਦੇ/ਸੁਧਾਰਦੇ ਹੋ ਅਤੇ ਅਗਲਾ ਛੋਟਾ ਬਦਲਾਵ ਮੰਗਦੇ ਹੋ।
ਇਕ ਪ੍ਰਯੋਗਿਕ ਪਰਿਭਾਸ਼ਾ: prompts → code → verification → refinement, ਇਹ ਲੂਪ ਹੁੰਦਾ ਹੈ ਅਤੇ ਤੰਗ ਤੰਗ ਦੁਹਰਾਇਆ ਜਾਂਦਾ ਹੈ।
ਇੱਕ ਓਹ ਦਸਤਾਵੇਜ਼ (spec) ਪਹਿਲਾਂ ਸਾਰੇ ਅਸਪੱਬਦਾਂ ਨੂੰ ਦੂਰ ਕਰਨ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰਦਾ ਹੈ; vibe coding ਅਸਪੱਬਦ ਨੂੰ ਇੱਕ ਸਰੋਤ ਵਜੋਂ ਵਰਤਦਾ ਹੈ ਅਤੇ ਤੇਜ਼ੀ ਨਾਲ ਕੰਮ ਕਰਨ ਵਾਲਾ ਨਤੀਜਾ ਵੇਖ ਕੇ ਜ਼ਰੂਰਤਾਂ ਦੀ ਖੋਜ ਕਰਦਾ ਹੈ।
Vibe coding ਨੂੰ ਵਰਤੋ ਜਦੋਂ ਤੁਹਾਨੂੰ ਤੇਜ਼ ਪੜਤਾਲ ਚਾਹੀਦੀ ਹੋਵੇ (UI ਫਲੋ, ਇੰਟੇਗ੍ਰੇਸ਼ਨ, ਆਮ ਪੈਟਰਨ)। ਜਦੋਂ ਗਲਤ ਹੋਣ ਦੀ ਕੀਮਤ ਵੱਧ ਹੋਵੇ (ਪੇਮੈਂਟ, 퍼ਮਿਸ਼ਨ, ਕੰਪਲਾਇੰਸ) ਜਾਂ ਕਈ ਟੀਮਾਂ ਨੂੰ ਇੱਕ ਪੱਕਾ ਕਾਨਟਰੈਕਟ ਚਾਹੀਦਾ ਹੋਵੇ ਤਾਂ spec ਲਿਖੋ।
ਸ਼ੁਰੂ ਤੋਂ ਸ਼ੁਰੂ ਕਰੋ:
ਫਿਰ AI ਨੂੰ ਕੋਡ ਲਿਖਣ ਤੋਂ ਪਹਿਲਾਂ ਆਪਣੇ ਸ਼ਬਦਾਂ ਵਿੱਚ ਦੁਹਰਾਉਣ ਲਈ ਕਹੋ; ਕੋਈ ਭੁੱਲ ਦੁਰੁਸਤ ਕਰੋ ਤੁਰੰਤ।
ਹਰ ਇਤਰੈਸ਼ਨ ਨੂੰ ਛੋਟਾ ਅਤੇ ਟੈਸਟੇਬਲ ਰੱਖੋ:
"ਪੂਰਾ ਫੀਚਰ ਬਣਾਓ" ਵਰਗੇ ਬੜੇ ਪ੍ਰਾਂਪਟ ਤੱਕ ਨਾ ਜਾਓ ਜਦ ਤੱਕ ਤੁਸੀਂ ਪਤਲਾ ਟੁਕੜਾ ਸਾਬਤ ਨਾ ਕਰ ਲਵੋ।
ਇਹ ਤਿੰਨ "ਟੋਪੀਆਂ" ਵਰਤੋ:
ਭਾਵੇਂ AI ਜ਼ਿਆਦਾ ਲਾਈਨਾਂ ਲਿਖੇ, ਸੱਚਾਈ ਅਤੇ ਜੋਖਿਮ ਦੀ ਮਾਲਕੀ ਮਨੁੱਖੀ ਟੀਮ ਹੀ ਰੱਖਦੀ ਹੈ।
ਮੰਗੋ:
ਜੇ ਤੁਸੀਂ ਇੱਕ ਜਾਂ ਦੋ ਰਾਊਂਡਾਂ ਦੇ ਬਾਅਦ ਪੂਰੀ ਤਰ੍ਹਾਂ ਕੋਡ ਪਾਥ ਬਿਆਨ ਨਹੀਂ ਕਰ ਸਕਦੇ, ਤਾਂ ਪਹੁੰਚ ਆਸਾਨ ਕਰੋ ਜਾਂ ਸਧਾਰਨ ਰਸਤਾ ਲਓ।
ਇੱਕ ਤੇਜ਼ ਸਵੀਕਾਰਤਾ ਨਿਯਮ:
ਵਾਸਤਵਿਕ ਤੌਰ 'ਤੇ: ਹਰ ਮਹੱਤਵਪੂਰਨ ਬਦਲਾਵ ਲਈ ਕਮ-ਤੋਂ-ਕਮ ਇੱਕ ਆਟੋਮੇਟਿਡ ਚੈਕ (ਯੂਨਿੱਟ/ਇੰਟੀਗ੍ਰੇਸ਼ਨ ਟੈਸਟ, ਟਾਇਪਚੈਕ, ਜਾਂ ਲਿੰਟ) ਲਾਜ਼ਮੀ ਰੱਖੋ ਅਤੇ ਜਾਣੂ ਨਾ API ਨੂੰ ਅਧਿਕਾਰਿਕ ਡੌਕਸ ਨਾਲ ਤਨਾਖ਼ਾ ਕਰੋ।
ਅਕਸਰ ਗਲਤ ਹੋਣ ਵਾਲੀਆਂ ਜਗ੍ਹਾਂ:
ਅਜਿਹੀਆਂ ਨਵੀਆਂ ਚੀਜ਼ਾਂ (ਡਿਪੈਂਡੈਂਸੀ, cache, queue) ਨੂੰ ਇੱਕ ਪਰਿਕਲਪਨਾ ਮੰਨੋ ਤੇ ਇਸਦੀ ਪੁਸ਼ਟੀ ਮੰਗੋ।
ਨਾ ਭੇਜੋ:
ਜਦੋਂ ਸੰਦੇਹ ਹੋਵੇ ਤਾਂ ਸਮਝੋ ਕਿ ਉਹ ਸੰਵੇਦਨਸ਼ੀਲ ਹੈ ਅਤੇ ਹਟਾ ਦਿਓ।
ਸੰਕੇਤ ਜੋ ਅਸਲ ਸਫਲਤਾ ਨੂੰ ਦਰਸਾਉਂਦੇ ਹਨ:
ਉੱਚ ਪ੍ਰਭਾਵ ਵਾਲੇ ਖੇਤਰਾਂ (auth, payments, permissions, data deletion) ਲਈ ਇੱਕ ਮਨੁੱਖੀ ਸਾਇਨ-ਆਫ ਨਿਯਮ ਰੱਖੋ, ਭਾਵੇਂ AI ਨੇ ਡਰਾਫਟ ਕੀਤਾ ਹੋਵੇ।